arch/powerpc/lib/xor_vmx.o is built with '-msoft-float' (from the main
powerpc Makefile) and '-maltivec' (from its CFLAGS), which causes an
error when building with clang after a recent change in main:
error: option '-msoft-float' cannot be specified with '-maltivec'
make[6]: *** [scripts/Makefile.build:243: arch/powerpc/lib/xor_vmx.o] Error 1
Explicitly add '-mhard-float' before '-maltivec' in xor_vmx.o's CFLAGS
to override the previous inclusion of '-msoft-float' (as the last option
wins), which matches how other areas of the kernel use '-maltivec', such
as AMDGPU.
Cc: stable(a)vger.kernel.org
Closes: https://github.com/ClangBuiltLinux/linux/issues/1986
Link: https://github.com/llvm/llvm-project/commit/4792f912b232141ecba4cbae538873b…
Signed-off-by: Nathan Chancellor <nathan(a)kernel.org>
---
arch/powerpc/lib/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/lib/Makefile b/arch/powerpc/lib/Makefile
index 6eac63e79a89..0ab65eeb93ee 100644
--- a/arch/powerpc/lib/Makefile
+++ b/arch/powerpc/lib/Makefile
@@ -76,7 +76,7 @@ obj-$(CONFIG_PPC_LIB_RHEAP) += rheap.o
obj-$(CONFIG_FTR_FIXUP_SELFTEST) += feature-fixups-test.o
obj-$(CONFIG_ALTIVEC) += xor_vmx.o xor_vmx_glue.o
-CFLAGS_xor_vmx.o += -maltivec $(call cc-option,-mabi=altivec)
+CFLAGS_xor_vmx.o += -mhard-float -maltivec $(call cc-option,-mabi=altivec)
# Enable <altivec.h>
CFLAGS_xor_vmx.o += -isystem $(shell $(CC) -print-file-name=include)
---
base-commit: 6613476e225e090cc9aad49be7fa504e290dd33d
change-id: 20240127-ppc-xor_vmx-drop-msoft-float-ad68b437f86c
Best regards,
--
Nathan Chancellor <nathan(a)kernel.org>
Since commit 1a50d9403fb9 ("treewide: Fix probing of devices in DT
overlays"), when using device-tree overlays, the FWNODE_FLAG_NOT_DEVICE
is set on each overlay nodes.
When an overlay contains a node related to a bus (i2c for instance)
and its children nodes representing i2c devices, the flag is cleared for
the bus node by the OF notifier but the "standard" probe sequence takes
place (the same one is performed without an overlay) for the bus and
children devices are created simply by walking the children DT nodes
without clearing the FWNODE_FLAG_NOT_DEVICE flag for these devices.
Clear the FWNODE_FLAG_NOT_DEVICE when the device is added, no matter if
an overlay is used or not.
Fixes: 1a50d9403fb9 ("treewide: Fix probing of devices in DT overlays")
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Herve Codina <herve.codina(a)bootlin.com>
---
drivers/base/core.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/base/core.c b/drivers/base/core.c
index 14d46af40f9a..61d09ac57bfb 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -3619,6 +3619,7 @@ int device_add(struct device *dev)
*/
if (dev->fwnode && !dev->fwnode->dev) {
dev->fwnode->dev = dev;
+ dev->fwnode->flags &= ~FWNODE_FLAG_NOT_DEVICE;
fw_devlink_link_device(dev);
}
--
2.43.0
Dear developers,
(sorry for the long CC list, it looks quite long to me, but I tried to
follow the issue reporting guide as closely as possible)
Since patches [1], [2] and [3] were applied to the kernel, there is a
regression with Lenovo ThinkPad Compact USB Keyboard (old model, not II).
[1]
https://github.com/torvalds/linux/commit/46a0a2c96f0f47628190f122c2e3d879e5…
[2]
https://github.com/torvalds/linux/commit/2f2bd7cbd1d1548137b351040dc4e037d1…
[3]
https://github.com/torvalds/linux/commit/43527a0094c10dfbf0d5a2e7979395a38d…
The regression is that a middle click is performed when releasing middle
button after wheel emulation.
The bug appears randomly, it can be after 5 minutes or 1 hour of
keyboard usage, and can only be worked around by unplugging/re-plugging
the keyboard. (I ended up resorting to simulate an unplug/replug, with a
script which echoes 0 then 1 to /sys/bus/usb/devices/<id>/authorized,
since I was afraid to damage the Micro-USB outlet by physically
unplugging/re-plugging too much).
Those spurious clicks are very annoying, since they can open links in
new tabs when scrolling in Firefox, or pasting text when scrolling in
terminals, or other unwanted stuff.
I witnessed it with latest kernels (Debian unstable) as well as stable
kernels (Debian 12 Bookworm, stable).
On Debian Stable, the last working kernel was 5.10.127, the regression
appeared in 5.10.136 (i read all changelogs on kernel.org between those
two releases but couldn't find anything about hid-lenovo, so I can't
tell exactly in which release the regression appeared, Debian upgraded
directly from .127 to .136).
I reported it in Debian [4], and apparently I'm not the only person
suffering from it [5].
[4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1058758#32
[5] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1058758#42
I would understand that such bugs would end up in a development kernel
like the ones provided by Debian Unstable, but not with stable kernels
like the ones provided by Debian Stable.
Regards,
--
Raphaël Halimi
While commit 69f89168b310 ("usb: typec: tpcm: Fix issues with power being
removed during reset") fixes the boot issues for bus powered devices such
as LibreTech Renegade Elite/Firefly, it trades off the CC pins NOT being
Hi-Zed during errory recovery (i.e PORT_RESET) for devices which are NOT
bus powered(a.k.a self powered). This change Hi-Zs the CC pins only for
self powered devices, thus preventing brown out for bus powered devices
Adhering to spec is gaining more importance due to the Common charger
initiative enforced by the European Union.
Quoting from the spec:
4.5.2.2.2.1 ErrorRecovery State Requirements
The port shall not drive VBUS or VCONN, and shall present a
high-impedance to ground (above zOPEN) on its CC1 and CC2 pins.
Hi-Zing the CC pins is the inteded behavior for PORT_RESET.
CC pins are set to default state after tErrorRecovery in
PORT_RESET_WAIT_OFF.
4.5.2.2.2.2 Exiting From ErrorRecovery State
A Sink shall transition to Unattached.SNK after tErrorRecovery.
A Source shall transition to Unattached.SRC after tErrorRecovery.
Fixes: 69f89168b310 ("usb: typec: tpcm: Fix issues with power being removed during reset")
Cc: stable(a)vger.kernel.org
Cc: Mark Brown <broonie(a)kernel.org>
Signed-off-by: Badhri Jagan Sridharan <badhri(a)google.com>
---
Changes since V1:
* Fix CC for linux stable
---
drivers/usb/typec/tcpm/tcpm.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c
index c9a78f55ca48..bbe1381232eb 100644
--- a/drivers/usb/typec/tcpm/tcpm.c
+++ b/drivers/usb/typec/tcpm/tcpm.c
@@ -5593,8 +5593,11 @@ static void run_state_machine(struct tcpm_port *port)
break;
case PORT_RESET:
tcpm_reset_port(port);
- tcpm_set_cc(port, tcpm_default_state(port) == SNK_UNATTACHED ?
- TYPEC_CC_RD : tcpm_rp_cc(port));
+ if (port->self_powered)
+ tcpm_set_cc(port, TYPEC_CC_OPEN);
+ else
+ tcpm_set_cc(port, tcpm_default_state(port) == SNK_UNATTACHED ?
+ TYPEC_CC_RD : tcpm_rp_cc(port));
tcpm_set_state(port, PORT_RESET_WAIT_OFF,
PD_T_ERROR_RECOVERY);
break;
base-commit: a560a5672826fc1e057068bda93b3d4c98d037a2
--
2.44.0.rc1.240.g4c46232300-goog
This is a small set of patches that address build breakage with
allyesconfig / allmodconfig.
This solves some, but not all, build breakage.
The parport fix depends on the previous patch, the rest are independent
fixes.
With v2 there is a extra patch that drops ZONE_DMA support.
It does not fix any build failure, but a nice cleanup.
Cc: Miquel Raynal <miquel.raynal(a)bootlin.com>
To: Maciej W. Rozycki <macro(a)orcam.me.uk>
To: <sparclinux(a)vger.kernel.org>
Cc: <linux-parport(a)lists.infradead.org>
Cc: David S. Miller <davem(a)davemloft.net>
To: Andreas Larsson <andreas(a)gaisler.com>
To: Randy Dunlap <rdunlap(a)infradead.org>
Cc: Arnd Bergmann <arnd(a)arndb.de>
Cc: <linux-kernel(a)vger.kernel.org>
Changes in v2:
- Added r-b/tested by (thanks to Randy and Maciej)
- Dropped patch for uhci-grlib.c as it is already upstream (Randy)
- Added a few Fixes (Maciej)
- Fixed commit message when dropping GENERIC_ISA_DMA (Maciej)
- Added new patch that drop ZONE_DMA (Maciej)
- Added new patch to fix section mismatch error
In an allmodconfig build I see a lot of:
modpost: "__udelay" [module] has no CRC!
Similar for a handful of other symbols.
Any hint how to get rid of them would be nice.
I have tried to add the prototype to asm-prototypes.h with no luck.
On top of this the link fails, but I assume this the kernel that grows
too big which is no surprise.
- Link to v1: https://lore.kernel.org/r/20240223-sam-fix-sparc32-all-builds-v1-0-5c60fd5c…
---
Sam Ravnborg (7):
sparc32: Use generic cmpdi2/ucmpdi2 variants
sparc32: Fix build with trapbase
mtd: maps: sun_uflash: Declare uflash_devinit static
sparc32: Do not select ZONE_DMA
sparc32: Do not select GENERIC_ISA_DMA
sparc32: Fix parport build with sparc32
sparc32: Fix section mismatch in leon_pci_grpci
arch/sparc/Kconfig | 7 +-
arch/sparc/include/asm/parport.h | 259 +-----------------------------------
arch/sparc/include/asm/parport_64.h | 256 +++++++++++++++++++++++++++++++++++
arch/sparc/kernel/irq_32.c | 6 +-
arch/sparc/kernel/kernel.h | 8 +-
arch/sparc/kernel/kgdb_32.c | 4 +-
arch/sparc/kernel/leon_pci_grpci1.c | 2 +-
arch/sparc/kernel/leon_pci_grpci2.c | 2 +-
arch/sparc/kernel/leon_smp.c | 6 +-
arch/sparc/kernel/setup_32.c | 4 +-
arch/sparc/lib/Makefile | 4 +-
arch/sparc/lib/cmpdi2.c | 28 ----
arch/sparc/lib/ucmpdi2.c | 20 ---
arch/sparc/mm/srmmu.c | 1 -
drivers/mtd/maps/sun_uflash.c | 2 +-
15 files changed, 284 insertions(+), 325 deletions(-)
---
base-commit: 626db6ee8ee1edac206610db407114aa83b53fd3
change-id: 20240223-sam-fix-sparc32-all-builds-0a0403d6e1b3
Best regards,
--
Sam Ravnborg <sam(a)ravnborg.org>