[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZdY_dBZyqiys0gf_@google.com>
Date: Wed, 21 Feb 2024 18:22:44 +0000
From: Matthias Kaehlcke <mka@...omium.org>
To: Javier Carrasco <javier.carrasco@...fvision.net>
Cc: Liam Girdwood <lgirdwood@...il.com>, Mark Brown <broonie@...nel.org>,
Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Conor Dooley <conor+dt@...nel.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
linux-sound@...r.kernel.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org,
Matthias Kaehlcke <matthias@...hlcke.net>
Subject: Re: [PATCH v3 1/7] usb: misc: onboard_hub: rename to onboard_dev
On Tue, Feb 13, 2024 at 11:36:25AM +0100, Javier Carrasco wrote:
> Hi Matthias,
>
> On 06.02.24 18:55, Matthias Kaehlcke wrote:
> > Hi Javier,
> >
> > a few comments inline
> >
> > On Tue, Feb 06, 2024 at 02:59:29PM +0100, Javier Carrasco wrote:
> >> +static struct onboard_dev *_find_onboard_dev(struct device *dev)
> >> +{
> >> + struct platform_device *pdev;
> >> + struct device_node *np;
> >> + struct onboard_dev *onboard_dev;
> >> +
> >> + pdev = of_find_device_by_node(dev->of_node);
> >> + if (!pdev) {
> >> + np = of_parse_phandle(dev->of_node, "peer-hub", 0);
> >> + if (!np) {
> >> + dev_err(dev, "failed to find device node for peer hub\n");
> >> + return ERR_PTR(-EINVAL);
> >> + }
> >> +
> >> + pdev = of_find_device_by_node(np);
> >> + of_node_put(np);
> >> +
> >> + if (!pdev)
> >> + return ERR_PTR(-ENODEV);
> >> + }
> >
> > The above branch should probably be guarded by 'if (!onboard_dev->pdata->is_hub)',
> > this is also a change for ""usb: misc: onboard_dev: add support for non-hub devices"
> >
> I am not sure how to guard the branch like that because onboard_dev is
> retrieved by means of pdev->dev, which is not available if
> of_find_device_by_node returns NULL. The non-hub device will not have a
> peer-hub property according to its bindings anyway, right?
Right, onboard_dev isn't available yet at that point, my bad. I thought it
would be nice to clearly separate the hub related logic from other devices,
but that isn't an option in this case.
Powered by blists - more mailing lists