[meta-ti] mis-definition of SLEWCTRL_FAST in dt-bindings amxxxx header

[Peter A. Bigot]

On 01/09/2015 03:46 PM, Denys Dmytriyenko wrote:
> On Fri, Dec 26, 2014 at 10:29:39AM -0600, Peter A. Bigot wrote:
>> On 12/26/2014 09:49 AM, Christian d'Heureuse wrote:
>>> Hi Peter
>>>
>>> I stumbled on the same error in am33xx.h as you described in September:
>>> https://lists.yoctoproject.org/pipermail/meta-ti/2014-September/005211.html
>>>
>>>
>>> Did you get any reactions?
>> Just the follow-up theorizing it'd been fixed upstream.  As of
>> today, it's still wrong in both am33xx.h and am43xx.h when
>> "upstream" means the torvalds master branch.
>>
>> I keep hoping a TIer will step up, but if not I suppose somebody
>> else has to do it.
>>
>> Maybe E2E will yield results. http://e2e.ti.com/support/arm/sitara_arm/f/791/p/367445/1382229#1382229
>
> Peter,
>
> For the record, here are 2 replies from one of our kernel developers (Cc-ed)
> that I received for my inquiries on your question back in September, stating
> it's in upstream, after which I closed it:
>
>
>> 1. Should rather be SLEWCONTROL like DRA7 rather than _FAST or _SLOW. that
>> avoids all kind of messed up translation.
>>
>> OR should define both _FAST and SLOW for all SoCs equally..
>
>> 2. Even better - if the change - like this one is already present in
>> upstream kernel(which in this case is actually in upstream) - ask the public
>> person to directly ask on linux-omap mailing list (public).
>
> Since meta-ti is not specifically a kernel mailing list, there's less chance
> to get it resolved through here. Please use corresponding upstream mailing
> lists - linux-omap at vger.kernel.org is the closest one here, or either
> devicetree at vger.kernel.org or linux-soc at vger.kernel.org or even E2E forums.
>
> You wouldn't send this to Debian, Ubuntu or even Buildroot mailing lists,
> would you? Similarly, this list is for OpenEmbedded/Yocto layer - the best I
> can do is forward questions and answers back and forth, which is not very
> efficient. So, reporting this on one of the kernel lists would have yelded
> better results, I'd say, since that's where kernel devs are hanging out -
> they don't usually frequent Yocto lists, unfortunately.

OK.  I understand it's out of scope for you and you're frustrated too; 
thanks for trying.  There are enough people aware of it now who should 
have some stake in getting it fixed that I'm not going to search out 
other places to report it.

Peter