Re: [PATCH v3 06/15] mfd: Add ROHM BD71815 ID

[Lee Jones <lee.jones@xxxxxxxxxx>]

On Wed, 10 Mar 2021, Matti Vaittinen wrote:

> 
> On Wed, 2021-03-10 at 13:31 +0000, Lee Jones wrote:
> > On Wed, 10 Mar 2021, Matti Vaittinen wrote:
> > 
> > > On Wed, 2021-03-10 at 11:17 +0000, Lee Jones wrote:
> > > > On Wed, 10 Mar 2021, Vaittinen, Matti wrote:
> > > > 
> > > > > Hello Lee,
> > > > > 
> > > > > On Wed, 2021-03-10 at 10:36 +0000, Lee Jones wrote:
> > > > > > On Mon, 08 Mar 2021, Matti Vaittinen wrote:
> > > > > > 
> > > > > > > Add chip ID for ROHM BD71815 and PMIC so that drivers can
> > > > > > > identify
> > > > > > > this IC.
> > > > > > > 
> > > > > > > Signed-off-by: Matti Vaittinen <
> > > > > > > matti.vaittinen@xxxxxxxxxxxxxxxxx>
> > > > > > > Acked-for-MFD-by: Lee Jones <lee.jones@xxxxxxxxxx>
> > > > > > > ---
> > > > > > >  include/linux/mfd/rohm-generic.h | 1 +
> > > > > > >  1 file changed, 1 insertion(+)
> > > > > > > 
> > > > > > > diff --git a/include/linux/mfd/rohm-generic.h
> > > > > > > b/include/linux/mfd/rohm-generic.h
> > > > > > > index 66f673c35303..e5392bcbc098 100644
> > > > > > > --- a/include/linux/mfd/rohm-generic.h
> > > > > > > +++ b/include/linux/mfd/rohm-generic.h
> > > > > > > @@ -14,6 +14,7 @@ enum rohm_chip_type {
> > > > > > >  	ROHM_CHIP_TYPE_BD71828,
> > > > > > >  	ROHM_CHIP_TYPE_BD9571,
> > > > > > >  	ROHM_CHIP_TYPE_BD9574,
> > > > > > > +	ROHM_CHIP_TYPE_BD71815,
> > > > > > 
> > > > > > Is there a technical reason why these can't be re-ordered?
> > > > > 
> > > > > No, I don't think so.
> > > > > 
> > > > > BTW. there will probably be a (trivial) conflict here as both
> > > > > this
> > > > > series and the BD9576/BD9573 series add an ID here. Let me
> > > > > guess,
> > > > > you'd
> > > > 
> > > > That's fine.  I will resolve that manually.
> > > 
> > > Thanks :)
> > > 
> > > > > like to see them sorted?
> > > > 
> > > > Wouldn't that be nice? :)
> > > Aesthetics is not really my cup of tea. OTOH, if amount of IDs
> > > grow,
> > > then sorting helps spotting whether some IC has an ID here. So yes,
> > > it
> > > kind of makes sense.
> > 
> > By 'nice' I don't mean 'pretty'.
> > 
> > I mean 'improving readability/maintainability would be nice'.
> > 
> > > Can you do sorting while resolving the conflict between series or
> > > do
> > > you want me to
> > > a) do sorting if (when) I re-spin the series
> > > b) send separate sorting patch as a part of this series
> > > c) send sepatate sorting patch after all the pending patches
> > > touching
> > > these IDs have been merged?
> > 
> > I'll let you use your imagination.
> > 
> 
> Right :)
> 
> I'll sort the ID enum when I respin a series which is touching it, ok?
> Or do you want me to resend this even if there were no other changes?
> 
> It's just an old habit to add new enums at the bottom to maintain
> binary compatibility - which does not matter in this case.

I won't let this alone hold up merging of the whole set, but it looks
like you're still short of quite a few reviews.  I'd be surprised if
it's this version that gets applied.

-- 
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog