All of lore.kernel.org
 help / color / mirror / Atom feed
From: gregory.clement@free-electrons.com (Gregory CLEMENT)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 1/3] usb: orion-echi: Add support for the Armada 3700
Date: Thu, 09 Mar 2017 16:22:37 +0100	[thread overview]
Message-ID: <878toelbk2.fsf@free-electrons.com> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1703091006390.1912-100000@iolanthe.rowland.org> (Alan Stern's message of "Thu, 9 Mar 2017 10:13:19 -0500 (EST)")

Hi Alan,
 
 On jeu., mars 09 2017, Alan Stern <stern@rowland.harvard.edu> wrote:

>> @@ -47,6 +47,21 @@
>>  #define USB_PHY_IVREF_CTRL	0x440
>>  #define USB_PHY_TST_GRP_CTRL	0x450
>>  
>> +#define USB_SBUSCFG		0x90
>> +#define	    USB_SBUSCFG_BAWR_SHIFT	    0x6
>> +#define	    USB_SBUSCFG_BARD_SHIFT	    0x3
>> +#define	    USB_SBUSCFG_AHBBRST_SHIFT	    0x0
>
> Shift amounts are just regular numbers.  Giving them in hex is 
> confusing because it leads people to think the bit pattern has some 
> particular significance, which it doesn't.  Which would you rather see: 
> (0x24 << 0x12) or (0x24 << 18)?

Right

>
>> +
>> +/* BAWR = BARD = 3 : Align read/write bursts packets larger than 128 bytes */
>> +#define USB_SBUSCFG_BAWR_ALIGN_128B	(0x3 << USB_SBUSCFG_BAWR_SHIFT)
>> +#define USB_SBUSCFG_BARD_ALIGN_128B	(0x3 << USB_SBUSCFG_BARD_SHIFT)
>> +/* AHBBRST = 3	   : Align AHB Burst to INCR16 (64 bytes) */
>> +#define USB_SBUSCFG_AHBBRST_INCR16	(0x3 << USB_SBUSCFG_AHBBRST_SHIFT)
>
> Besides, since these shift amounts are each used only once, it would be
> simpler (and easier to read!) to do:
>
> +#define USB_SBUSCFG_BAWR_ALIGN_128B  (0x3 << 6)
> +#define USB_SBUSCFG_BARD_ALIGN_128B  (0x3 << 3)
> +/* AHBBRST = 3          : Align AHB Burst to INCR16 (64 bytes) */
> +#define USB_SBUSCFG_AHBBRST_INCR16   (0x3 << 0)
>

I think the intent was to document the register layout. But I have no
problem following your advice.

>
>> +
>> +#define USB_SBUSCFG_DEF_VAL (USB_SBUSCFG_BAWR_ALIGN_128B	\
>> +			     | USB_SBUSCFG_BARD_ALIGN_128B	\
>> +			     | USB_SBUSCFG_AHBBRST_INCR16)
>> +
>>  #define DRIVER_DESC "EHCI orion driver"
>>  
>>  #define hcd_to_orion_priv(h) ((struct orion_ehci_hcd *)hcd_to_ehci(h)->priv)
>> @@ -151,8 +166,31 @@ ehci_orion_conf_mbus_windows(struct usb_hcd *hcd,
>>  	}
>>  }
>>  
>> +static int ehci_orion_drv_reset(struct usb_hcd *hcd)
>> +{
>> +	struct device *dev = hcd->self.controller;
>> +	int retval;
>> +
>> +	retval = ehci_setup(hcd);
>> +	if (retval)
>> +		dev_err(dev, "ehci_setup failed %d\n", retval);
>
> Was lack of this error message in the original driver a source of 
> problems?  If not, I submit that there's no good reason to add it.
>

I will remove the message and replace it by "return retval;" as
suggested below.

Thanks,

Gregory

>> +
>> +	/*
>> +	 * For SoC without hlock, need to program sbuscfg value to guarantee
>> +	 * AHB master's burst would not overrun or underrun FIFO.
>> +	 *
>> +	 * sbuscfg reg has to be set after usb controller reset, otherwise
>> +	 * the value would be override to 0.
>> +	 */
>> +	if (of_device_is_compatible(dev->of_node, "marvell,armada-3700-ehci"))
>> +		wrl(USB_SBUSCFG, USB_SBUSCFG_DEF_VAL);
>
> Do you want to do this even when retval != 0?
>
> Alan Stern

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

WARNING: multiple messages have this Message-ID (diff)
From: Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
To: Alan Stern <stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz@public.gmane.org>
Cc: Greg Kroah-Hartman
	<gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>,
	linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Jason Cooper <jason-NLaQJdtUoK4Be96aLqz0jA@public.gmane.org>,
	Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org>,
	Sebastian Hesselbarth
	<sebastian.hesselbarth-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Thomas Petazzoni
	<thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	Nadav Haklai <nadavh-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org>,
	Victor Gu <xigu-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org>,
	Marcin Wojtas <mw-nYOzD4b6Jr9Wk0Htik3J/w@public.gmane.org>,
	Wilson Ding <dingwei-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org>,
	Hua Jing <jinghua-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org>,
	Neta Zur Hershkovits
	<neta-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org>
Subject: Re: [PATCH v2 1/3] usb: orion-echi: Add support for the Armada 3700
Date: Thu, 09 Mar 2017 16:22:37 +0100	[thread overview]
Message-ID: <878toelbk2.fsf@free-electrons.com> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1703091006390.1912-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org> (Alan Stern's message of "Thu, 9 Mar 2017 10:13:19 -0500 (EST)")

Hi Alan,
 
 On jeu., mars 09 2017, Alan Stern <stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz@public.gmane.org> wrote:

>> @@ -47,6 +47,21 @@
>>  #define USB_PHY_IVREF_CTRL	0x440
>>  #define USB_PHY_TST_GRP_CTRL	0x450
>>  
>> +#define USB_SBUSCFG		0x90
>> +#define	    USB_SBUSCFG_BAWR_SHIFT	    0x6
>> +#define	    USB_SBUSCFG_BARD_SHIFT	    0x3
>> +#define	    USB_SBUSCFG_AHBBRST_SHIFT	    0x0
>
> Shift amounts are just regular numbers.  Giving them in hex is 
> confusing because it leads people to think the bit pattern has some 
> particular significance, which it doesn't.  Which would you rather see: 
> (0x24 << 0x12) or (0x24 << 18)?

Right

>
>> +
>> +/* BAWR = BARD = 3 : Align read/write bursts packets larger than 128 bytes */
>> +#define USB_SBUSCFG_BAWR_ALIGN_128B	(0x3 << USB_SBUSCFG_BAWR_SHIFT)
>> +#define USB_SBUSCFG_BARD_ALIGN_128B	(0x3 << USB_SBUSCFG_BARD_SHIFT)
>> +/* AHBBRST = 3	   : Align AHB Burst to INCR16 (64 bytes) */
>> +#define USB_SBUSCFG_AHBBRST_INCR16	(0x3 << USB_SBUSCFG_AHBBRST_SHIFT)
>
> Besides, since these shift amounts are each used only once, it would be
> simpler (and easier to read!) to do:
>
> +#define USB_SBUSCFG_BAWR_ALIGN_128B  (0x3 << 6)
> +#define USB_SBUSCFG_BARD_ALIGN_128B  (0x3 << 3)
> +/* AHBBRST = 3          : Align AHB Burst to INCR16 (64 bytes) */
> +#define USB_SBUSCFG_AHBBRST_INCR16   (0x3 << 0)
>

I think the intent was to document the register layout. But I have no
problem following your advice.

>
>> +
>> +#define USB_SBUSCFG_DEF_VAL (USB_SBUSCFG_BAWR_ALIGN_128B	\
>> +			     | USB_SBUSCFG_BARD_ALIGN_128B	\
>> +			     | USB_SBUSCFG_AHBBRST_INCR16)
>> +
>>  #define DRIVER_DESC "EHCI orion driver"
>>  
>>  #define hcd_to_orion_priv(h) ((struct orion_ehci_hcd *)hcd_to_ehci(h)->priv)
>> @@ -151,8 +166,31 @@ ehci_orion_conf_mbus_windows(struct usb_hcd *hcd,
>>  	}
>>  }
>>  
>> +static int ehci_orion_drv_reset(struct usb_hcd *hcd)
>> +{
>> +	struct device *dev = hcd->self.controller;
>> +	int retval;
>> +
>> +	retval = ehci_setup(hcd);
>> +	if (retval)
>> +		dev_err(dev, "ehci_setup failed %d\n", retval);
>
> Was lack of this error message in the original driver a source of 
> problems?  If not, I submit that there's no good reason to add it.
>

I will remove the message and replace it by "return retval;" as
suggested below.

Thanks,

Gregory

>> +
>> +	/*
>> +	 * For SoC without hlock, need to program sbuscfg value to guarantee
>> +	 * AHB master's burst would not overrun or underrun FIFO.
>> +	 *
>> +	 * sbuscfg reg has to be set after usb controller reset, otherwise
>> +	 * the value would be override to 0.
>> +	 */
>> +	if (of_device_is_compatible(dev->of_node, "marvell,armada-3700-ehci"))
>> +		wrl(USB_SBUSCFG, USB_SBUSCFG_DEF_VAL);
>
> Do you want to do this even when retval != 0?
>
> Alan Stern

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: Gregory CLEMENT <gregory.clement@free-electrons.com>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	<linux-usb@vger.kernel.org>, Jason Cooper <jason@lakedaemon.net>,
	Andrew Lunn <andrew@lunn.ch>,
	Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>,
	Rob Herring <robh+dt@kernel.org>, <devicetree@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>,
	Thomas Petazzoni <thomas.petazzoni@free-electrons.com>,
	<linux-arm-kernel@lists.infradead.org>,
	Nadav Haklai <nadavh@marvell.com>, Victor Gu <xigu@marvell.com>,
	Marcin Wojtas <mw@semihalf.com>,
	Wilson Ding <dingwei@marvell.com>, Hua Jing <jinghua@marvell.com>,
	Neta Zur Hershkovits <neta@marvell.com>
Subject: Re: [PATCH v2 1/3] usb: orion-echi: Add support for the Armada 3700
Date: Thu, 09 Mar 2017 16:22:37 +0100	[thread overview]
Message-ID: <878toelbk2.fsf@free-electrons.com> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1703091006390.1912-100000@iolanthe.rowland.org> (Alan Stern's message of "Thu, 9 Mar 2017 10:13:19 -0500 (EST)")

Hi Alan,
 
 On jeu., mars 09 2017, Alan Stern <stern@rowland.harvard.edu> wrote:

>> @@ -47,6 +47,21 @@
>>  #define USB_PHY_IVREF_CTRL	0x440
>>  #define USB_PHY_TST_GRP_CTRL	0x450
>>  
>> +#define USB_SBUSCFG		0x90
>> +#define	    USB_SBUSCFG_BAWR_SHIFT	    0x6
>> +#define	    USB_SBUSCFG_BARD_SHIFT	    0x3
>> +#define	    USB_SBUSCFG_AHBBRST_SHIFT	    0x0
>
> Shift amounts are just regular numbers.  Giving them in hex is 
> confusing because it leads people to think the bit pattern has some 
> particular significance, which it doesn't.  Which would you rather see: 
> (0x24 << 0x12) or (0x24 << 18)?

Right

>
>> +
>> +/* BAWR = BARD = 3 : Align read/write bursts packets larger than 128 bytes */
>> +#define USB_SBUSCFG_BAWR_ALIGN_128B	(0x3 << USB_SBUSCFG_BAWR_SHIFT)
>> +#define USB_SBUSCFG_BARD_ALIGN_128B	(0x3 << USB_SBUSCFG_BARD_SHIFT)
>> +/* AHBBRST = 3	   : Align AHB Burst to INCR16 (64 bytes) */
>> +#define USB_SBUSCFG_AHBBRST_INCR16	(0x3 << USB_SBUSCFG_AHBBRST_SHIFT)
>
> Besides, since these shift amounts are each used only once, it would be
> simpler (and easier to read!) to do:
>
> +#define USB_SBUSCFG_BAWR_ALIGN_128B  (0x3 << 6)
> +#define USB_SBUSCFG_BARD_ALIGN_128B  (0x3 << 3)
> +/* AHBBRST = 3          : Align AHB Burst to INCR16 (64 bytes) */
> +#define USB_SBUSCFG_AHBBRST_INCR16   (0x3 << 0)
>

I think the intent was to document the register layout. But I have no
problem following your advice.

>
>> +
>> +#define USB_SBUSCFG_DEF_VAL (USB_SBUSCFG_BAWR_ALIGN_128B	\
>> +			     | USB_SBUSCFG_BARD_ALIGN_128B	\
>> +			     | USB_SBUSCFG_AHBBRST_INCR16)
>> +
>>  #define DRIVER_DESC "EHCI orion driver"
>>  
>>  #define hcd_to_orion_priv(h) ((struct orion_ehci_hcd *)hcd_to_ehci(h)->priv)
>> @@ -151,8 +166,31 @@ ehci_orion_conf_mbus_windows(struct usb_hcd *hcd,
>>  	}
>>  }
>>  
>> +static int ehci_orion_drv_reset(struct usb_hcd *hcd)
>> +{
>> +	struct device *dev = hcd->self.controller;
>> +	int retval;
>> +
>> +	retval = ehci_setup(hcd);
>> +	if (retval)
>> +		dev_err(dev, "ehci_setup failed %d\n", retval);
>
> Was lack of this error message in the original driver a source of 
> problems?  If not, I submit that there's no good reason to add it.
>

I will remove the message and replace it by "return retval;" as
suggested below.

Thanks,

Gregory

>> +
>> +	/*
>> +	 * For SoC without hlock, need to program sbuscfg value to guarantee
>> +	 * AHB master's burst would not overrun or underrun FIFO.
>> +	 *
>> +	 * sbuscfg reg has to be set after usb controller reset, otherwise
>> +	 * the value would be override to 0.
>> +	 */
>> +	if (of_device_is_compatible(dev->of_node, "marvell,armada-3700-ehci"))
>> +		wrl(USB_SBUSCFG, USB_SBUSCFG_DEF_VAL);
>
> Do you want to do this even when retval != 0?
>
> Alan Stern

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

  reply	other threads:[~2017-03-09 15:22 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-09 11:04 [PATCH v2 0/3] Add EHCI support for Armada 37xx Gregory CLEMENT
2017-03-09 11:04 ` Gregory CLEMENT
2017-03-09 11:04 ` Gregory CLEMENT
2017-03-09 11:04 ` [PATCH v2 1/3] usb: orion-echi: Add support for the Armada 3700 Gregory CLEMENT
2017-03-09 11:04   ` Gregory CLEMENT
2017-03-09 11:04   ` Gregory CLEMENT
2017-03-09 15:13   ` Alan Stern
2017-03-09 15:13     ` Alan Stern
2017-03-09 15:13     ` Alan Stern
2017-03-09 15:22     ` Gregory CLEMENT [this message]
2017-03-09 15:22       ` Gregory CLEMENT
2017-03-09 15:22       ` Gregory CLEMENT
2017-03-09 11:04 ` [PATCH v2 2/3] usb: host: Allow to build ehci orion with mvebu SoCs Gregory CLEMENT
2017-03-09 11:04   ` Gregory CLEMENT
2017-03-09 11:04   ` Gregory CLEMENT
2017-03-09 11:04 ` [PATCH v2 3/3] ARM64: dts: marvell: armada-37xx: Add USB2 node Gregory CLEMENT
2017-03-09 11:04   ` Gregory CLEMENT
2017-03-09 11:04   ` Gregory CLEMENT
2017-03-09 13:05 ` [PATCH v2 0/3] Add EHCI support for Armada 37xx Andrew Lunn
2017-03-09 13:05   ` Andrew Lunn
2017-03-09 13:05   ` Andrew Lunn

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=878toelbk2.fsf@free-electrons.com \
    --to=gregory.clement@free-electrons.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.