Message ID | 1467756433-25062-4-git-send-email-f.fainelli@gmail.com |
---|---|
State | Changes Requested, archived |
Delegated to: | David Miller |
Headers | show |
On Tue, Jul 05, 2016 at 03:07:12PM -0700, Florian Fainelli wrote:
> Make it clear that these functions take a device_node structure pointer
Hi Florian
Didn't we agree that we would only support a single device via a C
coded platform data structure?
All the functions you are renaming will never be called in that
case. So i think they can retain there names. You have no need to add
none device node equivalents.
So lets drop this patch.
Andrew
On 07/05/2016 03:36 PM, Andrew Lunn wrote: > On Tue, Jul 05, 2016 at 03:07:12PM -0700, Florian Fainelli wrote: >> Make it clear that these functions take a device_node structure pointer > > Hi Florian > > Didn't we agree that we would only support a single device via a C > coded platform data structure? That is true for the devices I know about, both in and out of tree, however, while discussing offline with Vivien it seemed like there was a potential need for having a x86-based platform which could need that, Vivien do you think this platform could be in-tree one day (if not already)? > > All the functions you are renaming will never be called in that > case. So i think they can retain there names. You have no need to add > none device node equivalents. > > So lets drop this patch. > > Andrew >
> That is true for the devices I know about, both in and out of tree, > however, while discussing offline with Vivien it seemed like there was a > potential need for having a x86-based platform which could need that, > Vivien do you think this platform could be in-tree one day (if not already)? x86 can do device tree. And if it is a complex board, it probably needs more of the device tree features like fixed-phys, phy-mode, devlink when it lands, etc. If this board really does come to mainline, we should consider support for it, one way or the other, but until then, i prefer KISS. Andrew
Hi, Florian Fainelli <f.fainelli@gmail.com> writes: > On 07/05/2016 03:36 PM, Andrew Lunn wrote: >> On Tue, Jul 05, 2016 at 03:07:12PM -0700, Florian Fainelli wrote: >>> Make it clear that these functions take a device_node structure pointer >> >> Hi Florian >> >> Didn't we agree that we would only support a single device via a C >> coded platform data structure? > > That is true for the devices I know about, both in and out of tree, > however, while discussing offline with Vivien it seemed like there was a > potential need for having a x86-based platform which could need that, > Vivien do you think this platform could be in-tree one day (if not already)? This customer platform is not mainlined yet and I cannot say today if it will be. However it is likely to get a new revision soon with 3 interconnected 6352 hanging the x86 Baytrail. DT on x86 is possible, but not straight-forward, and thanks to Florian's work the pdata support is almost there for free. >> All the functions you are renaming will never be called in that >> case. So i think they can retain there names. You have no need to add >> none device node equivalents. >> >> So lets drop this patch. The patch is not big and I think it doesn't hurt to add that explicit suffix, I'd keep the patch in the series. Thanks, Vivien
On 07/05/2016 06:59 PM, Vivien Didelot wrote: > Hi, > > Florian Fainelli <f.fainelli@gmail.com> writes: > >> On 07/05/2016 03:36 PM, Andrew Lunn wrote: >>> On Tue, Jul 05, 2016 at 03:07:12PM -0700, Florian Fainelli wrote: >>>> Make it clear that these functions take a device_node structure pointer >>> >>> Hi Florian >>> >>> Didn't we agree that we would only support a single device via a C >>> coded platform data structure? >> >> That is true for the devices I know about, both in and out of tree, >> however, while discussing offline with Vivien it seemed like there was a >> potential need for having a x86-based platform which could need that, >> Vivien do you think this platform could be in-tree one day (if not already)? > > This customer platform is not mainlined yet and I cannot say today if it > will be. However it is likely to get a new revision soon with 3 > interconnected 6352 hanging the x86 Baytrail. > > DT on x86 is possible, but not straight-forward, and thanks to Florian's > work the pdata support is almost there for free. > >>> All the functions you are renaming will never be called in that >>> case. So i think they can retain there names. You have no need to add >>> none device node equivalents. >>> >>> So lets drop this patch. > > The patch is not big and I think it doesn't hurt to add that explicit > suffix, I'd keep the patch in the series. Either way is fine with me really, we can drop this patch, add it later, not add it, up to you guys. I think the 3 others could go in as they are pretty self contained, your call David.
diff --git a/net/dsa/dsa2.c b/net/dsa/dsa2.c index 3a782ceef716..bdde5d217326 100644 --- a/net/dsa/dsa2.c +++ b/net/dsa/dsa2.c @@ -110,8 +110,8 @@ static bool dsa_port_is_cpu(struct dsa_port *port) return false; } -static bool dsa_ds_find_port(struct dsa_switch *ds, - struct device_node *port) +static bool dsa_ds_find_port_dn(struct dsa_switch *ds, + struct device_node *port) { u32 index; @@ -121,8 +121,8 @@ static bool dsa_ds_find_port(struct dsa_switch *ds, return false; } -static struct dsa_switch *dsa_dst_find_port(struct dsa_switch_tree *dst, - struct device_node *port) +static struct dsa_switch *dsa_dst_find_port_dn(struct dsa_switch_tree *dst, + struct device_node *port) { struct dsa_switch *ds; u32 index; @@ -132,7 +132,7 @@ static struct dsa_switch *dsa_dst_find_port(struct dsa_switch_tree *dst, if (!ds) continue; - if (dsa_ds_find_port(ds, port)) + if (dsa_ds_find_port_dn(ds, port)) return ds; } @@ -153,7 +153,7 @@ static int dsa_port_complete(struct dsa_switch_tree *dst, if (!link) break; - dst_ds = dsa_dst_find_port(dst, link); + dst_ds = dsa_dst_find_port_dn(dst, link); of_node_put(link); if (!dst_ds) @@ -557,7 +557,7 @@ static int dsa_parse_ports_dn(struct device_node *ports, struct dsa_switch *ds) return 0; } -static int dsa_parse_member(struct device_node *np, u32 *tree, u32 *index) +static int dsa_parse_member_dn(struct device_node *np, u32 *tree, u32 *index) { int err; @@ -603,7 +603,7 @@ static int _dsa_register_switch(struct dsa_switch *ds, struct device *dev) u32 tree, index; int err; - err = dsa_parse_member(np, &tree, &index); + err = dsa_parse_member_dn(np, &tree, &index); if (err) return err;
Make it clear that these functions take a device_node structure pointer Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> --- net/dsa/dsa2.c | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-)