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 on
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
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
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 pe
s_add().
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 4d0d798c
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 equival
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, becau
address 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_n
driver 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
S
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 o
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
> > -
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
ould be confusing 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/smsc95x
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-
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
in DSA, so I've converted 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_NU
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-
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
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
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 and
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
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
> > *np
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
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
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
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, GFP_K
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
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 th
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 an
29 matches
Mail list logo
