lkml.org 
[lkml]   [2021]   [Mar]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v3 06/15] mfd: Add ROHM BD71815 ID
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@fi.rohmeurope.com>
> > > > > > > Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
> > > > > > > ---
> > > > > > > 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

\
 
 \ /
  Last update: 2021-03-10 17:39    [W:0.055 / U:0.180 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site