linux-kernel - RE: [PATCH 2/4] usb: typec: hd3ss3220: use typec_get_fw_cap() to fill typec

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [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