linux-kernel - Re: [PATCH 8/8] phy: add driver for TI TUSB1210 ULPI PHY

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: <20150203113739.GA3640@kuha.fi.intel.com>
Date:	Tue, 3 Feb 2015 13:37:39 +0200
From:	Heikki Krogerus <heikki.krogerus@...ux.intel.com>
To:	David Cohen <david.a.cohen@...ux.intel.com>,
	Felipe Balbi <balbi@...com>
Cc:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Baolu Lu <baolu.lu@...ux.intel.com>, linux-usb@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Kishon Vijay Abraham I <kishon@...com>
Subject: Re: [PATCH 8/8] phy: add driver for TI TUSB1210 ULPI PHY

Hi David, Felipe,

> > > > why would you have dwc3 mess around with the PHY's gpios ? Doesn't look
> > > > very good.
> > > 
> > > ..but unfortunately we can't use the bus without it :(. We depend on
> > > being able to read the vendor and product id's in the bus driver.
> > 
> > Doesn't the ugly platform device case look less ugly than this?
> 
> The platform device would in any case need to be created only for this
> case. We can't any more just create the phy device unconditionally for
> every PCI platform like it was created before, as it's clear now the
> PHY device can be be created from other sources. It was a risk always.
> 
> But the big problem is that since the PHY on your board is ULPI PHY,
> it will make it really difficult to add the ULPI bus support. And like
> I said in my previous mail, we would really need it for the boards
> that expect the PHY driver to provide functions like charger
> detection. We don't need it only for BYT based boards.
> 
> So on top of the above, since the GPIO resources are given to dwc3, I
> actually think that my hack is better then the platform device.

So what do you guys think we should do? I can't figure out how would
we make the platform device work with ulpi bus. If we think about
handling this in ulpi bus driver by setting setting the gpios before
attempting to access the phy, which I'm not completely against, we
have couple of problems.

Firstly, the gpio resources are given to the dwc3 in this case,
while normally they will be given to separate device object for the
phy.

Secondly, these gpios were not labeled in DSDT, but apparently
requesting the gpios with index will be deprecated and not acceptable
any more. With the remaining platforms that have not labeled the gpios
we have to bind the gpios to labels separately in the drivers. With
ACPI platforms the labels are introduced in struct acpi_gpio_mapping
which needs to be registered with acpi_dev_add_driver_gpios(). Check
net/rfkill/rfkill-gpio.c as an example how to use it.

I think those points would make this too platform specific case to be
handled in the ulpi bus driver.

Suggestions? I still think the correct thing to do is to handle this
in the quirk in dwc3-pci.c.

Cheers,

-- 
heikki
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/