On Thu, May 15, 2014 at 01:47:33PM +0530, Rahul Sharma wrote:
On 15 May 2014 13:12, Thierry Reding thierry.reding@gmail.com wrote:
On Thu, May 15, 2014 at 10:49:37AM +0530, Rahul Sharma wrote:
On 15 May 2014 03:44, Thierry Reding thierry.reding@gmail.com wrote:
On Thu, May 15, 2014 at 12:47:21AM +0530, Rahul Sharma wrote:
[...]
+#define PHY_NR 5
I'm not sure that this belongs here either. It's not a value that will ever appear in a DT source file.
I want it to grow along with new additions in the phy list else catastrophic. This will look unrelated in driver.
But this is in no way growing automatically as it is. Whoever adds a new type of PHY will need to manually increment this define. Furthermore the driver will need to be updated to cope with this anyway.
Not automatically. What I meant was If keeping it at end of the list, it is not possible that somebody skip the updation of PHY_NR when adding a new phy type.
It's perhaps not as likely, but still possible.
If I leave a comment at the end of the list to update PHY_NR (after moving it to driver), that also serves the purpose.
I don't think this is needed either. Like I said earlier, since the driver has an internal maximum number of PHYs that it supports the maximum that can be specified in the DTS is irrelevant. If it doesn't support a new one, then it will simply return an error. And I would assume that if somebody added support for a new PHY type then they probably wouldn't forget to update the driver since they're modifying it anyway and testing will fail if they don't.
Thierry