linux-kernel - Re: [PATCH v3 0/9] phy: use syscon framework APIs to set ctrl mod reg

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]

Date:	Tue, 15 Dec 2015 16:44:41 +0530
From:	Kishon Vijay Abraham I <kishon@...com>
To:	Arnd Bergmann <arnd@...db.de>
CC:	<devicetree@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
	<linux-omap@...r.kernel.org>, <robh+dt@...nel.org>,
	<pawel.moll@....com>, <mark.rutland@....com>,
	<ijc+devicetree@...lion.org.uk>, <galak@...eaurora.org>,
	<rogerq@...com>, <nsekhar@...com>, <linux-pci@...r.kernel.org>,
	<linux-usb@...r.kernel.org>, <tony@...mide.com>, <t-kristo@...com>
Subject: Re: [PATCH v3 0/9] phy: use syscon framework APIs to set ctrl mod reg

Hi Arnd,

On Tuesday 15 December 2015 04:26 PM, Arnd Bergmann wrote:
> On Tuesday 15 December 2015 14:45:59 Kishon Vijay Abraham I wrote:
>> This series is basically to deprecate using phy-omap-control and use
>> syscon APIs to program the control module registers.
>>
>> Changes from v2:
>> No changes.
>>
>> Changes from v1:
>> *) cleanup ti_pipe3_probe in multiple steps
>> *) other minor cleanups
>>
>> Changes from [1] in PHY patches include
>> *) cleanup ti_pipe3_probe
>> *) have mask, power_on and power_off values in usb_phy_data for
>>    omap-usb2 phy
>>
>> The patches have been pushed to
>>         git://git.ti.com/linux-phy/linux-phy.git syscon
>>
>> [1] -> https://lkml.org/lkml/2015/6/23/189
>>
>> All the testing was done both before applying the dt patches and after
>> applying the dt patches (dt patches will be posted shortly).
>>
> 
> Can you explain here what the conversion is good for? Why do you
> prefer the syscon mapping over a high-level driver in this case?

phy-omap-control driver was added when there was no proper
infrastructure for doing control module initializations. The
phy-omap-control driver is not an 'actual' PHY driver and it
was just a hack to do PHY related control module initializations.
phy-omap-control is also getting unmanageable with the number of
platforms each having number of modules (like USB, SATA, PCIe),
using the same driver for control module initializations.

Now with SYSCON framework being added to the kernel, phy-omap-control
shouldn't be needed and it also provides a uniform API across all the
modules to program the control module.

Thanks
Kishon
--
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/