Message ID | 1377833794.2552.26.camel@deadeye.wl.decadent.org.uk |
---|---|
State | Accepted, archived |
Delegated to: | David Miller |
Headers | show |
From: Ben Hutchings <bhutchings@solarflare.com> Date: Fri, 30 Aug 2013 04:36:34 +0100 > 1. A little more refactoring. > 2. Remove the unnecessary use of atomic_t that you pointed out. > 3. Add support for starting or queueing firmware requests from atomic > context. > 4. Add hwmon support for additional sensors found on some new boards. > 5. Add support for the EF10 controller architecture, the SFC9100 family > and specifically the SFC9120 controller. Pulled, thanks Ben. Maybe you can get away with just doing "atomic_inc_return()" for the MCDI sequence number bump and avoid the iface lock in those paths? Just an idea. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sat, 2013-08-31 at 22:28 -0400, David Miller wrote: > From: Ben Hutchings <bhutchings@solarflare.com> > Date: Fri, 30 Aug 2013 04:36:34 +0100 > > > 1. A little more refactoring. > > 2. Remove the unnecessary use of atomic_t that you pointed out. > > 3. Add support for starting or queueing firmware requests from atomic > > context. > > 4. Add hwmon support for additional sensors found on some new boards. > > 5. Add support for the EF10 controller architecture, the SFC9100 family > > and specifically the SFC9120 controller. > > Pulled, thanks Ben. > > Maybe you can get away with just doing "atomic_inc_return()" for the > MCDI sequence number bump and avoid the iface lock in those paths? I haven't checked, but I think the spinlock will almost always be uncontended. It can bounce between CPUs, but then so will seqno. So I don't think that would make any significant difference to performance. Ben.
On Sat, 2013-08-31 at 22:28 -0400, David Miller wrote: > From: Ben Hutchings <bhutchings@solarflare.com> > Date: Fri, 30 Aug 2013 04:36:34 +0100 > > > 1. A little more refactoring. > > 2. Remove the unnecessary use of atomic_t that you pointed out. > > 3. Add support for starting or queueing firmware requests from atomic > > context. > > 4. Add hwmon support for additional sensors found on some new boards. > > 5. Add support for the EF10 controller architecture, the SFC9100 family > > and specifically the SFC9120 controller. > > Pulled, thanks Ben. And thanks for reviewing all these changes so quickly. Ben. > Maybe you can get away with just doing "atomic_inc_return()" for the > MCDI sequence number bump and avoid the iface lock in those paths? > > Just an idea.