From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932913AbcHIQm4 (ORCPT ); Tue, 9 Aug 2016 12:42:56 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:34962 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932237AbcHIQmx (ORCPT ); Tue, 9 Aug 2016 12:42:53 -0400 Date: Tue, 9 Aug 2016 18:43:05 +0200 From: Greg KH To: Tal Shorer Cc: Heikki Krogerus , USB list , "" , balbi@kernel.org Subject: Re: [PATCH v2 00/10] usb: ulpi: remove "dev" field from struct ulpi_ops Message-ID: <20160809164305.GB29539@kroah.com> References: <1470075358-19792-1-git-send-email-tal.shorer@gmail.com> <20160809140411.GB9104@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.2 (2016-07-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Aug 09, 2016 at 06:55:18PM +0300, Tal Shorer wrote: > On Tue, Aug 9, 2016 at 5:04 PM, Greg KH 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? Wait another week or so, if no response, I'll queue it up for 4.9-rc1 :) thanks, greg k-h