From: Thomas Chou <hidden> Date: 2011-01-25 07:07:37
Signed-off-by: Thomas Chou <redacted>
---
v2 specify part numbers in compat as Grant suggested.
drivers/net/smc91x.c | 11 +++++++++++
1 files changed, 11 insertions(+), 0 deletions(-)
From: Thomas Chou <hidden> Date: 2011-01-25 12:11:52
Signed-off-by: Thomas Chou <redacted>
---
v2 specify part numbers in compat as Grant suggested.
v3 more specific part name.
drivers/net/smc91x.c | 11 +++++++++++
1 files changed, 11 insertions(+), 0 deletions(-)
You should not unconditionally put the 'of' device table into the
module image, otherwise the module will be marked as being able to
support OF based devices but the code to support that won't actually
be comiled into the module.
From: Thomas Chou <hidden> Date: 2011-01-26 05:19:48
Signed-off-by: Thomas Chou <redacted>
---
v2 specify part numbers in compat as Grant suggested.
v3 more specific part name.
v4 include match table only for OF as David suggested.
drivers/net/smc91x.c | 13 +++++++++++++
1 files changed, 13 insertions(+), 0 deletions(-)
From: Grant Likely <hidden> Date: 2011-01-26 05:52:58
On Tue, Jan 25, 2011 at 10:22 PM, Thomas Chou [off-list ref] wrote:
Signed-off-by: Thomas Chou <redacted>
---
v2 specify part numbers in compat as Grant suggested.
v3 more specific part name.
v4 include match table only for OF as David suggested.
drivers/net/smc91x.c | 13 +++++++++++++
1 files changed, 13 insertions(+), 0 deletions(-)
Looks okay to me.
Reviewed-by: Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
From: David Miller <davem@davemloft.net> Date: 2011-01-26 06:41:36
From: Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
Date: Tue, 25 Jan 2011 22:52:36 -0700
On Tue, Jan 25, 2011 at 10:22 PM, Thomas Chou [off-list ref] wrote:
quoted
Signed-off-by: Thomas Chou <redacted>
---
v2 specify part numbers in compat as Grant suggested.
v3 more specific part name.
v4 include match table only for OF as David suggested.
drivers/net/smc91x.c | 13 +++++++++++++
1 files changed, 13 insertions(+), 0 deletions(-)
Looks okay to me.
Reviewed-by: Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
From: Nicolas Pitre <nico@fluxnic.net> Date: 2011-01-26 15:17:38
On Wed, 26 Jan 2011, Thomas Chou wrote:
Signed-off-by: Thomas Chou <redacted>
---
v2 specify part numbers in compat as Grant suggested.
v3 more specific part name.
v4 include match table only for OF as David suggested.
The smc91x driver relies on many parameters which are platform specific,
such as the bus width capabilities, register spacing due to special bus
wiring, interrupt signal level, LED configuration, whether or not to
configure the chip with a wait state, etc. Will the device tree support
take care of those things?
Nicolas
From: Grant Likely <hidden> Date: 2011-01-26 15:33:17
On Wed, Jan 26, 2011 at 8:17 AM, Nicolas Pitre [off-list ref] wrote:
On Wed, 26 Jan 2011, Thomas Chou wrote:
quoted
Signed-off-by: Thomas Chou <redacted>
---
v2 specify part numbers in compat as Grant suggested.
v3 more specific part name.
v4 include match table only for OF as David suggested.
The smc91x driver relies on many parameters which are platform specific,
such as the bus width capabilities, register spacing due to special bus
wiring, interrupt signal level, LED configuration, whether or not to
configure the chip with a wait state, etc. Will the device tree support
take care of those things?
Short answer, yes
In general bindings are written and documented as they are needed. In
this specific case,yes the device configuration should be encoded into
the device tree node. It is okay for now to not wire up any of that
configuration if the defaults work for Thomas' platform, but to be
useful in the long run they do need to be added.
Typically a block or function call is added to the drivers .probe hook
to decode device tree data if the of_node pointer is set.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.