Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1684014 > unrolled thread

Re: [RESEND PATCH v6 0/8] mfd: Add OF device table to I2C drivers that are missing it

Started byJavier Martinez Canillas <javier@dowhile0.org>
First post2017-07-10 09:50 +0200
Last post2017-07-10 10:40 +0200
Articles 3 — 2 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: [RESEND PATCH v6 0/8] mfd: Add OF device table to I2C drivers  that are missing it Javier Martinez Canillas <javier@dowhile0.org> - 2017-07-10 09:50 +0200
    Re: [RESEND PATCH v6 0/8] mfd: Add OF device table to I2C drivers  that are missing it Lee Jones <lee.jones@linaro.org> - 2017-07-10 10:10 +0200
      Re: [RESEND PATCH v6 0/8] mfd: Add OF device table to I2C drivers  that are missing it Javier Martinez Canillas <javier@dowhile0.org> - 2017-07-10 10:40 +0200

#1684014 — Re: [RESEND PATCH v6 0/8] mfd: Add OF device table to I2C drivers that are missing it

FromJavier Martinez Canillas <javier@dowhile0.org>
Date2017-07-10 09:50 +0200
SubjectRe: [RESEND PATCH v6 0/8] mfd: Add OF device table to I2C drivers that are missing it
Message-ID<u1BC9-28a-7@gated-at.bofh.it>
Hello Lee,

On Thu, Jun 15, 2017 at 8:49 PM, Javier Martinez Canillas
<javier@dowhile0.org> wrote:
>
> This series add OF device ID tables to mfd I2C drivers whose devices are
> either used in Device Tree source files or are listed in binding docs as
> a compatible string.
>
> That's done because the plan is to change the I2C core to report proper OF
> modaliases instead of always reporting a MODALIAS=i2c:<foo> regardless if
> a device was registered via DT or using the legacy platform data mechanism.
>
> So these patches will make sure that mfd I2C drivers modules will continue
> to be autoloaded once the I2C core is changed to report proper OF modalias.
>
> Users didn't have a vendor prefix in the used compatible strings, but since
> there wasn't a DT binding document for these drivers, it can be said that
> were working for mere luck and so this series fixes the users and add a DT
> binding doc for the drivers.
>
> Most patches can be applied independently, with the exception of patches
> 2 to 4 that should be applied in the same tree to keep bisect-ability. I
> suggest these to go through the MFD subsystem tree.
>
> Best regards,
> Javier
>

Are you planning to pick this series? It has been in the list for
months and were resent many times...

Best regards,
Javier

[toc] | [next] | [standalone]


#1684042

FromLee Jones <lee.jones@linaro.org>
Date2017-07-10 10:10 +0200
Message-ID<u1BVw-2uD-29@gated-at.bofh.it>
In reply to#1684014
On Mon, 10 Jul 2017, Javier Martinez Canillas wrote:

> Hello Lee,
> 
> On Thu, Jun 15, 2017 at 8:49 PM, Javier Martinez Canillas
> <javier@dowhile0.org> wrote:
> >
> > This series add OF device ID tables to mfd I2C drivers whose devices are
> > either used in Device Tree source files or are listed in binding docs as
> > a compatible string.
> >
> > That's done because the plan is to change the I2C core to report proper OF
> > modaliases instead of always reporting a MODALIAS=i2c:<foo> regardless if
> > a device was registered via DT or using the legacy platform data mechanism.
> >
> > So these patches will make sure that mfd I2C drivers modules will continue
> > to be autoloaded once the I2C core is changed to report proper OF modalias.
> >
> > Users didn't have a vendor prefix in the used compatible strings, but since
> > there wasn't a DT binding document for these drivers, it can be said that
> > were working for mere luck and so this series fixes the users and add a DT
> > binding doc for the drivers.
> >
> > Most patches can be applied independently, with the exception of patches
> > 2 to 4 that should be applied in the same tree to keep bisect-ability. I
> > suggest these to go through the MFD subsystem tree.
> >
> > Best regards,
> > Javier
> >
> 
> Are you planning to pick this series? It has been in the list for
> months and were resent many times...

I think you exaggerate a little.  Your last Ack (from Linus) was only
collected in v6, which has only been resent once with that Ack
applied. =:)

We are currently only half way through the merge-window.  This patch
will be hoovered up during the early -rcs.  Please be patient around
the time of the merge-window, since Maintainers are either usually
very busy with pull-requests, or taking a 2 minute breather before
the chaos starts over.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

[toc] | [prev] | [next] | [standalone]


#1684051

FromJavier Martinez Canillas <javier@dowhile0.org>
Date2017-07-10 10:40 +0200
Message-ID<u1Coy-2DY-5@gated-at.bofh.it>
In reply to#1684042
On Mon, Jul 10, 2017 at 10:07 AM, Lee Jones <lee.jones@linaro.org> wrote:
> On Mon, 10 Jul 2017, Javier Martinez Canillas wrote:
>
>> Hello Lee,
>>
>> On Thu, Jun 15, 2017 at 8:49 PM, Javier Martinez Canillas
>> <javier@dowhile0.org> wrote:
>> >
>> > This series add OF device ID tables to mfd I2C drivers whose devices are
>> > either used in Device Tree source files or are listed in binding docs as
>> > a compatible string.
>> >
>> > That's done because the plan is to change the I2C core to report proper OF
>> > modaliases instead of always reporting a MODALIAS=i2c:<foo> regardless if
>> > a device was registered via DT or using the legacy platform data mechanism.
>> >
>> > So these patches will make sure that mfd I2C drivers modules will continue
>> > to be autoloaded once the I2C core is changed to report proper OF modalias.
>> >
>> > Users didn't have a vendor prefix in the used compatible strings, but since
>> > there wasn't a DT binding document for these drivers, it can be said that
>> > were working for mere luck and so this series fixes the users and add a DT
>> > binding doc for the drivers.
>> >
>> > Most patches can be applied independently, with the exception of patches
>> > 2 to 4 that should be applied in the same tree to keep bisect-ability. I
>> > suggest these to go through the MFD subsystem tree.
>> >
>> > Best regards,
>> > Javier
>> >
>>
>> Are you planning to pick this series? It has been in the list for
>> months and were resent many times...
>
> I think you exaggerate a little.  Your last Ack (from Linus) was only
> collected in v6, which has only been resent once with that Ack
> applied. =:)
>

You are right, sorry for the impatience.

> We are currently only half way through the merge-window.  This patch
> will be hoovered up during the early -rcs.  Please be patient around
> the time of the merge-window, since Maintainers are either usually
> very busy with pull-requests, or taking a 2 minute breather before
> the chaos starts over.
>

Great, I just was worried that it could fell through the cracks.
Thanks for your answer.

Best regards,
Javier

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web