netdev - Re: [PATCH net-next 07/16] sfc: Limit scope of a Falcon A1 IRQ workaround

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]

Message-ID: <1377557225.16071.21.camel@deadeye.wl.decadent.org.uk>
Date:	Mon, 26 Aug 2013 23:47:05 +0100
From:	Ben Hutchings <bhutchings@...arflare.com>
To:	Sergei Shtylyov <sergei.shtylyov@...entembedded.com>
CC:	David Miller <davem@...emloft.net>, <netdev@...r.kernel.org>,
	<linux-net-drivers@...arflare.com>
Subject: Re: [PATCH net-next 07/16] sfc: Limit scope of a Falcon A1 IRQ
 workaround

On Mon, 2013-08-26 at 16:31 +0400, Sergei Shtylyov wrote:
> Hello.
> 
> On 26-08-2013 3:03, Ben Hutchings wrote:
> 
> > We unconditionally acknowledge legacy interrupts just before disabling
> > them.  This workaround is needed on Falcon A1 but probably not on
> > later chips where the legacy interrupt mechanism is different.  It was
> > also originally done after the IRQ handler was removed, not before.
> > Restore the original behaviour for Falcon A1 only by doing this
> > acknowledgement in the efx_nic_type::fini operation.
> 
> > Signed-off-by: Ben Hutchings <bhutchings@...arflare.com>
> > ---
> >   drivers/net/ethernet/sfc/falcon.c |    4 ++--
> >   drivers/net/ethernet/sfc/nic.c    |    7 -------
> >   drivers/net/ethernet/sfc/nic.h    |    1 -
> >   3 files changed, 2 insertions(+), 10 deletions(-)
> 
> > diff --git a/drivers/net/ethernet/sfc/falcon.c b/drivers/net/ethernet/sfc/falcon.c
> > index f8de382..4492129 100644
> > --- a/drivers/net/ethernet/sfc/falcon.c
> > +++ b/drivers/net/ethernet/sfc/falcon.c
> > @@ -336,7 +336,7 @@ static void falcon_prepare_flush(struct efx_nic *efx)
> >    *
> >    * NB most hardware supports MSI interrupts
> >    */
> > -inline void falcon_irq_ack_a1(struct efx_nic *efx)
> > +static inline void falcon_irq_ack_a1(struct efx_nic *efx)
> 
>     Does inline make sense still when this now is referenced indirectly?

It's not inlined in the cleanup code, either before or after this
change.  But we do want this to be inlined in the following function,
falcon_legacy_interrupt_a1().  So I think it does make sense.

Ben.

> >   {
> >   	efx_dword_t reg;
> >
> > @@ -2343,7 +2343,7 @@ const struct efx_nic_type falcon_a1_nic_type = {
> >   	.remove = falcon_remove_nic,
> >   	.init = falcon_init_nic,
> >   	.dimension_resources = falcon_dimension_resources,
> > -	.fini = efx_port_dummy_op_void,
> > +	.fini = falcon_irq_ack_a1,
> >   	.monitor = falcon_monitor,
> >   	.map_reset_reason = falcon_map_reset_reason,
> >   	.map_reset_flags = falcon_map_reset_flags,
> 
> WBR, Sergei
> 

-- 
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

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