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:
 <MN0PR12MB595385EF839377E650B47274B78E2@MN0PR12MB5953.namprd12.prod.outlook.com>
Date: Wed, 21 Aug 2024 18:32:13 +0000
From: "Pandey, Radhey Shyam" <radhey.shyam.pandey@....com>
To: Greg KH <gregkh@...uxfoundation.org>
CC: "mka@...omium.org" <mka@...omium.org>, "javier.carrasco@...fvision.net"
	<javier.carrasco@...fvision.net>, "macpaul.lin@...iatek.com"
	<macpaul.lin@...iatek.com>, "jbrunet@...libre.com" <jbrunet@...libre.com>,
	"stefan.eichenberger@...adex.com" <stefan.eichenberger@...adex.com>,
	"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "git
 (AMD-Xilinx)" <git@....com>
Subject: RE: [PATCH v3 1/2] usb: misc: onboard_dev: extend platform data to
 add power on delay field

> -----Original Message-----
> From: Greg KH <gregkh@...uxfoundation.org>
> Sent: Wednesday, August 7, 2024 4:13 PM
> To: Pandey, Radhey Shyam <radhey.shyam.pandey@....com>
> Cc: mka@...omium.org; javier.carrasco@...fvision.net;
> macpaul.lin@...iatek.com; jbrunet@...libre.com;
> stefan.eichenberger@...adex.com; linux-usb@...r.kernel.org; linux-
> kernel@...r.kernel.org; git (AMD-Xilinx) <git@....com>
> Subject: Re: [PATCH v3 1/2] usb: misc: onboard_dev: extend platform data to
> add power on delay field
> 
> On Wed, Jul 31, 2024 at 09:12:27PM +0530, Radhey Shyam Pandey wrote:
> > Introduce dedicated field 'power_on_delay_us' in onboard platform data
> > and update its delay for USB5744 configuration. Hub itself requires some
> > delay after reset to get to state where configuration data is going to
> > be accepted. Without delay upcoming support for configuration via SMBUS
> > is reporting a failure on the first SMBus write.
> >
> > i2c 2-002d: error -ENXIO: BYPASS_UDC_SUSPEND bit configuration failed
> >
> > Similar delay is likely also required for default configuration but
> > because there is enough time (code execution) between reset and usage
> > of the hub any issue is not visible but it doesn't mean delay shouldn't
> > be reflected.
> >
> > Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@....com>
> > Suggested-by: Matthias Kaehlcke <mka@...omium.org>
> 
> This constant addition of "platform data" seems to be duplicating what
> we did before with device tree, right?  Why can't this information be
> there instead?
> 

Yes, similar to existing 'reset_us' field i extended platform data 
to add 'power_on_delay_us' field. I can move it to device tree but 
think there could be question on why we need to add a new binding
just for this property and not do it compatible based platform 
data considering this power_on_delay_us delay is fixed for USB5744?

Thanks,
Radhey

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ