Re: [PATCH v1] serdev: Set fwnode for serdev devices

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

Am 03.03.23 um 18:22 schrieb Florian Fainelli:
On 3/3/23 03:57, Stefan Wahren wrote:
Hi,

Am 02.03.23 um 18:51 schrieb Florian Fainelli:


On 3/2/2023 9:20 AM, Saravana Kannan wrote:
On Thu, Mar 2, 2023 at 9:01 AM Stefan Wahren <stefan.wahren@xxxxxxxx> wrote:

Hi Saravana,

Am 02.03.23 um 03:35 schrieb Saravana Kannan:
This allow fw_devlink to do dependency tracking for serdev devices.

Reported-by: Florian Fainelli <f.fainelli@xxxxxxxxx>
Link: https://lore.kernel.org/lkml/03b70a8a-0591-f28b-a567-9d2f736f17e5@xxxxxxxxx/
Cc: Stefan Wahren <stefan.wahren@xxxxxxxx>
Signed-off-by: Saravana Kannan <saravanak@xxxxxxxxxx>

since this fixes an issue on Raspberry Pi 4, shouldn't this be mentioned
in the commit message and providing a Fixes tag?

So RPi 4 was never creating a device links between serdev devices and
their consumers. The error message was just a new one I added and we
are noticing and catching the fact that serdev wasn't setting fwnode
for a device.

I'm also not sure if I can say this commit "Fixes" an issue in serdev
core because when serdev core was written, fw_devlink wasn't a thing.
Once I add Fixes, people will start pulling this into stable
branches/other trees where I don't think this should be pulled into
older stable branches.

That is kind of the point of Fixes: tag, is not it? It is appropriate to list a commit that is not specific to serdev, but maybe a particular point into the fw_devlink history. Given this did not appear to have a functional impact, we could go without one.

i was under the impression that this issue breaks at least Bluetooth on Raspberry Pi 4 because the driver is never probed. I cannot see the success output in Florian's trace. Something like this:

[    7.124879] hci_uart_bcm serial0-0: supply vbat not found, using dummy regulator [    7.131743] hci_uart_bcm serial0-0: supply vddio not found, using dummy regulator
...
[    7.517249] Bluetooth: hci0: BCM: chip id 107
[    7.517499] Bluetooth: hci0: BCM: features 0x2f
[    7.519757] Bluetooth: hci0: BCM4345C0
[    7.519768] Bluetooth: hci0: BCM4345C0 (003.001.025) build 0000
[    7.539495] Bluetooth: hci0: BCM4345C0 'brcm/BCM4345C0.hcd' Patch
...
[    8.348831] Bluetooth: hci0: BCM43455 37.4MHz Raspberry Pi 3+
[    8.348845] Bluetooth: hci0: BCM4345C0 (003.001.025) build 0342

I just want to make sure that 6.2 doesn't have a regression.

My configuration uses hci_uart as a module, and it would always load fine, but I suppose I can make sure that even built-in this works properly. Give me a day or two to test that.

okay, this is fine. From my point of view this is not necessary to test built-in.

I tested latest mainline with Raspberry Pi 4 (multi_v7_defconfig + ARM_LPAE) and there is no regression:

Tested-by: Stefan Wahren <stefan.wahren@xxxxxxxx>

Thanks




[Index of Archives]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux PPP]     [Linux FS]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Linmodem]     [Device Mapper]     [Linux Kernel for ARM]

  Powered by Linux