Recently (in commit 7df4cfef8b ("rtc: Make rtc_time64_to_tm() support
dates before 1970")) the function rtc_time64_to_tm() was repaired for
times before 1970. This introduced two if blocks. Cassio Neri pointed
out that to be not neccessary and suggested an adaption that allows to
drop the two branch points again.
This is implemented here.
Also adapt the reference to the theoretical paper to link to the final
published article instead of the preprint on Cassio's request.
Suggested-by: Cassio Neri <cassio.neri@gmail.com>
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
Link: https://lore.kernel.org/r/20250613142405.253420-2-u.kleine-koenig@baylibre.com
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Amlogic C3 SoCs uses the same rtc controller as A5 SoCs. There is
no need for an extra compatible line in the driver, but add C3
compatible line for documentation.
Signed-off-by: Xianwei Zhao <xianwei.zhao@amlogic.com>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://lore.kernel.org/r/20250717-rtc-c3-node-v1-1-4f9ae059b8e6@amlogic.com
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
In using CONFIG_RTC_HCTOSYS, rtc_hctosys() will sync the RTC time to the
kernel time as long as rtc_read_time() succeeds. In some power loss
situations, our supercapacitor-backed DS1342 RTC comes up with either an
unpredictable future time or the default 01/01/00 from the datasheet.
The oscillator stop flag (OSF) is set in these scenarios due to the
power loss and can be used to determine the validity of the RTC data.
This change expands the oscillator stop flag (OSF) handling that has
already been implemented for some chips to the ds1341 chip (DS1341 and
DS1342 share a datasheet). This handling manages the validity of the RTC
data in .read_time and .set_time based on the OSF.
Signed-off-by: Meagan Lloyd <meaganlloyd@linux.microsoft.com>
Reviewed-by: Tyler Hicks <code@tyhicks.com>
Acked-by: Rodolfo Giometti <giometti@enneenne.com>
Link: https://lore.kernel.org/r/1749665656-30108-3-git-send-email-meaganlloyd@linux.microsoft.com
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
In using CONFIG_RTC_HCTOSYS, rtc_hctosys() will sync the RTC time to the
kernel time as long as rtc_read_time() succeeds. In some power loss
situations, our supercapacitor-backed DS1342 RTC comes up with either an
unpredictable future time or the default 01/01/00 from the datasheet.
The oscillator stop flag (OSF) is set in these scenarios due to the
power loss and can be used to determine the validity of the RTC data.
Some chip types in the ds1307 driver already have OSF handling to
determine whether .read_time provides valid RTC data or returns -EINVAL.
This change removes the clear of the OSF in .probe as the OSF needs to
be preserved to expand the OSF handling to the ds1341 chip type (note
that DS1341 and DS1342 share a datasheet).
Signed-off-by: Meagan Lloyd <meaganlloyd@linux.microsoft.com>
Reviewed-by: Tyler Hicks <code@tyhicks.com>
Acked-by: Rodolfo Giometti <giometti@enneenne.com>
Link: https://lore.kernel.org/r/1749665656-30108-2-git-send-email-meaganlloyd@linux.microsoft.com
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
drm-misc-fixes for v6.16-rc8/final?:
- Revert all uses of drm_gem_object->dmabuf to
drm_gem_object->import_attach->dmabuf.
- Fix amdgpu returning BIOS cluttered VRAM after resume.
- Scheduler hang fix.
- Revert nouveau ioctl fix as it caused regressions.
- Fix null pointer deref in nouveau.
- Fix unnecessary semicolon in ti_sn_bridge_probe.
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://lore.kernel.org/r/72235afd-c849-49fe-9cc1-2b1781abdf08@linux.intel.com
StarFive:
Sort properties on the MilkV Mars and add the power status LED to all
jh7110 boards.
AMD:
Add 64-bit Microblaze V cpu compatible.
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
-----BEGIN PGP SIGNATURE-----
iHUEABYIAB0WIQRh246EGq/8RLhDjO14tDGHoIJi0gUCaIDzhAAKCRB4tDGHoIJi
0oNSAQCPRdAfpwl0dAvQHgn0XRQ7H8pY0OmtaC40wHmqerM8uQD9F1aO3xF1H1IH
svhfV5mJrHXgn2s9q/yZYBSgm39P6w4=
=OCr5
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmiBRL8ACgkQmmx57+YA
GNmn7w//S7QJyThD8b9FWXr06EgPDxBoCzXsvRy7XItRTrq2XstrJ3qum7OngGUS
9HWO+6j0PFdgMwXJjupVRI/TcdsmHlNCW8lFp//nKpWkJL7J6aVQry+pGihgBzyt
0QExxfEaywM57bxvl6DMnBYtmUjuQ5Mlj0l0fp5iJuAMIgqWTsseLRyWC0BCw74v
Ms0Oy9kDqP9Cf9FThq6hSP3BPALwymKF/Mq1BhMp5DKbPd2Nb3DFbk3oNt2rWkI7
Kol1vlWMytI0doqt30UIaK9XLQ9qbAjdsypQVTkzVj+7eOo8Wu6g4ONbf7UaRwlC
SsQtEwBzBWmtTlBjKvcHZIDvbtMWFf9FZ8b/kVrWuD0C/Iow/fIrwwXta2ZCG6d9
6OjZpM9+R/CKElJ1M0FZ9IiAamIl8sCnkS92KE6eTO6os9HAL161l+Oh7PKqEEnw
VKN+E4fcrxcRt/kB/yDI2qrlzYLNiVZ7NaaAVsM9pIcNvooHkxM6kLmHfdpceyb5
9FzkaLAeDqL56PUz/6Q/xC7qYtjChd7ODBoZ0r6pGKQzGuEjOQtgDxIkhF/MIbTj
Kl8yd0ta2+IcHK3YCiKpGs02dQuv7P+LySmrmW0UPZbE04uTB4n+FUH1DPprPbms
H1bSrxmxcaWYSpkbIfCLVRa2ibnveapk2hTl3YO3ksiBWHW38bs=
=AHIz
-----END PGP SIGNATURE-----
Merge tag 'riscv-dt-for-v6.17' of https://git.kernel.org/pub/scm/linux/kernel/git/conor/linux into soc/dt
RISC-V Misc Devicetrees for v6.17
StarFive:
Sort properties on the MilkV Mars and add the power status LED to all
jh7110 boards.
AMD:
Add 64-bit Microblaze V cpu compatible.
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
* tag 'riscv-dt-for-v6.17' of https://git.kernel.org/pub/scm/linux/kernel/git/conor/linux:
dt-bindings: riscv: cpus: Add AMD MicroBlaze V 64bit compatible
riscv: dts: starfive: jh7110-common: add status power led node
riscv: dts: starfive: jh7110-milkv-mars sort properties
Link: https://lore.kernel.org/r/20250723-postage-skylight-597377b5f8e4@spud
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Tesla FSD and Google GS101 DTS are handled via Samsung SoC tree, so the
clean dtbs_check rule applies there as well - mention this in their
maintainer entries.
Also, include Tesla FSD DTS patterns in Samsung SoC tree to document how
the patches actually travel.
-----BEGIN PGP SIGNATURE-----
iQJEBAABCgAuFiEE3dJiKD0RGyM7briowTdm5oaLg9cFAmiAozgQHGtyemtAa2Vy
bmVsLm9yZwAKCRDBN2bmhouD1y2cD/9A3rfP9e3zVcZmZJUG01iWruAxoDiia0ZR
HfJ0YIfts0f4yO6YifU6VCkhK6slv2TL8W5+ghJ/8hm5M0BoAUrV0WHmb6l+iT5A
XAP8y4MtoX8qOVHAaqAiTtP7vGNlo7N7YsEZzyFYa7EVLSNHvPILpGuvZy9vfjzn
+6TDsxfSRAsmFrUg4nc+/Yv3PusZb6VpCUhKQpXMWxp+TzFLm8PTAxoBHp2Xf0pa
sW1FHVA/4RuEv5toR/FGAID3raM2gTZq2e3LUJd90ZUf+V4/0cwiGtGuW8piKUGM
cYW7pWDDZp7PfTnTNQmoHTU1ZwKjjGT73IPC35V9jaGqWw+1D4TyY+Iq5rfEl0f9
6/ynzDzONZourkgHWn3s5aHt0Ct7tVMDGM99rQ2ffmxAg+2qVPncnAb+6mDOrV7d
mgqWT6czUw7Hy0DQUrT0UPOsuOb0zvAm/Zcq1GSPPLerYYoEkowCFo6v5WG11lHc
ZWUSVPqpovdD6+2q4prbbghmMRExE3aKhKiIpgFrS1mxdCPjqjN72EIA+sUJB8iR
2fDhffF4f4Oi7NkerBQRoDS96fMquM5BIqI8yNrlhAfLdvqpyP3PLOhs3obS6eul
1qpjhinpvgB3YI1Cm5mD5+s+O+qfN9Ttf0jWl//YUT9Ck4Sut9ZVel3BDdQgbvay
DLm+f/N0lw==
=pE6c
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmiBRGAACgkQmmx57+YA
GNnuow/+IGX4x0jSZ6uOweaAbi7+FYmxylAS/PZBetFs8CZLHx+TSbNhN28li7CT
3oEnN+DgmHkn1XP2XgjN696p1s6/LZ9ghxlxjVS219Yb2QhY+u1ASabIaNR2ZJqB
n9k/8Rzb7jyOTS3VBweqW1hNluYQ3qWk5IGAJYohFpu3JVhgxti4V9C1+dhXGOBC
aXCaboPULTzhHEdp68aV4eesMBBGwj9Jm6vdC7QQ1IQpYIwI5wdtVNwEbE+8/1ly
A59z1CmXvu5rnBfhdkW2VP56AsjwuK0C3WWr15feZNGBa74Q0ceXdkLCxcj7f7Qx
Gk2U+PJIoTe+Xiaz7+1xhRCzKdPhUJGQtfq3vnkEHaAvGdqxb7DaldzNAlxHnxuf
5oWiIMLp3mkUMesyddzHH3eJ8irJvW7ccboD6B1CzpiSl+uKENe1Op505xAoQpCj
OjG/ROfMOB1GUcA6MJf6XtyDw75FCmcR/czYGEh4TP+tzDu5NC7RyFmmYIBuLr6c
K9DHl1FT7N0AxOURaQYQH5Pz1RM58W7Ao2T25nsgF2Nk9pN4+kvUrOVs8tU/qHUa
CNNj7DlIlaW9FXZUPxnkOecltHjllnrznDUomKloNVF4q6Q59f0YSdckGZKAhxJ5
Ts+dlEBUll0NDkvhJm6MCuqFCbBW4ehYH4jsM8E4bu+vZIqBukA=
=LpY0
-----END PGP SIGNATURE-----
Merge tag 'samsung-dt64-6.17-2' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux into soc/dt
Samsung DTS ARM64 changes for v6.17, part two
Tesla FSD and Google GS101 DTS are handled via Samsung SoC tree, so the
clean dtbs_check rule applies there as well - mention this in their
maintainer entries.
Also, include Tesla FSD DTS patterns in Samsung SoC tree to document how
the patches actually travel.
* tag 'samsung-dt64-6.17-2' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux:
arm64: samsung: MAINTAINERS: Add Tesla FSD DTS to Exynos entry
arm64: tesla/google: MAINTAINERS: Reference "SoC clean" maintainer profile
Link: https://lore.kernel.org/r/20250723090455.25295-4-krzysztof.kozlowski@linaro.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Sophgo:
Add support for Duo Module 01 Evaluation Board.
This board uses SG2000(old codename CV181xH),
which is dual-arch, RISC-V and ARM64. This
patch add the support for ARM64.
Signed-off-by: Chen Wang <unicorn_wang@outlook.com>
-----BEGIN PGP SIGNATURE-----
iQGzBAABCgAdFiEEdoBX2jyDC9ZCTwZjDCzASqG0i0IFAmiAiNIACgkQDCzASqG0
i0KaPgv/Zbe5hJ869PocVXmt1+lHnMMh6bTANXlZO4G3NcjBOvCWF9rZaqY7Tb0w
ekLbSTnhBqcwix62FxDuOubsgAGrj/r5ejnPkLI/Ksst+81DDcgtxmU4YHjV/M92
win6fsrS5LppqS7+6lGAhN0Uz48K07j9URW2JtollpH0GyrzNo1r4YwfkUA38X+b
e+Eia0bvz8KU1aKPLgmx+dk/qjhDvvlWjNrroVyJAkUYM5AofSSzneo2hgM6FA0k
1LYZRwLDpbaJjMnBvAFT2Dqg3Mr+84PyHb7d+58lV4BYOzkA/wM6DGuDqD61dt4K
+pxflhrZsXp+a9SjnY6oecGy1srKDPhX8l6mRdwt3ISAFJ/6nKTEXk36sO1T9atq
mfpwDwDklhVwpvmk9JAWeTCX/XMBgivVDdUE9sRTzBqPIlBtSVHjS8W7e5nExbv8
yovIIKE4OLKn40ubcYM8Km0L3XF6VpoNFlPkxwrXDyf7FVzdHTphz0aW8CXIO0dP
4W1vqUcP
=v6O6
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmiBQ8MACgkQmmx57+YA
GNmgUQ/+JJHLhDUdfI6abJSs42ZS7yue8DRbSYi/h3RDkj7LutwbrTrOZ7Dg0uom
txv2dUPtmW2DIvJkRrBfNeF9bMt9oh0/0cLuf9QL8mLWHaSg9aAwmBDbw8EaKCy1
iwxwAhRxDg1bF6eB0QDE0f2+wuBBiR2ymWcpLgHw3pZw1Ao7R8nvV0UvrxUKJaMa
8GpenYRnVrxHtwtSLS+eFQUvxFGb8SYdHxhZYL3U34XduugK3xNv2+KoFdQvro6R
vEMnpR6USo2mV4RW7GTwJkPmQ/w0fMZF806bPNu7KhrC3DLmVnU6YuBDopJYrPvU
babwfughoSn7cz733gDSPuzkoNkjXiCZLQW9wSv+gGgYHK6NpjtHfZGkEfcRpXT1
G9Yb/H948BtLM4FxenFh+5VEvp63giN3hTIw/0JauFWEu4rTmN6sMLT1ibLDeUZV
zIfItosgFF+EjuGqgruR8dJ9wKowIR9DY8MxhWQ5Wu1WNl+KKMtln/bFIu9hgvRi
0WqgqPr6Vq5buHKaqHAz0tj8dR7yxBZvDijQfzzb0xrLgBXx35c7aX1aKWdxWbYZ
Y29KQLxsvr0AWs0tafmQ42M0l03QAB1voACn25rIQaU4b4Tub9W18GkA0V6Mmjno
diqH51MQy1haCJRZUMEyAUnmtOXlRw685Jzy1z5BekUJIhTGQfg=
=SQbL
-----END PGP SIGNATURE-----
Merge tag 'arm-sophgo-dt-for-v6.17' of https://github.com/sophgo/linux into soc/newsoc
ARM Devicetrees for v6.17
Sophgo:
Add support for Duo Module 01 Evaluation Board.
This board uses SG2000(old codename CV181xH),
which is dual-arch, RISC-V and ARM64. This
patch add the support for ARM64.
Signed-off-by: Chen Wang <unicorn_wang@outlook.com>
* tag 'arm-sophgo-dt-for-v6.17' of https://github.com/sophgo/linux:
arm64: defconfig: Enable rudimentary Sophgo SG2000 support
arm64: Add SOPHGO SOC family Kconfig support
arm64: dts: sophgo: Add Duo Module 01 Evaluation Board
arm64: dts: sophgo: Add Duo Module 01
arm64: dts: sophgo: Add initial SG2000 SoC device tree
Link: https://lore.kernel.org/r/MAUPR01MB11072C4B088AAC02268044E95FE5FA@MAUPR01MB11072.INDPRD01.PROD.OUTLOOK.COM
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Sophgo:
For CV18xx serials:
There are three major changes. The first is to add the
RTCSYS MFD node, which provides rich control registers
for soc power management and other rich control functions;
the second is to add the reset controller node and add
related reset properties for other peripherals; the third
is to add ethernet controller related nodes to the soc
and enable ethernet device control for HuashanPi.
For SG2042:
There are three major changes. The first is to add ISA
extensions such as xtheadvector/ziccrse/zfh for cpu cores;
the second is add ethernet controller support; the third
is add two new boards EVB_V1 & EVB_V2 which use SG2042
SoC.
For SG2044:
There are many changes. The first is to add pmu
configuration; the second is to add ISA extensions
ziccrse and add missing riscv,cbop-block-size property
for cpu cores; the third is to add more peripherals
nodes for SoC after clock controller is ready, such as
MSI/PCIe/pwm/SPI-NOR etc. This PR also add HWMON MCU
device for the sophgo-srd3-10 board and reserve uart0
node for sophgo-srd3-10 board because uart0 is already
occupied by the firmware.
This PR also moves sophgo.yaml from the riscv directory
to soc/sophgo for sharing between riscv and arm. CV18xx
SoC contains a RISC-V big core and an ARM64 big core.
Moving sophgo.yaml to a shared location will help us
add support for ARM cores to the CV18xx chip in the future.
Signed-off-by: Chen Wang <unicorn_wang@outlook.com>
-----BEGIN PGP SIGNATURE-----
iQGzBAABCgAdFiEEdoBX2jyDC9ZCTwZjDCzASqG0i0IFAmiAhvwACgkQDCzASqG0
i0IyCgv/UwnfACCIfPEOH1jLNwJqP1iUmsy5zyrcwapIZJMTiOE5PpizFPwgplKq
CUBZJhIsfS9VjpUsiE8fslOezNrJHXRDK8uR5MCZQe/IGm46xnoxsAKVoLnjMbLR
SWBN2I20xaEDNptyWNw5PNJmEMs9PVcvutFvGdLFBTdL6X8gf21XwO3B/K/jUimE
S3eck5PAnUhvIV6uBxedi16FqPB5MD/4cwMnIJnwMiwWrmim0vLYKD1L7fzUbYu6
vPRwv5JZZJg9/1QE+pgLm90dJ36J4sg5CYmRaCmgq05gyd5XXd6GSbbpChjvqrWy
sUmZNKsiwA5+yZR972cc3Rjt0QKjn79v/eV/A4gSsyBRH6d3oc+KgDJl1ZttcVWu
G0Yq+HcLwJnVL9A5hIMJEHSQkzLplScxzcRk94ii2vFS6uHtzd0K8fG8G47E/i6j
qrMpczNHiHCijPxDIHXLdvUDmHpRSwp3isciwouvU35b+wsLHrMgEsnpGF/cmHUO
kuPXLk6p
=/XJ6
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmiBQ18ACgkQmmx57+YA
GNn9ABAAvCqpUHtM68k72FYDC4Xt312i8q1APdetj+f5vTQxNYemIkO5hTwv5Sbe
GJqXcfglFtQ52+B7IazfGG+CQr7srDOAjD7DLrhuZvuF+AZRuotnEnt1fF7xvtsz
EK0JqkCq1gnZJ+ZLLutotuU6708IULAEFIxszH8gedcBygdcogXKxYPWdqd6IDtB
djjrHrU1caL7ioo3yEYLIIh6fDZpjUeXeWutrWVdrXi97d8YvsAypFBGjmRZw0wf
yNmwuGHru4vi8woxe11r5117xV4mBHoFrkx7MvSbZmUXTN3gufbnMGenj2/DbsHJ
T/fP5nijTjJUeyj2NuudKQqTbOsqmz10SE7n/E3l5vlx9rm4dayWEFufXXOrPWgx
Hyd8vz151HkvzkhgokXIwiTvpSF3us0c2SmoskMeZm+gOWYw4amr4jujOHEF8yGt
uDcdmnaZnys1+PMCfHHYq6nrtSy5SNV9bedasPuI5qw/Tmdx2oZ+JrI9zqP9gwrS
rDVdLcChDhdxLRAPKM9jHu9mjDJWlxmG3WbjYbaTztWNKvT6tIArcIGX65VbyNDc
xqFOc7wXtN2ZbXhEvAvxODdYLksUrJNRwJhNdwhD8PTbLR70VC3yCLb8UNJCVqY8
vqKzd9jl9HaujDeHfas8BPIgaIZCkYRTRWG4gXTwC+ClA3EQeZs=
=up6v
-----END PGP SIGNATURE-----
Merge tag 'riscv-sophgo-dt-for-v6.17' of https://github.com/sophgo/linux into soc/dt
RISC-V Devicetrees for v6.17
Sophgo:
For CV18xx serials:
There are three major changes. The first is to add the
RTCSYS MFD node, which provides rich control registers
for soc power management and other rich control functions;
the second is to add the reset controller node and add
related reset properties for other peripherals; the third
is to add ethernet controller related nodes to the soc
and enable ethernet device control for HuashanPi.
For SG2042:
There are three major changes. The first is to add ISA
extensions such as xtheadvector/ziccrse/zfh for cpu cores;
the second is add ethernet controller support; the third
is add two new boards EVB_V1 & EVB_V2 which use SG2042
SoC.
For SG2044:
There are many changes. The first is to add pmu
configuration; the second is to add ISA extensions
ziccrse and add missing riscv,cbop-block-size property
for cpu cores; the third is to add more peripherals
nodes for SoC after clock controller is ready, such as
MSI/PCIe/pwm/SPI-NOR etc. This PR also add HWMON MCU
device for the sophgo-srd3-10 board and reserve uart0
node for sophgo-srd3-10 board because uart0 is already
occupied by the firmware.
This PR also moves sophgo.yaml from the riscv directory
to soc/sophgo for sharing between riscv and arm. CV18xx
SoC contains a RISC-V big core and an ARM64 big core.
Moving sophgo.yaml to a shared location will help us
add support for ARM cores to the CV18xx chip in the future.
Signed-off-by: Chen Wang <unicorn_wang@outlook.com>
* tag 'riscv-sophgo-dt-for-v6.17' of https://github.com/sophgo/linux: (32 commits)
riscv: dts: sophgo: fix mdio node name for CV180X
riscv: dts: sophgo: sophgo-srd3-10: reserve uart0 device
riscv: dts: sophgo: add Sophgo SG2042_EVB_V2.0 board device tree
riscv: dts: sophgo: add Sophgo SG2042_EVB_V1.X board device tree
dt-bindings: riscv: add Sophgo SG2042_EVB_V1.X/V2.0 bindings
riscv: dts: sophgo: add ethernet GMAC device for sg2042
riscv: dts: sophgo: Enable ethernet device for Huashan Pi
riscv: dts: sophgo: Add mdio multiplexer device for cv18xx
riscv: dts: sophgo: Add ethernet device for cv18xx
riscv: dts: sophgo: sg2044: add pmu configuration
riscv: dts: sophgo: sg2044: add ziccrse extension
riscv: dts: sophgo: add zfh for sg2042
riscv: dts: sophgo: add ziccrse for sg2042
riscv: dts: sophgo: Add xtheadvector to the sg2042 devicetree
riscv: dts: sophgo: sg2044: add PCIe device support for SG2044
riscv: dts: sophgo: sg2044: add MSI device support for SG2044
riscv: dts: sophgo: add reset configuration for Sophgo CV1800 series SoC
riscv: dts: sophgo: add reset generator for Sophgo CV1800 series SoC
dt-bindings: soc: sophgo: Move SoCs/boards from riscv into soc, add SG2000
riscv: dts: sophgo: sg2044: Add missing riscv,cbop-block-size property
...
Link: https://lore.kernel.org/r/MAUPR01MB1107297124C9DA0CD77DA3DC1FE5FA@MAUPR01MB11072.INDPRD01.PROD.OUTLOOK.COM
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
The ipi tracepoints are mostly generic, but the tracepoints ipi_raise,
ipi_entry and ipi_exit are only used by arm and arm64. This means these
trace events are wasting memory in all the other architectures that do not
use them.
Add CONFIG_HAVE_EXTRA_IPI_TRACEPOINTS and have arm and arm64 select it to
enable these trace events. The config makes it easy if other architectures
decide to trace these as well.
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: Will Deacon <will@kernel.org>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Valentin Schneider <vschneid@redhat.com>
Cc: Nicolas Pitre <nico@fluxnic.net>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: https://lore.kernel.org/20250722103714.64eba013@gandalf.local.home
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Trace events can take up to 5K each when they are defined, regardless if
they are used or not. The binder lock events: binder_lock, binder_locked
and binder_unlock are no longer used.
Remove them.
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: "Arve =?utf-8?b?SGrDuG5u?= =?utf-8?b?ZXbDpWc=?= " <arve@android.com>
Cc: Todd Kjos <tkjos@android.com>
Cc: Martijn Coenen <maco@android.com>
Cc: Joel Fernandes <joelagnelf@nvidia.com>
Cc: Christian Brauner <brauner@kernel.org>
Cc: Suren Baghdasaryan <surenb@google.com>
Link: https://lore.kernel.org/20250612093408.3b7320fa@batman.local.home
Fixes: a60b890f60 ("binder: remove global binder lock")
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
Acked-by: Carlos Llamas <cmllamas@google.com>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
While we don't have official CI SR-IOV coverage for the Tigerlake
platforms, we were using this platform for the feature enabling
and Xe driver already has all required changes to support it.
Since TGL platforms are guarded by the xe.require_force_probe flag
enable SR-IOV feature on them, like we recently did for ADL/ATSM.
Suggested-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://lore.kernel.org/r/20250722182618.30811-5-michal.wajdeczko@intel.com
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
We were already testing those two platforms for a while on our CI,
but enabling flag (has_sriov) was only available on the topic branch
and only for builds with CONFIG_DRM_XE_DEBUG config.
Since those two platforms are guarded by the another enabling flag
(require_force_probe) and we believe our SR-IOV support for them is
at sufficient level to start enjoying the feature, turn on the
SR-IOV enabling flag unconditionally.
Suggested-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://lore.kernel.org/r/20250722182618.30811-4-michal.wajdeczko@intel.com
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
We already claim official support for SR-IOV PF/VF modes on PTL
and BMG platforms, but by default we start the Xe driver on those
platforms in non-virtualized mode (native) since we still have
max_vfs modparam set to disable creation of the VFs.
It's time to let the Xe driver support SR-IOV PF mode by default.
We were already testing this on our CI, which was relying on the
patch that was enabling it for CONFIG_DRM_XE_DEBUG used by our CI.
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Thomas Hellstrom <thomas.hellstrom@linux.intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://lore.kernel.org/r/20250722182618.30811-3-michal.wajdeczko@intel.com
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Microcrystal RV8063 is a real-time clock with SPI interface. Its
functionality is very similar to the RV8263 rtc.
Signed-off-by: Antoni Pokusinski <apokusinski01@gmail.com>
Link: https://lore.kernel.org/r/20250413130755.159373-4-apokusinski01@gmail.com
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Move the i2c-specific code from pcf85063_probe to the newly created
function.
This is a preparation for introducing the support for RV8063 real-time
clock with SPI interface.
Signed-off-by: Antoni Pokusinski <apokusinski01@gmail.com>
Link: https://lore.kernel.org/r/20250413130755.159373-3-apokusinski01@gmail.com
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Microcrystal RV8063 is a real-time clock module with SPI interface.
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Antoni Pokusinski <apokusinski01@gmail.com>
Link: https://lore.kernel.org/r/20250413130755.159373-2-apokusinski01@gmail.com
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Replace devm_add_action() with devm_add_action_or_reset() to avoid
explicitly dropping the 'port->clk' reference in error path.
Signed-off-by: Salah Triki <salah.triki@gmail.com>
[mani: reworded commit subject and description]
Signed-off-by: Manivannan Sadhasivam <mani@kernel.org>
Link: https://patch.msgid.link/aHsgYALHfQbrgq0t@pc
Commit 8211dad627 ("s390: add pte_free_defer() for pgtables sharing
page") added a warning to pte_free_defer(), on our request. It was meant
to warn if this would ever be reached for KVM guest mappings, because
the page table would be freed w/o a gmap_unlink(). THP mappings are not
allowed for KVM guests on s390, so this should never happen.
However, it is possible that the warning is triggered in a valid case as
false-positive.
s390_enable_sie() takes the mmap_lock, marks all VMAs as VM_NOHUGEPAGE and
splits possibly existing THP guest mappings. mm->context.has_pgste is set
to 1 before that, to prevent races with the mm_has_pgste() check in
MADV_HUGEPAGE.
khugepaged drops the mmap_lock for file mappings and might run in parallel,
before a vma is marked VM_NOHUGEPAGE, but after mm->context.has_pgste was
set to 1. If it finds file mappings to collapse, it will eventually call
pte_free_defer(). This will trigger the warning, but it is a valid case
because gmap is not yet set up, and the THP mappings will be split again.
Therefore, remove the warning and the comment.
Fixes: 8211dad627 ("s390: add pte_free_defer() for pgtables sharing page")
Cc: <stable@vger.kernel.org> # 6.6+
Reviewed-by: Alexander Gordeev <agordeev@linux.ibm.com>
Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
Signed-off-by: Gerald Schaefer <gerald.schaefer@linux.ibm.com>
Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
Add 50ms disable delay for NV116WHM-N49, NV122WUM-N41, and MNC207QS1-1
to satisfy T9+T10 timing. Add 50ms disable delay for MNE007JA1-2
as well, since MNE007JA1-2 copies the timing of MNC207QS1-1.
Specifically, it should be noted that the MNE007JA1-2 panel was added
by someone who did not have the panel documentation, so they simply
copied the timing from the MNC207QS1-1 panel. Adding an extra 50 ms
of delay should be safe.
Fixes: 0547692ac1 ("drm/panel-edp: Add several generic edp panels")
Fixes: 50625eab39 ("drm/edp-panel: Add panel used by T14s Gen6 Snapdragon")
Signed-off-by: Langyan Ye <yelangyan@huaqin.corp-partner.google.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/20250723072513.2880369-1-yelangyan@huaqin.corp-partner.google.com
-----BEGIN PGP SIGNATURE-----
iHUEABYIAB0WIQQqUNBr3gm4hGXdBJlZ7Krx/gZQ6wUCaIED9AAKCRBZ7Krx/gZQ
69tPAQD4FLiS82oG1LfSjPFa6of9omdkSQBhZptuFBTZ8MyVJwD/T/fDFnIXdZQb
J4MazfsRCtgRdFlRGH90EQGRygwxdQA=
=UiOi
-----END PGP SIGNATURE-----
Merge tag 'pull-ufs-fix' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs
Pull ufs fix from Al Viro:
"Fix regression in ufs options parsing"
* tag 'pull-ufs-fix' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
fix the regression in ufs options parsing
When CONFIG_DEBUG_FS is off, drivers/gpu/drm/xe/xe_gt_debugfs.o
is not built and build fails on some setups with:
ld: drivers/gpu/drm/xe/xe_gt.o: in function `xe_fault_inject_gt_reset':
drivers/gpu/drm/xe/xe_gt.h:27:(.text+0x1659): undefined reference to `gt_reset_failure'
ld: drivers/gpu/drm/xe/xe_gt.h:27:(.text+0x1c16): undefined reference to `gt_reset_failure'
collect2: error: ld returned 1 exit status
Do not use the gt_reset_failure attribute if debugfs is not enabled.
Fixes: 8f3013e0b2 ("drm/xe: Introduce fault injection for gt reset")
Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Tested-by: Randy Dunlap <rdunlap@infradead.org>
Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
Link: https://lore.kernel.org/r/20250722-xe-fix-build-fault-v1-1-157384d50987@intel.com
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
A really dumb braino on rebasing and a dumber fuckup with managing #for-next
Fixes: b70cb45989 ("ufs: convert ufs to the new mount API")
Fucked-up-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Since traceprobe_parse_event_name() is a bit complicated, add a
kerneldoc for explaining the behavior.
Link: https://lore.kernel.org/all/175323430565.57270.2602609519355112748.stgit@devnote2/
Suggested-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Reviewed-by: Steven Rostedt (Google) <rostedt@goodmis.org>
Sort the #include directives in trace_probe* files alphabetically for
easier maintenance and avoid double includes.
This also groups headers as linux-generic, asm-generic, and local
headers.
Link: https://lore.kernel.org/all/175323424678.57270.11975372127870059007.stgit@devnote2/
Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
In January 2015, tracefs was created to allow access to the tracing
infrastructure without needing to compile in debugfs. When tracefs is
configured, the directory /sys/kernel/tracing will exist and tooling is
expected to use that path to access the tracing infrastructure.
To allow backward compatibility, when debugfs is mounted, it would
automount tracefs in its "tracing" directory so that tooling that had hard
coded /sys/kernel/debug/tracing would still work.
It has been over 10 years since the new interface was introduced, and all
tooling should now be using it. Start the process of deprecating the old
path so that it doesn't need to be maintained anymore.
A new config is added to allow distributions to disable automounting of
tracefs on debugfs.
If /sys/kernel/debug/tracing is accessed, a pr_warn() will trigger stating:
"NOTICE: Automounting of tracing to debugfs is deprecated and will be removed in 2030"
Expect to remove this feature in 5 years (2030).
Cc: <linux-trace-users@vger.kernel.org>
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Al Viro <viro@ZenIV.linux.org.uk>
Cc: Christian Brauner <brauner@kernel.org>
Cc: Jan Kara <jack@suse.cz>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Ian Rogers <irogers@google.com>
Link: https://lore.kernel.org/20250722170806.40c068c6@gandalf.local.home
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
Add TAS2770 support in TI's HDA driver. And add hda_chip_id for
more products. Distinguish DSP and non-DSP in firmware
loading function.
Signed-off-by: Baojun Xu <baojun.xu@ti.com>
Link: https://patch.msgid.link/20250723142423.38768-1-baojun.xu@ti.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Currently, BIS_LINK is used for both BIG sync and PA sync connections,
which makes it impossible to distinguish them when searching for a PA
sync connection.
Adding PA_LINK will make the distinction clearer and simplify future
extensions for PA-related features.
Signed-off-by: Yang Li <yang.li@amlogic.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
The Event_Type field in an LE Extended Advertising Report uses bits 5
and 6 for data status (e.g. truncation or fragmentation), not the PDU
type itself.
The ext_evt_type_to_legacy() function fails to mask these status bits
before evaluation. This causes valid advertisements with status bits set
(e.g. a truncated non-connectable advertisement, which ends up showing
as PDU type 0x40) to be misclassified as unknown and subsequently
dropped. This is okay for most checks which use bitwise AND on the
relevant event type bits, but it doesn't work for non-connectable types,
which are checked with '== LE_EXT_ADV_NON_CONN_IND' (that is, zero).
In terms of behaviour, first the device sends a truncated report:
> HCI Event: LE Meta Event (0x3e) plen 26
LE Extended Advertising Report (0x0d)
Entry 0
Event type: 0x0040
Data status: Incomplete, data truncated, no more to come
Address type: Random (0x01)
Address: 1D:12:46:FA:F8:6E (Non-Resolvable)
SID: 0x03
RSSI: -98 dBm (0x9e)
Data length: 0x00
Then, a few seconds later, it sends the subsequent complete report:
> HCI Event: LE Meta Event (0x3e) plen 122
LE Extended Advertising Report (0x0d)
Entry 0
Event type: 0x0000
Data status: Complete
Address type: Random (0x01)
Address: 1D:12:46:FA:F8:6E (Non-Resolvable)
SID: 0x03
RSSI: -97 dBm (0x9f)
Data length: 0x60
Service Data: Google (0xfef3)
Data[92]: ...
These devices often send multiple truncated reports per second.
This patch introduces a PDU type mask to ensure only the relevant bits
are evaluated, allowing for the correct translation of all valid
extended advertising packets.
Fixes: b2cc9761f1 ("Bluetooth: Handle extended ADV PDU types")
Signed-off-by: Chris Down <chris@chrisdown.name>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
The firmware raises an alive interrupt upon sending the HCI_RESET or
BTINTEL_HCI_OP_RESET command. As part of handling the reset command,
firmware initializes the hardware and data path and raises the alive
interrupt. Upon receiving the alive interrupt, the driver must enable
the data path and grant RX buffers to the firmware before sending any
commands.
The alive context maintained in the driver must be updated before
sending BTINTEL_HCI_OP_RESET or HCI_OP_RESET to prevent a potential race
condition where the context is also updated in the threaded IRQ.
The issue was observed in a stress reboot usecase (1/25) using "sudo
reboot" command where the firmware download was failing as the driver
was not granting RX buffer to firmware due to race condition.
Bluetooth: hci0: API lock is disabled
Bluetooth: hci0: Debug lock is disabled
Bluetooth: hci0: Minimum firmware build 1 week 10 2014
Bluetooth: hci0: Bootloader timestamp 2023.43 buildtype 1 build 11631
Bluetooth: hci0: Found device firmware: intel/ibt-00a0-00a1-iml.sfi
Bluetooth: hci0: Boot Address: 0xb0301000
Bluetooth: hci0: Firmware Version: 167-12.25
Bluetooth: hci0: Waiting for firmware download to complete
Bluetooth: hci0: Firmware loaded in 99902 usecs
Bluetooth: hci0: Alive context: fw_dl old_boot_stage: 0xa0db0003
new_boot_stage: 0xa0db0003
Bluetooth: hci0: sent cmd: 0xfc01 alive context changed:
fw_dl -> intel_reset1
Bluetooth: hci0: Waiting for device to boot
Bluetooth: hci0: Device boot timeout
Bluetooth: hci0: Firmware download retry count: 1
Fixes: 05c200c8f0 ("Bluetooth: btintel_pcie: Add handshake between driver and firmware")
Signed-off-by: Kiran K <kiran.k@intel.com>
Signed-off-by: Sai Teja Aluvala <aluvala.sai.teja@intel.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
The firmware raises an alive interrupt upon receiving the HCI_RESET or
BTINTEL_HCI_OP_RESET (Intel reset - 0xfc01) command. This change fixes
the driver to properly wait for the alive interrupt to avoid driver
sending commands to firmware before it is ready to process.
For details on the handshake between the driver and firmware, refer to
commit 05c200c8f0 ("Bluetooth: btintel_pcie: Add handshake between
driver and firmware").
As the driver needs to handle two interrupts for HCI_OP_RESET and
BTINTEL_HCI_OP_RESET, the firmware ensures that the TX completion
interrupt is always followed by the alive interrupt.
Fixes: 05c200c8f0 ("Bluetooth: btintel_pcie: Add handshake between driver and firmware")
Signed-off-by: Sai Teja Aluvala <aluvala.sai.teja@intel.com>
Signed-off-by: Kiran K <kiran.k@intel.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Currently both dev_coredumpv and skb_put_data in hci_devcd_dump use
hdev->dump.head. However, dev_coredumpv can free the buffer. From
dev_coredumpm_timeout documentation, which is used by dev_coredumpv:
> Creates a new device coredump for the given device. If a previous one hasn't
> been read yet, the new coredump is discarded. The data lifetime is determined
> by the device coredump framework and when it is no longer needed the @free
> function will be called to free the data.
If the data has not been read by the userspace yet, dev_coredumpv will
discard new buffer, freeing hdev->dump.head. This leads to
vmalloc-out-of-bounds error when skb_put_data tries to access
hdev->dump.head.
A crash report from syzbot illustrates this:
==================================================================
BUG: KASAN: vmalloc-out-of-bounds in skb_put_data
include/linux/skbuff.h:2752 [inline]
BUG: KASAN: vmalloc-out-of-bounds in hci_devcd_dump+0x142/0x240
net/bluetooth/coredump.c:258
Read of size 140 at addr ffffc90004ed5000 by task kworker/u9:2/5844
CPU: 1 UID: 0 PID: 5844 Comm: kworker/u9:2 Not tainted
6.14.0-syzkaller-10892-g4e82c87058f4 #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 02/12/2025
Workqueue: hci0 hci_devcd_timeout
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:94 [inline]
dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120
print_address_description mm/kasan/report.c:408 [inline]
print_report+0xc3/0x670 mm/kasan/report.c:521
kasan_report+0xe0/0x110 mm/kasan/report.c:634
check_region_inline mm/kasan/generic.c:183 [inline]
kasan_check_range+0xef/0x1a0 mm/kasan/generic.c:189
__asan_memcpy+0x23/0x60 mm/kasan/shadow.c:105
skb_put_data include/linux/skbuff.h:2752 [inline]
hci_devcd_dump+0x142/0x240 net/bluetooth/coredump.c:258
hci_devcd_timeout+0xb5/0x2e0 net/bluetooth/coredump.c:413
process_one_work+0x9cc/0x1b70 kernel/workqueue.c:3238
process_scheduled_works kernel/workqueue.c:3319 [inline]
worker_thread+0x6c8/0xf10 kernel/workqueue.c:3400
kthread+0x3c2/0x780 kernel/kthread.c:464
ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:153
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
</TASK>
The buggy address ffffc90004ed5000 belongs to a vmalloc virtual mapping
Memory state around the buggy address:
ffffc90004ed4f00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
ffffc90004ed4f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
>ffffc90004ed5000: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
^
ffffc90004ed5080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
ffffc90004ed5100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8
==================================================================
To avoid this issue, reorder dev_coredumpv to be called after
skb_put_data that does not free the data.
Reported-by: syzbot+ac3c79181f6aecc5120c@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=ac3c79181f6aecc5120c
Fixes: b257e02ecc ("HCI: coredump: Log devcd dumps into the monitor")
Tested-by: syzbot+ac3c79181f6aecc5120c@syzkaller.appspotmail.com
Signed-off-by: Ivan Pravdin <ipravdin.official@gmail.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Sort WCN6855 device IDs to more easily manage them.
Signed-off-by: Zijun Hu <Zijun.Hu@oss.qualcomm.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
There are custom-made firmwares based on board ID for a given QCA BT
chip sometimes, and they are different with existing firmwares and put
in a separate subdirectory to avoid conflict, for example:
QCA2066, as a variant of WCN6855, has firmwares under 'qca/QCA2066/'
of linux-firmware repository.
Support downloading custom-made firmwares based on a table newly added.
Signed-off-by: Zijun Hu <zijun.hu@oss.qualcomm.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
This adds uevents which will be generated whenever FW dump is triggered,
FW dump is complete and FW (re)download is done.
This feature is needed for IW612 chipset, which is a tri-radio chipset,
where WLAN runs on CPU1 and BT and Zigbee runs on CPU2.
Currently, whenever BT FW crashes, and FW dump is in progress, there is
no way for 15.4 application to know that CPU2 is in bad state, and when
it will be recovered.
With the help of these uevents and udev rules, the 15.4 app, or any
userspace application can be alerted whenever CPU2 goes in bad state and
recoveres after BTNXPUART reloads the firmware.
[ 334.255154] Bluetooth: hci0: ==== Start FW dump ===
[ 334.261003] Bluetooth: hci0: ==== Send uevent: BTNXPUART_DEV=serial0-0:BTNXPUART_STATE=FW_DUMP_ACTIVE ===
[ 351.486048] Bluetooth: hci0: ==== FW dump complete ===
[ 351.491356] Bluetooth: hci0: ==== Send uevent: BTNXPUART_DEV=serial0-0:BTNXPUART_STATE=FW_DUMP_DONE ===
[ 352.028974] Bluetooth: hci0: ChipID: 7601, Version: 0
[ 352.034490] Bluetooth: hci0: Request Firmware: nxp/uartspi_n61x_v1.bin.se
[ 353.979977] Bluetooth: hci0: FW Download Complete: 417064 bytes
[ 355.197222] Bluetooth: hci0: ==== Send uevent: BTNXPUART_DEV=serial0-0:BTNXPUART_STATE=FW_READY ===
Tested this change by creating a simple udev rule to store the
BTNXPUART_STATE value in a ~/<BTNXPUART_DEV>/state file, and running
15.4 traffic.
The 15.4 packets were sent over SPI only when BTNXPUART_STATE was
FW_READY.
Signed-off-by: Neeraj Sanjay Kale <neeraj.sanjaykale@nxp.com>
Tested-by: Jean-Yves Salaün <jean-yves.salaun@nxp.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
This adds proper handling for the independent reset command sent by the
driver after FW dump is complete.
In normal scenario, the independent reset vendor command gives a success
response before jumping to bootcode.
However, when FW goes in a bad state, and sends out FW dump packets, the
independent reset command does not get any response from the controller.
[ 159.807732] Bluetooth: hci0: ==== Start FW dump ===
[ 180.759060] Bluetooth: hci0: ==== FW dump complete ===
[ 182.779208] Bluetooth: hci0: command 0xfcfc tx timeout
[ 183.364974] Bluetooth: hci0: ChipID: 7601, Version: 0
[ 183.368490] Bluetooth: hci0: Request Firmware: nxp/uartspi_n61x_v1.bin.se
[ 184.679977] Bluetooth: hci0: FW Download Complete: 417064 bytes
[ 187.963102] Bluetooth: hci0: Opcode 0x0c03 failed: -110
As a fix for such scenario, the independent reset vendor command is sent
using the __hci_cmd_send() API, which does not expect any response for
vendor commands.
__hci_cmd_send is non blocking, so before the tx_work is scheduled, it
sometimes gets canceled and 3F|FC command is never sent. Adding a small
delay after __hci_cmd_send allows the command to be sent to the
controller.
Signed-off-by: Neeraj Sanjay Kale <neeraj.sanjaykale@nxp.com>
Tested-by: Jean-Yves Salaün <jean-yves.salaun@nxp.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
User-space applications (e.g. PipeWire) depend on
ISO-formatted timestamps for precise audio sync.
The ISO ts is based on the controller’s clock domain,
so hardware timestamping (hwtimestamp) must be used.
Ref: Documentation/networking/timestamping.rst,
section 3.1 Hardware Timestamping.
Signed-off-by: Yang Li <yang.li@amlogic.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
User applications need a way to track which ISO interval a given SDU
belongs to, to properly detect packet loss. All controllers do not set
timestamps, and it's not guaranteed user application receives all packet
reports (small socket buffer, or controller doesn't send all reports
like Intel AX210 is doing).
Add socket option BT_PKT_SEQNUM that enables reporting of received
packet ISO sequence number in BT_SCM_PKT_SEQNUM CMSG.
Use BT_PKT_SEQNUM == 22 for the socket option, as 21 was used earlier
for a removed experimental feature that never got into mainline.
Signed-off-by: Pauli Virtanen <pav@iki.fi>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
