Replying to myself, because I may or may not like having conversations with myself :) On Thu, Mar 19, 2015 at 10:36:40AM -0700, Brian Norris wrote: > On Thu, Mar 19, 2015 at 06:02:16PM +0100, Hans de Goede wrote: > > On 19-03-15 16:53, Brian Norris wrote: > > >On Thu, Mar 19, 2015 at 12:10:25PM +0100, Hans de Goede wrote: > > >>On 19-03-15 02:23, Brian Norris wrote: > > >>>Signed-off-by: Brian Norris <computersforpeace@xxxxxxxxx> > > >>>--- > > >>>Light dependency on: > > >>> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/331921.html > > >>>for the surrounding text. > > >>> > > >>> arch/arm/boot/dts/bcm7445.dtsi | 36 ++++++++++++++++++++++++++++++++++++ > > >>> 1 file changed, 36 insertions(+) > > >>> > > >>>diff --git a/arch/arm/boot/dts/bcm7445.dtsi b/arch/arm/boot/dts/bcm7445.dtsi > > >>>index 9eaeac8dce1b..7a7c4d8c2afe 100644 > > >>>--- a/arch/arm/boot/dts/bcm7445.dtsi > > >>>+++ b/arch/arm/boot/dts/bcm7445.dtsi > > >>>@@ -108,6 +108,42 @@ > > >>> brcm,int-map-mask = <0x25c>, <0x7000000>; > > >>> brcm,int-fwd-mask = <0x70000>; > > >>> }; > > >>>+ > > >>>+ sata@f045a000 { > > >>>+ compatible = "brcm,bcm7445-ahci", "brcm,sata3-ahci"; > > >>>+ reg-names = "ahci", "top-ctrl"; > > >>>+ reg = <0x45a000 0xa9c>, <0x458040 0x24>; > > >> > > >>Why not simply drop the second register range here, and the minimal top-ctrl > > >>poking you need in the phy driver's phy_init function ? > > > > > >I agree it's a little ugly, but your recommended solution will not work. > > > > > >The 'top-ctrl' register range includes several SATA functionalities, > > >some of which are required for the PHY and some of which are definitely > > >required for the SATA driver. > > > > I see, but the phy driver is required for the SATA driver anyways, > > and since the BUS_CTRL setting seems to be static it might just as > > well be set by the phy driver. The phy driver also poking some > > common sata glue bits like this busctrl register is not unheard of, > > esp. when these glue bits are in the phy register range. I realized I *do* still have some reservations about moving the SATA_TOP_CTRL register range under the PHY DT binding; it's because all arguments for it seem to rest on descriptions of how the software would *like* to handle it. It's not at all about describing the hardware correctly. I still see SATA_TOP_CTRL as a register resource that belongs to the SATA controller, not to the PHY. It just happens that it has a few registers in it that are also for use in the PHY. So, to best describe the *hardware*, it seems we might split top-ctrl into 3 portions, where the middle gets assigned to a phy description, and the first and last belong to the SATA controller description. But to most easily describe how *software* would best handle them, we might stick all the custom stuff (i.e., all of top-ctrl + phy) into the PHY description. I still think that, practically speaking, the latter should work just fine, and it's only a theoretical concern that suggests the former. Thoughts? > > >We have: > > > > > >0x00 VERSION > > >0x04 BUS_CTRL > > >0x08 TP_CTRL > > >0x0C PHY_CTRL_1 > > >0x10 PHY_CTRL_2 > > >0x14 PHY_CTRL_3 > > >0x18 PHY_CTRL_4 > > >0x1C TP_OUT > > >0x20 CLIENT_INIT_CTRL [snip rest] Brian -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
