netdev - Re: [PATCH] fsl_pq_mdio: Clean up tbi address configuration

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 1 Dec 2011 23:16:23 -0600
From:	Andy Fleming <afleming@...il.com>
To:	Kumar Gala <galak@...nel.crashing.org>
Cc:	David Miller <davem@...emloft.net>, afleming@...escale.com,
	netdev@...r.kernel.org
Subject: Re: [PATCH] fsl_pq_mdio: Clean up tbi address configuration

On Thu, Dec 1, 2011 at 10:38 PM, Kumar Gala <galak@...nel.crashing.org> wrote:
>
> On Nov 13, 2011, at 11:26 PM, David Miller wrote:
>
>> From: Andy Fleming <afleming@...escale.com>
>> Date: Fri, 11 Nov 2011 09:10:39 -0600
>>
>>> The code for setting the address of the internal TBI PHY was
>>> convoluted enough without a maze of ifdefs. Clean it up a bit
>>> so we allow the logic to fail down to -ENODEV at the end of
>>> the if/else ladder, rather than using ifdefs to repeat the same
>>> failure code over and over.
>>>
>>> Also, remove the support for the auto-configuration. I'm not aware of
>>> anyone using it, and it ends up using the bus mutex before it's been
>>> initialized.
>>>
>>> Signed-off-by: Andy Fleming <afleming@...escale.com>
>>
>> Applied, thanks.
>
> I believe we need this on mainline otherwise we get something like:

I concur. I also have a 2 separate patches I will send out tonight,
which are independent of each other, but related.

The first will revert c3e072f8a6c5625028531c40ec65f7e301531be2 (net:
fsl_pq_mdio: fix non tbi phy access), which hides a bug. The second
will fix the bug in our p1/p2 device trees so that they all have tbi
nodes.

The first patch only applies to net-next (reverts a commit in that
tree). The second patch only applies to Kumar's "next" branch (applies
changes on top of significant device-tree changes). I have no idea how
you guys want to deal with that. Personally, I think that the patches
can be applied to their respective trees, and anyone who is working
off the bleeding edge can go find the appropriate patch in the other
tree. If we get my first patch into mainline, then I imagine Kumar's
tree will have all the necessary components...

Anyway, I will leave that to you. I will submit the two patches in the
next hour or so.

Andy
--
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