linux-kernel - Re: [PATCH v7 0/6] Add ChromeOS EC CEC Support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <f1c53c6d-a431-6dd2-8fb1-904fd9c8c7c4@xs4all.nl>
Date:   Mon, 11 Jun 2018 12:17:08 +0200
From:   Hans Verkuil <hverkuil@...all.nl>
To:     Neil Armstrong <narmstrong@...libre.com>,
        Lee Jones <lee.jones@...aro.org>,
        Hans Verkuil <hansverk@...co.com>
Cc:     airlied@...ux.ie, hans.verkuil@...co.com, olof@...om.net,
        seanpaul@...gle.com, sadolfsson@...gle.com, felixe@...gle.com,
        bleung@...gle.com, darekm@...gle.com, marcheu@...omium.org,
        fparent@...libre.com, dri-devel@...ts.freedesktop.org,
        linux-media@...r.kernel.org, intel-gfx@...ts.freedesktop.org,
        linux-kernel@...r.kernel.org, eballetbo@...il.com
Subject: Re: [PATCH v7 0/6] Add ChromeOS EC CEC Support

On 11/06/18 10:56, Neil Armstrong wrote:
> Hi Lee,
> 
> On 11/06/2018 08:03, Lee Jones wrote:
>> On Fri, 08 Jun 2018, Hans Verkuil wrote:
>>> On 08/06/18 10:17, Neil Armstrong wrote:
>>>> On 08/06/2018 09:53, Hans Verkuil wrote:
>>>>> On 06/01/2018 10:19 AM, Neil Armstrong wrote:
>>>>>> Hi All,
>>>>>>
>>>>>> The new Google "Fizz" Intel-based ChromeOS device is gaining CEC support
>>>>>> through it's Embedded Controller, to enable the Linux CEC Core to communicate
>>>>>> with it and get the CEC Physical Address from the correct HDMI Connector, the
>>>>>> following must be added/changed:
>>>>>> - Add the CEC sub-device registration in the ChromeOS EC MFD Driver
>>>>>> - Add the CEC related commands and events definitions into the EC MFD driver
>>>>>> - Add a way to get a CEC notifier with it's (optional) connector name
>>>>>> - Add the CEC notifier to the i915 HDMI driver
>>>>>> - Add the proper ChromeOS EC CEC Driver
>>>>>>
>>>>>> The CEC notifier with the connector name is the tricky point, since even on
>>>>>> Device-Tree platforms, there is no way to distinguish between multiple HDMI
>>>>>> connectors from the same DRM driver. The solution I implemented is pretty
>>>>>> simple and only adds an optional connector name to eventually distinguish
>>>>>> an HDMI connector notifier from another if they share the same device.
>>>>>
>>>>> This looks good to me, which brings me to the next question: how to merge
>>>>> this?
>>>>>
>>>>> It touches on three subsystems (media, drm, mfd), so that makes this
>>>>> tricky.
>>>>>
>>>>> I think there are two options: either the whole series goes through the
>>>>> media tree, or patches 1+2 go through drm and 3-6 through media. If there
>>>>> is a high chance of conflicts in the mfd code, then it is also an option to
>>>>> have patches 3-6 go through the mfd subsystem.
>>>>
>>>> I think patches 3-6 should go in the mfd tree, Lee is used to handle this,
>>>> then I think the rest could go in the media tree.
>>>>
>>>> Lee, do you think it would be possible to have an immutable branch with patches 3-6 ?
>>>>
>>>> Could we have an immutable branch from media tree with patch 1 to be merged in
>>>> the i915 tree for patch 2 ?
>>>>
>>>> Or patch 1+2 could me merged into the i915 tree and generate an immutable branch
>>>
>>> I think patches 1+2 can just go to the i915 tree. The i915 driver changes often,
>>> so going through that tree makes sense. The cec-notifier code is unlikely to change,
>>> and I am fine with that patch going through i915.
>>>
>>>> for media to merge the mfd branch + patch 7 ?
>>>
>>> Patch 7? I only count 6?
>>>
>>> If 1+2 go through drm and 3-6 go through mfd, then media isn't affected at all.
>>> There is chance of a conflict when this is eventually pushed to mainline for
>>> the media Kconfig, but that's all.
>>
>> What are the *build* dependencies within the set?
> 
> Here are the hard the build dependency :
> 
> Patch 2 depends on Patch 1
> Patch 5 depends on Patch 4
> Patch 6 depends on Patches 1 & 4

Ah, I missed the dependency of patch 6 on patch 1. So the whole series needs
to be merged as a single unit.

> 
>>
>> I'd be happy to send out a pull-request for either all of the patches,
>> or just the MFD changes once I've had chance to review them.
>>
> 
> Great, thanks !
> 
> Neil
> 

I'm OK if this goes through the mfd tree.

Regards,

	Hans