[GIT PULL] arm64: defconfig: hisilicon config updates for v4.18

[GIT PULL] arm64: defconfig: hisilicon config updates for v4.18

[Wei Xu]

Hi Arnd, Hi Olof,

Please help to pull the following changes.

About the CLOCK_STUB and the MAILBOX consolidate patch,
Jassi and Stephen have acked it.
Could you let me know how to handle this kind case
if it is not OK to be in this pull?
Thanks!

Best Regards,
Wei

---

The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:

  Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)

are available in the Git repository at:

  git://github.com/hisilicon/linux-hisi.git tags/hisi-defconfig-for-4.18

for you to fetch changes up to fafb929ce189a84d9915854f3323dded6cbb3e74:

  hisi: Consolidate the Kconfigs for the CLOCK_STUB and the MAILBOX (2018-05-11 11:49:31 +0100)

----------------------------------------------------------------
ARM64: hisilicon: defconfig updates for 4.18

- Sync the arm64 defconfig with savedefconfig
- Enable the support of ethernet, eMMC, Combo/INNO phy
  and PCIe for Hi3798CV200
- Enable the LPC for hip06 and hip07
- Consolidate the configs of the CLOCK_STUB and the MAILBOX
  for hi6220 and hi3660

----------------------------------------------------------------
Daniel Lezcano (1):
      hisi: Consolidate the Kconfigs for the CLOCK_STUB and the MAILBOX

John Garry (1):
      arm64: defconfig: Enable HISILICON_LPC

Shawn Guo (2):
      arm64: defconfig: sync it with savedefconfig
      arm64: defconfig: enable drivers for Poplar support

 arch/arm64/configs/defconfig  | 87 ++++++++++++++++++-------------------------
 drivers/clk/hisilicon/Kconfig | 13 ++++---
 drivers/mailbox/Kconfig       | 12 ++++--
 3 files changed, 52 insertions(+), 60 deletions(-)

[GIT PULL] arm64: defconfig: hisilicon config updates for v4.18

[Olof Johansson]

Hi Wei,

On Fri, May 11, 2018 at 03:31:38PM +0100, Wei Xu wrote:
> Hi Arnd, Hi Olof,
> 
> Please help to pull the following changes.
> 
> About the CLOCK_STUB and the MAILBOX consolidate patch,
> Jassi and Stephen have acked it.
> Could you let me know how to handle this kind case
> if it is not OK to be in this pull?

I don't think there's any need to group the Kconfig changes with the defconfig
updates here, is there?

So, the clk Kconfig change can go in through the clk maintainer (in one patch),
the mailbox can go in through that maintainer as a separate patch. The update
to the defconfig is just removing what's now the new default, so it's not
urgent to do.

Based on this, can you respin the pull request with that patch dropped? Thanks!


-Olof

[GIT PULL] arm64: defconfig: hisilicon config updates for v4.18

[Daniel Lezcano]

On Mon, May 14, 2018 at 01:14:45PM -0700, Olof Johansson wrote:
> Hi Wei,
> 
> On Fri, May 11, 2018 at 03:31:38PM +0100, Wei Xu wrote:
> > Hi Arnd, Hi Olof,
> > 
> > Please help to pull the following changes.
> > 
> > About the CLOCK_STUB and the MAILBOX consolidate patch,
> > Jassi and Stephen have acked it.
> > Could you let me know how to handle this kind case
> > if it is not OK to be in this pull?
> 
> I don't think there's any need to group the Kconfig changes with the defconfig
> updates here, is there?

I don't have the patches history, but likely this patch should come together with:

https://patchwork.kernel.org/patch/10399799/
https://patchwork.kernel.org/patch/10399801/

Otherwise the compilation options won't be consistent with what is enabled in
the DT.

 
> So, the clk Kconfig change can go in through the clk maintainer (in one patch),
> the mailbox can go in through that maintainer as a separate patch. The update
> to the defconfig is just removing what's now the new default, so it's not
> urgent to do.
> 
> Based on this, can you respin the pull request with that patch dropped? Thanks!
> 
> 
> -Olof

-- 

 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

[GIT PULL] arm64: defconfig: hisilicon config updates for v4.18

[Olof Johansson]

On Tue, May 15, 2018 at 10:28:11AM +0200, Daniel Lezcano wrote:
> On Mon, May 14, 2018 at 01:14:45PM -0700, Olof Johansson wrote:
> > Hi Wei,
> > 
> > On Fri, May 11, 2018 at 03:31:38PM +0100, Wei Xu wrote:
> > > Hi Arnd, Hi Olof,
> > > 
> > > Please help to pull the following changes.
> > > 
> > > About the CLOCK_STUB and the MAILBOX consolidate patch,
> > > Jassi and Stephen have acked it.
> > > Could you let me know how to handle this kind case
> > > if it is not OK to be in this pull?
> > 
> > I don't think there's any need to group the Kconfig changes with the defconfig
> > updates here, is there?
> 
> I don't have the patches history, but likely this patch should come together with:
> 
> https://patchwork.kernel.org/patch/10399799/
> https://patchwork.kernel.org/patch/10399801/
> 
> Otherwise the compilation options won't be consistent with what is enabled in
> the DT.

As long as neither side regresses due to the changes, there should be no
problem. Just because a DT node is added in the tree there's no need to
configure the driver. Or am I missing some aspect of it here?


-Olof

[GIT PULL] arm64: defconfig: hisilicon config updates for v4.18

[Daniel Lezcano]

On Tue, May 15, 2018 at 01:37:55PM -0700, Olof Johansson wrote:
> On Tue, May 15, 2018 at 10:28:11AM +0200, Daniel Lezcano wrote:
> > On Mon, May 14, 2018 at 01:14:45PM -0700, Olof Johansson wrote:
> > > Hi Wei,
> > > 
> > > On Fri, May 11, 2018 at 03:31:38PM +0100, Wei Xu wrote:
> > > > Hi Arnd, Hi Olof,
> > > > 
> > > > Please help to pull the following changes.
> > > > 
> > > > About the CLOCK_STUB and the MAILBOX consolidate patch,
> > > > Jassi and Stephen have acked it.
> > > > Could you let me know how to handle this kind case
> > > > if it is not OK to be in this pull?
> > > 
> > > I don't think there's any need to group the Kconfig changes with the defconfig
> > > updates here, is there?
> > 
> > I don't have the patches history, but likely this patch should come together with:
> > 
> > https://patchwork.kernel.org/patch/10399799/
> > https://patchwork.kernel.org/patch/10399801/
> > 
> > Otherwise the compilation options won't be consistent with what is enabled in
> > the DT.
> 
> As long as neither side regresses due to the changes, there should be no
> problem. Just because a DT node is added in the tree there's no need to
> configure the driver. Or am I missing some aspect of it here?

Actually, the DT node being added do not introduce regressions.

However it is expected by adding the clock stub and the mailbox to have the
cpufreq working which is not necessarily the case because the config may be
inconsistent, so the cpufreq may be working on some config if the user had the
options for the clock and the mailbox enabled but these options can disappear
and not come back because of this Kconfig inconsistencies.

>From my point of view, by adding those DT nodes, it makes sense to give a
consolidated Kconfig coming together and ensuring the drivers are enabled when
the node is parsed.

On the other side, the patch is simple enough to be split and submitted in
separated trees, hoping the maintainer Wu Xei and the branch users keep in mind
if the board does not boot or has inconsistent behavior they will have to
double check the options are enabled for the clock stub and the mailbox.

I don't have a strong opinion on this actually, whatever the decision is, I
will be fine with resubmitting the patch to the different trees, or keep it as
is and merge it through the hisi tree.

  -- Daniel

-- 

 <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

[GIT PULL] arm64: defconfig: hisilicon config updates for v4.18

[Wei Xu]

Hi Daniel,

On 2018/5/16 0:00, Daniel Lezcano wrote:
> On Tue, May 15, 2018 at 01:37:55PM -0700, Olof Johansson wrote:
>> On Tue, May 15, 2018 at 10:28:11AM +0200, Daniel Lezcano wrote:
>>> On Mon, May 14, 2018 at 01:14:45PM -0700, Olof Johansson wrote:
>>>> Hi Wei,
>>>>
>>>> On Fri, May 11, 2018 at 03:31:38PM +0100, Wei Xu wrote:
>>>>> Hi Arnd, Hi Olof,
>>>>>
>>>>> Please help to pull the following changes.
>>>>>
>>>>> About the CLOCK_STUB and the MAILBOX consolidate patch,
>>>>> Jassi and Stephen have acked it.
>>>>> Could you let me know how to handle this kind case
>>>>> if it is not OK to be in this pull?
>>>>
>>>> I don't think there's any need to group the Kconfig changes with the defconfig
>>>> updates here, is there?
>>>
>>> I don't have the patches history, but likely this patch should come together with:
>>>
>>> https://patchwork.kernel.org/patch/10399799/
>>> https://patchwork.kernel.org/patch/10399801/
>>>
>>> Otherwise the compilation options won't be consistent with what is enabled in
>>> the DT.
>>
>> As long as neither side regresses due to the changes, there should be no
>> problem. Just because a DT node is added in the tree there's no need to
>> configure the driver. Or am I missing some aspect of it here?
> 
> Actually, the DT node being added do not introduce regressions.
> 
> However it is expected by adding the clock stub and the mailbox to have the
> cpufreq working which is not necessarily the case because the config may be
> inconsistent, so the cpufreq may be working on some config if the user had the
> options for the clock and the mailbox enabled but these options can disappear
> and not come back because of this Kconfig inconsistencies.
> 
>>From my point of view, by adding those DT nodes, it makes sense to give a
> consolidated Kconfig coming together and ensuring the drivers are enabled when
> the node is parsed.
> 
> On the other side, the patch is simple enough to be split and submitted in
> separated trees, hoping the maintainer Wu Xei and the branch users keep in mind
> if the board does not boot or has inconsistent behavior they will have to
> double check the options are enabled for the clock stub and the mailbox.
> 
> I don't have a strong opinion on this actually, whatever the decision is, I
> will be fine with resubmitting the patch to the different trees, or keep it as
> is and merge it through the hisi tree.

Thanks to make it clear!
In this case, I will drop this patch in the pull firstly.

Best Regards,
Wei

> 
>   -- Daniel
>