| 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
| ||
|
Message-ID: <CAK7LNAQbWUYuhow5VdNDc+SuttY+u3xh9zk92kLEy9id6TNCFg@mail.gmail.com>
Date: Tue, 3 Apr 2018 21:14:47 +0900
From: Masahiro Yamada <yamada.masahiro@...ionext.com>
To: Lee Jones <lee.jones@...aro.org>
Cc: Andrew Lunn <andrew@...n.ch>, Rob Herring <robh+dt@...nel.org>,
devicetree@...r.kernel.org,
Kunihiko Hayashi <hayashi.kunihiko@...ionext.com>,
Felipe Balbi <felipe.balbi@...ux.intel.com>,
linux-usb@...r.kernel.org,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Jassi Brar <jaswinder.singh@...aro.org>,
Masami Hiramatsu <masami.hiramatsu@...aro.org>,
Arnd Bergmann <arnd@...db.de>,
linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [Question] MFD driver that handles clocks/resets and populates
child nodes
2018-04-03 17:03 GMT+09:00 Lee Jones <lee.jones@...aro.org>:
> On Mon, 02 Apr 2018, Andrew Lunn wrote:
>
>> On Mon, Apr 02, 2018 at 10:21:01PM +0900, Masahiro Yamada wrote:
>> > 2018-04-02 21:04 GMT+09:00 Andrew Lunn <andrew@...n.ch>:
>> > >> The maintainer of DWC3, Felipe Balbi, requested to
>> > >> split the glue layer driver into small parts such as
>> > >> reset, regulator, phy, etc.
>> > >
>> > > What exactly did Felipe ask for? Did he ask that the patch be split
>> > > up, one patch per reset, regulator, phy etc?
>> >
>> >
>> > Yeah. That is what we understood from his comments.
>> >
>> >
>> > These are the feed-backs from him.
>> >
>> > https://lkml.org/lkml/2018/1/23/298
>> > https://lkml.org/lkml/2018/1/24/352
>>
>> > > Are all these resources used just by the DWC3? Or is it a true MFD,
>> > > multiple functions?
>> >
>> > I do not think this is a real MFD.
>> >
>> > This is a DWC3 glue layer, i.e.
>> > a collection of misc registers that control
>> > the DWC3 IP.
>> >
>> >
>> > Just splitting it into small pieces
>> > to use PHY, reset, regulator framework in Linux.
>> >
>> > Of course, the price of this approach
>> > is so cluttered Device Tree,
>> > honestly I do not like it much.
>>
>> This however the correct way to do this. You should have a phy driver,
>> and a regulator driver, and a reset driver. The DWC3 then uses
>> phandles to these drivers.
>>
>> How is the IO map area 65b00000 split up. Can you cleanly separate it
>> into sub areas, which do not overlap, so you have a sub-area for the
>> PHY driver, a sub-area for the regulator driver and a sub-area for the
>> reset area? If you can cleanly split it up, you don't need an MFD. If
>> however the registers are in overlapping areas, you do need an
>> MFD. The MFD core provides access to the registers, while its children
>> implement PHY, reset, regulator etc.
>
> This device certainly sounds like an MFD to me.
>
> Can you share the DT you've written please?
This is still under the internal review in Socionext,
but I attached it below FWIW.
(I am not the author of this DT.
Written by Kunihiko Hayashi,
and clocks/resets parts were slightly modified by me.)
Just skimming the driver, I guess it will be possible to flatten
the node structure by separating the register space into sub-areas.
If this is success, we do not the MFD driver.
usb@...00000 {
compatible = "socionext,uniphier-ld20-usb3-glue",
"syscon";
reg = <0x65b00000 0x1000>;
clock-names = "usb";
clocks = <&sys_clk 14>;
reset-names = "usb";
resets = <&sys_rst 14>;
usb_rst: reset {
compatible = "socionext,uniphier-ld20-usb3-reset";
#reset-cells = <1>;
};
regulators {
compatible = "socionext,uniphier-ld20-usb3-regulator";
usb_vbus0: vbus-0 { };
usb_vbus1: vbus-1 { };
usb_vbus2: vbus-2 { };
usb_vbus3: vbus-3 { };
};
usb_hsphy: hs-phy {
compatible = "socionext,uniphier-ld20-usb3-hsphy";
#address-cells = <1>;
#size-cells = <0>;
#phy-cells = <0>;
clock-names = "phy-clk0", "phy-clk1";
clocks = <&sys_clk 16>, <&sys_clk 17>;
reset-names = "phy-rst0", "phy-rst1";
resets = <&sys_rst 16>, <&sys_rst 17>;
port0-supply = <&usb_vbus0>;
port1-supply = <&usb_vbus1>;
port2-supply = <&usb_vbus2>;
port3-supply = <&usb_vbus3>;
port@0 {
reg = <0>;
nvmem-cell-names = "rterm", "sel_t",
"hs_i";
nvmem-cells = <&usb_rterm0>,
<&usb_sel_t0>,
<&usb_hs_i0>;
};
port@1 {
reg = <1>;
nvmem-cell-names = "rterm", "sel_t",
"hs_i";
nvmem-cells = <&usb_rterm1>,
<&usb_sel_t1>,
<&usb_hs_i0>;
};
port@2 {
reg = <2>;
nvmem-cell-names = "rterm", "sel_t",
"hs_i";
nvmem-cells = <&usb_rterm2>,
<&usb_sel_t2>,
<&usb_hs_i2>;
};
port@3 {
reg = <3>;
nvmem-cell-names = "rterm", "sel_t",
"hs_i";
nvmem-cells = <&usb_rterm3>,
<&usb_sel_t3>,
<&usb_hs_i2>;
};
};
usb_ssphy: ss-phy {
compatible = "socionext,uniphier-ld20-usb3-ssphy";
#address-cells = <1>;
#size-cells = <0>;
#phy-cells = <0>;
reset-names = "phy-rst0", "phy-rst1";
resets = <&sys_rst 18>, <&sys_rst 19>;
port0-supply = <&usb_vbus0>;
port1-supply = <&usb_vbus1>;
port@0 {
reg = <0>;
};
port@1 {
reg = <1>;
};
};
};
--
Best Regards
Masahiro Yamada
Powered by blists - more mailing lists