[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <55CCA897.5080108@arm.com>
Date: Thu, 13 Aug 2015 09:24:23 -0500
From: Jeremy Linton <jeremy.linton@....com>
To: Robin Murphy <Robin.Murphy@....com>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>
Cc: "steve.glendinning@...well.net" <steve.glendinning@...well.net>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"rafael.j.wysocki@...el.com" <rafael.j.wysocki@...el.com>,
"suravee.suthikulpanit@....com" <suravee.suthikulpanit@....com>,
Catalin Marinas <Catalin.Marinas@....com>,
"grant.likely@...aro.org" <grant.likely@...aro.org>
Subject: Re: [PATCH 1/2] Add a matching set of device_ functions for
determining mac/phy
Hello Robin,
On 08/13/2015 06:57 AM, Robin Murphy wrote:
>> +static void *device_get_mac_addr(struct device *dev,
>> + const char *name, char *addr,
>> + int alen)
>> +{
>> + int ret = device_property_read_u8_array(dev, name, addr, alen);
>> +
>> + if (ret == 0 && is_valid_ether_addr(addr))
>> + return addr;
>> + return NULL;
>> +}
>
> Not sure I understand the logic here - "return the same thing we were
> given if we updated it, or null if we didn't". It's only indicating
> success/failure (the caller can perfectly well cast its own buffer to a
> void * if it needs to), so why wouldn't you just return a normal int
> error code?
No particular reason, other than initially I was trying to keep the
function as similar as possible to the one in of_net. AKA copy paste
job. I can convert the return types, but I was trying for a simple
function rename. That way the users of the of version could be converted
with relative ease, and the drivers which invented their own version of
these functions could be changed to use this instead. Of course, that
plan took a blow, when I added the addr/alen parameters.
Same thing applies for the other function.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists