Re: [RFC PATCH 46/57] driver: Add variants of driver_find_device()

[Greg KH]

On Tue, Jun 04, 2019 at 11:55:36AM +0100, Suzuki K Poulose wrote:
> 
> 
> On 04/06/2019 09:45, Suzuki K Poulose wrote:
> > 
> > 
> > On 03/06/2019 20:10, Greg KH wrote:
> > > On Mon, Jun 03, 2019 at 04:50:12PM +0100, Suzuki K Poulose wrote:
> > > > Add a wrappers to lookup a device by name for a given driver, by various
> > > > generic properties of a device. This can avoid the proliferation of custom
> > > > match functions throughout the drivers.
> > > > 
> > > > Cc: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
> > > > Cc: "Rafael J. Wysocki" <rafael@xxxxxxxxxx>
> > > > Signed-off-by: Suzuki K Poulose <suzuki.poulose@xxxxxxx>
> > > > ---
> > > >    include/linux/device.h | 44 ++++++++++++++++++++++++++++++++++++++++++++
> > > >    1 file changed, 44 insertions(+)
> > > 
> > > You should put the "here are the new functions that everyone can use"
> > > much earlier in the patch series, otherwise it's hard to dig out.
> > 
> > Sure, I will add it in the respective commits.
> > 
> > > 
> > > And if you send just those as an individual series, and they look good,
> > > I can queue them up now so that everyone else can take the individual
> > > patches through their respective trees.
> > 
> > I see. I think I may be able to do that.
> 
> The API change patch (i.e, "drivers: Unify the match prototype for
> bus_find_device with class_find_device" ) is tricky and prevents us from
> doing
> this. So, that patch has to come via your tree as it must be a one shot change.
> And that would make the individual subsystem patches conflict with your tree.
> Also, it would break the builds until the individual subsystem trees are merged
> with your tree with the new API.
> 
> So I am not quite sure what the best approach here would be.

That's for you to work out :)

one-shot changes are usually not a good idea, there are lots of ways to
prevent this from being required.

good luck!

greg k-h