Re: [PATCH] UHCI: add missing memory barriers

Re: [PATCH] UHCI: add missing memory barriers

[Benjamin Herrenschmidt]

On Fri, 2005-12-16 at 11:59 -0800, Linux Kernel Mailing List wrote:
> tree d094f197975af7ef7b80006dbea0f5d38915f88b
> parent 42f3ab42875a52af7e711803bfb8d8d7cca84c1c
> author Alan Stern <stern@rowland.harvard.edu> Sat, 17 Dec 2005 03:09:01 -0800
> committer Linus Torvalds <torvalds@g5.osdl.org> Sat, 17 Dec 2005 03:25:25 -0800
> 
> [PATCH] UHCI: add missing memory barriers
> 
> This patch (as617) adds a couple of memory barriers that Ben H. forgot in
> his recent suspend/resume fix.

I didn't think they were necessary but they certainly won't hurt and
it's not a hot code path...

>  	pci_write_config_word(to_pci_dev(uhci_dev(uhci)), USBLEGSUP, 0);
> +	mb();

Isn't pci config space access always fully synchronous ?

>  	clear_bit(HCD_FLAG_HW_ACCESSIBLE, &hcd->flags);
>  	uhci->hc_inaccessible = 1;
>  	hcd->poll_rh = 0;
> @@ -738,6 +739,7 @@ static int uhci_resume(struct usb_hcd *h
>  	 * really don't want to keep a stale HCD_FLAG_HW_ACCESSIBLE=0
>  	 */
>  	set_bit(HCD_FLAG_HW_ACCESSIBLE, &hcd->flags);
> +	mb();

I don't think that one matters much but it won't hurt for sure.

>  	if (uhci->rh_state == UHCI_RH_RESET)	/* Dead */
>  		return 0;
> -
> To unsubscribe from this list: send the line "unsubscribe git-commits-head" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] UHCI: add missing memory barriers

[Alan Stern]

On Sat, 17 Dec 2005, Benjamin Herrenschmidt wrote:

> > This patch (as617) adds a couple of memory barriers that Ben H. forgot in
> > his recent suspend/resume fix.
> 
> I didn't think they were necessary but they certainly won't hurt and
> it's not a hot code path...

True.

> >  	pci_write_config_word(to_pci_dev(uhci_dev(uhci)), USBLEGSUP, 0);
> > +	mb();
> 
> Isn't pci config space access always fully synchronous ?

If it is, it's not documented.

Looking at the PCI code, I see that the accesses are protected by a 
spinlock.  Does that guarantee in-order execution of writes to 
configuration space with respect to writes to regular memory?  On all 
platforms?  If yes, then this barrier is not needed.

> > @@ -738,6 +739,7 @@ static int uhci_resume(struct usb_hcd *h
> >  	 * really don't want to keep a stale HCD_FLAG_HW_ACCESSIBLE=0
> >  	 */
> >  	set_bit(HCD_FLAG_HW_ACCESSIBLE, &hcd->flags);
> > +	mb();
> 
> I don't think that one matters much but it won't hurt for sure.

Actually this one only needs to be smp_mb(), although the reasoning is a
bit subtle.  Anyway, as you said, leaving the barriers in certainly won't
hurt anything.

Alan Stern

Re: [PATCH] UHCI: add missing memory barriers

[Benjamin Herrenschmidt]

> Looking at the PCI code, I see that the accesses are protected by a 
> spinlock.  Does that guarantee in-order execution of writes to 
> configuration space with respect to writes to regular memory?  On all 
> platforms?  If yes, then this barrier is not needed.

Hrm... there is a wmb in the unlock path, I suppose on all platforms,
and iirc, ppc & ppc64 implementation of config space accesses do a full
sync. On x86, they are IO ports, thus I would expect them to be fully
sychronous, but I can't guarantee that semantic is respected accross all
architectures.