Re: PCI: Race condition in pci_create_sysfs_dev_files

Pali Rohár [2021-04-07 16:51:47]: > Could you run 'dmesg' and provide its output? So also missing / garbage > messages would be visible. Adding it inline for archives. It's log from serial console, with output of dmesg at the bottom so one can compare if needed. [0.00] Booting Linux

Re: PCI: Race condition in pci_create_sysfs_dev_files

Pali Rohár [2020-10-07 10:12:27]: Hi, [adding Koen to Cc:] > I'm hitting these race conditions randomly on pci aardvark controller > driver- I prepared patch which speed up initialization of this driver, > but also increase probability that it hits above race conditions :-( it seems, that I'm

Re: [PATCH] iio: chemical: scd30: fix Oops due to missing parent device

Jonathan Cameron [2021-02-12 19:12:19]: Hi Jonathan, > > CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.4.96+ #473 > > So, we moved this into the core a while back (to avoid exactly this sort of > issue). > That change predates this introduction of this driver as it went in > in v5.8 sorry for

Re: [PATCH v2] leds: apu: extend support for PC Engines APU1 with newer firmware

Enrico Weigelt, metux IT consult [2021-02-17 12:02:47]: Hi, (adding Zbynek to Cc: who seems to own a complete range of APU boards and has done the runtime testing already) > Looks good to me. But don't dare giving official ack, since I don't > have an apu1 board for testing. @Zbynek can you

[PATCH] iio: chemical: scd30: fix Oops due to missing parent device

Cc: # v5.9+ Fixes: 64b3d8b1b0f5 ("iio: chemical: scd30: add core driver") Signed-off-by: Petr Štetiar --- drivers/iio/chemical/scd30_core.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/iio/chemical/scd30_core.c b/drivers/iio/chemical/scd30_core.c index 4d0d798c7cd3..33aa

Re: [PATCH] mt76: mt7915: fix misplaced #ifdef

Arnd Bergmann [2021-01-03 14:57:55]: Hi, just a small nitpick, > From: Arnd Bergmann > > The lone '|' at the end of a line causes a build failure: > > drivers/net/wireless/mediatek/mt76/mt7915/init.c:47:2: error: expected > expression before '}' token > > Replace the #ifdef with an

Re: [PATCH AUTOSEL 4.9 18/25] MIPS: perf: ath79: Fix perfcount IRQ assignment

Hi, Karl has reported to me today, that he's experiencing weird reboot hang on his devices with 4.9.180 kernel and that he has bisected it down to my backported patch. I would like to kindly ask you for removal of this patch. This patch should be reverted from all stable kernels up to 5.1,

[PATCH] of_net: fix of_get_mac_address retval if compiled without CONFIG_OF

ss in case where the kernel is compiled without CONFIG_OF, so I'm doing so now. Cc: Mirko Lindner Cc: Stephen Hemminger Fixes: d01f449c008a ("of_net: add NVMEM support to of_get_mac_address") Reported-by: Octavio Alvarez Signed-off-by: Petr Štetiar --- include/linux/of_net.h | 2 +

[PATCH net 1/5] of_net: remove nvmem-mac-address property

er unbinds, the buffer is freed, but DT code would be still referencing that memory. I'm removing this property completely instead of fixing it, as it's not needed to have it. Fixes: d01f449c008a ("of_net: add NVMEM support to of_get_mac_address") Suggested-by: Rob Herring Signed-off-by: Petr Š

Re: [PATCH v2 1/4] of_net: Add NVMEM support to of_get_mac_address

Rob Herring [2019-05-07 11:06:43]: Hi, > > Honestly I don't know if it's necessary to have it, but so far address, > > mac-address and local-mac-address properties provide this DT nodes, so I've > > simply thought, that it would be good to have it for MAC address from NVMEM > > as > > well in

Re: [PATCH v4 02/10] dt-bindings: doc: reflect new NVMEM of_get_mac_address behaviour

Rob Herring [2019-05-07 11:44:57]: Hi, > > -- local-mac-address: the driver is designed to use the > > of_get_mac_address api > > - only if efuse-mac is 0. When efuse-mac is 0, the MAC > > - address is obtained from local-mac-address. If this > > -

netdev patchwork issues [Was: Re: [PATCH net-next v2 0/4] of_get_mac_address ERR_PTR fixes]

Petr Štetiar [2019-05-07 10:39:18]: [adding Jeremy to the Cc: loop] > it was applied[2] to David's net-next tree, but unfortunately partialy, just 9 > patches out of 10, as the patch 05/10 in that series (which is patch 1/4 in > this series) never reached netdev mailing list and

[PATCH net-next v2 4/4] net: usb: smsc: fix warning reported by kbuild test robot

to check for impossible return value just to make a compiler happy. Fixes: adfb3cb2c52e ("net: usb: support of_get_mac_address new ERR_PTR error") Reported-by: kbuild test robot Signed-off-by: Petr Štetiar --- drivers/net/usb/smsc75xx.c | 2 +- drivers/net/usb/smsc95xx.c | 2 +- 2 files

[PATCH net-next v2 3/4] staging: octeon-ethernet: Fix of_get_mac_address ERR_PTR check

the kernel is compiled without DT support this NULL would get passed to IS_ERR, which would lead to the wrong decision and would pass that NULL pointer and invalid MAC address further. Fixes: 284eb160681c ("staging: octeon-ethernet: support of_get_mac_address new ERR_PTR error") Signed-

[PATCH net-next v2 2/4] net: dsa: support of_get_mac_address new ERR_PTR error

is always valid and checked by is_valid_ether_addr anyway. Fixes: d01f449c008a ("of_net: add NVMEM support to of_get_mac_address") Signed-off-by: Petr Štetiar --- net/dsa/slave.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/dsa/slave.c b/net/dsa/slave.c index 316bce

[PATCH net-next 0/3] of_get_mac_address ERR_PTR fixes

this user to the new ERR_PTR encoded error value as well. Third patch which was sent as v5 wasn't considered for merge, but I still think, that we need to check for possible NULL value, thus current IS_ERR check isn't sufficient and we need to use IS_ERR_OR_NULL instead. Cheers, Petr Petr Štetiar

[PATCH net-next 3/3] staging: octeon-ethernet: Fix of_get_mac_address ERR_PTR check

the kernel is compiled without DT support this NULL would get passed to IS_ERR, which would lead to the wrong decision and would pass that NULL pointer and invalid MAC address further. Fixes: 284eb160681c ("staging: octeon-ethernet: support of_get_mac_address new ERR_PTR error") Signed-

[PATCH v4 06/10] net: usb: support of_get_mac_address new ERR_PTR error

There was NVMEM support added to of_get_mac_address, so it could now return ERR_PTR encoded error values, so we need to adjust all current users of of_get_mac_address to this new fact. Signed-off-by: Petr Štetiar --- Changes since v3: * IS_ERR_OR_NULL -> IS_ERR drivers/net/usb/smsc75x

[PATCH v4 09/10] ARM: Kirkwood: support of_get_mac_address new ERR_PTR error

There was NVMEM support added to of_get_mac_address, so it could now return ERR_PTR encoded error values, so we need to adjust all current users of of_get_mac_address to this new fact. Signed-off-by: Petr Štetiar --- Changes since v3: * IS_ERR_OR_NULL -> IS_ERR arch/arm/mach-mv

[PATCH v4 03/10] net: macb: support of_get_mac_address new ERR_PTR error

There was NVMEM support added directly to of_get_mac_address, and it uses nvmem_get_mac_address under the hood, so we can remove it. As of_get_mac_address can now return ERR_PTR encoded error values, adjust to that as well. Signed-off-by: Petr Štetiar --- Changes since v2: * ERR_PTR

[PATCH v4 04/10] net: davinci: support of_get_mac_address new ERR_PTR error

There was NVMEM support added directly to of_get_mac_address, and it uses nvmem_get_mac_address under the hood, so we can remove it. As of_get_mac_address can now return ERR_PTR encoded error values, adjust to that as well. Signed-off-by: Petr Štetiar --- Changes since v2: * ERR_PTR

Re: [PATCH v3 01/10] of_net: add NVMEM support to of_get_mac_address

Sergei Shtylyov [2019-05-03 11:44:54]: Hi Sergei, > > diff --git a/drivers/of/of_net.c b/drivers/of/of_net.c > > index d820f3e..258ceb8 100644 > > --- a/drivers/of/of_net.c > > +++ b/drivers/of/of_net.c > [...] > > @@ -64,6 +113,9 @@ static const void *of_get_mac_addr(struct device_node > >

[PATCH v3 04/10] net: davinci: support of_get_mac_address new ERR_PTR error

There was NVMEM support added directly to of_get_mac_address, and it uses nvmem_get_mac_address under the hood, so we can remove it. As of_get_mac_address can now return NULL and ERR_PTR encoded error values, adjust to that as well. Signed-off-by: Petr Štetiar --- Changes since v2: * ERR_PTR

[PATCH v3 09/10] ARM: Kirkwood: support of_get_mac_address new ERR_PTR error

There was NVMEM support added to of_get_mac_address, so it could now return NULL and ERR_PTR encoded error values, so we need to adjust all current users of of_get_mac_address to this new fact. Signed-off-by: Petr Štetiar --- arch/arm/mach-mvebu/kirkwood.c | 3 ++- 1 file changed, 2 insertions

[PATCH v3 08/10] staging: octeon-ethernet: support of_get_mac_address new ERR_PTR error

There was NVMEM support added to of_get_mac_address, so it could now return NULL and ERR_PTR encoded error values, so we need to adjust all current users of of_get_mac_address to this new fact. Signed-off-by: Petr Štetiar --- drivers/staging/octeon/ethernet.c | 2 +- 1 file changed, 1 insertion

Re: [PATCH v2 1/4] of_net: Add NVMEM support to of_get_mac_address

Rob Herring [2019-05-01 15:19:25]: Hi Rob, > > + struct property *pp; ... > > + pp = kzalloc(sizeof(*pp), GFP_KERNEL); > > + if (!pp) > > + return NULL; > > + > > + pp->name = "nvmem-mac-address"; > > + pp->length = ETH_ALEN; > > + pp->value = kmemdup(mac, ETH_ALEN,

Re: [PATCH] i.MX6 PCIe: Fix imx6_pcie_deassert_core_reset() polarity

Krzysztof Hałasa [2016-03-25 14:32:35]: Cześć, > I wonder if all boards (except maybe that Toradex set) use an active-low > PCIe reset and are now broken. Perhaps Toradex uses active-high and thus > works. I'm really puzzled by this :-) With your patch applied I get following

Re: [PATCH] i.MX6 PCIe: Fix imx6_pcie_deassert_core_reset() polarity

Krzysztof Hałasa [2016-03-25 14:32:35]: Cześć, > I wonder if all boards (except maybe that Toradex set) use an active-low > PCIe reset and are now broken. Perhaps Toradex uses active-high and thus > works. I'm really puzzled by this :-) With your patch applied I get following on Toradex Apalis

Re: [PATCH v4 1/2] ARM: dts: imx6: Add support for Toradex Apalis iMX6Q/D SoM

Marcel Ziswiler [2016-01-24 23:48:22]: Hi Marcel, sorry for not commenting on your v3, I've missed it :( > + regulators { > + compatible = "simple-bus"; > + I've commented this on your v2 already. One of the Lucas's comments[1] about this node was following: "Get rid of

Re: [PATCH v4 1/2] ARM: dts: imx6: Add support for Toradex Apalis iMX6Q/D SoM

Marcel Ziswiler [2016-01-24 23:48:22]: Hi Marcel, sorry for not commenting on your v3, I've missed it :( > + regulators { > + compatible = "simple-bus"; > + I've commented this on your v2 already. One of the Lucas's comments[1] about this node was

Re: [PATCH v2 1/2] ARM: dts: imx6: Add support for Toradex Apalis iMX6Q/D SoM

Marcel Ziswiler [2016-01-05 17:39:01]: Hi Marcel, thanks for taking care of this, I'm quite busy with other tasks :( > - integrated review feedback from Lucas You've probably missed few of them :) See my nitpicks bellow. > - left and even added some more comments as I don't see why putting

Re: [PATCH v2 1/2] ARM: dts: imx6: Add support for Toradex Apalis iMX6Q/D SoM

Marcel Ziswiler [2016-01-05 17:39:01]: Hi Marcel, thanks for taking care of this, I'm quite busy with other tasks :( > - integrated review feedback from Lucas You've probably missed few of them :) See my nitpicks bellow. > - left and even added some more comments