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

[Matti Vaittinen <matti.vaittinen@xxxxxxxxxxxxxxxxx>]

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.

Br,
	Matti Vaittinen