[PATCH] Documentation: DT: cpsw: document missing compatible

[Mugunthan V N]

CPSW driver has multiple compatibles for errata implentations but not
documented, add necessary documentation.

Signed-off-by: Mugunthan V N 
---

The compatibles are added in the commit 7da1160002f1 ('drivers:
net: cpsw: add am335x errata workarround for interrutps') which
is present in linux-next/master

---
 Documentation/devicetree/bindings/net/cpsw.txt | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/net/cpsw.txt 
b/Documentation/devicetree/bindings/net/cpsw.txt
index 33fe846..a9df21a 100644
--- a/Documentation/devicetree/bindings/net/cpsw.txt
+++ b/Documentation/devicetree/bindings/net/cpsw.txt
@@ -2,7 +2,11 @@ TI SoC Ethernet Switch Controller Device Tree Bindings
 --
 
 Required properties:
-- compatible   : Should be "ti,cpsw"
+- compatible   : Should be one of the below:-
+ "ti,cpsw" for backward compatible
+ "ti,am335x-cpsw" for AM335x controllers
+ "ti,am4372-cpsw" for AM437x controllers
+ "ti,dra7-cpsw" for DRA7x controllers
 - reg  : physical base address and size of the cpsw
  registers map
 - interrupts   : property with a value describing the interrupt
-- 
2.5.0.474.g3a9835b

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] regulator: pbias: use untranslated address to program pbias regulator

[Mark Brown]

On Mon, Aug 31, 2015 at 04:14:07PM +0530, Kishon Vijay Abraham I wrote:
> On Tuesday 25 August 2015 07:20 PM, Mark Brown wrote:
> > On Tue, Aug 25, 2015 at 01:03:04PM +0300, Grygorii Strashko wrote:
> >> On 08/19/2015 09:11 PM, Mark Brown wrote:

> >>> So substract this address from the start of the resource to get the
> >>> offset?  Or provide a wrapper function in the resource code which does
> >>> that.  
> > 
> >> I'd be very appreciated if you have and can share any thought on
> >> How can we get this absolute base address to substract?
> > 
> > Ask the syscon device for its resource?  Or have it provide an absolute
> 
> Even if we get the absolute address of syscon, we have to do the
> subtraction only for the newer dtbs (previous dtbs already have only the
> offset). Do you recommend adding a new property to differentiate between
> older dtbs and newer dtbs? Any other suggestions here?

Hang on.  This is the first I've heard of any DTs not just having
absolute addresses.  How does any of this work - has it ever worked, and
is the situation completely understood?  My original concern with this
was that I coudn't understand the commit log and your original response
seemed to indicate that we always have the absolute address :(  Perhaps
this is something to do with the brief mention of having moved the DT
node for some reason?

We at least need some sort of coherent explanation of the problem and a
comprehensible fix to go with it.  Right now it seems like things are
just being moved about to hide problems without either of these things
which seems like it makes the code less clear and more fragile.

> > address based interface for that matter?

> Syscon doesn't directly expose any API's to write to it's register.
> Rather it uses regmap APIs to read/write to it's register. I'm not sure
> if it's possible to add regmap APIs to write to a register with absolute
> address. Any hints?

Yes, I'm aware that it is regmap based!  What I am suggesting is that if
people are making DTs like yours with devices that are children of the
syscon then presumably it might be useful for it to allow client drivers
to pass absolute addresses in so that it can translate for them.


signature.asc
Description: Digital signature

[PATCH 2/2] ARM: dts: am437x-gp-evm: Add pinctrl states for usb

[Sekhar Nori]

From: Dave Gerlach 

Add pinctrl default and sleep states for each usb device.
The only pin that can be controlled is USB_DRVVBUS, this
must be set to MUX_MODE7 (gpio) during sleep to conserve
power.

Signed-off-by: Dave Gerlach 
[nsek...@ti.com: move pins to core dwc3]
Signed-off-by: Sekhar Nori 
---
 arch/arm/boot/dts/am437x-gp-evm.dts | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts 
b/arch/arm/boot/dts/am437x-gp-evm.dts
index 84aa30c3235a..2e990a5f9e95 100644
--- a/arch/arm/boot/dts/am437x-gp-evm.dts
+++ b/arch/arm/boot/dts/am437x-gp-evm.dts
@@ -409,6 +409,30 @@
0x234 (PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* 
uart3_rtsn.uart3_rtsn */
>;
};
+
+   usb1_pins_default: usb1_pins_default {
+   pinctrl-single,pins = <
+   0x2c0 (DS0_PULL_UP_DOWN_EN | PIN_INPUT_PULLDOWN | 
MUX_MODE0)
+   >;
+   };
+
+   usb1_pins_sleep: usb1_pins_sleep {
+   pinctrl-single,pins = <
+   0x2c0 (DS0_PULL_UP_DOWN_EN | PIN_INPUT_PULLDOWN | 
MUX_MODE7)
+   >;
+   };
+
+   usb2_pins_default: usb2_pins_default {
+   pinctrl-single,pins = <
+   0x2c4 (DS0_PULL_UP_DOWN_EN | PIN_INPUT_PULLDOWN | 
MUX_MODE0)
+   >;
+   };
+
+   usb2_pins_sleep: usb2_pins_sleep {
+   pinctrl-single,pins = <
+   0x2c4 (DS0_PULL_UP_DOWN_EN | PIN_INPUT_PULLDOWN | 
MUX_MODE7)
+   >;
+   };
 };
 
  {
@@ -615,6 +639,9 @@
  {
dr_mode = "peripheral";
status = "okay";
+   pinctrl-names = "default", "sleep";
+   pinctrl-0 = <_pins_default>;
+   pinctrl-1 = <_pins_sleep>;
 };
 
 _phy2 {
@@ -624,6 +651,9 @@
  {
dr_mode = "host";
status = "okay";
+   pinctrl-names = "default", "sleep";
+   pinctrl-0 = <_pins_default>;
+   pinctrl-1 = <_pins_sleep>;
 };
 
  {
-- 
2.4.4.408.g16da57c

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/2] usb: dwc3: support for pinctrl state change during system sleep

[Sekhar Nori]

Add support for USB DRVVBUS pinctrl state change during
suspend/resume. This helps is conserving power during
system sleep.

Signed-off-by: Sekhar Nori 
---
 drivers/usb/dwc3/core.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index ff5773c66b84..a5ffa66e39fb 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -1093,6 +1093,8 @@ static int dwc3_suspend(struct device *dev)
phy_exit(dwc->usb2_generic_phy);
phy_exit(dwc->usb3_generic_phy);
 
+   pinctrl_pm_select_sleep_state(dev);
+
return 0;
 }
 
@@ -1102,6 +1104,8 @@ static int dwc3_resume(struct device *dev)
unsigned long   flags;
int ret;
 
+   pinctrl_pm_select_default_state(dev);
+
usb_phy_init(dwc->usb3_phy);
usb_phy_init(dwc->usb2_phy);
ret = phy_init(dwc->usb2_generic_phy);
-- 
2.4.4.408.g16da57c

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/2] AM437x: USB DWC3: save power during system sleep

[Sekhar Nori]

Hi,

This series add support to DWC3 core to conserve
power during system sleep by setting the USB
DRVVBUS line to a lower power consuming state.

Tested to make sure USB host and device works on
AM437x with v4.2. Tested for power savings on v4.1
kernel where there is an implementation of suspend-
to-RAM for AM437x available.

Dave Gerlach (1):
  ARM: dts: am437x-gp-evm: Add pinctrl states for usb

Sekhar Nori (1):
  usb: dwc3: support for pinctrl state change during system sleep

 arch/arm/boot/dts/am437x-gp-evm.dts | 30 ++
 drivers/usb/dwc3/core.c |  4 
 2 files changed, 34 insertions(+)

-- 
2.4.4.408.g16da57c

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 2/5] ARM: OMAP2+: DRA7: Add hwmod entries for PWMSS

[Paul Walmsley]

Hi

On Thu, 16 Jul 2015, R, Vignesh wrote:

> On 07/16/2015 03:24 AM, Paul Walmsley wrote:
> > 
> > On Wed, 3 Jun 2015, Vignesh R wrote:
> > 
> >> Add hwmod entries for the PWMSS on DRA7.
> >>
> >> Set l4_root_clk_div as the main_clk of PWMSS. It is fixed-factored clock
> >> equal to L4PER2_L3_GICLK/2(l3_iclk_div/2).
> >> As per AM57x TRM SPRUHZ6[1], October 2014, Section 29.1.3 Table 29-4,
> >> clock source to PWMSS is L4PER2_L3_GICLK. But it is actually
> >> L4PER2_L3_GICLK/2. The TRM does not show the division by 2.
> > 
> > Is the divide-by-two coming from PWMSS_EPWM.EPWM_TBCTL[HSPCLKDIV]?  Or is 
> > HSPCLKDIV a separate divider after the divide-by-2 you mention above?
> 
> No, it not related to HSPCLKDIV. The TRM wrongly states L4PER2_L3_GICLK
> as clock input for PWMSS. But actually  L4PER2_L4_GICLK(=L3_GICLK/2) is
> the clock input for PWMSS. This will be updated in TRM soon.

OK

> >> --- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> >> +++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> >> @@ -362,6 +362,149 @@ static struct omap_hwmod dra7xx_dcan2_hwmod = {
> >>},
> >>  };
> >>  
> >> +/* pwmss  */
> >> +static struct omap_hwmod_class_sysconfig dra7xx_epwmss_sysc = {
> >> +  .rev_offs   = 0x0,
> >> +  .sysc_offs  = 0x4,
> >> +  .sysc_flags = SYSC_HAS_SIDLEMODE | SYSC_HAS_RESET_STATUS,
> > 
> > This doesn't match SPRUHZ6 Table 29-13 "PWMSS_SYSCONFIG".  There's no 
> > RESETSTATUS bit.  There is a SOFTRESET bit. 
> > 
> > Could you please confirm whether this is intentional?
> 
> sorry my bad... I will change this in v3.

OK

> >> +/* ecap0 */
> >> +struct omap_hwmod dra7xx_ecap0_hwmod = {
> >> +  .name   = "ecap0",
> >> +  .class  = _ecap_hwmod_class,
> >> +  .clkdm_name = "l4per2_clkdm",
> >> +  .main_clk   = "l4_root_clk_div",
> > 
> > Looking at SPRUHZ6 Section 29.1.4.2 "PWMSS Modules Local Clock Gating", 
> > there appears to be a local "mini-PRCM" for the PWMSS which implements 
> > clock gating and reports back on the status of what I'd guess is the local 
> > clock gating FSM.
> > 
> > So from that point of view, you should probably create a clock driver that 
> > manages both the clock gate request bit and the FSM status bit.  It should 
> > be something that can be reused for the other PWMSS IP blocks.  Then 
> > you'd create per-IP block clock nodes and set the main_clk to point to 
> > that node.
> 
> Since, this register is within the config space of PWMSS, the individual
> gating and reporting for the modules within PWMSS
> (PWMSS_CLKCONFIG) is currently being taken care by pwm-tipwmss.c(almost
> the sole function this driver is doing). It has been the same since
> am335x. Adding new clock nodes will result in driver changes and also
> changes to am335x, am437x (and other platforms) hwmod files. It also
> involves adding new nodes to clocks.dtsi and it will be difficult to
> maintain backward compatibility for older platforms. Is it not better to
> keep this as is, in order to maintain consistency (with am335x, am437x
> etc) and also that these clock bits are within IP's config space?

It's certainly possible that we as maintainers didn't look closely enough 
at the AM33xx data for the PWMSS when we merged it.  But if that's 
incorrect too, then now is the time to fix this.  Otherwise it will never 
get fixed, since each new group of people patching this code will keep 
punting it off to the indeterminate future.

In terms of hwmod data: based on the register maps in sections 29.4.3, 
29.3.3, and 29.2.3 of SPRUHZ6, none of these subdevices are hwmod devices.  
They don't support the Highlander OCP registers, they have no individual 
PRCM registers or register bitfields, and all of the idle and status 
reporting is to the PWMSS top-level IP block itself.  So it looks to me 
like the eCAP, eQEP, and ePWM modules should be registered via DT, rather 
than via hwmod.  It looks like you can get away with using the 
"simple-bus" abstraction, but you might ultimately have to define 
something custom here.  However, the PWMSS top level subsystem, described 
in section 29.1, does have the OCP registers, sideband signals, etc., and 
thus should remain a hwmod-registered device (via DT).

In terms of the clock data: based on section 29.1.4, section 29.1.5.2, 
figure 29-3, and table 29-4, there are several clock gating control bits.  
These should be modeled as clock nodes in the Linux common clock 
framework.  Furthermore these registers are located inside the PWMSS 
subsystem itself, and are only accessible when the PWMSS IP block is 
functional in a PM runtime point of view: i.e., when the block is mapped 
into memory space, clocked and out of reset, etc.  So the clock types for 
the PWMSS_CFG IP block should most likely be implemented in the PWMSS 
driver.  I think you'll still be able to define the clock node data itself 
in DT, but this will probably need a closer look.  Ideally, since the 
clock node register address data is the same for all three 

Re: Linux 4.2.0-rc5: am335x: musb warnings

[Felipe Balbi]

On Mon, Aug 31, 2015 at 03:11:58PM +0200, Yegor Yefremov wrote:
> Hi Felipe,
> 
> On Fri, Aug 7, 2015 at 12:57 PM, Yegor Yefremov
>  wrote:
> > On Fri, Aug 7, 2015 at 12:16 PM, Yegor Yefremov
> >  wrote:
> >> On Thu, Aug 6, 2015 at 4:21 PM, Felipe Balbi  wrote:
> >>> HI,
> >>>
> >>> On Thu, Aug 06, 2015 at 09:40:26AM +0200, Yegor Yefremov wrote:
>  I performed a stress test with several FT4232H chips connected to a
> >>>
> >>> how many ?
> >>
> >> # lsusb -t
> >> /:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M
> >> /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M
> >> |__ Port 1: Dev 2, If 0, Class=, Driver=hub/4p, 480M
> >> |__ Port 1: Dev 3, If 0, Class=, Driver=ftdi_sio, 480M
> >> |__ Port 1: Dev 3, If 1, Class=, Driver=ftdi_sio, 480M
> >> |__ Port 1: Dev 3, If 2, Class=, Driver=ftdi_sio, 480M
> >> |__ Port 1: Dev 3, If 3, Class=, Driver=ftdi_sio, 480M
> >> |__ Port 2: Dev 4, If 0, Class=, Driver=ftdi_sio, 480M
> >> |__ Port 2: Dev 4, If 1, Class=, Driver=ftdi_sio, 480M
> >> |__ Port 2: Dev 4, If 2, Class=, Driver=ftdi_sio, 480M
> >> |__ Port 2: Dev 4, If 3, Class=, Driver=ftdi_sio, 480M
> >> |__ Port 3: Dev 5, If 0, Class=, Driver=ftdi_sio, 480M
> >> |__ Port 3: Dev 5, If 1, Class=, Driver=ftdi_sio, 480M
> >> |__ Port 3: Dev 5, If 2, Class=, Driver=ftdi_sio, 480M
> >> |__ Port 3: Dev 5, If 3, Class=, Driver=ftdi_sio, 480M
> >>
> >> 3 chips a 4-ports are attached.
> >
> > Warnings appear on another device (without internal hub) with only one
> > FT4232H too:
> >
> > # lsusb -t
> > /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M
> > |__ Port 1: Dev 2, If 0, Class=, Driver=ftdi_sio, 480M
> > |__ Port 1: Dev 2, If 1, Class=, Driver=ftdi_sio, 480M
> > |__ Port 1: Dev 2, If 2, Class=, Driver=ftdi_sio, 480M
> > |__ Port 1: Dev 2, If 3, Class=, Driver=ftdi_sio, 480M
> >
>  hub, that is attached to one of the musb ports. So far the test was
>  successful for several hours. But I've seen following warnings:
> 
>  musb_host_rx 1973: Rx interrupt with no errors or packet!
>  musb_ep_program 931: broken !rx_reinit, ep5 csr 0203
>  musb_host_rx 1973: Rx interrupt with no errors or packet!
>  musb_host_rx 1973: Rx interrupt with no errors or packet!
>  musb_host_rx 1973: Rx interrupt with no errors or packet!
>  musb_host_rx 1973: Rx interrupt with no errors or packet!
>  musb_ep_program 931: broken !rx_reinit, ep5 csr 0003
>  musb_host_rx 1973: Rx interrupt with no errors or packet!
>  musb_ep_program 931: broken !rx_reinit, ep7 csr 0003
> 
>  Is this expected behavior?
> >>>
> >>> no, that shouldn't happen, but it does and, apparently, in more than one
> >>> implementation. Wondering if you're running into endpoint limitation due
> >>> to MUSB's poor transfer scheduling for non-bulk endpoints.
> >>>
> >>> --
> >>> balbi
> 
> Now I have another trouble with msub and FTDI FT4232H chip. If I start
> something like this on all 4 ports at 115200b/s, then pull USB cable
> and the system freezes:
> 
> cat /dev/urandom > /dev/ttyUSB0
> ...
> cat /dev/urandom > /dev/ttyUSB3
> 
> I see these messages:
> 
> ftdi_sio ttyUSB3: usb_serial_generic_write_bulk_callback - nonzero urb
> status: -110
> ftdi_sio ttyUSB0: usb_serial_generic_write_bulk_callback - nonzero urb
> status: -110
> ftdi_sio ttyUSB1: usb_serial_generic_write_bulk_callback - nonzero urb
> status: -110
> ftdi_sio ttyUSB2: usb_serial_generic_write_bulk_callback - nonzero urb
> status: -110
> ftdi_sio ttyUSB3: usb_serial_generic_write_bulk_callback - nonzero urb
> status: -110
> ftdi_sio ttyUSB0: usb_serial_generic_write_bulk_callback - nonzero urb
> status: -110
> ftdi_sio ttyUSB1: usb_serial_generic_write_bulk_callback - nonzero urb
> status: -110
> ftdi_sio ttyUSB2: usb_serial_generic_write_bulk_callback - nonzero urb
> status: -110
> ftdi_sio ttyUSB3: usb_serial_generic_write_bulk_callback - nonzero urb
> status: -110
> 
> After them system reboots as my watchdog time expires.
> 
> Kernel 4.2.0-rc5
> 
> Older FTDI chips like FT2232 have no problems. Somehow is musb really
> allergic to FTDI and vice versa :-(

those are just messages of URB time out. They should be expected. No
idea why you're getting a reboot though. I'll see if I can reproduce.

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH] net/smsc911x: Fix deferred probe for interrupt

[Sergei Shtylyov]

Hello.

On 08/31/2015 05:03 PM, Grygorii Strashko wrote:


The interrupt handler may not be available when smsc911x probes if the
interrupt handler is a GPIO controller for example. Let's fix that
by adding handling for -EPROBE_DEFER.



Cc: Steve Glendinning 
Signed-off-by: Tony Lindgren 
---
   drivers/net/ethernet/smsc/smsc911x.c | 5 -
   1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/smsc/smsc911x.c
b/drivers/net/ethernet/smsc/smsc911x.c
index 959aeea..cb9f166f 100644
--- a/drivers/net/ethernet/smsc/smsc911x.c
+++ b/drivers/net/ethernet/smsc/smsc911x.c
@@ -2435,7 +2435,10 @@ static int smsc911x_drv_probe(struct
platform_device *pdev)
   res_size = resource_size(res);

   irq = platform_get_irq(pdev, 0);
-if (irq <= 0) {
+if (irq == -EPROBE_DEFER) {
+retval = -EPROBE_DEFER;
+goto out_0;
+} else if (irq <= 0) {
   pr_warn("Could not allocate irq resource\n");
   retval = -ENODEV;


 I'd propagate the error code from platfrom_get_irq() instead (in
fact, I've submitted a couple of such patches yesterday and they have
been already merged).



Have you paid some attention on current platform_get_irq_() implementation?



The platform_get_irq() can return 0 in case of DT-boot.


   This is what's indeed worth filtering out and converting to -ENODEV. ;-)
But my patches just ignored this possibility. I'm not at all fond of Linus' 
idea about IRQ0 being invalid, BTW...


WBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [V4] [TWL4030 MADC] Fix ADC[3:6] readings

[Jonathan Cameron]

On 10/08/15 17:56, Adam Lee wrote:
> Yes I will do a better job in following the patch submission conventions.
> Thanks for your comment Jonathan.
> 
> @Sebastian, let me know if you have any concerns with the patch.
This has been sat around for long enough that I suspect Sebastian isn't
going to reply.  As such I've just applied it as is to the fixes-togreg
branch of iio.git (with some editing of the patch description!)

Thanks,

Jonathan
> 
> 
> 
> On Sat, Aug 8, 2015 at 8:15 AM Jonathan Cameron  > wrote:
> 
> On 04/08/15 19:15, Adam YH Lee wrote:
> > MADC[3:6] reads incorrect values without these two following changes:
> >
> > - enable the 3v1 bias regulator for ADC[3:6]
> > - configure ADC[3:6] lines as input, not as USB
> >
> > Signed-off-by: Adam YH Lee  >
> I'd ideally like an ack from the driver author or Sebastian as this isn't
> a driver I'm particular familiar with.
> 
> Also, for future reference, patches should be titled something like
> [Patch v4] iio: twl4030 madc: Fix ADC[3:6] readings.
> (the patch bit is standard, the rest is iio convention)
> 
> Jonathan
> 
> > ---
> >  drivers/iio/adc/twl4030-madc.c | 34 ++
> >  1 file changed, 34 insertions(+)
> >
> > diff --git a/drivers/iio/adc/twl4030-madc.c 
> b/drivers/iio/adc/twl4030-madc.c
> > index 94c5f05..8c58498 100644
> > --- a/drivers/iio/adc/twl4030-madc.c
> > +++ b/drivers/iio/adc/twl4030-madc.c
> > @@ -45,13 +45,18 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >
> >  #include 
> >
> > +#define TWL4030_USB_SEL_MADC_MCPC(1<<3)
> > +#define TWL4030_USB_CARKIT_ANA_CTRL  0xBB
> > +
> >  /**
> >   * struct twl4030_madc_data - a container for madc info
> >   * @dev: Pointer to device structure for madc
> >   * @lock:Mutex protecting this data structure
> > + * @regulator:   Pointer to bias regulator for madc
> >   * @requests:Array of request struct corresponding to 
> SW1, SW2 and RT
> >   * @use_second_irq:  IRQ selection (main or co-processor)
> >   * @imr: Interrupt mask register of MADC
> > @@ -60,6 +65,7 @@
> >  struct twl4030_madc_data {
> >   struct device *dev;
> >   struct mutex lock;  /* mutex protecting this data structure */
> > + struct regulator *usb3v1;
> >   struct twl4030_madc_request requests[TWL4030_MADC_NUM_METHODS];
> >   bool use_second_irq;
> >   u8 imr;
> > @@ -842,6 +848,32 @@ static int twl4030_madc_probe(struct 
> platform_device *pdev)
> >   }
> >   twl4030_madc = madc;
> >
> > + /* Configure MADC[3:6] */
> > + ret = twl_i2c_read_u8(TWL_MODULE_USB, ,
> > + TWL4030_USB_CARKIT_ANA_CTRL);
> > + if (ret) {
> > + dev_err(>dev, "unable to read reg CARKIT_ANA_CTRL  
> 0x%X\n",
> > + TWL4030_USB_CARKIT_ANA_CTRL);
> > + goto err_i2c;
> > + }
> > + regval |= TWL4030_USB_SEL_MADC_MCPC;
> > + ret = twl_i2c_write_u8(TWL_MODULE_USB, regval,
> > +  TWL4030_USB_CARKIT_ANA_CTRL);
> > + if (ret) {
> > + dev_err(>dev, "unable to write reg CARKIT_ANA_CTRL 
> 0x%X\n",
> > + TWL4030_USB_CARKIT_ANA_CTRL);
> > + goto err_i2c;
> > + }
> > +
> > + /* Enable 3v1 bias regulator for MADC[3:6] */
> > + madc->usb3v1 = devm_regulator_get(madc->dev, "vusb3v1");
> > + if (IS_ERR(madc->usb3v1))
> > + return -ENODEV;
> > +
> > + ret = regulator_enable(madc->usb3v1);
> > + if (ret)
> > + dev_err(madc->dev, "could not enable 3v1 bias 
> regulator\n");
> > +
> >   ret = iio_device_register(iio_dev);
> >   if (ret) {
> >   dev_err(>dev, "could not register iio device\n");
> > @@ -867,6 +899,8 @@ static int twl4030_madc_remove(struct 
> platform_device *pdev)
> >   twl4030_madc_set_current_generator(madc, 0, 0);
> >   twl4030_madc_set_power(madc, 0);
> >
> > + regulator_disable(madc->usb3v1);
> > +
> >   return 0;
> >  }
> >
> >
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Linux 4.2.0-rc5: am335x: musb warnings

[Felipe Balbi]

Hi,

On Mon, Aug 31, 2015 at 11:41:59AM -0500, Felipe Balbi wrote:
> On Mon, Aug 31, 2015 at 03:11:58PM +0200, Yegor Yefremov wrote:
> > Hi Felipe,
> > 
> > On Fri, Aug 7, 2015 at 12:57 PM, Yegor Yefremov
> >  wrote:
> > > On Fri, Aug 7, 2015 at 12:16 PM, Yegor Yefremov
> > >  wrote:
> > >> On Thu, Aug 6, 2015 at 4:21 PM, Felipe Balbi  wrote:
> > >>> HI,
> > >>>
> > >>> On Thu, Aug 06, 2015 at 09:40:26AM +0200, Yegor Yefremov wrote:
> >  I performed a stress test with several FT4232H chips connected to a
> > >>>
> > >>> how many ?
> > >>
> > >> # lsusb -t
> > >> /:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M
> > >> /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M
> > >> |__ Port 1: Dev 2, If 0, Class=, Driver=hub/4p, 480M
> > >> |__ Port 1: Dev 3, If 0, Class=, Driver=ftdi_sio, 480M
> > >> |__ Port 1: Dev 3, If 1, Class=, Driver=ftdi_sio, 480M
> > >> |__ Port 1: Dev 3, If 2, Class=, Driver=ftdi_sio, 480M
> > >> |__ Port 1: Dev 3, If 3, Class=, Driver=ftdi_sio, 480M
> > >> |__ Port 2: Dev 4, If 0, Class=, Driver=ftdi_sio, 480M
> > >> |__ Port 2: Dev 4, If 1, Class=, Driver=ftdi_sio, 480M
> > >> |__ Port 2: Dev 4, If 2, Class=, Driver=ftdi_sio, 480M
> > >> |__ Port 2: Dev 4, If 3, Class=, Driver=ftdi_sio, 480M
> > >> |__ Port 3: Dev 5, If 0, Class=, Driver=ftdi_sio, 480M
> > >> |__ Port 3: Dev 5, If 1, Class=, Driver=ftdi_sio, 480M
> > >> |__ Port 3: Dev 5, If 2, Class=, Driver=ftdi_sio, 480M
> > >> |__ Port 3: Dev 5, If 3, Class=, Driver=ftdi_sio, 480M
> > >>
> > >> 3 chips a 4-ports are attached.
> > >
> > > Warnings appear on another device (without internal hub) with only one
> > > FT4232H too:
> > >
> > > # lsusb -t
> > > /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M
> > > |__ Port 1: Dev 2, If 0, Class=, Driver=ftdi_sio, 480M
> > > |__ Port 1: Dev 2, If 1, Class=, Driver=ftdi_sio, 480M
> > > |__ Port 1: Dev 2, If 2, Class=, Driver=ftdi_sio, 480M
> > > |__ Port 1: Dev 2, If 3, Class=, Driver=ftdi_sio, 480M
> > >
> >  hub, that is attached to one of the musb ports. So far the test was
> >  successful for several hours. But I've seen following warnings:
> > 
> >  musb_host_rx 1973: Rx interrupt with no errors or packet!
> >  musb_ep_program 931: broken !rx_reinit, ep5 csr 0203
> >  musb_host_rx 1973: Rx interrupt with no errors or packet!
> >  musb_host_rx 1973: Rx interrupt with no errors or packet!
> >  musb_host_rx 1973: Rx interrupt with no errors or packet!
> >  musb_host_rx 1973: Rx interrupt with no errors or packet!
> >  musb_ep_program 931: broken !rx_reinit, ep5 csr 0003
> >  musb_host_rx 1973: Rx interrupt with no errors or packet!
> >  musb_ep_program 931: broken !rx_reinit, ep7 csr 0003
> > 
> >  Is this expected behavior?
> > >>>
> > >>> no, that shouldn't happen, but it does and, apparently, in more than one
> > >>> implementation. Wondering if you're running into endpoint limitation due
> > >>> to MUSB's poor transfer scheduling for non-bulk endpoints.
> > >>>
> > >>> --
> > >>> balbi
> > 
> > Now I have another trouble with msub and FTDI FT4232H chip. If I start
> > something like this on all 4 ports at 115200b/s, then pull USB cable
> > and the system freezes:
> > 
> > cat /dev/urandom > /dev/ttyUSB0
> > ...
> > cat /dev/urandom > /dev/ttyUSB3
> > 
> > I see these messages:
> > 
> > ftdi_sio ttyUSB3: usb_serial_generic_write_bulk_callback - nonzero urb
> > status: -110
> > ftdi_sio ttyUSB0: usb_serial_generic_write_bulk_callback - nonzero urb
> > status: -110
> > ftdi_sio ttyUSB1: usb_serial_generic_write_bulk_callback - nonzero urb
> > status: -110
> > ftdi_sio ttyUSB2: usb_serial_generic_write_bulk_callback - nonzero urb
> > status: -110
> > ftdi_sio ttyUSB3: usb_serial_generic_write_bulk_callback - nonzero urb
> > status: -110
> > ftdi_sio ttyUSB0: usb_serial_generic_write_bulk_callback - nonzero urb
> > status: -110
> > ftdi_sio ttyUSB1: usb_serial_generic_write_bulk_callback - nonzero urb
> > status: -110
> > ftdi_sio ttyUSB2: usb_serial_generic_write_bulk_callback - nonzero urb
> > status: -110
> > ftdi_sio ttyUSB3: usb_serial_generic_write_bulk_callback - nonzero urb
> > status: -110
> > 
> > After them system reboots as my watchdog time expires.
> > 
> > Kernel 4.2.0-rc5
> > 
> > Older FTDI chips like FT2232 have no problems. Somehow is musb really
> > allergic to FTDI and vice versa :-(
> 
> those are just messages of URB time out. They should be expected. No
> idea why you're getting a reboot though. I'll see if I can reproduce.

okay, reproduced. Seems to be a race somewhere. some printks() made it
go away :-)

I'll have a look.

-- 
balbi


signature.asc
Description: Digital signature

[PATCH] security: device_cgroup: fix RCU lockdep splat

[Felipe Balbi]

while booting AM437x device, the following splat
triggered:

[   12.005238] ===
[   12.009749] [ INFO: suspicious RCU usage. ]
[   12.014116] 4.2.0-next-20150831 #1154 Not tainted
[   12.019050] ---
[   12.023408] security/device_cgroup.c:405 device_cgroup:verify_new_ex called 
without proper synchronization!
[   12.033576] other info that might help us debug this:

[   12.041942] rcu_scheduler_active = 1, debug_locks = 0
[   12.048796] 4 locks held by systemd/1:
[   12.052700]  #0:  (sb_writers#7){.+.+.+}, at: [] 
__sb_start_write+0x8c/0xb0
[   12.060954]  #1:  (>mutex){+.+.+.}, at: [] 
kernfs_fop_write+0x50/0x1b8
[   12.069085]  #2:  (s_active#30){.+}, at: [] 
kernfs_fop_write+0x58/0x1b8
[   12.077310]  #3:  (devcgroup_mutex){+.+...}, at: [] 
devcgroup_access_write+0x20/0x658
[   12.086575] stack backtrace:
[   12.091124] CPU: 0 PID: 1 Comm: systemd Not tainted 4.2.0-next-20150831 #1154
[   12.098609] Hardware name: Generic AM43 (Flattened Device Tree)
[   12.104807] [] (unwind_backtrace) from [] 
(show_stack+0x10/0x14)
[   12.112924] [] (show_stack) from [] 
(dump_stack+0x84/0x9c)
[   12.120491] [] (dump_stack) from [] 
(verify_new_ex+0xc4/0xdc)
[   12.128326] [] (verify_new_ex) from [] 
(devcgroup_access_write+0x374/0x658)
[   12.137426] [] (devcgroup_access_write) from [] 
(cgroup_file_write+0x28/0x1bc)
[   12.146796] [] (cgroup_file_write) from [] 
(kernfs_fop_write+0xc0/0x1b8)
[   12.155620] [] (kernfs_fop_write) from [] 
(__vfs_write+0x1c/0xd8)
[   12.163783] [] (__vfs_write) from [] 
(vfs_write+0x90/0x16c)
[   12.171426] [] (vfs_write) from [] (SyS_write+0x44/0x9c)
[   12.178806] [] (SyS_write) from [] 
(ret_fast_syscall+0x0/0x1c)

Fix it by making sure rcu_read_lock() is held
around devcgroup_update_access().

Signed-off-by: Felipe Balbi <ba...@ti.com>
---
 security/device_cgroup.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/security/device_cgroup.c b/security/device_cgroup.c
index 73455089feef..0a6316b50357 100644
--- a/security/device_cgroup.c
+++ b/security/device_cgroup.c
@@ -766,8 +766,10 @@ static ssize_t devcgroup_access_write(struct 
kernfs_open_file *of,
int retval;
 
mutex_lock(_mutex);
+   rcu_read_lock();
retval = devcgroup_update_access(css_to_devcgroup(of_css(of)),
 of_cft(of)->private, strstrip(buf));
+   rcu_read_unlock();
mutex_unlock(_mutex);
return retval ?: nbytes;
 }
-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 02/15] mmc: host: omap_hsmmc: return on fatal errors from omap_hsmmc_reg_get

[Tony Lindgren]

* Kishon Vijay Abraham I <kis...@ti.com> [150830 22:47]:
> Hi,
> 
> On Saturday 29 August 2015 12:33 AM, Tony Lindgren wrote:
> > * Olof Johansson <o...@lixom.net> [150828 11:11]:
> >> Hi,
> >>
> >> On Thu, Aug 27, 2015 at 2:13 AM, Kishon Vijay Abraham I <kis...@ti.com> 
> >> wrote:
> >>> Now return error only if the return value of
> >>> devm_regulator_get_optional() is not the same as -ENODEV, since with
> >>> -EPROBE_DEFER, the regulator can be obtained later and all other
> >>> errors are fatal.
> >>>
> >>> Signed-off-by: Kishon Vijay Abraham I <kis...@ti.com>
> >>> Tested-by: Tony Lindgren <t...@atomide.com>
> >>
> >> I bisected boot failures on Panda ES with multi_v7_defconfig down to
> >> this commit on last night's -next build:
> >>
> >> http://arm-soc.lixom.net/bootlogs/next/next-20150828/pandaes-arm-multi_v7_defconfig.html
> > 
> > MMC is working for me at least on Duovero. Interesting that you also
> > have all kind of errors there, I guess this is some older revision
> > of the board.
> > 
> > Anyways, Kishon, care to look into what might be causing this?
> 
> I think this might be because my pbias fix [1] patch wasn't merged yet.
> I'll try to get that resolved asap.

Kishon, as there seems to be an ongoing discussion with the regulator regmap
stuff for pbias, I suggest you provide a fix for the hsmmc driver instead for
now or revert some patches to remove the dependency and get things working.

And I must have tested next-20150827 instead of next-20150828. Or
else it does not happen on every boot. In any case, I'm now getting
the following on next-20150831 most of the time:

[9.493133] omap_hsmmc 4809c000.mmc: using lookup tables for GPIO lookup
[9.500274] omap_hsmmc 4809c000.mmc: lookup for GPIO wp failed
[9.506378] [ cut here ]
[9.508941] WARNING: CPU: 0 PID: 6 at drivers/bus/omap_l3_noc.c:147 
l3_interrupt_handler+0x224/0x350()
[9.520568] 4400.ocp:L3 Custom Error: MASTER MPU TARGET L4PER2 (Read): 
Data Access in User mode during Functional access
[9.524810] Modules linked in: rtc_twl twl4030_wdt
[9.534820] CPU: 0 PID: 6 Comm: kworker/u4:0 Not tainted 
4.2.0-next-20150831-2-gf55bad8 #1113
[9.544830] Hardware name: Generic OMAP4 (Flattened Device Tree)
[9.544830] Workqueue: deferwq deferred_probe_work_func
[9.554809] [] (unwind_backtrace) from [] 
(show_stack+0x10/0x14)
[9.564819] [] (show_stack) from [] 
(dump_stack+0x84/0x9c)
[9.574829] [] (dump_stack) from [] 
(warn_slowpath_common+0x78/0xb4)
[9.574951] [] (warn_slowpath_common) from [] 
(warn_slowpath_fmt+0x30/0x40)
[9.584686] [] (warn_slowpath_fmt) from [] 
(l3_interrupt_handler+0x224/0x350)
[9.594818] [] (l3_interrupt_handler) from [] 
(handle_irq_event_percpu+0x44/0x1f0)
[9.604827] [] (handle_irq_event_percpu) from [] 
(handle_irq_event+0x40/0x64)
[9.614807] [] (handle_irq_event) from [] 
(handle_fasteoi_irq+0xcc/0x1c4)
[9.625396] [] (handle_fasteoi_irq) from [] 
(generic_handle_irq+0x28/0x3c)
[9.638732] [] (generic_handle_irq) from [] 
(__handle_domain_irq+0x64/0xe0)
[9.647827] [] (__handle_domain_irq) from [] 
(gic_handle_irq+0x40/0x8c)
[9.654693] [] (gic_handle_irq) from [] 
(__irq_svc+0x58/0x78)
[9.664367] Exception stack(0xee0cfd80 to 0xee0cfdc8)
[9.665130] fd80: ee1ec010 c082f174 00d0  ee6b0800 ee6ae850 
ee1ec000 ee1ec010
[9.674835] fda0:  ee6b0cc0 00ee fa09c000 0003 ee0cfdd0 
c04cd748 c04df4e0
[9.684814] fdc0: 2113 
[9.684814] [] (__irq_svc) from [] 
(devm_clk_get+0x8/0x70)
[9.694824] [] (devm_clk_get) from [] 
(omap_hsmmc_probe+0x2e8/0x9f0)
[9.704833] [] (omap_hsmmc_probe) from [] 
(platform_drv_probe+0x44/0xac)
[9.714691] [] (platform_drv_probe) from [] 
(driver_probe_device+0x1f4/0x2f0)
[9.724548] [] (driver_probe_device) from [] 
(bus_for_each_drv+0x64/0x98)
[9.733459] [] (bus_for_each_drv) from [] 
(__device_attach+0xb0/0x118)
[9.734832] [] (__device_attach) from [] 
(bus_probe_device+0x88/0x90)
[9.744812] [] (bus_probe_device) from [] 
(deferred_probe_work_func+0x60/0x90)
[9.760040] [] (deferred_probe_work_func) from [] 
(process_one_work+0x1a4/0x558)
[9.769470] [] (process_one_work) from [] 
(worker_thread+0x3c/0x514)
[9.774688] [] (worker_thread) from [] 
(kthread+0xd4/0xf0)
[9.785614] [] (kthread) from [] 
(ret_from_fork+0x14/0x24)
[9.785614] ---[ end trace 402743bd8cfdde2f ]---
 
> [1] -> http://lkml.iu.edu/hypermail/linux/kernel/1507.3/01594.html

With patch 1/2 of the above applied, I'm getting this instead:

[2.930938] [ cut here ]
[2.935852] WARNING: CPU: 0 PID: 6 at drivers/regulator/core.c:2105 
_regul

Re: [PATCH v3 02/15] mmc: host: omap_hsmmc: return on fatal errors from omap_hsmmc_reg_get

[Tony Lindgren]

* Tony Lindgren <t...@atomide.com> [150831 14:02]:
> 
> And I must have tested next-20150827 instead of next-20150828. Or
> else it does not happen on every boot. In any case, I'm now getting
> the following on next-20150831 most of the time:
> 
> [9.493133] omap_hsmmc 4809c000.mmc: using lookup tables for GPIO lookup
> [9.500274] omap_hsmmc 4809c000.mmc: lookup for GPIO wp failed
> [9.506378] [ cut here ]
> [9.508941] WARNING: CPU: 0 PID: 6 at drivers/bus/omap_l3_noc.c:147 
> l3_interrupt_handler+0x224/0x350()
> [9.520568] 4400.ocp:L3 Custom Error: MASTER MPU TARGET L4PER2 (Read): 
> Data Access in User mode during Functional access
> [9.524810] Modules linked in: rtc_twl twl4030_wdt
> [9.534820] CPU: 0 PID: 6 Comm: kworker/u4:0 Not tainted 
> 4.2.0-next-20150831-2-gf55bad8 #1113
> [9.544830] Hardware name: Generic OMAP4 (Flattened Device Tree)
> [9.544830] Workqueue: deferwq deferred_probe_work_func
> [9.554809] [] (unwind_backtrace) from [] 
> (show_stack+0x10/0x14)
> [9.564819] [] (show_stack) from [] 
> (dump_stack+0x84/0x9c)
> [9.574829] [] (dump_stack) from [] 
> (warn_slowpath_common+0x78/0xb4)
> [9.574951] [] (warn_slowpath_common) from [] 
> (warn_slowpath_fmt+0x30/0x40)
> [9.584686] [] (warn_slowpath_fmt) from [] 
> (l3_interrupt_handler+0x224/0x350)
> [9.594818] [] (l3_interrupt_handler) from [] 
> (handle_irq_event_percpu+0x44/0x1f0)
> [9.604827] [] (handle_irq_event_percpu) from [] 
> (handle_irq_event+0x40/0x64)
> [9.614807] [] (handle_irq_event) from [] 
> (handle_fasteoi_irq+0xcc/0x1c4)
> [9.625396] [] (handle_fasteoi_irq) from [] 
> (generic_handle_irq+0x28/0x3c)
> [9.638732] [] (generic_handle_irq) from [] 
> (__handle_domain_irq+0x64/0xe0)
> [9.647827] [] (__handle_domain_irq) from [] 
> (gic_handle_irq+0x40/0x8c)
> [9.654693] [] (gic_handle_irq) from [] 
> (__irq_svc+0x58/0x78)
> [9.664367] Exception stack(0xee0cfd80 to 0xee0cfdc8)
> [9.665130] fd80: ee1ec010 c082f174 00d0  ee6b0800 ee6ae850 
> ee1ec000 ee1ec010
> [9.674835] fda0:  ee6b0cc0 00ee fa09c000 0003 ee0cfdd0 
> c04cd748 c04df4e0
> [9.684814] fdc0: 2113 
> [9.684814] [] (__irq_svc) from [] 
> (devm_clk_get+0x8/0x70)
> [9.694824] [] (devm_clk_get) from [] 
> (omap_hsmmc_probe+0x2e8/0x9f0)
> [9.704833] [] (omap_hsmmc_probe) from [] 
> (platform_drv_probe+0x44/0xac)
> [9.714691] [] (platform_drv_probe) from [] 
> (driver_probe_device+0x1f4/0x2f0)
> [9.724548] [] (driver_probe_device) from [] 
> (bus_for_each_drv+0x64/0x98)
> [9.733459] [] (bus_for_each_drv) from [] 
> (__device_attach+0xb0/0x118)
> [9.734832] [] (__device_attach) from [] 
> (bus_probe_device+0x88/0x90)
> [9.744812] [] (bus_probe_device) from [] 
> (deferred_probe_work_func+0x60/0x90)
> [9.760040] [] (deferred_probe_work_func) from [] 
> (process_one_work+0x1a4/0x558)
> [9.769470] [] (process_one_work) from [] 
> (worker_thread+0x3c/0x514)
> [9.774688] [] (worker_thread) from [] 
> (kthread+0xd4/0xf0)
> [9.785614] [] (kthread) from [] 
> (ret_from_fork+0x14/0x24)
> [9.785614] ---[ end trace 402743bd8cfdde2f ]---

And with the (currently almost useless) l3 interrupt stuff taken out by
removing the ti,omap4-l3-noc compatible from omap4.dtsi, we get a real
trace that might be of some help to you:

[8.440917] omap_hsmmc 4809c000.mmc: lookup for GPIO wp failed
[8.447418] Unhandled fault: imprecise external abort (0x1406) at 0xbeafaa10
[8.454925] pgd = c0004000
[8.454986] [beafaa10] *pgd=/root/init: line 14: 
/sys/devices/6800.ocp/4
8098000.spi/spi_master/spi1/spi1[8.461334] Internal error: : 1406 [#1] SMP 
ARM
.2/backlight/acx565akm/brightness: No such file [8.473175] Modules linked 
in:or directory
 rtc_twl twl4030_wdt
[8.483520] CPU: 1 PID: 66 Comm: kworker/u4:1 Not tainted 
4.2.0-next-20150831-2-gf55bad8-dirty #1115
[8.493652] Hardware name: Generic OMAP4 (Flattened Device Tree)
[8.498352] Workqueue: deferwq deferred_probe_work_func
[8.505493] task: ee5f4f40 ti: ee5f6000 task.ti: ee5f6000
[8.510803] PC is at devm_clk_get+0x8/0x70
[8.514801] LR is at omap_hsmmc_probe+0x2e8/0x9f0
[8.520385] pc : []lr : []psr: 20010013
[8.520385] sp : ee5f7dd0  ip : 0003  fp : fa09c000
[8.532470] r10: 00ee  r9 : ee6904c0  r8 : 
[8.537963] r7 : ee1ec010  r6 : ee1ec000  r5 : ee6e7dd0  r4 : ee69
[8.544769] r3 :   r2 : 00d0  r1 : c082f184  r0 : ee1ec010
[8.551666] Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
[8.559143] Control: 10c5387d  Table: ae73804a  DAC: 0051
[8.564727] Process kworker/

Re: [PATCH] gpio: omap: Fix gpiochip_add() handling for deferred probe

[Grygorii Strashko]

Hi Tony,

On 08/28/2015 09:44 PM, Tony Lindgren wrote:

Currently we gpio-omap breaks if gpiochip_add() returns -EPROBE_DEFER:

[0.57] gpiochip_add: GPIOs 0..31 (gpio) failed to register
[0.57] omap_gpio 4831.gpio: Could not register gpio chip -517
...
[3.67] omap_gpio 4831.gpio: Unbalanced pm_runtime_enable!


I have no objection to the patch itself.

But I curious, How have you got this error output? Was it simulated?



Let's fix the issue by adding the missing pm_runtime_put() on error.

Cc: Grygorii Strashko 
Cc: Javier Martinez Canillas 
Cc: Kevin Hilman 
Cc: Santosh Shilimkar 
Signed-off-by: Tony Lindgren 
---
  drivers/gpio/gpio-omap.c | 5 -
  1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index b0c57d5..f09bf0b 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -1232,8 +1232,11 @@ static int omap_gpio_probe(struct platform_device *pdev)
omap_gpio_mod_init(bank);

ret = omap_gpio_chip_init(bank, irqc);
-   if (ret)
+   if (ret) {
+   pm_runtime_put_sync(bank->dev);
+   pm_runtime_disable(bank->dev);
return ret;
+   }

omap_gpio_show_rev(bank);





--
regards,
-grygorii
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] regulator: pbias: use untranslated address to program pbias regulator

[Kishon Vijay Abraham I]

Hi Mark,

On Tuesday 25 August 2015 07:20 PM, Mark Brown wrote:
> On Tue, Aug 25, 2015 at 01:03:04PM +0300, Grygorii Strashko wrote:
>> On 08/19/2015 09:11 PM, Mark Brown wrote:
> 
>>> So substract this address from the start of the resource to get the
>>> offset?  Or provide a wrapper function in the resource code which does
>>> that.  
> 
>> I'd be very appreciated if you have and can share any thought on
>> How can we get this absolute base address to substract?
> 
> Ask the syscon device for its resource?  Or have it provide an absolute

Even if we get the absolute address of syscon, we have to do the
subtraction only for the newer dtbs (previous dtbs already have only the
offset). Do you recommend adding a new property to differentiate between
older dtbs and newer dtbs? Any other suggestions here?

> address based interface for that matter?

Syscon doesn't directly expose any API's to write to it's register.
Rather it uses regmap APIs to read/write to it's register. I'm not sure
if it's possible to add regmap APIs to write to a register with absolute
address. Any hints?

Thanks
Kishon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] spi: omap2-mcspi: add runtime PM to set_cs()

[Mark Brown]

On Sun, Aug 30, 2015 at 11:44:45AM -0500, Michael Welling wrote:

> The patch is currently sitting in linux-next.

> Not sure why it wasn't merged with 4.2.0-rc8.

You didn't indicate that it was a bug fix for Linus rather than a fix
for recent development :(


signature.asc
Description: Digital signature

Re: Linux 4.2.0-rc5: am335x: musb warnings

[Yegor Yefremov]

Hi Felipe,

On Fri, Aug 7, 2015 at 12:57 PM, Yegor Yefremov
 wrote:
> On Fri, Aug 7, 2015 at 12:16 PM, Yegor Yefremov
>  wrote:
>> On Thu, Aug 6, 2015 at 4:21 PM, Felipe Balbi  wrote:
>>> HI,
>>>
>>> On Thu, Aug 06, 2015 at 09:40:26AM +0200, Yegor Yefremov wrote:
 I performed a stress test with several FT4232H chips connected to a
>>>
>>> how many ?
>>
>> # lsusb -t
>> /:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M
>> /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M
>> |__ Port 1: Dev 2, If 0, Class=, Driver=hub/4p, 480M
>> |__ Port 1: Dev 3, If 0, Class=, Driver=ftdi_sio, 480M
>> |__ Port 1: Dev 3, If 1, Class=, Driver=ftdi_sio, 480M
>> |__ Port 1: Dev 3, If 2, Class=, Driver=ftdi_sio, 480M
>> |__ Port 1: Dev 3, If 3, Class=, Driver=ftdi_sio, 480M
>> |__ Port 2: Dev 4, If 0, Class=, Driver=ftdi_sio, 480M
>> |__ Port 2: Dev 4, If 1, Class=, Driver=ftdi_sio, 480M
>> |__ Port 2: Dev 4, If 2, Class=, Driver=ftdi_sio, 480M
>> |__ Port 2: Dev 4, If 3, Class=, Driver=ftdi_sio, 480M
>> |__ Port 3: Dev 5, If 0, Class=, Driver=ftdi_sio, 480M
>> |__ Port 3: Dev 5, If 1, Class=, Driver=ftdi_sio, 480M
>> |__ Port 3: Dev 5, If 2, Class=, Driver=ftdi_sio, 480M
>> |__ Port 3: Dev 5, If 3, Class=, Driver=ftdi_sio, 480M
>>
>> 3 chips a 4-ports are attached.
>
> Warnings appear on another device (without internal hub) with only one
> FT4232H too:
>
> # lsusb -t
> /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, 480M
> |__ Port 1: Dev 2, If 0, Class=, Driver=ftdi_sio, 480M
> |__ Port 1: Dev 2, If 1, Class=, Driver=ftdi_sio, 480M
> |__ Port 1: Dev 2, If 2, Class=, Driver=ftdi_sio, 480M
> |__ Port 1: Dev 2, If 3, Class=, Driver=ftdi_sio, 480M
>
 hub, that is attached to one of the musb ports. So far the test was
 successful for several hours. But I've seen following warnings:

 musb_host_rx 1973: Rx interrupt with no errors or packet!
 musb_ep_program 931: broken !rx_reinit, ep5 csr 0203
 musb_host_rx 1973: Rx interrupt with no errors or packet!
 musb_host_rx 1973: Rx interrupt with no errors or packet!
 musb_host_rx 1973: Rx interrupt with no errors or packet!
 musb_host_rx 1973: Rx interrupt with no errors or packet!
 musb_ep_program 931: broken !rx_reinit, ep5 csr 0003
 musb_host_rx 1973: Rx interrupt with no errors or packet!
 musb_ep_program 931: broken !rx_reinit, ep7 csr 0003

 Is this expected behavior?
>>>
>>> no, that shouldn't happen, but it does and, apparently, in more than one
>>> implementation. Wondering if you're running into endpoint limitation due
>>> to MUSB's poor transfer scheduling for non-bulk endpoints.
>>>
>>> --
>>> balbi

Now I have another trouble with msub and FTDI FT4232H chip. If I start
something like this on all 4 ports at 115200b/s, then pull USB cable
and the system freezes:

cat /dev/urandom > /dev/ttyUSB0
...
cat /dev/urandom > /dev/ttyUSB3

I see these messages:

ftdi_sio ttyUSB3: usb_serial_generic_write_bulk_callback - nonzero urb
status: -110
ftdi_sio ttyUSB0: usb_serial_generic_write_bulk_callback - nonzero urb
status: -110
ftdi_sio ttyUSB1: usb_serial_generic_write_bulk_callback - nonzero urb
status: -110
ftdi_sio ttyUSB2: usb_serial_generic_write_bulk_callback - nonzero urb
status: -110
ftdi_sio ttyUSB3: usb_serial_generic_write_bulk_callback - nonzero urb
status: -110
ftdi_sio ttyUSB0: usb_serial_generic_write_bulk_callback - nonzero urb
status: -110
ftdi_sio ttyUSB1: usb_serial_generic_write_bulk_callback - nonzero urb
status: -110
ftdi_sio ttyUSB2: usb_serial_generic_write_bulk_callback - nonzero urb
status: -110
ftdi_sio ttyUSB3: usb_serial_generic_write_bulk_callback - nonzero urb
status: -110

After them system reboots as my watchdog time expires.

Kernel 4.2.0-rc5

Older FTDI chips like FT2232 have no problems. Somehow is musb really
allergic to FTDI and vice versa :-(

Regards,
Yegor
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] spi: omap2-mcspi: add runtime PM to set_cs()

[Mark Brown]

On Mon, Aug 31, 2015 at 08:46:46AM -0500, Michael Welling wrote:
> On Mon, Aug 31, 2015 at 09:53:55AM +0100, Mark Brown wrote:
> > On Sun, Aug 30, 2015 at 11:44:45AM -0500, Michael Welling wrote:

> > > The patch is currently sitting in linux-next.

> > > Not sure why it wasn't merged with 4.2.0-rc8.

> > You didn't indicate that it was a bug fix for Linus rather than a fix
> > for recent development :(

Ah, actually it did get applied as a fix - it's just that I didn't send
a pull request before v4.3 got released.  Looking at what's there I
wasn't comfortable with the volume of fixes that arrived and never got
round to picking out those that were most urgent.  Sorry, these things
do happen from time to time I'm afraid especially when I'm travelling,
if something is urgent it's good to verify around -rc6 or so.

> Sorry, I did not know that it was my responsibility.

> How do I indicate this for future reference?

> The patch that Sebastian sent said the following:

> "
> Michael also tested the patch, but have not explicitly written an
> Tested-By, so you may want to wait for feedback from him. The patch
> should be sent for 4.2-rc, which introduced the regression.
> "

That's not in the changelog which is all I have after the patch is
applied (and what I was looking at since I just pulled the commit up by
ID).  If something is in Linus' tree it's often helpful to say
"...introduced in v4.2-rc1" or similar in the changelog.  Though in this
case it wasn't the issue.


signature.asc
Description: Digital signature

Re: [PATCH] spi: omap2-mcspi: add runtime PM to set_cs()

[Michael Welling]

On Mon, Aug 31, 2015 at 09:53:55AM +0100, Mark Brown wrote:
> On Sun, Aug 30, 2015 at 11:44:45AM -0500, Michael Welling wrote:
> 
> > The patch is currently sitting in linux-next.
> 
> > Not sure why it wasn't merged with 4.2.0-rc8.
> 
> You didn't indicate that it was a bug fix for Linus rather than a fix
> for recent development :(

Sorry, I did not know that it was my responsibility.

How do I indicate this for future reference?

The patch that Sebastian sent said the following:
"
Michael also tested the patch, but have not explicitly written an
Tested-By, so you may want to wait for feedback from him. The patch
should be sent for 4.2-rc, which introduced the regression.
"

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] net/smsc911x: Fix deferred probe for interrupt

[Grygorii Strashko]

On 08/30/2015 12:33 AM, Sergei Shtylyov wrote:
> Hello.
> 
> On 8/28/2015 9:50 PM, Tony Lindgren wrote:
> 
>> The interrupt handler may not be available when smsc911x probes if the
>> interrupt handler is a GPIO controller for example. Let's fix that
>> by adding handling for -EPROBE_DEFER.
> 
>> Cc: Steve Glendinning 
>> Signed-off-by: Tony Lindgren 
>> ---
>>   drivers/net/ethernet/smsc/smsc911x.c | 5 -
>>   1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/ethernet/smsc/smsc911x.c 
>> b/drivers/net/ethernet/smsc/smsc911x.c
>> index 959aeea..cb9f166f 100644
>> --- a/drivers/net/ethernet/smsc/smsc911x.c
>> +++ b/drivers/net/ethernet/smsc/smsc911x.c
>> @@ -2435,7 +2435,10 @@ static int smsc911x_drv_probe(struct 
>> platform_device *pdev)
>>   res_size = resource_size(res);
>>
>>   irq = platform_get_irq(pdev, 0);
>> -if (irq <= 0) {
>> +if (irq == -EPROBE_DEFER) {
>> +retval = -EPROBE_DEFER;
>> +goto out_0;
>> +} else if (irq <= 0) {
>>   pr_warn("Could not allocate irq resource\n");
>>   retval = -ENODEV;
> 
> I'd propagate the error code from platfrom_get_irq() instead (in 
> fact, I've submitted a couple of such patches yesterday and they have 
> been already merged).

Have you paid some attention on current platform_get_irq_() implementation?

The platform_get_irq() can return 0 in case of DT-boot.


-- 
regards,
-grygorii
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] gpio: omap: Fix gpiochip_add() handling for deferred probe

[Tony Lindgren]

* Grygorii Strashko  [150831 02:07]:
> Hi Tony,
> 
> On 08/28/2015 09:44 PM, Tony Lindgren wrote:
> >Currently we gpio-omap breaks if gpiochip_add() returns -EPROBE_DEFER:
> >
> >[0.57] gpiochip_add: GPIOs 0..31 (gpio) failed to register
> >[0.57] omap_gpio 4831.gpio: Could not register gpio chip -517
> >...
> >[3.67] omap_gpio 4831.gpio: Unbalanced pm_runtime_enable!
> 
> I have no objection to the patch itself.
> 
> But I curious, How have you got this error output? Was it simulated?

I ran into it when trying to get rid of all the custom initcalls
for various drivers. And especially if adding dts mappings for
gpio-ranges to try to find some solution for the 1.158 issue that
keeps me from having a mainline GPIO PM regresion test with
pinging wl12xx during off idle :)

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] gpio: omap: Fix gpiochip_add() handling for deferred probe

[Grygorii Strashko]

On 08/31/2015 05:11 PM, Tony Lindgren wrote:
> * Grygorii Strashko  [150831 02:07]:
>> Hi Tony,
>>
>> On 08/28/2015 09:44 PM, Tony Lindgren wrote:
>>> Currently we gpio-omap breaks if gpiochip_add() returns -EPROBE_DEFER:
>>>
>>> [0.57] gpiochip_add: GPIOs 0..31 (gpio) failed to register
>>> [0.57] omap_gpio 4831.gpio: Could not register gpio chip -517
>>> ...
>>> [3.67] omap_gpio 4831.gpio: Unbalanced pm_runtime_enable!
>>
>> I have no objection to the patch itself.
>>
>> But I curious, How have you got this error output? Was it simulated?
> 
> I ran into it when trying to get rid of all the custom initcalls
> for various drivers. And especially if adding dts mappings for
> gpio-ranges to try to find some solution for the 1.158 issue that
> keeps me from having a mainline GPIO PM regresion test with
> pinging wl12xx during off idle :)
> 

Ah. So, -EPROBE_DEFER was returned by of_gpiochip_add_pin_range(),
I was not able to find a place where gpiochip_add() can return -EPROBE_DEFER ;)

Thanks for clarification.


-- 
regards,
-grygorii
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html