public inbox for linux-m68k@lists.linux-m68k.org
 help / color / mirror / Atom feed
From: "Song Bao Hua (Barry Song)" <song.bao.hua@hisilicon.com>
To: Finn Thain <fthain@telegraphics.com.au>
Cc: tanxiaofei <tanxiaofei@huawei.com>,
	"jejb@linux.ibm.com" <jejb@linux.ibm.com>,
	"martin.petersen@oracle.com" <martin.petersen@oracle.com>,
	"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linuxarm@openeuler.org" <linuxarm@openeuler.org>,
	"linux-m68k@vger.kernel.org" <linux-m68k@vger.kernel.org>
Subject: RE: Re: [PATCH for-next 00/32] spin lock usage optimization for SCSI drivers
Date: Fri, 12 Feb 2021 02:45:54 +0000	[thread overview]
Message-ID: <48d2891ad9e340028c3b551a83d570b0@hisilicon.com> (raw)
In-Reply-To: <4dcf1410-768e-ae95-33bf-cba093b0751d@telegraphics.com.au>



> -----Original Message-----
> From: Finn Thain [mailto:fthain@telegraphics.com.au]
> Sent: Friday, February 12, 2021 1:09 PM
> To: Song Bao Hua (Barry Song) <song.bao.hua@hisilicon.com>
> Cc: tanxiaofei <tanxiaofei@huawei.com>; jejb@linux.ibm.com;
> martin.petersen@oracle.com; linux-scsi@vger.kernel.org;
> linux-kernel@vger.kernel.org; linuxarm@openeuler.org;
> linux-m68k@vger.kernel.org
> Subject: RE: Re: [PATCH for-next 00/32] spin lock usage optimization for SCSI
> drivers
> 
> On Fri, 12 Feb 2021, Song Bao Hua (Barry Song) wrote:
> 
> >
> > > -----Original Message-----
> > > From: Finn Thain [mailto:fthain@telegraphics.com.au]
> > > Sent: Friday, February 12, 2021 12:57 PM
> > > To: Song Bao Hua (Barry Song) <song.bao.hua@hisilicon.com>
> > > Cc: tanxiaofei <tanxiaofei@huawei.com>; jejb@linux.ibm.com;
> > > martin.petersen@oracle.com; linux-scsi@vger.kernel.org;
> > > linux-kernel@vger.kernel.org; linuxarm@openeuler.org;
> > > linux-m68k@vger.kernel.org
> > > Subject: RE: Re: [PATCH for-next 00/32] spin lock usage optimization for
> SCSI
> > > drivers
> > >
> > >
> > > On Thu, 11 Feb 2021, Song Bao Hua (Barry Song) wrote:
> > >
> > > >
> > > > Actually in m68k, I also saw its IRQ entry disabled interrupts by
> > > > ' move	#0x2700,%sr		/* disable intrs */'
> > > >
> > > > arch/m68k/include/asm/entry.h:
> > > >
> > > > .macro SAVE_ALL_SYS
> > > > 	move	#0x2700,%sr		/* disable intrs */
> > > > 	btst	#5,%sp@(2)		/* from user? */
> > > > 	bnes	6f			/* no, skip */
> > > > 	movel	%sp,sw_usp		/* save user sp */
> > > > ...
> > > >
> > > > .macro SAVE_ALL_INT
> > > > 	SAVE_ALL_SYS
> > > > 	moveq	#-1,%d0			/* not system call entry */
> > > > 	movel	%d0,%sp@(PT_OFF_ORIG_D0)
> > > > .endm
> > > >
> > > > arch/m68k/kernel/entry.S:
> > > >
> > > > /* This is the main interrupt handler for autovector interrupts */
> > > >
> > > > ENTRY(auto_inthandler)
> > > > 	SAVE_ALL_INT
> > > > 	GET_CURRENT(%d0)
> > > > 					|  put exception # in d0
> > > > 	bfextu	%sp@(PT_OFF_FORMATVEC){#4,#10},%d0
> > > > 	subw	#VEC_SPUR,%d0
> > > >
> > > > 	movel	%sp,%sp@-
> > > > 	movel	%d0,%sp@-		|  put vector # on stack
> > > > auto_irqhandler_fixup = . + 2
> > > > 	jsr	do_IRQ			|  process the IRQ
> > > > 	addql	#8,%sp			|  pop parameters off stack
> > > > 	jra	ret_from_exception
> > > >
> > > > So my question is that " move	#0x2700,%sr" is actually disabling
> > > > all interrupts? And is m68k actually running irq handlers
> > > > with interrupts disabled?
> > > >
> > >
> > > When sonic_interrupt() executes, the IPL is 2 or 3 (since either IRQ may
> > > be involved). That is, SR & 0x700 is 0x200 or 0x300. The level 3 interrupt
> > > may interrupt execution of the level 2 handler so an irq lock is used to
> > > avoid re-entrance.
> > >
> > > This patch,
> > >
> > > diff --git a/drivers/net/ethernet/natsemi/sonic.c
> > > b/drivers/net/ethernet/natsemi/sonic.c
> > > index d17d1b4f2585..041354647bad 100644
> > > --- a/drivers/net/ethernet/natsemi/sonic.c
> > > +++ b/drivers/net/ethernet/natsemi/sonic.c
> > > @@ -355,6 +355,8 @@ static irqreturn_t sonic_interrupt(int irq, void *dev_id)
> > >          */
> > >         spin_lock_irqsave(&lp->lock, flags);
> > >
> > > +       printk_once(KERN_INFO "%s: %08lx\n", __func__, flags);
> > > +
> > >         status = SONIC_READ(SONIC_ISR) & SONIC_IMR_DEFAULT;
> > >         if (!status) {
> > >                 spin_unlock_irqrestore(&lp->lock, flags);
> > >
> > > produces this output,
> > >
> > > [    3.800000] sonic_interrupt: 00002300
> >
> > I actually hope you can directly read the register rather than reading
> > a flag which might be a software one not from register.
> >
> 
> Again, the implementation of arch_local_irq_save() may be found in
> arch/m68k/include/asm/irqflags.h

Yes. I have read it. Anyway, I started a discussion in genirq
with you cc-ed:
https://lore.kernel.org/lkml/c46ddb954cfe45d9849c911271d7ec23@hisilicon.com/

And thanks very much for all your efforts to help me understand
M68k. Let's get this clarified thoroughly in genirq level.

In arm, we also have some special high-priority interrupts
which are not NMI but able to preempt normal IRQ. They are
managed by arch-extended APIs rather than common APIs.

Neither arch_irqs_disabled() nor local_irq_disable() API can
access this kind of interrupts. They are using things specific
to ARM like:
local_fiq_disable()
local_fiq_enable()
set_fiq_handler()
disable_fiq()
enable_fiq()
...

so fiq doesn't bother us anyhow in genirq.

> 
> > >
> > > I ran that code in QEMU, but experience shows that Apple hardware works
> > > exactly the same. Please do confirm this for yourself, if you still think
> > > the code and comments in sonic_interrupt are wrong.
> > >
> > > > Best Regards
> > > > Barry
> > > >
> >

Thanks
Barry


      reply	other threads:[~2021-02-12  2:53 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-11 11:01 Re: [PATCH for-next 00/32] spin lock usage optimization for SCSI drivers Song Bao Hua (Barry Song)
2021-02-11 23:57 ` Finn Thain
2021-02-12  0:03   ` Song Bao Hua (Barry Song)
2021-02-12  0:08     ` Finn Thain
2021-02-12  2:45       ` Song Bao Hua (Barry Song) [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=48d2891ad9e340028c3b551a83d570b0@hisilicon.com \
    --to=song.bao.hua@hisilicon.com \
    --cc=fthain@telegraphics.com.au \
    --cc=jejb@linux.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-m68k@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=linuxarm@openeuler.org \
    --cc=martin.petersen@oracle.com \
    --cc=tanxiaofei@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox