[PATCH 1/2] net: macb: Add phy-handle DT support

2018-03-07 Thread Brad Mouring
// first mac's mdio bus (it's wired thusly) ... } The work done to add the phy_node in the first place (dacdbb4dfc1a1: "net: macb: add fixed-link node support") will consume the device_node (if found). Signed-off-by: Brad Mouring --- drivers/net/ethernet/cadence/macb_main.c |

[PATCH 2/2] Documentation: macb: Document phy-handle optional binding

2018-03-07 Thread Brad Mouring
Signed-off-by: Brad Mouring --- Documentation/devicetree/bindings/net/macb.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/net/macb.txt b/Documentation/devicetree/bindings/net/macb.txt index 27966ae741e0..457d5ae16f23 100644 --- a/Documentation

[PATCH] net: phy: Move interrupt check from phy_check to phy_interrupt

2018-03-07 Thread Brad Mouring
allow other devices on this irq a chance to check if it was their interrupt. Signed-off-by: Brad Mouring --- drivers/net/phy/phy.c | 16 ++-- 1 file changed, 6 insertions(+), 10 deletions(-) diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c index e3e29c2b028b..ff1aa815568f

Re: [PATCH] net: phy: Move interrupt check from phy_check to phy_interrupt

2018-03-08 Thread Brad Mouring
On Thu, Mar 08, 2018 at 05:29:05PM +0100, Andrew Lunn wrote: > On Wed, Mar 07, 2018 at 04:50:42PM -0600, Brad Mouring wrote: > > If multiple phys share the same interrupt (e.g. a multi-phy chip), > > the first device registered is the only one checked as phy_interrupt > &g

Re: [PATCH] net: phy: Move interrupt check from phy_check to phy_interrupt

2018-03-08 Thread Brad Mouring
Thanks for the feedback, Sergei. On Thu, Mar 08, 2018 at 10:41:04PM +0300, Sergei Shtylyov wrote: > Hello! > > On 03/08/2018 01:50 AM, Brad Mouring wrote: > > > If multiple phys share the same interrupt (e.g. a multi-phy chip), > > the first device registered is

[PATCH] net: phy: Tell caller result of phy_change()

2018-03-08 Thread Brad Mouring
interrupt source. Signed-off-by: Brad Mouring --- drivers/net/phy/phy.c | 13 +++-- include/linux/phy.h | 1 - 2 files changed, 7 insertions(+), 7 deletions(-) diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c index e3e29c2b028b..ebce9f2b2742 100644 --- a/drivers/net/phy/p

Re: [1/2] net: macb: Add phy-handle DT support

2018-03-08 Thread Brad Mouring
On Thu, Mar 08, 2018 at 06:32:47PM +0100, Andrew Lunn wrote: > On Wed, Mar 07, 2018 at 04:42:56PM -0600, Brad Mouring wrote: > > This optional binding (as described in the ethernet DT bindings doc) > > directs the netdev to the phydev to use. This is useful for a phy > > chip

[PATCH net v3] net: phy: Tell caller result of phy_change()

2018-03-08 Thread Brad Mouring
interrupt source. Signed-off-by: Brad Mouring --- drivers/net/phy/phy.c | 145 +- include/linux/phy.h | 1 - 2 files changed, 72 insertions(+), 74 deletions(-) diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c index e3e29c2b028b..df

Re: [PATCH 1/2] net/macb: Adding comments to various #defs to make interpretation easier

2015-01-14 Thread Brad Mouring
On Wed, Jan 14, 2015 at 12:26:09AM -0500, David Miller wrote: > From: Xander Huff > Date: Tue, 13 Jan 2015 16:15:50 -0600 > > > This change is to help improve at-a-glace knowledge of the purpose of the > > various Cadence MACB/GEM registers. Comments are more helpful for human > > readability tha

Re: [patch V3 1/7] rtmutex: Deobfuscate chain walk

2014-06-10 Thread Brad Mouring
eixner I also am not a huge fan of the verbiage of the commit message here. Steven's makes more sense to me, and you basically say the same thing in the actual commit message. Reviewed-by: Brad Mouring -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" i

Re: [patch V3 2/7] rtmutex: Clarify the boost/deboost part

2014-06-10 Thread Brad Mouring
st few weeks. Reviewed-by: Brad Mouring -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/

Re: [patch V3 4/7] rtmutex: Siplify remove_waiter()

2014-06-10 Thread Brad Mouring
tatic void remove_waiter(struct rt_mute > { > int first = (waiter == rt_mutex_top_waiter(lock)); I agree that @first is ambiguous and would prefer something like @is_top_waiter Reviewed-by: Brad Mouring -- To unsubscribe from this list: send the line "unsubscribe linux-kernel"

Re: [patch V3 3/7] rtmutex: Document pi chain walk

2014-06-10 Thread Brad Mouring
On Mon, Jun 09, 2014 at 08:28:08PM -, Thomas Gleixner wrote: > Add commentry to document the chain walk and the protection mechanisms > and their scope. > > Signed-off-by: Thomas Gleixner Reviewed-by: Brad Mouring -- To unsubscribe from this list: send the line "unsubsc

Re: [patch V3 7/7] rtmutex: Avoid pointless requeueing in the deadlock detection chain walk

2014-06-10 Thread Brad Mouring
On Mon, Jun 09, 2014 at 08:28:10PM -, Thomas Gleixner wrote: > In case the dead lock detector is enabled we follow the lock chain to > the end in rt_mutex_adjust_prio_chain, even if we could stop earlier > due to the priority/waiter constellation. > > But once we are not longer the top priorit

Re: [patch V3 6/7] rtmutex: Cleanup deadlock detector debug logic

2014-06-10 Thread Brad Mouring
On Mon, Jun 09, 2014 at 08:28:10PM -, Thomas Gleixner wrote: > The conditions under which deadlock detection is conducted are unclear > and undocumented. > > Add constants instead of using 0/1 and provide a selection function > which hides the additional debug dependency from the calling code.

Re: [PATCH 1/1] rtmutex: Handle when top lock owner changes

2014-06-04 Thread Brad Mouring
task_top_pi_waiter(task)) > > top_waiter is C, and D has pi_waiters, and C is still the top pi waiter > for D. > > Then we get to the test. > > lock == orig_lock || rt_mutex_owner(lock) == top_task > > lock happens to be L2 and this is the original lock we wanted to ta

Re: [PATCH 1/1] rtmutex: Handle when top lock owner changes

2014-06-04 Thread Brad Mouring
On Wed, Jun 04, 2014 at 10:16:12AM -0400, Steven Rostedt wrote: > On Wed, 4 Jun 2014 08:05:25 -0500 > "Brad Mouring" wrote: > > > A->L2 > > > > This is a slight variation on what I was seeing. To use the nomenclature > > that you

Re: [PATCH 1/1] rtmutex: Handle when top lock owner changes

2014-06-04 Thread Brad Mouring
On Wed, Jun 04, 2014 at 10:58:23AM -0400, Steven Rostedt wrote: > On Wed, 4 Jun 2014 09:38:30 -0500 > "Brad Mouring" wrote: > > > On Wed, Jun 04, 2014 at 10:16:12AM -0400, Steven Rostedt wrote: > > > On Wed, 4 Jun 2014 08:05:25 -0500 > > > "Brad

Re: [PATCH 1/1] rtmutex: Handle when top lock owner changes

2014-06-04 Thread Brad Mouring
On Wed, Jun 04, 2014 at 08:02:16PM +0200, Thomas Gleixner wrote: > On Wed, 4 Jun 2014, Steven Rostedt wrote: > > > On Wed, 4 Jun 2014 17:32:37 +0200 (CEST) > > Thomas Gleixner wrote: > > > > > T3 releases L3 > > > T2 gets L3 > > > T2 drops L3 and L2 > > > T2 blocks on L4 held by T4 > > > T4 bloc

Re: [PATCH 1/1] rtmutex: Handle when top lock owner changes

2014-06-04 Thread Brad Mouring
On Wed, Jun 04, 2014 at 09:53:16PM +0200, Thomas Gleixner wrote: > On Wed, 4 Jun 2014, Brad Mouring wrote: > > On Wed, Jun 04, 2014 at 08:02:16PM +0200, Thomas Gleixner wrote: > > > I'll fixup the check so it wont break the real deadlock case and queue > > > it. >

[PATCH] rtmutex: Handle when top lock owner changes

2014-06-04 Thread Brad Mouring
additional check for this situation before reporting a deadlock to userspace. Signed-off-by: Brad Mouring Acked-by: Scot Salmon Acked-by: Ben Shelton Tested-by: Jeff Westfahl --- kernel/locking/rtmutex.c | 20 1 file changed, 20 insertions(+) diff --git a/kernel/locking