[elrepo] el7: Intel Braswell i2c host adapter support

[Phil Perry]

On 18/01/16 08:43, Björn Gerhart wrote:
> 
>> Am 16.01.2016 um 17:09 schrieb Phil Perry <phil at elrepo.org>:
>>
>>> On 15/01/16 18:12, Phil Perry wrote:
>>>> On 15/01/16 17:16, Akemi Yagi wrote:
>>>>> On Fri, Jan 15, 2016 at 6:19 AM, Björn Gerhart <gerhart at posteo.de> wrote:
>>>>>
>>>>> Hi folks,
>>>>>
>>>>> afaik the el7 kernel yet doesn't support the i2c host adapter of the
>>>>> Braswell chipset by Intel. However, it's possible to simply compile a newer
>>>>> release (taken from 3.19) of the i2c-i801 source code against the el7
>>>>> kernel, and the module seems to work properly.
>>>>>
>>>>> Is anybody out there already working on a kmod-i2c-i801 rpm package, or
>>>>> otherwise: does it make sense to contribute it for general availability in
>>>>> elrepo?
>>>>>
>>>>> General rpmbuild knowledge available on my side, but not into contributing
>>>>> for elrepo yet.
>>>>>
>>>>> Best - Björn
>>>>
>>>> We always welcome contributions.
>>>>
>>>> You can send it to us as an srpm file. Or if you are comfortable with git,
>>>> please submit it through our git ( https://github.com/elrepo/packages ) by
>>>> following the procedure shown in http://elrepo.org/tiki/GitHub .
>>>>
>>>> Thank you,
>>>> Akemi
>>>
>>> Or this is something I could pick up for you, if you're happy to assist
>>> / test as you've already done most of the hard work by confirming that
>>> the kernel-3.19 source code compiles cleanly and works.
>>>
>>> The only thing I'd add is I'd rather run with code backported from a
>>> kernel that is still supported longterm so we can easily continue to
>>> backport any upstream security fixes and maintain the package in elrepo.
>>> Thus, either 3.18 (if it contains support), or 4.1 (if it compiles
>>> cleanly) kernels would be possible candidates. Your thoughts welcome as
>>> you clearly have more experience with the module code than me.
>>
>> I've built the package for you and just released it to the elrepo
>> repository - it should show up on the mirrors shortly.
>>
>>
>> kmod-i2c-i801-0.0-2.el7.elrepo.x86_64.rpm
>> i2c-i801-kmod-0.0-2.el7.elrepo.src.rpm
>>
> That's very kind of you Phil, thanks so much! What would be an appropriate versioning scheme to give a hint pointing to the origin module's source code revision in the kernel tree? I saw that e.g. the nct6775 module package uses the related git revision within the rpm release data.
> 

The elrepo standard where a module is backported from an upstream kernel
is the use any internal module versioning if present or version 0.0 as
in this case if no versioning information is provided. Thus the version
will never indicate the kernel it is backported from. The changelog
should always say which kernel the module was backported from, in this
case kernel-4.1.15, so that's where users should look for that information.

So this module will likely progress as 0.0-1, 0.0-2, 0.0-3 etc for each
new release.

The nct6775 example you refer to is slightly different as it is not
backported from the upstream kernel but is maintained out of the kernel
tree in a separate git repository, thus we use the git date notation to
indicate the date the source code was pulled from the git tree.

Hope that makes sense

>> The required Braswell support first appeared in kernel-3.19, so I've
>> backported the module from kernel-4.1.15. As 4.1 is a longterm kernel
>> branch it should be easy to maintain the module for the supported life
>> of that kernel.
>>
> Sounds good.
> 
>> It's probably worth filing a bug with Red Hat requesting the module be
>> updated in the RHEL kernel. State what you've done (i.e, simple backport
>> from 4.1 works) as proof of principle and someone might pick it up for you.
>>
> Thanks, I'll go for that.
> 

If you file a bug with Red Hat I'd appreciate if you could post a link
here so I may follow it. If we can get native support added to the RHEL
kernel then we can deprecate our kmod package.

>> I'd appreciate if you could test and confirm the package works as expected.
>>
> The package gets installed properly on my CentOS 7.2, and the module detects the hardware properly. Excellent!
> 

Brilliant - thanks for testing and confirming.

> Best - Björn