On Thu, 2 Sep 2010, David Miller wrote:
> > Arguably using a union here would make things cleaner and any reasonable
> > ABI will place small unions used as arguments or return values in
> > registers, but I'm not sure if the cost of the rewrite is worth the
>
> Well, sparc 32-bit's ABI for o
From: "Maciej W. Rozycki"
Date: Thu, 2 Sep 2010 16:20:34 +0100 (BST)
> Arguably using a union here would make things cleaner and any reasonable
> ABI will place small unions used as arguments or return values in
> registers, but I'm not sure if the cost of the rewrite is worth the
Well, spar
On Wed, 1 Sep 2010, Grant Likely wrote:
> I've been looking at the phylib code, and specifically at the use of
> the ERR_PTR() pattern. I'm personally not a big fan of ERR_PTR()
> because the compiler cannot type check the result and it runs
> completely counter to the pattern "if (!ptr)" than is
From: Grant Likely
Date: Wed, 1 Sep 2010 12:56:29 -0600
> The error codes in phylib are almost arbitrary and don't really give
> enough information about where the a failure lies. dev_err() is more
> useful for debugging.
If it's using bad error codes, that's only indicative of a bug in
phylib.
On Wed, Sep 1, 2010 at 9:27 AM, David Miller wrote:
> From: Grant Likely
> Date: Wed, 1 Sep 2010 08:42:49 -0600
>
>> It seems to me that phylib is one of the cases where the users (the
>> network drivers) don't actually care about the specific error code
>> when calling phylib functions. The dri
On Sep 1, 2010, at 9:43, Grant Likely wrote:
>
> In the interest of making driver code easier to write and review,
> would you be opposed to a set of patches to remove the ERR_PTR()
> pattern from phylib and its users?
Not at all. I was trying to make sure all the information was available,
From: Grant Likely
Date: Wed, 1 Sep 2010 08:42:49 -0600
> It seems to me that phylib is one of the cases where the users (the
> network drivers) don't actually care about the specific error code
> when calling phylib functions. The drivers only seem to care whether
> or not the function failed,
Hi Andy,
I've been looking at the phylib code, and specifically at the use of
the ERR_PTR() pattern. I'm personally not a big fan of ERR_PTR()
because the compiler cannot type check the result and it runs
completely counter to the pattern "if (!ptr)" than is common for
testing a pointer return va
