linux-kernel - Re: [PATCH 1/4] phy: miphy365x: Add Device Tree bindings for the MiPHY365x

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: <20140624124634.GO13803@lee--X1>
Date:	Tue, 24 Jun 2014 13:46:34 +0100
From:	Lee Jones <lee.jones@...aro.org>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	Kishon Vijay Abraham I <kishon@...com>,
	Sergei Shtylyov <sergei.shtylyov@...entembedded.com>,
	devicetree <devicetree@...r.kernel.org>,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/4] phy: miphy365x: Add Device Tree bindings for the
 MiPHY365x

> > > > converting all addresses to to resources so drivers can easily pull
> > > > them out using platform_get_resource() and friends.  Pushing the reg
> > > 
> > > right. Can't we use of_address_to_resource here?
> > 
> > We could, but that would be an extra layer.  We'd be pulling the
> > address, putting it into a resource, then pulling it from the resource
> > for use.  If we're going to be pulling addresses out manually, we're
> > probably better off using of_get_address().  But again, we're just
> > carrying out functionality which is already provided by the
> > framework.
> 
> there is also of_ioremap().

Isn't this SPARK only?  And doesn't it require a populated resource?  
Which is what I'm saying is the issue here i.e. we don't have one.

> > > > properties down into a child node means that we have to now iterate
> > > > over the sub-nodes and pull them out manually.  This will lead to a
> > > 
> > > You anyway iterate while creating PHYs based on some constant. Now you have to
> > > iterate over the sub-nodes.
> > > > pretty messy implementation IMHO.
> > 
> > This much is true.
> > 
> > > > Can you point me in the direction of previous implementations where you
> > > > have stipulated the same set of constraints please?
> > > 
> > > ah.. there isn't any. The author of the other multi-phy driver [1] also feels
> > > this will just add to the complexity of the driver.
> > 
> > =:)
> > 
> > > Maybe we should ask the opinion of others?
> > 
> > We could.  I'll CC Arnd as he likes this PHY stuff. :)
> > 
> > > [1] -> http://www.spinics.net/lists/linux-sh/msg32087.html
> 
> Having sub-nodes for each individual PHY managed by a controller seems
> very reasonable to me. Making them show up as separate platform devices
> seems less useful though.

Are there any examples of other nodes with reg properties, but not
compatible strings i.e. ones that aren't probed independently and
aren't platform devices that I can use for reference.  I'm having a
hard time figuring out how to _easily_ obtain indexed addresses
without adding a bunch of new code.  Perhaps if we did something in
the core there would be less overhead overall? 

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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/