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

Message-ID: <20190128152727.GG7262@kuha.fi.intel.com>
Date:   Mon, 28 Jan 2019 17:27:27 +0200
From:   Heikki Krogerus <heikki.krogerus@...ux.intel.com>
To:     Hans de Goede <hdegoede@...hat.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 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.

thanks,

-- 
heikki