linux-kernel - Re: [PATCH 1/8] platform/x86: intel_cht_int33fe: Remove connection for the alt mode mux

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] [day] [month] [year] [list]

Message-ID: <c6551374-8954-a940-6805-bceae3ccb543@redhat.com>
Date:   Thu, 31 Jan 2019 11:04:44 +0100
From:   Hans de Goede <hdegoede@...hat.com>
To:     Heikki Krogerus <heikki.krogerus@...ux.intel.com>
Cc:     Andy Shevchenko <andy.shevchenko@...il.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Chen Yu <chenyu56@...wei.com>, Jun Li <jun.li@....com>,
        USB <linux-usb@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/8] platform/x86: intel_cht_int33fe: Remove connection
 for the alt mode mux

Hi,

On 28-01-19 16:27, Heikki Krogerus wrote:
> Hi Hans,
> 
> On Mon, Jan 28, 2019 at 11:44:29AM +0100, Hans de Goede wrote:
>> Hi,
>>
>> On 28-01-19 10:45, Andy Shevchenko wrote:
>>> On Fri, Jan 25, 2019 at 3:17 PM Heikki Krogerus
>>> <heikki.krogerus@...ux.intel.com> wrote:
>>>>
>>>> Driver for fusb302 does not support alternate modes, so the
>>>> connection is not really needed for now. Removing that
>>>> connection description allows us to improve the USB Type-C
>>>> mux API.
>>>>
>>>
>>> Acked-by: Andy Shevchenko <andy.shevchenko@...il.com>
>>> supposed to go via USB tree.
>>
>> I missed the original posting of this, so let me reply here:
>>
>> Nack to this change, I've a patch-set in the works to
>> make display-port over type-c work with 2 devices with a fusb302
>> mux and that needs this connection.
> 
> I can add the connections back in this series after the API
> modification patches, but should the connections be added back only
> after we actually support the alt mode in the driver?
> 
> Btw. I'm preparing patches where I remove struct tcpc_config
> completely. We can do that by taking advantage of the software fwnodes
> (I'll send the patches RFC to give you an idea what I'm talking about).
> 
> That's related as we don't need struct tcpc_config for anything else
> except for alternate modes (which no driver supports currently) after
> that series, and even with the alt modes, it's only a question of
> supplying DT bindings that define the appropriate device properties.
> 
> Also, as a "heads-up": As I explained in the cover-letter, my plan is
> to take advantage of the software fwnodes also with the connections.
> By adding support for reference handling to the software nodes, we
> don't need to maintain the list of connections as we do today. And
> more importantly, we don't need to match using device names, which is
> always fragile.
> 
> That means we will change the connection registration, actually,
> remove connection registration :-). The connections after that can
> always be described in the fwnode for the device.

I see that you've posted a v2 series now and that you've kept the dev_name
matching for platforms where there are no fwnodes to match on, thanks.

I've just reviewed the v2 series and it looks good to me, I will reply
there.

Regards,

Hans