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

Groups > linux.kernel > #1706105 > unrolled thread

Re: [PATCH v2 3/5] thermal: imx: Add support for reading OCOTP through nvmem

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: [PATCH v2 3/5] thermal: imx: Add support for reading OCOTP  through nvmem Zhang Rui <rui.zhang@intel.com> - 2017-08-08 09:30 +0200
    Re: [PATCH v2 3/5] thermal: imx: Add support for reading OCOTP  through nvmem Srinivas Kandagatla <srinivas.kandagatla@linaro.org> - 2017-08-08 13:10 +0200
      Re: [PATCH v2 3/5] thermal: imx: Add support for reading OCOTP  through nvmem Srinivas Kandagatla <srinivas.kandagatla@linaro.org> - 2017-08-08 13:50 +0200
        Re: [PATCH v2 3/5] thermal: imx: Add support for reading OCOTP  through nvmem Zhang Rui <rui.zhang@intel.com> - 2017-08-08 15:00 +0200

#1706105 — Re: [PATCH v2 3/5] thermal: imx: Add support for reading OCOTP through nvmem

On Tue, 2017-07-25 at 16:08 +0800, Shawn Guo wrote:
> On Fri, Jul 14, 2017 at 05:11:08PM +0300, Leonard Crestez wrote:
> > 
> > On newer imx SOCs accessing OCOTP directly is wrong because the
> > ocotp clock
> > needs to be enabled first. Add support for reading those same
> > values through
> > the nvmem API instead.
> > 
> > The older path is preserved for compatibility with older dts and
> > because it
> > works correctly on imx6qdl chips.
> > 
> > Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
> Acked-by: Shawn Guo <shawnguo@kernel.org>

I'm okay with the thermal change.
We still need ACK for the nvmem changes in this patch series.

thanks,
rui

[toc] | [next] | [standalone]

#1706335

On 08/08/17 08:21, Zhang Rui wrote:
> On Tue, 2017-07-25 at 16:08 +0800, Shawn Guo wrote:
>> On Fri, Jul 14, 2017 at 05:11:08PM +0300, Leonard Crestez wrote:
>>>
>>> On newer imx SOCs accessing OCOTP directly is wrong because the
>>> ocotp clock
>>> needs to be enabled first. Add support for reading those same
>>> values through
>>> the nvmem API instead.
>>>
>>> The older path is preserved for compatibility with older dts and
>>> because it
>>> works correctly on imx6qdl chips.
>>>
>>> Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
>> Acked-by: Shawn Guo <shawnguo@kernel.org>
> 
> I'm okay with the thermal change.
> We still need ACK for the nvmem changes in this patch series.
NVMEM changes are already sent to Greg K H with other patches 
(https://lkml.org/lkml/2017/7/26/164), should appear in next.


> 
> thanks,
> rui
> 

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

#1706411

On 08/08/17 12:38, Leonard Crestez wrote:
> On Tue, 2017-08-08 at 12:00 +0100, Srinivas Kandagatla wrote:
>> On 08/08/17 08:21, Zhang Rui wrote:
>>> On Tue, 2017-07-25 at 16:08 +0800, Shawn Guo wrote:
>>>> On Fri, Jul 14, 2017 at 05:11:08PM +0300, Leonard Crestez wrote:
> 
>>>>> On newer imx SOCs accessing OCOTP directly is wrong because the
>>>>> ocotp clock
>>>>> needs to be enabled first. Add support for reading those same
>>>>> values through
>>>>> the nvmem API instead.
>>>>>
>>>>> The older path is preserved for compatibility with older dts and
>>>>> because it
>>>>> works correctly on imx6qdl chips.
>>>>>
>>>>> Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
>>>> Acked-by: Shawn Guo <shawnguo@kernel.org>
> 
>>> I'm okay with the thermal change.
>>> We still need ACK for the nvmem changes in this patch series.
> 
>> NVMEM changes are already sent to Greg K H with other patches
>> (https://lkml.org/lkml/2017/7/26/164), should appear in next.
> 
> These patches have a compile-time dependency on each other. Wouldn't it
> make more sense for the whole series to go through a single maintainer
> tree, atomically? Most of the changes are in driver/thermal.

I was expecting that the nvmem change go in as fix in a rc release so 
that you could apply the other patches after that.

Let me ping Greg about this!!
> 
> I'm really very confused about how series that touch multiple areas are
> applied. It seems to be a mostly ad-hoc process.
> 
> --
> Regards,
> Leonard
> 

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

#1706522

On Tue, 2017-08-08 at 12:44 +0100, Srinivas Kandagatla wrote:
> > 


> 
> On 08/08/17 12:38, Leonard Crestez wrote:
> > 
> > On Tue, 2017-08-08 at 12:00 +0100, Srinivas Kandagatla wrote:
> > > 
> > > On 08/08/17 08:21, Zhang Rui wrote:
> > > > 
> > > > On Tue, 2017-07-25 at 16:08 +0800, Shawn Guo wrote:
> > > > > 
> > > > > On Fri, Jul 14, 2017 at 05:11:08PM +0300, Leonard Crestez
> > > > > wrote:
> > > 
> > > > 
> > > > > 
> > > > > > 
> > > > > > On newer imx SOCs accessing OCOTP directly is wrong because
> > > > > > the
> > > > > > ocotp clock
> > > > > > needs to be enabled first. Add support for reading those
> > > > > > same
> > > > > > values through
> > > > > > the nvmem API instead.
> > > > > > 
> > > > > > The older path is preserved for compatibility with older
> > > > > > dts and
> > > > > > because it
> > > > > > works correctly on imx6qdl chips.
> > > > > > 
> > > > > > Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
> > > > > Acked-by: Shawn Guo <shawnguo@kernel.org>
> > > 
> > > > 
> > > > I'm okay with the thermal change.
> > > > We still need ACK for the nvmem changes in this patch series.
> > > 
> > > NVMEM changes are already sent to Greg K H with other patches
> > > (https://lkml.org/lkml/2017/7/26/164), should appear in next.
> > These patches have a compile-time dependency on each other.
> > Wouldn't it
> > make more sense for the whole series to go through a single
> > maintainer
> > tree, atomically? Most of the changes are in driver/thermal.
> I was expecting that the nvmem change go in as fix in a rc release
> so 
> that you could apply the other patches after that.
> 
> Let me ping Greg about this!!

As Shawn is okay with patch 4/5 and 5/5, I guess I can queue patch 1/5,
3/5, 4/5, 5/5 for 4.14-rc1, if the nvmem patch can catch 4.13, or I can
queue the full patch set for 4.14, with Srinivas' ACK.

thanks,
rui
> > 
> > I'm really very confused about how series that touch multiple areas
> > are
> > applied. It seems to be a mostly ad-hoc process.
> > 
> > --
> > Regards,
> > Leonard
> > 

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web