[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID:
<ZR1P278MB102298AE3011962AEE1BC91E9F5C2@ZR1P278MB1022.CHEP278.PROD.OUTLOOK.COM>
Date: Thu, 7 Nov 2024 15:24:44 +0000
From: Facklam, Olivér <oliver.facklam@...hlke.com>
To: Heikki Krogerus <heikki.krogerus@...ux.intel.com>
CC: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "von Heyl,
Benedict" <benedict.vonheyl@...hlke.com>, Först, Mathis
<mathis.foerst@...hlke.com>, "Glettig, Michael" <Michael.Glettig@...hlke.com>
Subject: RE: [PATCH 2/4] usb: typec: hd3ss3220: use typec_get_fw_cap() to fill
typec_cap
Hello Heikki,
> -----Original Message-----
> From: Heikki Krogerus <heikki.krogerus@...ux.intel.com>
> Sent: Thursday, November 7, 2024 3:21 PM
> To: Facklam, Olivér <oliver.facklam@...hlke.com>
> Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>; linux-
> usb@...r.kernel.org; linux-kernel@...r.kernel.org; von Heyl, Benedict
> <benedict.vonheyl@...hlke.com>; Först, Mathis
> <mathis.foerst@...hlke.com>; Glettig, Michael
> <Michael.Glettig@...hlke.com>
> Subject: Re: [PATCH 2/4] usb: typec: hd3ss3220: use typec_get_fw_cap() to fill
> typec_cap
>
> Hi Oliver,
>
> On Thu, Nov 07, 2024 at 12:43:28PM +0100, Oliver Facklam via B4 Relay
> wrote:
> > From: Oliver Facklam <oliver.facklam@...hlke.com>
> >
> > The type, data, and prefer_role properties were previously hard-coded
> > when creating the struct typec_capability.
> >
> > Use typec_get_fw_cap() to populate these fields based on the
> > respective fwnode properties.
> >
> > Signed-off-by: Oliver Facklam <oliver.facklam@...hlke.com>
> > ---
> > drivers/usb/typec/hd3ss3220.c | 8 ++++----
> > 1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/usb/typec/hd3ss3220.c
> > b/drivers/usb/typec/hd3ss3220.c index
> >
> 56f74bf70895ca701083bde44a5bbe0b691551e1..e6e4b1871b5d805f8c3671
> 31509f
> > 4e6ec0d2b5f0 100644
> > --- a/drivers/usb/typec/hd3ss3220.c
> > +++ b/drivers/usb/typec/hd3ss3220.c
> > @@ -259,12 +259,12 @@ static int hd3ss3220_probe(struct i2c_client
> *client)
> > goto err_put_fwnode;
> > }
> >
> > - typec_cap.prefer_role = TYPEC_NO_PREFERRED_ROLE;
> > + ret = typec_get_fw_cap(&typec_cap, connector);
> > + if (ret)
> > + goto err_put_role;
>
> You are not leaving any fallback here. Are you sure all the existing systems
> supply those properties?
>
> There is another problem. At least "data-role" property is optional, but that
> will in practice make it a requirement.
I missed that typec_get_fw_cap() was not setting a default if the property is absent.
>
> I think it would be safer to use the values from the device properties only if
> they are available. Otherwise simply use default values.
I'll add back the previous values as defaults before calling typec_get_fw_cap().
That will make data-role and try-power-role optional again, as intended.
However, "power-role" seems to be required by the function. Is this expected?
Or should I write my own fwnode parsing logic?
>
> > typec_cap.driver_data = hd3ss3220;
> > - typec_cap.type = TYPEC_PORT_DRP;
> > - typec_cap.data = TYPEC_PORT_DRD;
> > typec_cap.ops = &hd3ss3220_ops;
> > - typec_cap.fwnode = connector;
> >
> > hd3ss3220->port = typec_register_port(&client->dev, &typec_cap);
> > if (IS_ERR(hd3ss3220->port)) {
>
> thanks,
>
> --
> heikki
Best regards,
Oliver
Powered by blists - more mailing lists