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


Groups > linux.kernel > #1650981 > unrolled thread

Re: [GIT PULL (RESEND)] ARM: uniphier: UniPhier fixes for v4.12

Started byOlof Johansson <olof@lixom.net>
First post2017-05-26 02:10 +0200
Last post2017-05-26 03:50 +0200
Articles 2 — 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: [GIT PULL (RESEND)] ARM: uniphier: UniPhier fixes for v4.12 Olof Johansson <olof@lixom.net> - 2017-05-26 02:10 +0200
    Re: [GIT PULL (RESEND)] ARM: uniphier: UniPhier fixes for v4.12 Masahiro Yamada <yamada.masahiro@socionext.com> - 2017-05-26 03:50 +0200

#1650981 — Re: [GIT PULL (RESEND)] ARM: uniphier: UniPhier fixes for v4.12

FromOlof Johansson <olof@lixom.net>
Date2017-05-26 02:10 +0200
SubjectRe: [GIT PULL (RESEND)] ARM: uniphier: UniPhier fixes for v4.12
Message-ID<tLaZj-6RO-5@gated-at.bofh.it>
On Mon, May 22, 2017 at 11:03:49AM +0900, Masahiro Yamada wrote:
> Hi Arnd, Olof,
> 
> Last week, I thought I found a problem in my pull request,
> but it turned out my misunderstanding.
> 
> So, my pull request I sent is OK.
> I am re-sending this request mail for clarification.
> 
> Here are some ARM UniPhier SoC fixes for v4.12.
> Due to the eMMC driver update, PHY parameters must be specified
> via DT to make the eMMC controller work again.

That's not good, that's a regression in behavior. The driver should
have a fallback when the properties are not present to avoid regressions
like these.

Please work with the driver maintainer to either get them to revert
their change that regresses you, or promptly fix it appropriately with
fallback values.

Also, the driver changes were commited back in March, with plenty of time
to land DT changes well before the merge window. Waiting until the merge
window is closed is not appropriate -- this should have come in earlier.


-Olof

[toc] | [next] | [standalone]


#1651026

FromMasahiro Yamada <yamada.masahiro@socionext.com>
Date2017-05-26 03:50 +0200
Message-ID<tLcy6-7L5-7@gated-at.bofh.it>
In reply to#1650981
Hi Olof,

2017-05-26 8:59 GMT+09:00 Olof Johansson <olof@lixom.net>:
> On Mon, May 22, 2017 at 11:03:49AM +0900, Masahiro Yamada wrote:
>> Hi Arnd, Olof,
>>
>> Last week, I thought I found a problem in my pull request,
>> but it turned out my misunderstanding.
>>
>> So, my pull request I sent is OK.
>> I am re-sending this request mail for clarification.
>>
>> Here are some ARM UniPhier SoC fixes for v4.12.
>> Due to the eMMC driver update, PHY parameters must be specified
>> via DT to make the eMMC controller work again.
>
> That's not good, that's a regression in behavior. The driver should
> have a fallback when the properties are not present to avoid regressions
> like these.

Right.  The care for old DT is missing from the driver change.
Theoretically, it is a regression if Linux 4.12 kernel image is used with
DT from Linux 4.11 tree.

However, all our customer products are based on Linux 4.4 (or older)
so I am sure there is no practical problem.
Because the eMMC driver was not upstreamed at that time,
products kernels are locally patched as needed.

I am upstreaming patches to create a better code base for future products, but
Linux 4.11 and 4.12 are not LTS, so never used at least on socionext products.


> Please work with the driver maintainer to either get them to revert
> their change that regresses you, or promptly fix it appropriately with
> fallback values.

You are right, but this is a different issue.


If you are unhappy with pulling this as a fix
(because it is not DT but the driver that should be fixed),
I can include the DT changes in usual PRs for v4.13-rc1.


As I said above, I admit this is not fatal for us
because socionext kernel developers are co-located
and know the upstream status.



> Also, the driver changes were commited back in March, with plenty of time
> to land DT changes well before the merge window. Waiting until the merge
> window is closed is not appropriate -- this should have come in earlier.

You are right.
But, v4.11-rc4 had already passed and I had already sent the pull request
before the driver change was merged.

I generally try to send my PRs around -rc4
because "sorry, this is too late" is scary.
I should have sent the second pull request.
If you do not mind some after -rc4, I will do late PRs next time.


So, what should I do about this?

If you do not want to pull this, I will move the patches
to for-v4.13 branch, which will be sent around -rc4.

-- 
Best Regards
Masahiro Yamada

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web