linux-kernel - Re: [PATCH v2 00/10] usb: ulpi: remove "dev" field from struct ulpi

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] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 9 Aug 2016 18:55:18 +0300
From:	Tal Shorer <tal.shorer@...il.com>
To:	Greg KH <gregkh@...uxfoundation.org>,
	Heikki Krogerus <heikki.krogerus@...ux.intel.com>
Cc:	USB list <linux-usb@...r.kernel.org>,
	"<linux-kernel@...r.kernel.org>" <linux-kernel@...r.kernel.org>,
	balbi@...nel.org
Subject: Re: [PATCH v2 00/10] usb: ulpi: remove "dev" field from struct ulpi_ops

On Tue, Aug 9, 2016 at 5:04 PM, Greg KH <gregkh@...uxfoundation.org> wrote:
> On Mon, Aug 01, 2016 at 09:15:48PM +0300, Tal Shorer wrote:
>> struct ulpi_ops is defined as follows:
>>
>> struct ulpi_ops {
>>         struct device *dev;
>>         int (*read)(struct ulpi_ops *ops, u8 addr);
>>         int (*write)(struct ulpi_ops *ops, u8 addr, u8 val);
>> };
>>
>> Upon calling ulpi_register_interface(), the struct device argument is
>> put inside the struct ulpi_ops argument's dev field. Later, when
>> calling the actual read()/write() operations, the struct ulpi_ops is
>> passed to them and they use the stored device to access whatever
>> private data they need.
>>
>> This means that if one wishes to reuse the same oprations for multiple
>> interfaces (e.g if we have multiple instances of the same controller),
>> any but the last interface registered will not operate properly (and
>> the one that does work will be at the mercy of the others to not mess
>> it up).
>>
>> I understand that barely any driver uses this bus right now, but I
>> suppose it's there to be used at some point. We might as well fix the
>> design here before we hit this bug.
>>
>> This series fixes this by passing the given struct device directly to
>> the operation functions via ulpi->dev.parent in ulpi_read() and
>> ulpi_write(). It also changes the operations struct to be constant
>> since now nobody has a reason to modify it.
>>
>> Changes from v1:
>>  * Split the actual api change into multiple patch as per Felipe Balbi's
>>    suggestion. The series now first adds the new api, then migrates
>>    everything to use and only then removes the old api.
>>
>> Tal Shorer (10):
>>   usb: ulpi: move setting of ulpi->dev parent up in ulpi_register()
>>   usb: ulpi: add new api functions, {read|write}_dev()
>>   usb: ulpi: use new api functions if available
>>   usb: dwc3: ulpi: use new api
>>   usb: ulpi: remove calls to old api callbacks
>>   usb: ulpi: remove old api callbacks from struct ulpi_ops
>>   usb: ulpi: rename operations {read|write}_dev to simply {read|write}
>>   usb: ulpi: remove "dev" field from struct ulpi_ops
>>   usb: ulpi: make ops struct constant
>>   usb: dwc3: ulpi: make dwc3_ulpi_ops constant
>
> I'd like to get Heikki's ack for this series...
Anything to do on my end except waiting?