Re: [PATCH v2] security: device_cgroup: fix RCU lockdep splat

[Josh Boyer]

On Wed, Sep 2, 2015 at 8:14 PM, Paul E. McKenney
 wrote:
> On Wed, Sep 02, 2015 at 12:24:50PM -0400, Tejun Heo wrote:
>> cc'ing Paul.
>>
>> On Wed, Sep 02, 2015 at 08:12:28AM -0500, Felipe Balbi wrote:
>> > 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.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)
>>
>> This shouldn't be happening because devcgroup_access_write() always
>> grabs devcgroup_mutex.  Looking at the log, the culprit seems to be
>> f78f5b90c4ff ("rcu: Rename rcu_lockdep_assert() to
>> RCU_LOCKDEP_WARN()").  It missed the bang for the second test while
>> inverting it, so adding rcu_read_lock() isn't the right fix here.
>>
>> Paul, can you please fix it?
>
> Gah!  Please see below.
>
> Thanx, Paul
>
> 
>
> security/device_cgroup: Fix RCU_LOCKDEP_WARN() condition
>
> f78f5b90c4ff ("rcu: Rename rcu_lockdep_assert() to RCU_LOCKDEP_WARN()")
> introduced a bug by incorrectly inverting the condition when moving from
> rcu_lockdep_assert() to RCU_LOCKDEP_WARN().  This commit therefore fixes
> the inversion.
>
> Reported-by: Felipe Balbi 
> Reported-by: Tejun Heo 
> Signed-off-by: Paul E. McKenney 
> Cc: Serge Hallyn 

Just tested this patch without Felipe's previous version on all my
machines.  The splat is indeed gone.

Tested-by: Josh Boyer 

josh

>
> diff --git a/security/device_cgroup.c b/security/device_cgroup.c
> index 73455089feef..03c1652c9a1f 100644
> --- a/security/device_cgroup.c
> +++ b/security/device_cgroup.c
> @@ -401,7 +401,7 @@ static bool verify_new_ex(struct dev_cgroup *dev_cgroup,
> bool match = false;
>
> RCU_LOCKDEP_WARN(!rcu_read_lock_held() &&
> -lockdep_is_held(_mutex),
> +!lockdep_is_held(_mutex),
>  "device_cgroup:verify_new_ex called without proper 
> synchronization");
>
> if (dev_cgroup->behavior == DEVCG_DEFAULT_ALLOW) {
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
--
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 v4 8/9] usb: dwc3: core: Prevent otg events from disabling themselves

[Roger Quadros]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 02/09/15 17:47, Felipe Balbi wrote:
> On Wed, Sep 02, 2015 at 05:24:23PM +0300, Roger Quadros wrote:
>> There is a race happening during dwc3_drd_init() that causes
>> otg events to get disabled. This is what happens.
>>
>> dwc3_otg_irq() happens immediately when PRTCAP is set to OTG,
>> even though OEVTEN is 0. This is because BIT 31 IRQ of
>> OEVT can't be disabled by OEVTEN.
>> We configure OEVTEN in dwc3_otg_init() but dwc3_otg_irq() has
>> already saved OEVTEN as 0 into dwc->oevten. So finally when
>> dwc3_irq_thread_irq() is called we save 0 into OEVTEN
>> thus disabling OTG irqs forever.
>>
>> We fix this by disabling IRQs when configuring OEVTEN in
>> dwc3_otg_init().
>>
>> Signed-off-by: Roger Quadros 
> 
> can't you just merge this patch into the one which introduced the bug to
> start with ?

Yes, I'll do that.

> 
>> ---
>>  drivers/usb/dwc3/core.c | 5 +
>>  1 file changed, 5 insertions(+)
>>
>> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
>> index 684010c..654aebf 100644
>> --- a/drivers/usb/dwc3/core.c
>> +++ b/drivers/usb/dwc3/core.c
>> @@ -921,6 +921,7 @@ static int dwc3_drd_init(struct dwc3 *dwc)
>>  int ret, id, vbus;
>>  struct usb_otg_caps *otgcaps = >otg_config.otg_caps;
>>  u32 reg;
>> +unsigned long flags;
>>  
>>  otgcaps->otg_rev = 0;
>>  otgcaps->hnp_support = false;
>> @@ -993,6 +994,8 @@ try_otg_core:
>>  goto error;
>>  }
>>  
>> +spin_lock_irqsave(>lock, flags);
>> +
>>  /* we need to set OTG to get events from OTG core */
>>  dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_OTG);
>>  /* GUSB2PHYCFG0.SusPHY=0 */
>> @@ -1018,6 +1021,8 @@ try_otg_core:
>>  /* OCTL.PeriMode = 1 */
>>  dwc3_writel(dwc->regs, DWC3_OCTL, DWC3_OCTL_PERIMODE);
>>  
>> +spin_unlock_irqrestore(>lock, flags);
>> +
>>  dwc3_otg_fsm_sync(dwc);
>>  usb_otg_sync_inputs(dwc->fsm);
>>  
>> -- 
>> 2.1.4
>>
> 
- --
cheers,
- -roger
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJV6FEnAAoJENJaa9O+djCTSjgQALL73OtdfKAWte2JFxsw1PVT
Xeh+ec7FJqNCKb2TwTSgnnWp6BxapbAlkK3kSwhsbgZvZLGtf3IC+xPHWNCs4dZs
uCs9oDPC/oAiYBnN3gYZxBFuhe1fsFEuS7aFIzrvKD/+tnXmd0IQ5Yu3k06VDXIM
jf/034Wep9AK44fyPy0sLKET1J6/UMvjxvUpEyxj9elbvs+GqzD9qR/GF6Ob8q6d
5f7y4ajMBCgyoC/wpIXDIJi7yqH1MUZq8bdC+7BKyc8Fz7kzVSpU2SL0BSRMU7Jn
Mzyx25WbWy1mXkfdgOjXtxx6MH5gV6jIIvqobyXXrK/e0z3kU6OeFprbubsOAvmC
fcgRkOrfr1O7/G5Gm7mhU5kLSZF6kvf6MoDPGCd/TbP4OgfYcPiTj5O020qDbRxZ
Hfuy/5Xk1oxR2aui1q9ycCWrpSA4L+B4fSpDXUznZw755BhhPnVeoYlXUfcb2sI+
YPNs6cLeX95I27AoMpK0wjMptmswaKcDmwv50mjK0kXgUcnVGs6z7YxSIJ2eAxPV
OpYLwVTfJiqoeJMscHvqoipwjlHqq4xS780SbzgZTDFOk2Ik7l0B6mNoL9CgaaXa
LVCBEywdWo+9os4b3JRrjDSqqdOMhBVaO0GvtiZZqfF7mOTmJHF/yFAODBw/CLXi
jAmBC/nM3M32CJphQQ1J
=z7cJ
-END PGP SIGNATURE-
--
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 v4 9/9] usb: dwc3: core: don't break during suspend/resume while we're dual-role

[Roger Quadros]

On 02/09/15 20:22, Sergei Shtylyov wrote:
> Hello.
> 
> On 09/02/2015 05:24 PM, Roger Quadros wrote:
> 
>> We can't rely just on dr_mode to decide if we're in host or gadget
>> mode when we're configured as otg/dual-role. So while dr_mode is
>> OTG, we find out from  the otg state machine if we're in host
>> or gadget mode and take the necessary actions during suspend/resume.
>>
>> Also make sure that we disable OTG irq and events during system suspend
>> so that we don't lockup the system during system suspend/resume.
>>
>> Signed-off-by: Roger Quadros 
>> ---
>>   drivers/usb/dwc3/core.c | 27 +--
>>   1 file changed, 9 insertions(+), 18 deletions(-)
>>
>> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
>> index 654aebf..25891e3 100644
>> --- a/drivers/usb/dwc3/core.c
>> +++ b/drivers/usb/dwc3/core.c
>> @@ -1455,18 +1455,15 @@ static int dwc3_suspend(struct device *dev)
>>   dwc->octl = dwc3_readl(dwc->regs, DWC3_OCTL);
>>   dwc->oevt = dwc3_readl(dwc->regs, DWC3_OEVT);
>>   dwc->oevten = dwc3_readl(dwc->regs, DWC3_OEVTEN);
>> +dwc3_writel(dwc->regs, DWC3_OEVTEN, 0);
>> +disable_irq(dwc->otg_irq);
>>   }
>>
>> -switch (dwc->dr_mode) {
>> -case USB_DR_MODE_PERIPHERAL:
>> -case USB_DR_MODE_OTG:
>> +if (dwc->dr_mode == USB_DR_MODE_PERIPHERAL ||
>> +((dwc->dr_mode == USB_DR_MODE_OTG) && (dwc->fsm->protocol == 
>> PROTO_GADGET)))
> 
>Hm, you're not very consistent about your parens. :-)

You're right. Should be

if ((dwc->dr_mode == USB_DR_MODE_PERIPHERAL) ||
((dwc->dr_mode == USB_DR_MODE_OTG) && (dwc->fsm->protocol == PROTO_GADGET)))


> 
> [...]
>> @@ -1506,18 +1503,12 @@ static int dwc3_resume(struct device *dev)
>>   dwc3_writel(dwc->regs, DWC3_OCTL, dwc->octl);
>>   dwc3_writel(dwc->regs, DWC3_OEVT, dwc->oevt);
>>   dwc3_writel(dwc->regs, DWC3_OEVTEN, dwc->oevten);
>> +enable_irq(dwc->otg_irq);
>>   }
>>
>> -switch (dwc->dr_mode) {
>> -case USB_DR_MODE_PERIPHERAL:
>> -case USB_DR_MODE_OTG:
>> +if (dwc->dr_mode == USB_DR_MODE_PERIPHERAL ||
>> +((dwc->dr_mode == USB_DR_MODE_OTG) && (dwc->fsm->protocol == 
>> PROTO_GADGET)))
> 
>Same here...

--
cheers,
-roger
--
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 v4 5/9] usb: dwc3: core: make dual-role work with OTG irq

[Roger Quadros]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 02/09/15 17:43, Felipe Balbi wrote:
> Hi,
> 
> On Wed, Sep 02, 2015 at 05:24:20PM +0300, Roger Quadros wrote:
>> If the ID pin event is not available over extcon
>> then we rely on the OTG controller to provide us ID and VBUS
>> information.
>>
>> We still don't support any OTG features but just
>> dual-role operation.
>>
>> Signed-off-by: Roger Quadros 
>> ---
>>  drivers/usb/dwc3/core.c | 217 
>> 
>>  drivers/usb/dwc3/core.h |   3 +
>>  2 files changed, 205 insertions(+), 15 deletions(-)
>>
>> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
>> index 38b31df..632ee53 100644
>> --- a/drivers/usb/dwc3/core.c
>> +++ b/drivers/usb/dwc3/core.c
>> @@ -704,6 +704,63 @@ static int dwc3_core_get_phy(struct dwc3 *dwc)
>>  return 0;
>>  }
>>  
>> +/* Get OTG events and sync it to OTG fsm */
>> +static void dwc3_otg_fsm_sync(struct dwc3 *dwc)
>> +{
>> +u32 reg;
>> +int id, vbus;
>> +
>> +reg = dwc3_readl(dwc->regs, DWC3_OSTS);
>> +dev_dbg(dwc->dev, "otgstatus 0x%x\n", reg);
>> +
>> +id = !!(reg & DWC3_OSTS_CONIDSTS);
>> +vbus = !!(reg & DWC3_OSTS_BSESVLD);
>> +
>> +if (id != dwc->fsm->id || vbus != dwc->fsm->b_sess_vld) {
>> +dev_dbg(dwc->dev, "id %d vbus %d\n", id, vbus);
>> +dwc->fsm->id = id;
>> +dwc->fsm->b_sess_vld = vbus;
>> +usb_otg_sync_inputs(dwc->fsm);
>> +}
> 
> this guy shouldn't try to filter events here. That's what the FSM should
> be doing.

OK. I'll remove the if condition.

> 
>> +}
>> +
>> +static irqreturn_t dwc3_otg_thread_irq(int irq, void *_dwc)
>> +{
>> +struct dwc3 *dwc = _dwc;
>> +unsigned long flags;
>> +irqreturn_t ret = IRQ_NONE;
> 
> this IRQ will be disabled pretty quickly. You *always* return IRQ_NONE
> 
>> +spin_lock_irqsave(>lock, flags);
> 
> if you cache current OSTS in dwc3, you can use that instead and change
> this to a spin_lock() instead of disabling IRQs here. This device's IRQs
> are already masked anyway.

OK.

> 
>> +dwc3_otg_fsm_sync(dwc);
>> +/* unmask interrupts */
>> +dwc3_writel(dwc->regs, DWC3_OEVTEN, dwc->oevten);
>> +spin_unlock_irqrestore(>lock, flags);
>> +
>> +return ret;
>> +}
>> +
>> +static irqreturn_t dwc3_otg_irq(int irq, void *_dwc)
>> +{
>> +struct dwc3 *dwc = _dwc;
>> +irqreturn_t ret = IRQ_NONE;
>> +u32 reg;
>> +
>> +spin_lock(>lock);
> 
> this seems unnecessary, we're already in hardirq with IRQs disabled.
> What sort of race could we have ? (in fact, this also needs change in
> dwc3/gadget.c).

You're right. Will fix at both places.
> 
>> +
>> +reg = dwc3_readl(dwc->regs, DWC3_OEVT);
>> +if (reg) {
>> +dwc3_writel(dwc->regs, DWC3_OEVT, reg);
>> +/* mask interrupts till processed */
>> +dwc->oevten = dwc3_readl(dwc->regs, DWC3_OEVTEN);
>> +dwc3_writel(dwc->regs, DWC3_OEVTEN, 0);
>> +ret = IRQ_WAKE_THREAD;
>> +}
>> +
>> +spin_unlock(>lock);
>> +
>> +return ret;
>> +}
>> +
>>  /* - Dual-Role management 
>> --- */
>>  
>>  static void dwc3_drd_fsm_sync(struct dwc3 *dwc)
>> @@ -728,15 +785,44 @@ static int dwc3_drd_start_host(struct otg_fsm *fsm, 
>> int on)
>>  {
>>  struct device *dev = usb_otg_fsm_to_dev(fsm);
>>  struct dwc3 *dwc = dev_get_drvdata(dev);
>> +u32 reg;
>>  
>>  dev_dbg(dwc->dev, "%s: %d\n", __func__, on);
>> +if (dwc->edev) {
>> +if (on) {
>> +dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_HOST);
>> +/* start the HCD */
>> +usb_otg_start_host(fsm, true);
>> +} else {
>> +/* stop the HCD */
>> +usb_otg_start_host(fsm, false);
>> +}
> 
>   if (on)
>   dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_HOST);
>   usb_otg_start_host(fsm, on);
> 

OK.

>> +
>> +return 0;
>> +}
>> +
>> +/* switch OTG core */
>>  if (on) {
>> -dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_HOST);
>> +/* OCTL.PeriMode = 0 */
>> +reg = dwc3_readl(dwc->regs, DWC3_OCTL);
>> +reg &= ~DWC3_OCTL_PERIMODE;
>> +dwc3_writel(dwc->regs, DWC3_OCTL, reg);
>> +/* unconditionally turn on VBUS */
>> +reg |= DWC3_OCTL_PRTPWRCTL;
>> +dwc3_writel(dwc->regs, DWC3_OCTL, reg);
>>  /* start the HCD */
>>  usb_otg_start_host(fsm, true);
>>  } else {
>>  /* stop the HCD */
>>  usb_otg_start_host(fsm, false);
>> +/* turn off VBUS */
>> +reg = dwc3_readl(dwc->regs, DWC3_OCTL);
>> +reg &= ~DWC3_OCTL_PRTPWRCTL;
>> +dwc3_writel(dwc->regs, DWC3_OCTL, reg);
>> +/* OCTL.PeriMode = 1 */
>> +reg = 

Re: [PATCH v4 6/9] usb: dwc3: save/restore OTG registers during suspend/resume

[Roger Quadros]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 02/09/15 17:44, Felipe Balbi wrote:
> On Wed, Sep 02, 2015 at 05:24:21PM +0300, Roger Quadros wrote:
>> Without this we loose OTG controller register context and malfunction
>> after a system suspend-resume.
>>
>> Signed-off-by: Roger Quadros 
>> ---
>>  drivers/usb/dwc3/core.c | 17 +
>>  drivers/usb/dwc3/core.h |  6 +-
>>  2 files changed, 22 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
>> index 632ee53..684010c 100644
>> --- a/drivers/usb/dwc3/core.c
>> +++ b/drivers/usb/dwc3/core.c
>> @@ -56,6 +56,7 @@ void dwc3_set_mode(struct dwc3 *dwc, u32 mode)
>>  reg = dwc3_readl(dwc->regs, DWC3_GCTL);
>>  reg &= ~(DWC3_GCTL_PRTCAPDIR(DWC3_GCTL_PRTCAP_OTG));
>>  reg |= DWC3_GCTL_PRTCAPDIR(mode);
>> +dwc->current_mode = mode;
>>  dwc3_writel(dwc->regs, DWC3_GCTL, reg);
>>  }
>>  
>> @@ -1443,6 +1444,14 @@ static int dwc3_suspend(struct device *dev)
>>  
>>  spin_lock_irqsave(>lock, flags);
>>  
>> +/* Save OTG state only if we're really using it */
>> +if (dwc->current_mode == DWC3_GCTL_PRTCAP_OTG) {
>> +dwc->ocfg = dwc3_readl(dwc->regs, DWC3_OCFG);
>> +dwc->octl = dwc3_readl(dwc->regs, DWC3_OCTL);
>> +dwc->oevt = dwc3_readl(dwc->regs, DWC3_OEVT);
> 
> oevt is what you use to clear pending IRQs, which means that ...
> 
>> +dwc->oevten = dwc3_readl(dwc->regs, DWC3_OEVTEN);
>> +}
>> +
>>  switch (dwc->dr_mode) {
>>  case USB_DR_MODE_PERIPHERAL:
>>  case USB_DR_MODE_OTG:
>> @@ -1486,6 +1495,14 @@ static int dwc3_resume(struct device *dev)
>>  dwc3_event_buffers_setup(dwc);
>>  dwc3_writel(dwc->regs, DWC3_GCTL, dwc->gctl);
>>  
>> +/* Restore OTG state only if we're really using it */
>> +if (dwc->current_mode == DWC3_GCTL_PRTCAP_OTG) {
>> +dwc3_writel(dwc->regs, DWC3_OCFG, dwc->ocfg);
>> +dwc3_writel(dwc->regs, DWC3_OCTL, dwc->octl);
>> +dwc3_writel(dwc->regs, DWC3_OEVT, dwc->oevt);
> 
> ... you could be clearing pending IRQs right here.

Good catch. So we can't really restore this register.
I'll remove this line.

> 
>> +dwc3_writel(dwc->regs, DWC3_OEVTEN, dwc->oevten);
>> +}
>> +
>>  switch (dwc->dr_mode) {
>>  case USB_DR_MODE_PERIPHERAL:
>>  case USB_DR_MODE_OTG:
>> diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
>> index 129ef37..1115ce0 100644
>> --- a/drivers/usb/dwc3/core.h
>> +++ b/drivers/usb/dwc3/core.h
>> @@ -737,6 +737,7 @@ struct dwc3_scratchpad_array {
>>   * @regs: base address for our registers
>>   * @regs_size: address space size
>>   * @oevten: otg interrupt enable mask copy
>> + * @current_mode: current mode of operation written to PRTCAPDIR
>>   * @nr_scratch: number of scratch buffers
>>   * @num_event_buffers: calculated number of event buffers
>>   * @u1u2: only used on revisions <1.83a for workaround
>> @@ -858,9 +859,12 @@ struct dwc3 {
>>  /* used for suspend/resume */
>>  u32 dcfg;
>>  u32 gctl;
>> -
>> +u32 ocfg;
>> +u32 octl;
>> +u32 oevt;
>>  u32 oevten;
>>  
>> +u32 current_mode;
>>  u32 nr_scratch;
>>  u32 num_event_buffers;
>>  u32 u1u2;
>> -- 
>> 2.1.4
>>
> 

- --
cheers,
- -roger
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJV6FEGAAoJENJaa9O+djCTE7gP/0rlQJPL1R11k8hJCM842zjT
SSxfdNQ9kkG008D88As8nLodL79agvD/XBot7iIrTGVFMG/tzzkwQb71gZoCOogb
K0eMMnLNyzLRapNpOe1OJqI1NjO8Yx1o7heoaGkGYERR7m6dwz1LmSPYEtaaveVq
5gb5NbUKfSq0Cs6wM+3+U8CQzAPLf7eRSZwiORkzyn7cWiZDsYHr9Bn35NA24r5v
0YMQvmTp7K/7pFENiFHmOWbKPoY6G8ebkInBSMXQfHcLPtL86l9e+VrlJrIZzBqQ
SJyoQw8JFU9c2ojtKeG9AYn8fSbCQpbsuIFAZtCVy2rK4xMiITmaSsjHF5+KpBt2
cE7eahicYAP3edLqT0R0hYfiI+JrVuOdkiW+W8UWPHrGt/nELQjQxZtIkTOI1b9B
FIxnZbIwp0veEE+vqXiTQizUPdZag0qPG1PZ5Bpu0867vfX6khY2MCNeYTDatzHT
dz9RwWIDH3/K5K7TOug/VZEiqvLY3BYMrMK+W3FreGfagwvYvlLyojsHifrA1x9z
1+zAjkml1kIIP5Jlf3VOYdLsN8mgeMyCNfi5USvVFnzPITAjtwm9+ai7xxxCjSxA
QTvmhQRjAxIPWWZgVuc/Z5PdqgHKFKpCLxG8IE9bqGBQnNSKueZHEhfUCxfPNKV6
ZkkhIq/s6hm6S/YM4WcS
=hUag
-END PGP SIGNATURE-
--
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 v4 9/9] usb: dwc3: core: don't break during suspend/resume while we're dual-role

[Roger Quadros]

On 03/09/15 17:05, Sergei Shtylyov wrote:
> Hello.
> 
> On 09/03/2015 05:01 PM, Roger Quadros wrote:
> 
 We can't rely just on dr_mode to decide if we're in host or gadget
 mode when we're configured as otg/dual-role. So while dr_mode is
 OTG, we find out from  the otg state machine if we're in host
 or gadget mode and take the necessary actions during suspend/resume.

 Also make sure that we disable OTG irq and events during system suspend
 so that we don't lockup the system during system suspend/resume.

 Signed-off-by: Roger Quadros 
 ---
drivers/usb/dwc3/core.c | 27 +--
1 file changed, 9 insertions(+), 18 deletions(-)

 diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
 index 654aebf..25891e3 100644
 --- a/drivers/usb/dwc3/core.c
 +++ b/drivers/usb/dwc3/core.c
 @@ -1455,18 +1455,15 @@ static int dwc3_suspend(struct device *dev)
dwc->octl = dwc3_readl(dwc->regs, DWC3_OCTL);
dwc->oevt = dwc3_readl(dwc->regs, DWC3_OEVT);
dwc->oevten = dwc3_readl(dwc->regs, DWC3_OEVTEN);
 +dwc3_writel(dwc->regs, DWC3_OEVTEN, 0);
 +disable_irq(dwc->otg_irq);
}

 -switch (dwc->dr_mode) {
 -case USB_DR_MODE_PERIPHERAL:
 -case USB_DR_MODE_OTG:
 +if (dwc->dr_mode == USB_DR_MODE_PERIPHERAL ||
 +((dwc->dr_mode == USB_DR_MODE_OTG) && (dwc->fsm->protocol == 
 PROTO_GADGET)))
>>>
>>> Hm, you're not very consistent about your parens. :-)
>>
>> You're right. Should be
>>
>> if ((dwc->dr_mode == USB_DR_MODE_PERIPHERAL) ||
>>  ((dwc->dr_mode == USB_DR_MODE_OTG) && (dwc->fsm->protocol == 
>> PROTO_GADGET)))
> 
>Parens around == are useless, I'd prefer if you deleted them. But if you'd 
> like to keep them, let it be so. :-)

OK, how about this then?

if (dwc->dr_mode == USB_DR_MODE_PERIPHERAL ||
(dwc->dr_mode == USB_DR_MODE_OTG && dwc->fsm->protocol == PROTO_GADGET))

cheers,
-roger
--
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 0/6] regulator: Fix pbias regulator enable

[Tony Lindgren]

* Kishon Vijay Abraham I  [150903 02:25]:
> On Thursday 03 September 2015 01:09 PM, Ulf Hansson wrote:
> > 
> > Finally, perhaps it's better if we queue this through my mmc tree
> > since we would then be able to avoid the regression - if I put
> > $subject patchset before [1], right? Then I need an ack from Mark for
> > the regulator patch.
> > Please tell me if you guys prefer another way.

That works for me too. Or Mark can set up an immutable signed
branch that you can merge in, up to you guys.

It's still going to break git bisect for booting but
removes the regression when mergeing to mainline.

I'd squash all the one liner dts changes into a single
patch though when applying to cut down on the commit
noise.

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 v2] security: device_cgroup: fix RCU lockdep splat

[Serge E. Hallyn]

On Wed, Sep 02, 2015 at 05:14:33PM -0700, Paul E. McKenney wrote:
> On Wed, Sep 02, 2015 at 12:24:50PM -0400, Tejun Heo wrote:
> > cc'ing Paul.
> > 
> > On Wed, Sep 02, 2015 at 08:12:28AM -0500, Felipe Balbi wrote:
> > > 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.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)
> > 
> > This shouldn't be happening because devcgroup_access_write() always
> > grabs devcgroup_mutex.  Looking at the log, the culprit seems to be
> > f78f5b90c4ff ("rcu: Rename rcu_lockdep_assert() to
> > RCU_LOCKDEP_WARN()").  It missed the bang for the second test while
> > inverting it, so adding rcu_read_lock() isn't the right fix here.
> > 
> > Paul, can you please fix it?
> 
> Gah!  Please see below.
> 
>   Thanx, Paul
> 
> 
> 
> security/device_cgroup: Fix RCU_LOCKDEP_WARN() condition
> 
> f78f5b90c4ff ("rcu: Rename rcu_lockdep_assert() to RCU_LOCKDEP_WARN()")
> introduced a bug by incorrectly inverting the condition when moving from
> rcu_lockdep_assert() to RCU_LOCKDEP_WARN().  This commit therefore fixes
> the inversion.
> 
> Reported-by: Felipe Balbi 
> Reported-by: Tejun Heo 
> Signed-off-by: Paul E. McKenney 
> Cc: Serge Hallyn 

Oh, makes sense :)  (didn't see the original patch when it came by, sorry)

Acked-by: Serge Hallyn 

> diff --git a/security/device_cgroup.c b/security/device_cgroup.c
> index 73455089feef..03c1652c9a1f 100644
> --- a/security/device_cgroup.c
> +++ b/security/device_cgroup.c
> @@ -401,7 +401,7 @@ static bool verify_new_ex(struct dev_cgroup *dev_cgroup,
>   bool match = false;
>  
>   RCU_LOCKDEP_WARN(!rcu_read_lock_held() &&
> -  lockdep_is_held(_mutex),
> +  !lockdep_is_held(_mutex),
>"device_cgroup:verify_new_ex called without proper 
> synchronization");
>  
>   if (dev_cgroup->behavior == DEVCG_DEFAULT_ALLOW) {
--
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 0/4] omap: Fix broken address translation for pbias

[Tony Lindgren]

* Kishon Vijay Abraham I  [150903 04:31]:
> pbias device stopped having memory resource after
> "ARM: dts: : add minimal l4 bus layout with control module
> support" got merged. This results in platform_get_resource returning
> -EINVAL in pbias driver. This is because address translation fails
> while trying to convert the address to resource which happens
> during the device creation process during boot up.
> 
> Even though after [1], reg property in pbias dt node is un-used,
> it might be an issue if we plan to use it at a later point of time.
> 
> Patch series is created on top of [1].
> 
> [1] -> https://lkml.org/lkml/2015/9/3/51
> 
> Verified the address in omap4 panda, omap5 uevm and dra72 boards.

Your other series is obviously needed for v4.3.. But seems these
are also needed for stable? If so, which versions, v4.2+?

Can you please just do a single patch with multiple Fixes tags
as they fix regression for multiple commits? Doing tons of one
liner patches for the same thing just creates commit log noise..

Remember to not Cc stable when posting, I'll add that tag when
committing if needed.

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 v4 9/9] usb: dwc3: core: don't break during suspend/resume while we're dual-role

[Sergei Shtylyov]

Hello.

On 09/03/2015 05:01 PM, Roger Quadros wrote:


We can't rely just on dr_mode to decide if we're in host or gadget
mode when we're configured as otg/dual-role. So while dr_mode is
OTG, we find out from  the otg state machine if we're in host
or gadget mode and take the necessary actions during suspend/resume.

Also make sure that we disable OTG irq and events during system suspend
so that we don't lockup the system during system suspend/resume.

Signed-off-by: Roger Quadros 
---
   drivers/usb/dwc3/core.c | 27 +--
   1 file changed, 9 insertions(+), 18 deletions(-)

diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 654aebf..25891e3 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -1455,18 +1455,15 @@ static int dwc3_suspend(struct device *dev)
   dwc->octl = dwc3_readl(dwc->regs, DWC3_OCTL);
   dwc->oevt = dwc3_readl(dwc->regs, DWC3_OEVT);
   dwc->oevten = dwc3_readl(dwc->regs, DWC3_OEVTEN);
+dwc3_writel(dwc->regs, DWC3_OEVTEN, 0);
+disable_irq(dwc->otg_irq);
   }

-switch (dwc->dr_mode) {
-case USB_DR_MODE_PERIPHERAL:
-case USB_DR_MODE_OTG:
+if (dwc->dr_mode == USB_DR_MODE_PERIPHERAL ||
+((dwc->dr_mode == USB_DR_MODE_OTG) && (dwc->fsm->protocol == 
PROTO_GADGET)))


Hm, you're not very consistent about your parens. :-)


You're right. Should be

if ((dwc->dr_mode == USB_DR_MODE_PERIPHERAL) ||
 ((dwc->dr_mode == USB_DR_MODE_OTG) && (dwc->fsm->protocol == 
PROTO_GADGET)))


   Parens around == are useless, I'd prefer if you deleted them. But if you'd 
like to keep them, let it be so. :-)



--
cheers,
-roger


MBR, 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: [net-next PATCH v2] drivers: net: cpsw: Add support to make gpio drive which slave connected to phy

[Tony Lindgren]

* Mugunthan V N  [150902 23:05]:
> In DRA72x EVM, by default slave 1 is connected to the onboard
> phy, but slave 2 pins are also muxed with video input module
> which is controlled by pcf857x gpio and currently to select slave
> 0 to connect to phy gpio hogging is used, but with
> omap2plus_defconfig the pcf857x gpio is built as module. So when
> using NFS on DRA72x EVM, board doesn't boot as gpio hogging do
> not set proper gpio state to connect slave 0 to phy as it is
> built as module and you do not see any errors for not setting
> gpio and just mentions dhcp reply not got.
> 
> To solve this issue, introducing "mode-gpio" in DT when gpio
> based muxing is required. This will throw a warning when gpio
> get fails and returns probe defer. When gpio-pcf857x module is
> installed, cpsw probes again and ethernet becomes functional.
> Verified this on DRA72x with pcf as module and ramdisk.

Hmm you might be able to make it even a little bit more generic.
The gpios can be an array.. So typically they're named "-gpios":

[linux] $ git grep "\-gpio " arch/arm/boot/dts/*.dts* | wc -l
219
[linux] $ git grep "\-gpios " arch/arm/boot/dts/*.dts* | wc -l
704

So I'd use mode-gpios even though there's just one gpio in
this case. Up to you though, and should be retested after
the change naturally. At some point gpio code was not parsing
"gpio" or "gpios" properly.. But that's probably been fixed
a long time ago.

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: [RFC PATCH 1/4] ARM: OMAP2: DRA7: Modify optimize string comparisons in soc_is calls

[Tony Lindgren]

* Felipe Balbi  [150902 05:34]:
> On Wed, Sep 02, 2015 at 03:50:10PM +0530, Keerthy wrote:
> > Currently everytime soc_is calls are made, firstly device tree nodes
> > are parsed and then string comparisons are made to determine the
> > soc version. Optimizing it to be done one time and store the result.
> 
> but is that really a problem ? Are soc_is* calls made in any critical
> path ? Please provide some benchmarking data.

Regarding the SoC detection, there are multiple issues to consider here:

1. We want to unify the SoC detection so it behaves the same way
   for all SoCs

2. We don't want the dts files to explode with boards having
   multiple SoC revisions. So SoC detection and features
   detection for SGX and DSP etc should be done after setting
   the major SoC class based on compatible value

3. We don't want to do pointless string comparison over and
   over

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] ARM: multi_v7_defconfig: Enable PBIAS regulator

[Tony Lindgren]

* Kishon Vijay Abraham I  [150903 02:58]:
> PBIAS regulator is required for MMC module in OMAP2, OMAP3, OMAP4,
> OMAP5 and DRA7 SoCs. Enable it here.
> 
> Signed-off-by: Kishon Vijay Abraham I 

For the multi_v7_defconfig changes you need to resend this
to a...@kernel.org. This is to avoid conflicts with other
patches.

Regards,

Tony

>  arch/arm/configs/multi_v7_defconfig |1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/configs/multi_v7_defconfig 
> b/arch/arm/configs/multi_v7_defconfig
> index 5fd8df6..f497c96 100644
> --- a/arch/arm/configs/multi_v7_defconfig
> +++ b/arch/arm/configs/multi_v7_defconfig
> @@ -403,6 +403,7 @@ CONFIG_REGULATOR_MAX8973=y
>  CONFIG_REGULATOR_MAX77686=y
>  CONFIG_REGULATOR_MAX77693=m
>  CONFIG_REGULATOR_PALMAS=y
> +CONFIG_REGULATOR_PBIAS=y
>  CONFIG_REGULATOR_S2MPS11=y
>  CONFIG_REGULATOR_S5M8767=y
>  CONFIG_REGULATOR_TPS51632=y
> -- 
> 1.7.9.5
> 
--
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 v4 9/9] usb: dwc3: core: don't break during suspend/resume while we're dual-role

[Roger Quadros]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 02/09/15 17:48, Felipe Balbi wrote:
> On Wed, Sep 02, 2015 at 05:24:24PM +0300, Roger Quadros wrote:
>> We can't rely just on dr_mode to decide if we're in host or gadget
>> mode when we're configured as otg/dual-role. So while dr_mode is
>> OTG, we find out from  the otg state machine if we're in host
>> or gadget mode and take the necessary actions during suspend/resume.
>>
>> Also make sure that we disable OTG irq and events during system suspend
>> so that we don't lockup the system during system suspend/resume.
>>
>> Signed-off-by: Roger Quadros 
>> ---
>>  drivers/usb/dwc3/core.c | 27 +--
>>  1 file changed, 9 insertions(+), 18 deletions(-)
>>
>> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
>> index 654aebf..25891e3 100644
>> --- a/drivers/usb/dwc3/core.c
>> +++ b/drivers/usb/dwc3/core.c
>> @@ -1455,18 +1455,15 @@ static int dwc3_suspend(struct device *dev)
>>  dwc->octl = dwc3_readl(dwc->regs, DWC3_OCTL);
>>  dwc->oevt = dwc3_readl(dwc->regs, DWC3_OEVT);
>>  dwc->oevten = dwc3_readl(dwc->regs, DWC3_OEVTEN);
>> +dwc3_writel(dwc->regs, DWC3_OEVTEN, 0);
>> +disable_irq(dwc->otg_irq);
> 
> you don't need disable_irq() here. In fact, it causes problems since
> you're calling it with IRQs disabled.

OK. will remove it.

> 
>>  }
>>  
>> -switch (dwc->dr_mode) {
>> -case USB_DR_MODE_PERIPHERAL:
>> -case USB_DR_MODE_OTG:
>> +if (dwc->dr_mode == USB_DR_MODE_PERIPHERAL ||
>> +((dwc->dr_mode == USB_DR_MODE_OTG) && (dwc->fsm->protocol == 
>> PROTO_GADGET)))
>>  dwc3_gadget_suspend(dwc);
>> -/* FALLTHROUGH */
>> -case USB_DR_MODE_HOST:
>> -default:
>> -dwc3_event_buffers_cleanup(dwc);
>> -break;
>> -}
>> +
>> +dwc3_event_buffers_cleanup(dwc);
>>  
>>  dwc->gctl = dwc3_readl(dwc->regs, DWC3_GCTL);
>>  spin_unlock_irqrestore(>lock, flags);
>> @@ -1506,18 +1503,12 @@ static int dwc3_resume(struct device *dev)
>>  dwc3_writel(dwc->regs, DWC3_OCTL, dwc->octl);
>>  dwc3_writel(dwc->regs, DWC3_OEVT, dwc->oevt);
>>  dwc3_writel(dwc->regs, DWC3_OEVTEN, dwc->oevten);
>> +enable_irq(dwc->otg_irq);
>>  }
>>  
>> -switch (dwc->dr_mode) {
>> -case USB_DR_MODE_PERIPHERAL:
>> -case USB_DR_MODE_OTG:
>> +if (dwc->dr_mode == USB_DR_MODE_PERIPHERAL ||
>> +((dwc->dr_mode == USB_DR_MODE_OTG) && (dwc->fsm->protocol == 
>> PROTO_GADGET)))
>>  dwc3_gadget_resume(dwc);
>> -/* FALLTHROUGH */
>> -case USB_DR_MODE_HOST:
>> -default:
>> -/* do nothing */
>> -break;
>> -}
>>  
>>  spin_unlock_irqrestore(>lock, flags);
>>  
>> -- 
>> 2.1.4
>>
> 

- --
cheers,
- -roger
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJV6FLtAAoJENJaa9O+djCTxnMQANGOTEBjO8E9v32qfrgwL6X+
VyTeGBHhfwv7/u7xOM0im6tfXXaLtjj16mEY8fePC+oXO2Vv3RDxi0HTiF6sePnT
odt8nTOYGq7arPAKrtL8BK/8xyJRDjijXWGdQDAgPT1D5V2y8Ib4AbkM2j5IkL+/
75EGybhxIPNGNEV2eS/OBn2BPWSzn/r6rFMJiuYPY2yoPQqwG1ovdt+K+tvMybvZ
sYdQxu4UPN1z1pKplmCQxmPut9SyCqIAeHXdWGT6kJsleBsv2WNM1ZdM/y4zZmMw
gpyNOs+HYqdd/llfEYFrSRnSM2io2GyKZ73xM+DVfY8ot7Vf/h4x41Dz4V19jqtC
3IoyPzNb+inbsRKs0GhTw3yD9N8b7xRbVF+qZPIvDvn7QGLF2pY8cDiqZE1LiOs2
VpKBRoC0wdmdQ/bjRMt516jFmJiQ2RbR2SenGffIr+PrCb1EQ7Fmwtoya5FPgIz/
nMdL7g1MGHUzWvzXTYO+RH4bHV9cDL66qekOL7PR1yEyAAo09vLc+ds/4z85MGQ6
2JYKYb4Mdtv2EAOzIqNR3+FzcCawpZbhm8bBFz14Kj12pgjwl5A3o+fYaZ4Q07OK
ZfFRAUG4RKFNVcjb7hhiBPdN+mb34/50YreFcNj/MOYwklXwUAmgiTFH7cjO9SA7
XZpbfSRwT4Ec4WWqTeeR
=unNn
-END PGP SIGNATURE-
--
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 v4 9/9] usb: dwc3: core: don't break during suspend/resume while we're dual-role

[Sergei Shtylyov]

On 09/03/2015 05:10 PM, Roger Quadros wrote:


We can't rely just on dr_mode to decide if we're in host or gadget
mode when we're configured as otg/dual-role. So while dr_mode is
OTG, we find out from  the otg state machine if we're in host
or gadget mode and take the necessary actions during suspend/resume.

Also make sure that we disable OTG irq and events during system suspend
so that we don't lockup the system during system suspend/resume.

Signed-off-by: Roger Quadros 
---
drivers/usb/dwc3/core.c | 27 +--
1 file changed, 9 insertions(+), 18 deletions(-)

diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 654aebf..25891e3 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -1455,18 +1455,15 @@ static int dwc3_suspend(struct device *dev)
dwc->octl = dwc3_readl(dwc->regs, DWC3_OCTL);
dwc->oevt = dwc3_readl(dwc->regs, DWC3_OEVT);
dwc->oevten = dwc3_readl(dwc->regs, DWC3_OEVTEN);
+dwc3_writel(dwc->regs, DWC3_OEVTEN, 0);
+disable_irq(dwc->otg_irq);
}

-switch (dwc->dr_mode) {
-case USB_DR_MODE_PERIPHERAL:
-case USB_DR_MODE_OTG:
+if (dwc->dr_mode == USB_DR_MODE_PERIPHERAL ||
+((dwc->dr_mode == USB_DR_MODE_OTG) && (dwc->fsm->protocol == 
PROTO_GADGET)))


 Hm, you're not very consistent about your parens. :-)


You're right. Should be

if ((dwc->dr_mode == USB_DR_MODE_PERIPHERAL) ||
  ((dwc->dr_mode == USB_DR_MODE_OTG) && (dwc->fsm->protocol == 
PROTO_GADGET)))


Parens around == are useless, I'd prefer if you deleted them. But if you'd 
like to keep them, let it be so. :-)



OK, how about this then?



if (dwc->dr_mode == USB_DR_MODE_PERIPHERAL ||
 (dwc->dr_mode == USB_DR_MODE_OTG && dwc->fsm->protocol == PROTO_GADGET))


   Strictly speaking, parens around && are also not needed but gcc may 
probably issue a warning without them. Not sure, your call.



cheers,
-roger


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

[PATCH] pinctrl: core: Warn about NULL gpio_chip in pinctrl_ready_for_gpio_range()

[Tony Lindgren]

If the gpio driver is confused about the numbers for gpio-ranges,
pinctrl_ready_for_gpio_range() may get called with invalid GPIO
causing a NULL pointer exception. Let's instead provide a warning
that allows fixing the problem and return with error.

Signed-off-by: Tony Lindgren 
---
 drivers/pinctrl/core.c | 3 +++
 1 file changed, 3 insertions(+)

--- a/drivers/pinctrl/core.c
+++ b/drivers/pinctrl/core.c
@@ -349,6 +349,9 @@ static bool pinctrl_ready_for_gpio_range(unsigned gpio)
struct pinctrl_gpio_range *range = NULL;
struct gpio_chip *chip = gpio_to_chip(gpio);
 
+   if (WARN(!chip, "no gpio_chip for gpio%i?", gpio))
+   return false;
+
mutex_lock(_list_mutex);
 
/* Loop over the pin controllers */
-- 
2.1.4

--
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] gpio: omap: Fix GPIO numbering for deferred probe

[Tony Lindgren]

If gpio-omap probe fails with -EPROBE_DEFER, the GPIO numbering
keeps increasing. Only increase the gpio count if gpiochip_add()
was successful as otherwise the numbers will increase for each
probe attempt.

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

--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -1095,7 +1095,6 @@ static int omap_gpio_chip_init(struct gpio_bank *bank, 
struct irq_chip *irqc)
} else {
bank->chip.label = "gpio";
bank->chip.base = gpio;
-   gpio += bank->width;
}
bank->chip.ngpio = bank->width;
 
@@ -1105,6 +1104,9 @@ static int omap_gpio_chip_init(struct gpio_bank *bank, 
struct irq_chip *irqc)
return ret;
}
 
+   if (!bank->is_mpuio)
+   gpio += bank->width;
+
 #ifdef CONFIG_ARCH_OMAP1
/*
 * REVISIT: Once we have OMAP1 supporting SPARSE_IRQ, we can drop
-- 
2.1.4

--
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] ARM: dts: am57xx-beagle-x15: Add wakeup irq for mcp79410

[Nishanth Menon]

With the support in the generic PM framework for wakeirq and capability
added to the rtc-ds1307 driver to support this, we can now define the
optional wakeup irq to allow the RTC to wakeup the system from low power
modes as part of suspend.

Signed-off-by: Nishanth Menon 
---

This patch depends on upcoming merge for RTC
https://git.kernel.org/cgit/linux/kernel/git/abelloni/linux.git/log/?h=rtc-next=50

merge to master of:
9901c41bd019 rtc: ds1307: Support optional wakeup interrupt source
496a7ede6cac rtc: ds1307: Sort the headers
e28475b15b65 rtc: ds1307: Switch to managed irq allocation
27a1dce6528a rtc: ds1307: Convert to threaded IRQ

Tested with the above commits from linux-next: 
http://pastebin.ubuntu.com/12265857/

Could probably go in round 2 of merges for 4.3?

 arch/arm/boot/dts/am57xx-beagle-x15.dts |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/am57xx-beagle-x15.dts 
b/arch/arm/boot/dts/am57xx-beagle-x15.dts
index ede7fb73c717..8464f3cea280 100644
--- a/arch/arm/boot/dts/am57xx-beagle-x15.dts
+++ b/arch/arm/boot/dts/am57xx-beagle-x15.dts
@@ -526,7 +526,8 @@
mcp_rtc: rtc@6f {
compatible = "microchip,mcp7941x";
reg = <0x6f>;
-   interrupts = ;  /* IRQ_SYS_1N */
+   interrupts-extended = <_mpu GIC_SPI 2 
IRQ_TYPE_EDGE_RISING>,
+ <_pmx_core 0x424>;
 
pinctrl-names = "default";
pinctrl-0 = <_pins_default>;
-- 
1.7.9.5

--
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] ARM: dts: am57xx-beagle-x15: Update Phy supplies

[Nishanth Menon]

Originally, all the SoC PHY rails were supplied by LDO3. However, as a
result of characterization, it was determined that this posed a risk in
extreme load  conditions. Hence the PHY rails are split between two
different LDOs. Update the related node as a result

LDO3/VDDA_1V8_PHYA supplies vdda_usb1, vdda_usb2, vdda_sata, vdda_usb3
LDO4/VDDA_1V8_PHYB supplies vdda_pcie1, vdda_pcie0, vdda_hdmi, vdda_pcie

NOTE: We break compatibility with pre-production boards with this change
since, the PMIC LDO4 is disabled at OTP level.

The new configuration is the plan of record and all pre-production
boards are supposed to be replaced with the latest boards matching the
mentioned configuration.

Signed-off-by: Nishanth Menon 
---
 arch/arm/boot/dts/am57xx-beagle-x15.dts |   13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/am57xx-beagle-x15.dts 
b/arch/arm/boot/dts/am57xx-beagle-x15.dts
index 3a05b94f59ed..ede7fb73c717 100644
--- a/arch/arm/boot/dts/am57xx-beagle-x15.dts
+++ b/arch/arm/boot/dts/am57xx-beagle-x15.dts
@@ -432,7 +432,7 @@
};
 
ldo3_reg: ldo3 {
-   /* VDDA_1V8_PHY */
+   /* VDDA_1V8_PHYA */
regulator-name = "ldo3";
regulator-min-microvolt = <180>;
regulator-max-microvolt = <180>;
@@ -440,6 +440,15 @@
regulator-boot-on;
};
 
+   ldo4_reg: ldo4 {
+   /* VDDA_1V8_PHYB */
+   regulator-name = "ldo4";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   regulator-always-on;
+   regulator-boot-on;
+   };
+
ldo9_reg: ldo9 {
/* VDD_RTC */
regulator-name = "ldo9";
@@ -681,7 +690,7 @@
 
  {
status = "ok";
-   vdda-supply = <_reg>;
+   vdda-supply = <_reg>;
 
pinctrl-names = "default";
pinctrl-0 = <_pins>;
-- 
1.7.9.5

--
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 v4 4/9] usb: dwc3: core: Adapt to named interrupts

[Felipe Balbi]

Hi,

On Thu, Sep 03, 2015 at 03:46:43PM +0300, Roger Quadros wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> On 02/09/15 17:34, Felipe Balbi wrote:
> > On Wed, Sep 02, 2015 at 05:24:19PM +0300, Roger Quadros wrote:
> >> From: Felipe Balbi 
> >>
> >> Add support to use interrupt names,
> >>
> >> Following are the interrupt names
> >>
> >> Peripheral Interrupt - peripheral
> >> HOST Interrupt - host
> >> OTG Interrupt - otg
> >>
> >> [Roger Q]
> >> - If any of these are missing we use the
> >> first available IRQ resource so that we don't
> >> break with older DTBs.
> > 
> > this is what original commit did:
> > 
> > commit ecd5f71cfd663bcd4efd2f29824acd8b2ba9715d
> > Author: Felipe Balbi 
> > Date:   Fri Jan 3 13:49:38 2014 -0600
> > 
> > usb: dwc3: cleanup IRQ resources
> > 
> > In order to make it easier for the driver to
> > figure out which modes of operation it has,
> > and because some dwc3 integrations have rather
> > fuzzy IRQ routing, we now require three different
> > IRQ numbers (peripheral, host, otg).
> > 
> > In order to do that and maintain backwards compatibility,
> > we still maintain support for the old IRQ resource name,
> > but if you *really* want to have proper peripheral/host/otg
> > support, you should make sure your resources are correct.
> > 
> > Signed-off-by: Felipe Balbi 
> 
> This is better since we request the resource only if needed and bail out
> if it is not present.
> 
> > 
> > diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
> > index 60580a01cdd2..1f01031873b7 100644
> > --- a/drivers/usb/dwc3/core.c
> > +++ b/drivers/usb/dwc3/core.c
> > @@ -556,10 +556,22 @@ static int dwc3_core_get_phy(struct dwc3 *dwc)
> >  static int dwc3_core_init_mode(struct dwc3 *dwc)
> >  {
> > struct device *dev = dwc->dev;
> > +   struct platform_device *pdev = to_platform_device(dev);
> > int ret;
> >  
> > switch (dwc->dr_mode) {
> > case USB_DR_MODE_PERIPHERAL:
> > +   dwc->gadget_irq = platform_get_irq_byname(pdev, 
> > "dwc3_peripheral");
> 
> Shall we just name it just "peripheral"?

sure, why not :-)

> > +   if (dwc->gadget_irq < 0) {
> > +   dwc->gadget_irq = platform_get_irq_byname(pdev, 
> > "dwc_usb3");
> 
> How will this work? Currently we don't have a name for the IRQ in the DT.

we can just add interrupt-names, right ? Or, the fallback could be what
is already done today: just fetch it by index.

> 
> > +   if (dwc->gadget_irq < 0) {
> > +   dev_err(dev, "missing IRQ\n");
> > +   return dwc->gadget_irq;
> > +   } else {
> > +   dev_warn(dev, "dwc_usb3 resource is 
> > deprecated\n");
> 
> Do we want to warn about legacy nodes?

Sure :-)

Now, do you want me to update it, or will you do it ? BTW, if you decide
to do it, we need to patch all users :-)

> > @@ -576,6 +604,28 @@ static int dwc3_core_init_mode(struct dwc3 *dwc)
> > }
> > break;
> > case USB_DR_MODE_OTG:
> > +   dwc->gadget_irq = platform_get_irq_byname(pdev, 
> > "dwc3_peripheral");
> > +   if (dwc->gadget_irq < 0) {
> > +   dwc->gadget_irq = platform_get_irq_byname(pdev, 
> > "dwc_usb3");
> > +   if (dwc->gadget_irq < 0) {
> > +   dev_err(dev, "missing IRQ\n");
> > +   return dwc->gadget_irq;
> > +   } else {
> > +   dev_warn(dev, "dwc_usb3 resource is 
> > deprecated\n");
> > +   }
> > +
> > +   dwc->xhci_irq = dwc->gadget_irq;
> > +   dwc->otg_irq = dwc->gadget_irq;
> > +   } else {
> > +   dwc->xhci_irq = platform_get_irq_byname(pdev, 
> > "dwc3_host");
> > +   if (dwc->xhci_irq < 0) {
> > +   dev_err(dev, "missing Host IRQ\n");
> > +   return dwc->xhci_irq;
> > +   }
> > +
> > +   dwc->otg_irq = platform_get_irq_byname(pdev, 
> > "dwc3_otg");
> 
> need to check if error?

right

> > +   }
> 
> Need to setup xhci_resource[1]?

isn't it done above ?

-- 
balbi


signature.asc
Description: Digital signature

Re: PowerVR SGX540 drivers for PandaBoard(OMAP4460) on vanilla kernel

[Tony Lindgren]

* Sedat Marangoz  [150902 01:24]:
> Tried hard but nothing available my hands except my experiences. I
> gave up trying custom kernel due to lots of error, and instead tried
> Ubuntu precise 3.2.0-1412-omap4 kernel which is one of the working
> kernel with SGX540 driver module. I built "omapdrm_pvr.ko" and load
> this module without error. Beside kernel module, user space libraries
> are needed for running with hardware acceleration. However these user
> space libraries also depends on X11, and  my file system does not
> contain any library related X11. Even if kernel module loaded
> successfully, it seems it is impossible to use PVR without X11
> libraries(mentioned here:
> http://pandaboard.org/pbirclogs/index.php?date=2011-12-29 )
> 
> Dependency tree:
> 
> libpvrPVR2D_DRIWSEGL.so.1.7.10.0
> -> [libpvr2d.so]
> -> [libdl.so.2]
> -> [libdrm.so.2]
> -> [libX11.so.6]
> -> [libxcb.so.1]
>  -> [libXau.so.6]
>  -> [libXdmcp.so.6]
>  -> [libc.so.6]
>  -> [ld-linux.so.3]
> -> [libdl.so.2]
> -> [libc.so.6]
> -> [ld-linux.so.3]
> -> [libXext.so.6]
>  -> [libX11.so.6]
>  -> [libc.so.6]
>  -> [ld-linux.so.3]
> 
>  -> [libXfixes.so.3]
>  -> [libX11.so.6]
>  -> [libc.so.6]
> 
> So, it seems currently there is no way to install SGX540 driver to
> Pandaboard ES (OMAP4460) which has custom kernel such as version
> 3.10.80 and small filesystem(without X11)  :(

Sorry no idea why the libX11 dependency is there.. I was mostly
thinking if there's something we should patch in the mainline
kernel to make things easier.

> In my opinion, another platform such as BeagleBone Black which has
> SGX530 is more appropriate for my needs, I have already used modules
> and libraries for hardware acceleration without x11.

OK that sounds right to me.

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 v4 1/9] usb: dwc3: add dual-role support

[Felipe Balbi]

Hi,

On Thu, Sep 03, 2015 at 03:21:48PM +0300, Roger Quadros wrote:
> >> +  dwc->fsm->id = id;
> >> +  dwc->fsm->b_sess_vld = vbus;
> >> +  usb_otg_sync_inputs(dwc->fsm);
> >> +}
> >> +
> >> +static int dwc3_drd_start_host(struct otg_fsm *fsm, int on)
> >> +{
> >> +  struct device *dev = usb_otg_fsm_to_dev(fsm);
> >> +  struct dwc3 *dwc = dev_get_drvdata(dev);
> > 
> > how about adding a usb_otg_get_drvdata(fsm) ?
> 
> You meant for otg core? That can be done.

yeah. BTW, I think otg core needs quite a few changes to become actually
useful. Currently it's just too much pointer ping-pong going back and
forth between phy, otg core, udc and hcd.

Also, I caught a ton of issues with it and suspend/resume. You might
want to fix them before adding more users to it.

It's also rather racy and that needs fixing too. On top of all that, I
think there's too much being added to UDC just to get Dual-Role, let's
see if we can improve that too.

> >> @@ -843,6 +998,16 @@ static int dwc3_probe(struct platform_device *pdev)
> >>hird_threshold = 12;
> >>  
> >>if (node) {
> >> +  if (of_property_read_bool(node, "extcon"))
> >> +  dwc->edev = extcon_get_edev_by_phandle(dev, 0);
> >> +  else if (of_property_read_bool(dev->parent->of_node, "extcon"))
> >> +  dwc->edev = extcon_get_edev_by_phandle(dev->parent, 0);
> > 
> > why do you need to check the parent ? Why isn't that done on the glue
> > layer ?
> 
> On DRA7-evm, the extcon device is defined in the glue layer node. But
> we need the device both at the glue layer and at the core layer.

why do you need extcon here ? Glue updates core via UTMI about the
states, right ? So you should get proper VBUS and ID status via OTG IRQ.
Is that not working ?

> We do get the extcon device in dwc3-omap.c
> 
> Any suggestion how to pass the extcon device from glue layer to core.c?
> Or should I add the extcon property to dwc3 USB node as well in the DT?

GPIO toggles
  dwc3-omap extcon event
update status via UTMI STATUS register
  OTG IRQ on core
Horray!

:-)

> >> +
> >> +  if (IS_ERR(dwc->edev)) {
> >> +  dev_vdbg(dev, "couldn't get extcon device\n");
> > 
> > dev_err() ??
> 
> Is it ok to print it even in EPROBE_DEFER case?

hmm, probably pointless, indeed.

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH v4 5/9] usb: dwc3: core: make dual-role work with OTG irq

[Felipe Balbi]

Hi,

On Thu, Sep 03, 2015 at 04:52:02PM +0300, Roger Quadros wrote:
> >>if (on) {
> >> -  dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_HOST);
> >> +  /* OCTL.PeriMode = 0 */
> >> +  reg = dwc3_readl(dwc->regs, DWC3_OCTL);
> >> +  reg &= ~DWC3_OCTL_PERIMODE;
> >> +  dwc3_writel(dwc->regs, DWC3_OCTL, reg);
> >> +  /* unconditionally turn on VBUS */
> >> +  reg |= DWC3_OCTL_PRTPWRCTL;
> >> +  dwc3_writel(dwc->regs, DWC3_OCTL, reg);
> >>/* start the HCD */
> >>usb_otg_start_host(fsm, true);
> >>} else {
> >>/* stop the HCD */
> >>usb_otg_start_host(fsm, false);
> >> +  /* turn off VBUS */
> >> +  reg = dwc3_readl(dwc->regs, DWC3_OCTL);
> >> +  reg &= ~DWC3_OCTL_PRTPWRCTL;
> >> +  dwc3_writel(dwc->regs, DWC3_OCTL, reg);
> >> +  /* OCTL.PeriMode = 1 */
> >> +  reg = dwc3_readl(dwc->regs, DWC3_OCTL);
> >> +  reg |= DWC3_OCTL_PERIMODE;
> >> +  dwc3_writel(dwc->regs, DWC3_OCTL, reg);
> >>}
> > 
> > it looks like you're not really following the fluxchart from SNPS
> > documentation, see Figure 11-4 on section 11.1.4.5
> 
> Did you mean that I'm ignoring all OTG bits (HNP/SRP/ADP)?

yes and no :-)  There's a rather complex flux chart which details how we
switch from host to peripheral and vice versa. We need to follow that to
the smallest details since that's what IP provider considers to be
correct. If we deviate from that we should have very strong reasons for
doing so and we also want big, fat, long comments in source code
detailing why and how we're deviating :-)

-- 
balbi


signature.asc
Description: Digital signature

RE: [PATCH 2/3][v3] drivers: usb: dwc3: Add frame length adjustment quirk

[Badola Nikhil]

> -Original Message-
> From: Felipe Balbi [mailto:ba...@ti.com]
> Sent: Thursday, September 03, 2015 9:25 PM
> To: Badola Nikhil-B46172 
> Cc: linux-ker...@vger.kernel.org; linux-...@vger.kernel.org; linux-
> o...@vger.kernel.org; ba...@ti.com; gre...@linuxfoundation.org
> Subject: Re: [PATCH 2/3][v3] drivers: usb: dwc3: Add frame length
> adjustment quirk
> 
> On Thu, Sep 03, 2015 at 11:34:04AM +0530, Nikhil Badola wrote:
> > Add adjust_frame_length_quirk for writing to fladj register which
> > adjusts (micro)frame length to value provided by
> > "snps,quirk-frame-length-adjustment" property thus avoiding USB 2.0
> > devices to time-out over a longer run
> >
> > Signed-off-by: Nikhil Badola 
> > ---
> > Changes for v3:
> > - removed unnecessary if(fladj) condition
> > - removed stray newline
> >
> >  drivers/usb/dwc3/core.c  | 34
> ++
> >  drivers/usb/dwc3/core.h  |  5 +
> >  drivers/usb/dwc3/platform_data.h |  2 ++
> >  3 files changed, 41 insertions(+)
> >
> > diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c index
> > 064123e..75a17bf 100644
> > --- a/drivers/usb/dwc3/core.c
> > +++ b/drivers/usb/dwc3/core.c
> > @@ -143,6 +143,32 @@ static int dwc3_soft_reset(struct dwc3 *dwc)
> > return 0;
> >  }
> >
> > +/*
> > + * dwc3_frame_length_adjustment - Adjusts frame length if required
> > + * @dwc3: Pointer to our controller context structure
> > + * @fladj: Value of GFLADJ_30MHZ to adjust frame length  */ static
> > +void dwc3_frame_length_adjustment(struct dwc3 *dwc, u32 fladj) {
> > +   if (dwc->revision < DWC3_REVISION_250A)
> > +   return;
> > +
> > +   if (fladj == 0)
> > +   return;
> > +
> > +   u32 reg;
> > +   u32 dft;
> 
> are you seriously telling me that GCC didn't warn you about mixing
> declaration and code ?

That's really careless of me.  Somehow this warning skipped my attention.
Apologies for this silly thing. I will resend the patch.

--
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 2/3][v3] drivers: usb: dwc3: Add frame length adjustment quirk

[Felipe Balbi]

On Thu, Sep 03, 2015 at 11:34:04AM +0530, Nikhil Badola wrote:
> Add adjust_frame_length_quirk for writing to fladj register
> which adjusts (micro)frame length to value provided by
> "snps,quirk-frame-length-adjustment" property thus avoiding
> USB 2.0 devices to time-out over a longer run
> 
> Signed-off-by: Nikhil Badola 
> ---
> Changes for v3:
>   - removed unnecessary if(fladj) condition
>   - removed stray newline
> 
>  drivers/usb/dwc3/core.c  | 34 ++
>  drivers/usb/dwc3/core.h  |  5 +
>  drivers/usb/dwc3/platform_data.h |  2 ++
>  3 files changed, 41 insertions(+)
> 
> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
> index 064123e..75a17bf 100644
> --- a/drivers/usb/dwc3/core.c
> +++ b/drivers/usb/dwc3/core.c
> @@ -143,6 +143,32 @@ static int dwc3_soft_reset(struct dwc3 *dwc)
>   return 0;
>  }
>  
> +/*
> + * dwc3_frame_length_adjustment - Adjusts frame length if required
> + * @dwc3: Pointer to our controller context structure
> + * @fladj: Value of GFLADJ_30MHZ to adjust frame length
> + */
> +static void dwc3_frame_length_adjustment(struct dwc3 *dwc, u32 fladj)
> +{
> + if (dwc->revision < DWC3_REVISION_250A)
> + return;
> +
> + if (fladj == 0)
> + return;
> +
> + u32 reg;
> + u32 dft;

are you seriously telling me that GCC didn't warn you about mixing
declaration and code ?

-- 
balbi


signature.asc
Description: Digital signature

Re: [RFC PATCH 1/4] ARM: OMAP2: DRA7: Modify optimize string comparisons in soc_is calls

[Tony Lindgren]

* Keerthy  [150902 03:23]:
> Currently everytime soc_is calls are made, firstly device tree nodes
> are parsed and then string comparisons are made to determine the
> soc version. Optimizing it to be done one time and store the result.
> Use the stored value in all the subsequent checks for soc_is calls.
...

> --- a/arch/arm/mach-omap2/id.c
> +++ b/arch/arm/mach-omap2/id.c
> @@ -44,12 +44,29 @@ static char soc_name[OMAP_SOC_MAX_NAME_LENGTH];
>  static char soc_rev[OMAP_SOC_MAX_NAME_LENGTH];
>  u32 omap_features;
>  
> +static int soc_ids[MAX_ID];

Hmm why would we need to keep an array of the non-booted
socs? We know they're all false after booting..

A bitmask is usually used here?

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

[net-next PATCH v2] drivers: net: cpsw: Add support to make gpio drive which slave connected to phy

[Mugunthan V N]

In DRA72x EVM, by default slave 1 is connected to the onboard
phy, but slave 2 pins are also muxed with video input module
which is controlled by pcf857x gpio and currently to select slave
0 to connect to phy gpio hogging is used, but with
omap2plus_defconfig the pcf857x gpio is built as module. So when
using NFS on DRA72x EVM, board doesn't boot as gpio hogging do
not set proper gpio state to connect slave 0 to phy as it is
built as module and you do not see any errors for not setting
gpio and just mentions dhcp reply not got.

To solve this issue, introducing "mode-gpio" in DT when gpio
based muxing is required. This will throw a warning when gpio
get fails and returns probe defer. When gpio-pcf857x module is
installed, cpsw probes again and ethernet becomes functional.
Verified this on DRA72x with pcf as module and ramdisk.

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

Changes from initial version:
* Updated the gpio dt naming to be more generic.

This patch is texted on DRA72x, Logs [1] and pushed a branch [2]

[1]: http://pastebin.ubuntu.com/12260767/
[2]: git://git.ti.com/~mugunthanvnm/ti-linux-kernel/linux.git 
cpsw-gpio-optional-v2

---
 Documentation/devicetree/bindings/net/cpsw.txt | 7 +++
 drivers/net/ethernet/ti/cpsw.c | 9 +
 2 files changed, 16 insertions(+)

diff --git a/Documentation/devicetree/bindings/net/cpsw.txt 
b/Documentation/devicetree/bindings/net/cpsw.txt
index 33fe846..dfe3e0b 100644
--- a/Documentation/devicetree/bindings/net/cpsw.txt
+++ b/Documentation/devicetree/bindings/net/cpsw.txt
@@ -26,6 +26,13 @@ Optional properties:
 - dual_emac: Specifies Switch to act as Dual EMAC
 - syscon   : Phandle to the system control device node, which is
  the control module device of the am33x
+- mode-gpio: Should be added if a gpio line is required to
+ be driven so that cpsw data lines can be
+ connected to the phy via selective mux. For
+ example in dra72x-evm, pcf gpio has to be
+ driven low so that cpsw slave 0 and phy
+ data lines are connected via mux.
+
 
 Slave Properties:
 Required properties:
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 8fc90f1..90ae3f9 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -2207,6 +2208,7 @@ static int cpsw_probe(struct platform_device *pdev)
void __iomem*ss_regs;
struct resource *res, *ss_res;
const struct of_device_id   *of_id;
+   struct gpio_desc*mode;
u32 slave_offset, sliver_offset, slave_size;
int ret = 0, i;
int irq;
@@ -2232,6 +2234,13 @@ static int cpsw_probe(struct platform_device *pdev)
goto clean_ndev_ret;
}
 
+   mode = devm_gpiod_get_optional(>dev, "mode", GPIOD_OUT_LOW);
+   if (IS_ERR(mode)) {
+   ret = PTR_ERR(mode);
+   dev_err(>dev, "gpio request failed, ret %d\n", ret);
+   goto clean_ndev_ret;
+   }
+
/*
 * This may be required here for child devices.
 */
-- 
2.5.1.522.g7aa67f6

--
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/3] ARM: OMAP2+: clockdomain: Add mechanism for disabling HW_AUTO

[Roger Quadros]

On 28/07/15 14:34, Roger Quadros wrote:
> Paul,
> 
> On 16/07/15 16:56, Roger Quadros wrote:
>> On 16/07/15 04:25, Paul Walmsley wrote:
>>> Hi
>>>
>>> On Tue, 23 Jun 2015, Roger Quadros wrote:
>>>
 For some hwmods (e.g. DCAN on DRA7) we need the possibility to
 disable HW_AUTO for the clockdomain while the module is active.

 To achieve this there needs to be a refcounting mechanism to
 indicate whether any module in the clockdomain has requested
 to disable HW_AUTO. We keep track of this in 'noidlecount'.

 Hwmod code must use clkdm_hwmod_prevent_hwauto() to prevent
 HW_AUTO of the clockdomain in the future clkdm_hwmod_hwauto() calls.

 It must use clkdm_hwmod_allow_hwauto() to allow HW_AUTO in
 the future clkdm_hwmod_hwauto() calls.

 Hwmod code must use clkdm_hwmod_allow_hwauto() whenever it needs
 to request HW_AUTO of any clockdomain. (Typically after it has
 enabled the module).
>>>
>>> How about just modifying clkdm_{allow,deny}_idle*() to do the 
>>> idle-block-counting?  The default state would be to allow idle, assuming 
>>> that the clockdomain flags support that state, and then clkdm_deny_idle*() 
>>> would increment the idle-blocking count, clkdm_allow_idle*() would 
>>> decrement it.  Then on the 0 -> 1 or 1 -> 0 transitions, the hardware 
>>> would be reprogrammed appropiately.
>>
>> That is not possible with current hwmod code as clkdm_allow_idle() and 
>> clkdm_deny_idle()
>> are not symmetrically placed.
>>
>> The usual flow is
>>  clkdm_enable_hwmod();
>>  if (hwsup)
>>  clkdm_allow_idle();
>>
>> This is mainly because it is redundant to disable auto idle before enableing
>> (SW_WKUP) the clockdomain.
>>
>> If we take your proposal above then we have to modify all users like so.
>>
>>  if (hwsup)
>>  clkdm_deny_idle();
>>  clkdm_enable_hwmod();
>>  if (hwsup)
>>  clkdm_allow_idle();
>>
>> Is this really what we want?
> 
> Any comments on this?

Paul. I'm waiting on your input to rework this series if needed.
Early input would be much appreciated. Thanks.

cheers,
-roger

> 
>>
>>>
>>> Anyway, seems like that would avoid races with any 
>>> clkdm_{allow,deny}_idle*() users.  
>>>
>>> A few other comments below:
>>>
>>>

 Signed-off-by: Roger Quadros 
 ---
  arch/arm/mach-omap2/clockdomain.c | 71 
 +++
  arch/arm/mach-omap2/clockdomain.h |  5 +++
  2 files changed, 76 insertions(+)

 diff --git a/arch/arm/mach-omap2/clockdomain.c 
 b/arch/arm/mach-omap2/clockdomain.c
 index 2da3b5e..a7190d2 100644
 --- a/arch/arm/mach-omap2/clockdomain.c
 +++ b/arch/arm/mach-omap2/clockdomain.c
 @@ -1212,6 +1212,77 @@ ccd_exit:
return 0;
  }
  
 +/*
 + * prevent future hwauto for this clkdm. If clkdm->usecount becomes 
 hwauto isn't prevented.
 + * It will only prevnt future hwauto but not bring it out of hwauto.
 + */
>>>
>>> If you modify clkdm_{allow,deny}_idle*(), this shouldn't be a major issue 
>>> - but all of the function comments should be fixed so that they are 
>>> understandable and follow kernel-doc-nano specs.
>>
>> OK for updating the comments.
>>
>>
>> cheers,
>> -roger
>>
>>>
 +int clkdm_hwmod_prevent_hwauto(struct clockdomain *clkdm, struct 
 omap_hwmod *oh)
 +{
 +  /* The clkdm attribute does not exist yet prior OMAP4 */
 +  if (cpu_is_omap24xx() || cpu_is_omap34xx())
 +  return 0;
 +
 +  if (!clkdm || !oh || !arch_clkdm || !arch_clkdm->clkdm_clk_disable)
 +  return -EINVAL;
 +
 +
 +  pwrdm_lock(clkdm->pwrdm.ptr);
 +  clkdm->noidlecount++;
 +  pwrdm_unlock(clkdm->pwrdm.ptr);
 +
 +  return 0;
 +}
 +
 +/*
 + * allow future hwauto for this clkdm
 + * It won't put clkdm into hwauto. use clkdm_hwmod_hwauto() for that.
 + */
 +int clkdm_hwmod_allow_hwauto(struct clockdomain *clkdm, struct omap_hwmod 
 *oh)
 +{
 +  /* The clkdm attribute does not exist yet prior OMAP4 */
 +  if (cpu_is_omap24xx() || cpu_is_omap34xx())
 +  return 0;
 +
 +  if (!clkdm || !oh || !arch_clkdm || !arch_clkdm->clkdm_clk_disable)
 +  return -EINVAL;
 +
 +
 +  pwrdm_lock(clkdm->pwrdm.ptr);
 +
 +  if (clkdm->noidlecount == 0) {
 +  pwrdm_unlock(clkdm->pwrdm.ptr);
 +  WARN_ON(1); /* underflow */
 +  return -ERANGE;
 +  }
 +
 +  clkdm->noidlecount--;
 +  pwrdm_unlock(clkdm->pwrdm.ptr);
 +
 +  return 0;
 +}
 +
 +/*
 + * put clkdm in hwauto if we can. checks noidlecount to see if we can.
 + */
 +int clkdm_hwmod_hwauto(struct clockdomain *clkdm, struct omap_hwmod *oh)
 +{
 +  /* The clkdm attribute does not exist yet prior OMAP4 */
 +  if (cpu_is_omap24xx() || cpu_is_omap34xx())
 +  

Re: [PATCH] mtd: nand: omap2: Rename shippable module to omap2_nand

[Roger Quadros]

On 03/09/15 00:06, Brian Norris wrote:
> On Fri, Aug 21, 2015 at 01:45:35PM +0300, Roger Quadros wrote:
>> As both omap2 onenand and omap2 nand driver modules are
>> named the same i.e. "omap2.ko", only one of them gets shipped
>> during MODPOST if both are configured as loadable modules.
>>
>> To avoid this ambiguity let's ship the omap2 nand
>> driver as "omap2_nand.ko"
>>
>> Reported by Pierre Neyron via github
>> https://github.com/beagleboard/linux/issues/40
>>
>> Cc: Robert Nelson 
>> Signed-off-by: Roger Quadros 
>> ---
>>  drivers/mtd/nand/Makefile | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
>> index 1f897ec..075a027 100644
>> --- a/drivers/mtd/nand/Makefile
>> +++ b/drivers/mtd/nand/Makefile
>> @@ -26,7 +26,8 @@ obj-$(CONFIG_MTD_NAND_CS553X)  += cs553x_nand.o
>>  obj-$(CONFIG_MTD_NAND_NDFC) += ndfc.o
>>  obj-$(CONFIG_MTD_NAND_ATMEL)+= atmel_nand.o
>>  obj-$(CONFIG_MTD_NAND_GPIO) += gpio.o
>> -obj-$(CONFIG_MTD_NAND_OMAP2)+= omap2.o
>> +omap2_nand-objs := omap2.o
>> +obj-$(CONFIG_MTD_NAND_OMAP2)+= omap2_nand.o
> 
> Pushed to l2-mtd.git. I suppose this one should go out for 4.3, as
> there's little downside to it, and it's kind of a bugfix.

That is perfectly fine. Thanks.

cheers,
-roger

> 
>>  obj-$(CONFIG_MTD_NAND_OMAP_BCH_BUILD)   += omap_elm.o
>>  obj-$(CONFIG_MTD_NAND_CM_X270)  += cmx270_nand.o
>>  obj-$(CONFIG_MTD_NAND_PXA3xx)   += pxa3xx_nand.o
>> -- 
>> 2.1.4
>>
--
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 v2 1/6] regulator: pbias: program pbias register offset in pbias driver

[Kishon Vijay Abraham I]

Add separate compatible strings for every platform and populate the
pbias register offset in the driver data.
This helps avoid depending on the dt for pbias register offset.

Also update the dt binding documentation for the new compatible
strings.

Suggested-by: Tony Lindgren 
Signed-off-by: Kishon Vijay Abraham I 
Acked-by: Tony Lindgren 
---
 .../bindings/regulator/pbias-regulator.txt |7 ++-
 drivers/regulator/pbias-regulator.c|   56 +---
 2 files changed, 56 insertions(+), 7 deletions(-)

diff --git a/Documentation/devicetree/bindings/regulator/pbias-regulator.txt 
b/Documentation/devicetree/bindings/regulator/pbias-regulator.txt
index 32aa26f..acbcb45 100644
--- a/Documentation/devicetree/bindings/regulator/pbias-regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/pbias-regulator.txt
@@ -2,7 +2,12 @@ PBIAS internal regulator for SD card dual voltage i/o pads on 
OMAP SoCs.
 
 Required properties:
 - compatible:
-  - "ti,pbias-omap" for OMAP2, OMAP3, OMAP4, OMAP5, DRA7.
+  - should be "ti,pbias-dra7" for DRA7
+  - should be "ti,pbias-omap2" for OMAP2
+  - should be "ti,pbias-omap3" for OMAP3
+  - should be "ti,pbias-omap4" for OMAP4
+  - should be "ti,pbias-omap5" for OMAP5
+  - "ti,pbias-omap" is deprecated
 - reg: pbias register offset from syscon base and size of pbias register.
 - syscon : phandle of the system control module
 - regulator-name : should be
diff --git a/drivers/regulator/pbias-regulator.c 
b/drivers/regulator/pbias-regulator.c
index bd2b75c..c21cedb 100644
--- a/drivers/regulator/pbias-regulator.c
+++ b/drivers/regulator/pbias-regulator.c
@@ -44,6 +44,10 @@ struct pbias_regulator_data {
int voltage;
 };
 
+struct pbias_of_data {
+   unsigned int offset;
+};
+
 static const unsigned int pbias_volt_table[] = {
180,
300
@@ -98,8 +102,35 @@ static struct of_regulator_match pbias_matches[] = {
 };
 #define PBIAS_NUM_REGS ARRAY_SIZE(pbias_matches)
 
+/* Offset from SCM general area (and syscon) base */
+
+static const struct pbias_of_data pbias_of_data_omap2 = {
+   .offset = 0x230,
+};
+
+static const struct pbias_of_data pbias_of_data_omap3 = {
+   .offset = 0x2b0,
+};
+
+static const struct pbias_of_data pbias_of_data_omap4 = {
+   .offset = 0x60,
+};
+
+static const struct pbias_of_data pbias_of_data_omap5 = {
+   .offset = 0x60,
+};
+
+static const struct pbias_of_data pbias_of_data_dra7 = {
+   .offset = 0xe00,
+};
+
 static const struct of_device_id pbias_of_match[] = {
{ .compatible = "ti,pbias-omap", },
+   { .compatible = "ti,pbias-omap2", .data = _of_data_omap2, },
+   { .compatible = "ti,pbias-omap3", .data = _of_data_omap3, },
+   { .compatible = "ti,pbias-omap4", .data = _of_data_omap4, },
+   { .compatible = "ti,pbias-omap5", .data = _of_data_omap5, },
+   { .compatible = "ti,pbias-dra7", .data = _of_data_dra7, },
{},
 };
 MODULE_DEVICE_TABLE(of, pbias_of_match);
@@ -114,6 +145,9 @@ static int pbias_regulator_probe(struct platform_device 
*pdev)
const struct pbias_reg_info *info;
int ret = 0;
int count, idx, data_idx = 0;
+   const struct of_device_id *match;
+   const struct pbias_of_data *data;
+   unsigned int offset;
 
count = of_regulator_match(>dev, np, pbias_matches,
PBIAS_NUM_REGS);
@@ -129,6 +163,20 @@ static int pbias_regulator_probe(struct platform_device 
*pdev)
if (IS_ERR(syscon))
return PTR_ERR(syscon);
 
+   match = of_match_device(of_match_ptr(pbias_of_match), >dev);
+   if (match && match->data) {
+   data = match->data;
+   offset = data->offset;
+   } else {
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   if (!res)
+   return -EINVAL;
+
+   offset = res->start;
+   dev_WARN(>dev,
+"using legacy dt data for pbias offset\n");
+   }
+
cfg.regmap = syscon;
cfg.dev = >dev;
 
@@ -141,10 +189,6 @@ static int pbias_regulator_probe(struct platform_device 
*pdev)
if (!info)
return -ENODEV;
 
-   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   if (!res)
-   return -EINVAL;
-
drvdata[data_idx].syscon = syscon;
drvdata[data_idx].info = info;
drvdata[data_idx].desc.name = info->name;
@@ -154,9 +198,9 @@ static int pbias_regulator_probe(struct platform_device 
*pdev)
drvdata[data_idx].desc.volt_table = pbias_volt_table;
drvdata[data_idx].desc.n_voltages = 2;
drvdata[data_idx].desc.enable_time = info->enable_time;
-   drvdata[data_idx].desc.vsel_reg = res->start;
+   

[PATCH v2 0/6] regulator: Fix pbias regulator enable

[Kishon Vijay Abraham I]

vsel_reg and enable_reg of the pbias regulator descriptor should actually
have the offset from syscon.

However after
"ARM: dts: : add minimal l4 bus layout with control module
support"
vsel_reg and enable_reg started to have the absolute address because
of address translation that happens due to pbias node made as the
child node of syscon. This breaks the pbias regulator enable.

This series adds the 'offset' to be populated in vsel_reg and enable_reg
in the pbias driver itself.

Changes from v1:
*) Fixed Tony's review comments on adding a 'comment' for adding offset in
   the driver and adding a warning for using platform_get_resource.
*) Added Tony's Acked-by.

Tested these patches against mmc -next in omap4 panda, omap3 beagle xm,
dra72 and omap5 uevm

Kishon Vijay Abraham I (6):
  regulator: pbias: program pbias register offset in pbias driver
  ARM: dts: dra7: use "ti,pbias-dra7" compatible string for pbias
  ARM: dts: omap243x: use "ti,pbias-omap2" compatible string for pbias
  ARM: dts: omap3: use "ti,pbias-omap3" compatible string for pbias
  ARM: dts: omap4: use "ti,pbias-omap4" compatible string for pbias
  ARM: dts: omap5: use "ti,pbias-omap5" compatible string for pbias

 .../bindings/regulator/pbias-regulator.txt |7 ++-
 arch/arm/boot/dts/dra7.dtsi|2 +-
 arch/arm/boot/dts/omap2430.dtsi|2 +-
 arch/arm/boot/dts/omap3.dtsi   |2 +-
 arch/arm/boot/dts/omap4.dtsi   |2 +-
 arch/arm/boot/dts/omap5.dtsi   |2 +-
 drivers/regulator/pbias-regulator.c|   56 +---
 7 files changed, 61 insertions(+), 12 deletions(-)

-- 
1.7.9.5

--
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 v2 2/6] ARM: dts: dra7: use "ti,pbias-dra7" compatible string for pbias

[Kishon Vijay Abraham I]

Use "ti,pbias-dra7" compatible string which is specifically added
for DRA7 SoCs.

Signed-off-by: Kishon Vijay Abraham I 
Acked-by: Tony Lindgren 
---
 arch/arm/boot/dts/dra7.dtsi |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 1e29ccf..d6bc6db 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -122,7 +122,7 @@
#size-cells = <1>;
 
pbias_regulator: pbias_regulator {
-   compatible = "ti,pbias-omap";
+   compatible = "ti,pbias-dra7", 
"ti,pbias-omap";
reg = <0xe00 0x4>;
syscon = <_conf>;
pbias_mmc_reg: pbias_mmc_omap5 {
-- 
1.7.9.5

--
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 v2 4/6] ARM: dts: omap3: use "ti,pbias-omap3" compatible string for pbias

[Kishon Vijay Abraham I]

Use "ti,pbias-omap3" compatible string which is specifically added
for OMAP3.

Signed-off-by: Kishon Vijay Abraham I 
Acked-by: Tony Lindgren 
---
 arch/arm/boot/dts/omap3.dtsi |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 69a40cf..9af9ae1 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -203,7 +203,7 @@
};
 
pbias_regulator: pbias_regulator {
-   compatible = "ti,pbias-omap";
+   compatible = "ti,pbias-omap3", "ti,pbias-omap";
reg = <0x2b0 0x4>;
syscon = <_conf>;
pbias_mmc_reg: pbias_mmc_omap2430 {
-- 
1.7.9.5

--
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 v2 3/6] ARM: dts: omap243x: use "ti,pbias-omap2" compatible string for pbias

[Kishon Vijay Abraham I]

Use "ti,pbias-omap2" compatible string which is specifically added
for OMAP2.

Signed-off-by: Kishon Vijay Abraham I 
Acked-by: Tony Lindgren 
---
 arch/arm/boot/dts/omap2430.dtsi |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/omap2430.dtsi b/arch/arm/boot/dts/omap2430.dtsi
index 2390f38..3961a6f 100644
--- a/arch/arm/boot/dts/omap2430.dtsi
+++ b/arch/arm/boot/dts/omap2430.dtsi
@@ -63,7 +63,7 @@
};
 
pbias_regulator: pbias_regulator {
-   compatible = "ti,pbias-omap";
+   compatible = "ti,pbias-omap2", 
"ti,pbias-omap";
reg = <0x230 0x4>;
syscon = <_conf>;
pbias_mmc_reg: 
pbias_mmc_omap2430 {
-- 
1.7.9.5

--
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 0/6] regulator: Fix pbias regulator enable

[Kishon Vijay Abraham I]

Hi,

On Thursday 03 September 2015 01:09 PM, Ulf Hansson wrote:
> +Olof
> 
> On 3 September 2015 at 08:50, Kishon Vijay Abraham I  wrote:
>> vsel_reg and enable_reg of the pbias regulator descriptor should actually
>> have the offset from syscon.
>>
>> However after
>> "ARM: dts: : add minimal l4 bus layout with control module
>> support"
>> vsel_reg and enable_reg started to have the absolute address because
>> of address translation that happens due to pbias node made as the
>> child node of syscon. This breaks the pbias regulator enable.
>>
>> This series adds the 'offset' to be populated in vsel_reg and enable_reg
>> in the pbias driver itself.
>>
>> Changes from v1:
>> *) Fixed Tony's review comments on adding a 'comment' for adding offset in
>>the driver and adding a warning for using platform_get_resource.
>> *) Added Tony's Acked-by.
>>
>> Tested these patches against mmc -next in omap4 panda, omap3 beagle xm,
>> dra72 and omap5 uevm
>>
>> Kishon Vijay Abraham I (6):
>>   regulator: pbias: program pbias register offset in pbias driver
>>   ARM: dts: dra7: use "ti,pbias-dra7" compatible string for pbias
>>   ARM: dts: omap243x: use "ti,pbias-omap2" compatible string for pbias
>>   ARM: dts: omap3: use "ti,pbias-omap3" compatible string for pbias
>>   ARM: dts: omap4: use "ti,pbias-omap4" compatible string for pbias
>>   ARM: dts: omap5: use "ti,pbias-omap5" compatible string for pbias
>>
>>  .../bindings/regulator/pbias-regulator.txt |7 ++-
>>  arch/arm/boot/dts/dra7.dtsi|2 +-
>>  arch/arm/boot/dts/omap2430.dtsi|2 +-
>>  arch/arm/boot/dts/omap3.dtsi   |2 +-
>>  arch/arm/boot/dts/omap4.dtsi   |2 +-
>>  arch/arm/boot/dts/omap5.dtsi   |2 +-
>>  drivers/regulator/pbias-regulator.c|   56 
>> +---
>>  7 files changed, 61 insertions(+), 12 deletions(-)
>>
>> --
>> 1.7.9.5
>>
> 
> I have recently queued another patchset [1] for the mmc omap driver
> for 4.3 through my mmc tree for which Olof Johansson reported a
> regression [2] for Panda ES with multi_v7_defconfig.

I generally perform my tests with omap2plus_defconfig and without this
series MMC doesn't work with omap2plus_defconfig.
> 
> Kishon, could you please clarify if $subject patchset solves that
> regression reported by Olof? Or perhaps Olof can run a test?

Just checked multi_v7_defconfig and this series is definitely required
to get MMC working. But we also have to enable 'CONFIG_REGULATOR_PBIAS'
which is not enabled by default in multi_v7_defconfig.

So we should have a patch to enable 'CONFIG_REGULATOR_PBIAS' in
multi_v7_defconfig to completely solve the problem reported by Olof.
I'll prepare a patch for multi_v7_defconfig and post it asap.

Thanks
Kishon

> 
> Finally, perhaps it's better if we queue this through my mmc tree
> since we would then be able to avoid the regression - if I put
> $subject patchset before [1], right? Then I need an ack from Mark for
> the regulator patch.
> Please tell me if you guys prefer another way.
> 
> Kind regards
> Uffe
> 
> [1]
> http://permalink.gmane.org/gmane.linux.kernel/2027789
> 
> [2]
> http://www.spinics.net/lists/linux-mmc/msg33146.html
> 
--
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 v2 6/6] ARM: dts: omap5: use "ti,pbias-omap5" compatible string for pbias

[Kishon Vijay Abraham I]

Use "ti,pbias-omap5" compatible string which is specifically added
for OMAP5.

Signed-off-by: Kishon Vijay Abraham I 
Acked-by: Tony Lindgren 
---
 arch/arm/boot/dts/omap5.dtsi |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index b1a1263..76ef595 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -187,7 +187,7 @@
#size-cells = <1>;
 
pbias_regulator: pbias_regulator {
-   compatible = "ti,pbias-omap";
+   compatible = "ti,pbias-omap5", 
"ti,pbias-omap";
reg = <0x60 0x4>;
syscon = 
<_padconf_global>;
pbias_mmc_reg: pbias_mmc_omap5 {
-- 
1.7.9.5

--
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 v2 5/6] ARM: dts: omap4: use "ti,pbias-omap4" compatible string for pbias

[Kishon Vijay Abraham I]

Use "ti,pbias-omap4" compatible string which is specifically added
for OMAP4.

Signed-off-by: Kishon Vijay Abraham I 
Acked-by: Tony Lindgren 
---
 arch/arm/boot/dts/omap4.dtsi |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index abc4473..5aad7f3 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -198,7 +198,7 @@
#size-cells = <1>;
 
pbias_regulator: pbias_regulator {
-   compatible = "ti,pbias-omap";
+   compatible = "ti,pbias-omap4", 
"ti,pbias-omap";
reg = <0x60 0x4>;
syscon = 
<_padconf_global>;
pbias_mmc_reg: pbias_mmc_omap4 {
-- 
1.7.9.5

--
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/2] ARM: dts: am57xx-beagle-x15: use palmas-usb for USB2

[Roger Quadros]

Chanwoo,

On 06/08/15 02:36, Chanwoo Choi wrote:
> On 08/05/2015 07:37 PM, Tony Lindgren wrote:
>> * Roger Quadros  [150727 06:13]:
>>> The VBUS line of USB2 is connected to VBUS detect logic on
>>> the PMIC. Use the palmas-usb driver to report VBUS events
>>> to the USB driver.
>>>
>>> As the palmas-usb driver supports GPIO based ID reporting
>>> provide the GPIO for ID pin as well.
>>>
>>> Signed-off-by: Roger Quadros 
>>
>> This should not cause merge conflicts with what I have queeud
>> for v4.3, so Chanwoo please feel free to apply with the rest
>> of the extcon series:
>>
>> Acked-by: Tony Lindgren 
>>
> 
> I reviewd this patchset related to extcon and give the acked-by message.
> but patch1 must need the acked-by message from MFD maintainer.
> 
> If patch1 receive the acked-by message from MFD maintainer,
> I'll apply it for v4.3.
> 
> Roger,
> I think that you better to recevie the acked-by message before v4.2-rc6 
> release.
> I have the plan about pull request of extcon for v4.3 after v4.2-rc6 releas.

Seems like you picked patch 1 but not this one. As Tony has already Acked it
can you please include patch 2 as well in your tree for -next? Thanks.

cheers,
-roger
--
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 0/6] regulator: Fix pbias regulator enable

[Ulf Hansson]

+Olof

On 3 September 2015 at 08:50, Kishon Vijay Abraham I  wrote:
> vsel_reg and enable_reg of the pbias regulator descriptor should actually
> have the offset from syscon.
>
> However after
> "ARM: dts: : add minimal l4 bus layout with control module
> support"
> vsel_reg and enable_reg started to have the absolute address because
> of address translation that happens due to pbias node made as the
> child node of syscon. This breaks the pbias regulator enable.
>
> This series adds the 'offset' to be populated in vsel_reg and enable_reg
> in the pbias driver itself.
>
> Changes from v1:
> *) Fixed Tony's review comments on adding a 'comment' for adding offset in
>the driver and adding a warning for using platform_get_resource.
> *) Added Tony's Acked-by.
>
> Tested these patches against mmc -next in omap4 panda, omap3 beagle xm,
> dra72 and omap5 uevm
>
> Kishon Vijay Abraham I (6):
>   regulator: pbias: program pbias register offset in pbias driver
>   ARM: dts: dra7: use "ti,pbias-dra7" compatible string for pbias
>   ARM: dts: omap243x: use "ti,pbias-omap2" compatible string for pbias
>   ARM: dts: omap3: use "ti,pbias-omap3" compatible string for pbias
>   ARM: dts: omap4: use "ti,pbias-omap4" compatible string for pbias
>   ARM: dts: omap5: use "ti,pbias-omap5" compatible string for pbias
>
>  .../bindings/regulator/pbias-regulator.txt |7 ++-
>  arch/arm/boot/dts/dra7.dtsi|2 +-
>  arch/arm/boot/dts/omap2430.dtsi|2 +-
>  arch/arm/boot/dts/omap3.dtsi   |2 +-
>  arch/arm/boot/dts/omap4.dtsi   |2 +-
>  arch/arm/boot/dts/omap5.dtsi   |2 +-
>  drivers/regulator/pbias-regulator.c|   56 
> +---
>  7 files changed, 61 insertions(+), 12 deletions(-)
>
> --
> 1.7.9.5
>

I have recently queued another patchset [1] for the mmc omap driver
for 4.3 through my mmc tree for which Olof Johansson reported a
regression [2] for Panda ES with multi_v7_defconfig.

Kishon, could you please clarify if $subject patchset solves that
regression reported by Olof? Or perhaps Olof can run a test?

Finally, perhaps it's better if we queue this through my mmc tree
since we would then be able to avoid the regression - if I put
$subject patchset before [1], right? Then I need an ack from Mark for
the regulator patch.
Please tell me if you guys prefer another way.

Kind regards
Uffe

[1]
http://permalink.gmane.org/gmane.linux.kernel/2027789

[2]
http://www.spinics.net/lists/linux-mmc/msg33146.html
--
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] ARM: multi_v7_defconfig: Enable PBIAS regulator

[Kishon Vijay Abraham I]

PBIAS regulator is required for MMC module in OMAP2, OMAP3, OMAP4,
OMAP5 and DRA7 SoCs. Enable it here.

Signed-off-by: Kishon Vijay Abraham I 
---
 arch/arm/configs/multi_v7_defconfig |1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/multi_v7_defconfig 
b/arch/arm/configs/multi_v7_defconfig
index 5fd8df6..f497c96 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -403,6 +403,7 @@ CONFIG_REGULATOR_MAX8973=y
 CONFIG_REGULATOR_MAX77686=y
 CONFIG_REGULATOR_MAX77693=m
 CONFIG_REGULATOR_PALMAS=y
+CONFIG_REGULATOR_PBIAS=y
 CONFIG_REGULATOR_S2MPS11=y
 CONFIG_REGULATOR_S5M8767=y
 CONFIG_REGULATOR_TPS51632=y
-- 
1.7.9.5

--
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: Myir AM437x Rico board support for Linux 4.1 kernel

[Roger Quadros]

+Tony, Tomi, linux-omap

Hi Pavel,

On 25/08/15 16:39, Pavel Pisa wrote:
> Hello everybody,
> 
> I have been asked to help with Linux on Myir Rico board.
> I have decided to try actual stable kernel from Ti tree
> 
>   git://git.ti.com/ti-linux-kernel/ti-linux-kernel.git
>  branch ti-linux-4.1.y
> 
> instead of delivered dated 3.12.10 one to solve some issues
> and have chance to port possible enhancements to mainline.
> 
> I have successfully prepared environment which loads kernel
> over TFTP and boot actual Debian Jessie armhf from NFS export.
> 
> Because I have not found up to date device tree for this
> board I have analyzed delivered sources against best matching
> Ti kernel and then prepared DTS which works on the board
> and I want to know if somebody works on this support, can help
> to finish/better tune parameters and if there is chance
> that configs are included into mainline or some other public
> repository. Because I do not know who is working on this support
> and who is right maintainer I send only pointers to my files.

Tony Lindgren is the OMAP platform maintainer and you must
include linux-omap mailing list in in the discussion.

> 
> http://cmp.felk.cvut.cz/~pisa/arm/myir-rico/am437x-myir-ricoboard.dts
>  based on Ti am437x-gp-evm.dts
> 
> http://cmp.felk.cvut.cz/~pisa/arm/myir-rico/am437x-myir-ricoboard-hdmi.dts
>  based on Ti am437x-gp-evm-hdmi.dts
> 
> http://cmp.felk.cvut.cz/~pisa/arm/myir-rico/am437x-myir-ricoboard_defconfig
> 
> If there is interrest for discussion and inclusion, I send usual
> inlined GIT patches series.

Please send patches for the new board so that we can review.

> 
> As for DTS, I expect that the regulators section does not match correctly
> Rico board HW but it works for what client company needs
>   evm_v3_3d: fixedregulator-v3_3d
>   vtt_fixed: fixedregulator-vtt
> 
> Ethernet, serials, cameras, local MTD, SDcard and most of other devices works.
> SPI Flash does not work. I have not invested time to that.
> 
> The client needs to connect special camera (infrared) to the VPFE so I have
> spent some time on AM437x VPFE support enhancement.
> 
> I have added V4L2_PIX_FMT_Y10 pixel format and some minimal/stub 
> implementation of vpfe_enum_frameintervals, vpfe_g_parm, vvpfe_s_parm, 
> pfe_s_parm and I would be happy if my work can help to somebody other
> as well. But work has been driven strict deadline to provide working
> solution in one week so if there is interrest then most has to be
> rewritten/clean up.
> 
> Generally, I am quite pleased by Ti's Linux tree state and support.
> That week has been my first time with AM chips we used other archs
> (powerpc and multiple i.MXs for most of our other projects till now).
> 
> Probably off topic for these lists but what are suggested options
> for graphic configuration when Qt4/E or Qt5 is run on framebuffer.
> Is it better to use CONFIG_DRM_OMAP or CONFIG_FB_OMAP2 ?
> Is SGX driver available for 4.1 Linux kernel (reply offlist, please,
> if proprietary only)? Are there other possibilities how to use
> OMAP AM437xx hardware to accelerate video color and formats
> transformations? Can be VPFE planes used somehow to embed
> video in Qt application? I, personally, prefer strongly
> opensource only options but target company has probably minimal
> requirements in this area.

Tomi might be able to answer video related questions.

cheers,
-roger
--
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/4] ARM: dts: omap24xx: fix address translation for pbias

[Kishon Vijay Abraham I]

commit <72b10ac00eb1> ("ARM: dts: omap24xx: add minimal l4 bus
layout with control module support") moved pbias_regulator dt node
from being a child node of ocp to be the child node of
scm_conf. Since scm_conf doesn't have the 'ranges' property,
address translation fails while trying to convert the address
to resource. Fix it here.

Fixes: 72b10ac00eb1 ("ARM: dts: omap24xx: add minimal l4 bus
layout with control module support")

Signed-off-by: Kishon Vijay Abraham I 
---
 arch/arm/boot/dts/omap2430.dtsi |1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/omap2430.dtsi b/arch/arm/boot/dts/omap2430.dtsi
index 3961a6f..798dda0 100644
--- a/arch/arm/boot/dts/omap2430.dtsi
+++ b/arch/arm/boot/dts/omap2430.dtsi
@@ -56,6 +56,7 @@
reg = <0x270 0x240>;
#address-cells = <1>;
#size-cells = <1>;
+   ranges = <0 0x270 0x240>;
 
scm_clocks: clocks {
#address-cells = <1>;
-- 
1.7.9.5

--
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 4/4] ARM: dts: dra7: fix address translation for pbias

[Kishon Vijay Abraham I]

commit  ("ARM: dts: dra7: add minimal l4 bus
layout with control module support") moved pbias_regulator dt node
from being a child node of ocp to be the child node of
scm_conf. Since scm_conf doesn't have the 'ranges'
property, address translation fails while trying to convert the
address to resource. Fix it here.

Fixes: d919501feffa ("ARM: dts: dra7: add minimal l4 bus
layout with control module support")

Signed-off-by: Kishon Vijay Abraham I 
---
 arch/arm/boot/dts/dra7.dtsi |1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index d6bc6db..5896896 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -120,6 +120,7 @@
reg = <0x0 0x1400>;
#address-cells = <1>;
#size-cells = <1>;
+   ranges = <0 0x0 0x1400>;
 
pbias_regulator: pbias_regulator {
compatible = "ti,pbias-dra7", 
"ti,pbias-omap";
-- 
1.7.9.5

--
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/4] omap: Fix broken address translation for pbias

[Kishon Vijay Abraham I]

pbias device stopped having memory resource after
"ARM: dts: : add minimal l4 bus layout with control module
support" got merged. This results in platform_get_resource returning
-EINVAL in pbias driver. This is because address translation fails
while trying to convert the address to resource which happens
during the device creation process during boot up.

Even though after [1], reg property in pbias dt node is un-used,
it might be an issue if we plan to use it at a later point of time.

Patch series is created on top of [1].

[1] -> https://lkml.org/lkml/2015/9/3/51

Verified the address in omap4 panda, omap5 uevm and dra72 boards.

Kishon Vijay Abraham I (4):
  ARM: dts: omap24xx: fix address translation for pbias
  ARM: dts: omap4: fix address translation for pbias
  ARM: dts: omap5: fix address translation for pbias
  ARM: dts: dra7: fix address translation for pbias

 arch/arm/boot/dts/dra7.dtsi |1 +
 arch/arm/boot/dts/omap2430.dtsi |1 +
 arch/arm/boot/dts/omap4.dtsi|1 +
 arch/arm/boot/dts/omap5.dtsi|1 +
 4 files changed, 4 insertions(+)

-- 
1.7.9.5

--
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] ARM: dts: am335x-phycore-som: Fix mpu voltage

[Teresa Remmet]

Fix the mpu voltage as it is set to low for the silicon
revision 2.1.

Signed-off-by: Teresa Remmet 
---
 arch/arm/boot/dts/am335x-phycore-som.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/am335x-phycore-som.dtsi 
b/arch/arm/boot/dts/am335x-phycore-som.dtsi
index 4d28fc3..5dd084f 100644
--- a/arch/arm/boot/dts/am335x-phycore-som.dtsi
+++ b/arch/arm/boot/dts/am335x-phycore-som.dtsi
@@ -252,10 +252,10 @@
};
 
vdd1_reg: regulator@2 {
-   /* VDD_MPU voltage limits 0.95V - 1.26V with +/-4% 
tolerance */
+   /* VDD_MPU voltage limits 0.95V - 1.325V with +/-4% 
tolerance */
regulator-name = "vdd_mpu";
regulator-min-microvolt = <912500>;
-   regulator-max-microvolt = <1312500>;
+   regulator-max-microvolt = <1378000>;
regulator-boot-on;
regulator-always-on;
};
-- 
1.9.1

--
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 v4 1/9] usb: dwc3: add dual-role support

[Roger Quadros]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 02/09/15 17:31, Felipe Balbi wrote:
> Hi,
> 
> On Wed, Sep 02, 2015 at 05:24:16PM +0300, Roger Quadros wrote:
>> Register with the USB OTG core. Since we don't support
>> OTG yet we just work as a dual-role device even
>> if device tree says "otg".
>>
>> Use extcon framework to get VBUS/ID cable events and
>> kick the OTG state machine.
>>
>> Signed-off-by: Roger Quadros 
>> ---
>>  drivers/usb/dwc3/core.c  | 174 
>> ++-
>>  drivers/usb/dwc3/core.h  |   7 ++
>>  drivers/usb/dwc3/platform_data.h |   1 +
>>  3 files changed, 181 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
>> index 064123e..2e36a9b 100644
>> --- a/drivers/usb/dwc3/core.c
>> +++ b/drivers/usb/dwc3/core.c
>> @@ -704,6 +704,152 @@ static int dwc3_core_get_phy(struct dwc3 *dwc)
>>  return 0;
>>  }
>>  
>> +/* - Dual-Role management 
>> --- */
>> +
>> +static void dwc3_drd_fsm_sync(struct dwc3 *dwc)
>> +{
>> +int id, vbus;
>> +
>> +/* get ID */
>> +id = extcon_get_cable_state(dwc->edev, "USB-HOST");
>> +/* Host means ID == 0 */
>> +id = !id;
>> +
>> +/* get VBUS */
>> +vbus = extcon_get_cable_state(dwc->edev, "USB");
>> +dev_dbg(dwc->dev, "id %d vbus %d\n", id, vbus);
> 
> tracepoint please. We don't want this driver to use dev_(v)?db anymore.
> Ditto to all others.

OK.

> 
>> +
>> +dwc->fsm->id = id;
>> +dwc->fsm->b_sess_vld = vbus;
>> +usb_otg_sync_inputs(dwc->fsm);
>> +}
>> +
>> +static int dwc3_drd_start_host(struct otg_fsm *fsm, int on)
>> +{
>> +struct device *dev = usb_otg_fsm_to_dev(fsm);
>> +struct dwc3 *dwc = dev_get_drvdata(dev);
> 
> how about adding a usb_otg_get_drvdata(fsm) ?

You meant for otg core? That can be done.

> 
>> +dev_dbg(dwc->dev, "%s: %d\n", __func__, on);
>> +if (on) {
>> +dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_HOST);
>> +/* start the HCD */
>> +usb_otg_start_host(fsm, true);
>> +} else {
>> +/* stop the HCD */
>> +usb_otg_start_host(fsm, false);
>> +}
> 
> This can be simplified.
> 
>   if (on)
>   dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_HOST);
> 
>   usb_otg_start_host(fsm, on);

Indeed.

> 
>> +
>> +return 0;
>> +}
>> +
>> +static int dwc3_drd_start_gadget(struct otg_fsm *fsm, int on)
>> +{
>> +struct device *dev = usb_otg_fsm_to_dev(fsm);
>> +struct dwc3 *dwc = dev_get_drvdata(dev);
>> +
>> +dev_dbg(dwc->dev, "%s: %d\n", __func__, on);
>> +if (on) {
>> +dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_DEVICE);
>> +dwc3_event_buffers_setup(dwc);
>> +
>> +/* start the UDC */
>> +usb_otg_start_gadget(fsm, true);
>> +} else {
>> +/* stop the UDC */
>> +usb_otg_start_gadget(fsm, false);
>> +}
> 
> likewise:
> 
>   if (on) {
>   dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_DEVICE);
>   dwc3_event_buffers_setup(dwc);
>   }
> 
>   usb_otg_start_gadget(fsm, on);

OK.
> 
>> +return 0;
>> +}
>> +
>> +static struct otg_fsm_ops dwc3_drd_ops = {
>> +.start_host = dwc3_drd_start_host,
>> +.start_gadget = dwc3_drd_start_gadget,
>> +};
>> +
>> +static int dwc3_drd_notifier(struct notifier_block *nb,
>> + unsigned long event, void *ptr)
>> +{
>> +struct dwc3 *dwc = container_of(nb, struct dwc3, otg_nb);
>> +
>> +dwc3_drd_fsm_sync(dwc);
>> +
>> +return NOTIFY_DONE;
>> +}
>> +
>> +static int dwc3_drd_init(struct dwc3 *dwc)
>> +{
>> +int ret, id, vbus;
>> +struct usb_otg_caps *otgcaps = >otg_config.otg_caps;
>> +
>> +otgcaps->otg_rev = 0;
>> +otgcaps->hnp_support = false;
>> +otgcaps->srp_support = false;
>> +otgcaps->adp_support = false;
>> +dwc->otg_config.fsm_ops = _drd_ops;
>> +
>> +if (!dwc->edev) {
>> +dev_err(dwc->dev, "No extcon device found for OTG mode\n");
>> +return -ENODEV;
>> +}
>> +
>> +dwc->otg_nb.notifier_call = dwc3_drd_notifier;
>> +ret = extcon_register_notifier(dwc->edev, EXTCON_USB, >otg_nb);
>> +if (ret < 0) {
>> +dev_err(dwc->dev, "Couldn't register USB cable notifier\n");
>> +return -ENODEV;
>> +}
>> +
>> +ret = extcon_register_notifier(dwc->edev, EXTCON_USB_HOST,
>> +   >otg_nb);
>> +if (ret < 0) {
>> +dev_err(dwc->dev, "Couldn't register USB-HOST cable 
>> notifier\n");
>> +ret = -ENODEV;
>> +goto extcon_fail;
>> +}
>> +
>> +/* sanity check id & vbus states */
>> +id = extcon_get_cable_state(dwc->edev, "USB-HOST");
>> +vbus = extcon_get_cable_state(dwc->edev, "USB");
>> +if (id < 0 || vbus < 0) {
>> +dev_err(dwc->dev, "Invalid USB cable state. id %d, vbus %d\n",
>> +   

[PATCH 3/4] ARM: dts: omap5: fix address translation for pbias

[Kishon Vijay Abraham I]

commit  ("ARM: dts: omap5: add minimal l4 bus
layout with control module support") moved pbias_regulator dt node
from being a child node of ocp to be the child node of
omap5_padconf_global. Since omap5_padconf_global doesn't have the
'ranges' property, address translation fails while trying to convert
the address to resource. Fix it here.

Fixes: ed8509edddeb ("ARM: dts: omap5: add minimal l4 bus
layout with control module support")

Signed-off-by: Kishon Vijay Abraham I 
---
 arch/arm/boot/dts/omap5.dtsi |1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 76ef595..dd7a0e8 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -185,6 +185,7 @@
reg = <0x5a0 0xec>;
#address-cells = <1>;
#size-cells = <1>;
+   ranges = <0 0x5a0 0xec>;
 
pbias_regulator: pbias_regulator {
compatible = "ti,pbias-omap5", 
"ti,pbias-omap";
-- 
1.7.9.5

--
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 2/4] ARM: dts: omap4: fix address translation for pbias

[Kishon Vijay Abraham I]

commit <7415b0b4c645> ("ARM: dts: omap4: add minimal l4 bus layout
with control module support") moved pbias_regulator dt node
from being a child node of ocp to be the child node of
omap4_padconf_global. Since omap4_padconf_global doesn't have the
'ranges' property, address translation fails while trying to convert
the address to resource. Fix it here.

Fixes: 7415b0b4c645 ("ARM: dts: omap4: add minimal l4 bus layout
with control module support")

Signed-off-by: Kishon Vijay Abraham I 
---
 arch/arm/boot/dts/omap4.dtsi |1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 5aad7f3..5a206c1 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -196,6 +196,7 @@
reg = <0x5a0 0x170>;
#address-cells = <1>;
#size-cells = <1>;
+   ranges = <0 0x5a0 0x170>;
 
pbias_regulator: pbias_regulator {
compatible = "ti,pbias-omap4", 
"ti,pbias-omap";
-- 
1.7.9.5

--
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 2/2] ARM: dts: am335x-wega: Clean up regulators

[Teresa Remmet]

Cleaned up the regulators on the wega board. Created a simple bus,
renamed the regulators according to the schematics and added missing
regulator on wega.

Signed-off-by: Teresa Remmet 
---
 arch/arm/boot/dts/am335x-phycore-som.dtsi | 36 ---
 arch/arm/boot/dts/am335x-wega.dtsi| 13 ++-
 2 files changed, 31 insertions(+), 18 deletions(-)

diff --git a/arch/arm/boot/dts/am335x-phycore-som.dtsi 
b/arch/arm/boot/dts/am335x-phycore-som.dtsi
index 5dd084f..2f43e45 100644
--- a/arch/arm/boot/dts/am335x-phycore-som.dtsi
+++ b/arch/arm/boot/dts/am335x-phycore-som.dtsi
@@ -29,8 +29,17 @@
reg = <0x8000 0x1000>; /* 256 MB */
};
 
-   vbat: fixedregulator@0 {
-   compatible = "regulator-fixed";
+   regulators {
+   compatible = "simple-bus";
+
+   vcc5v: fixedregulator@0 {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc5v";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   regulator-boot-on;
+   regulator-always-on;
+   };
};
 };
 
@@ -233,14 +242,14 @@
 #include "tps65910.dtsi"
 
  {
-   vcc1-supply = <>;
-   vcc2-supply = <>;
-   vcc3-supply = <>;
-   vcc4-supply = <>;
-   vcc5-supply = <>;
-   vcc6-supply = <>;
-   vcc7-supply = <>;
-   vccio-supply = <>;
+   vcc1-supply = <>;
+   vcc2-supply = <>;
+   vcc3-supply = <>;
+   vcc4-supply = <>;
+   vcc5-supply = <>;
+   vcc6-supply = <>;
+   vcc7-supply = <>;
+   vccio-supply = <>;
 
regulators {
vrtc_reg: regulator@0 {
@@ -311,13 +320,6 @@
};
 };
 
- {
-   regulator-name = "vbat";
-   regulator-min-microvolt = <500>;
-   regulator-max-microvolt = <500>;
-   regulator-boot-on;
-};
-
 /* SPI Busses */
 _pinmux {
spi0_pins: pinmux_spi0 {
diff --git a/arch/arm/boot/dts/am335x-wega.dtsi 
b/arch/arm/boot/dts/am335x-wega.dtsi
index 5e541bd..2cecb39 100644
--- a/arch/arm/boot/dts/am335x-wega.dtsi
+++ b/arch/arm/boot/dts/am335x-wega.dtsi
@@ -11,6 +11,17 @@
model = "Phytec AM335x phyBOARD-WEGA";
compatible = "phytec,am335x-wega", "phytec,am335x-phycore-som", 
"ti,am33xx";
 
+   regulators {
+   compatible = "simple-bus";
+
+   vcc3v3: fixedregulator@1 {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc3v3";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-boot-on;
+   };
+   };
 };
 
 /* CAN Busses */
@@ -80,7 +91,7 @@
 };
 
  {
-   vmmc-supply = <_reg>;
+   vmmc-supply = <>;
bus-width = <4>;
pinctrl-names = "default";
pinctrl-0 = <_pins>;
-- 
1.9.1

--
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] ARM: OMAP2+: Remove legacy OMAP3 ISP instantiation

[Suman Anna]

Hi Sakari,

On 07/16/2015 07:58 AM, Tony Lindgren wrote:
> * Laurent Pinchart  [150716 05:57]:
>> The OMAP3 ISP is now fully supported in DT, remove its instantiation
>> from C code.
> 
> Please feel to queue this along with the second patch in this series,
> this should not cause any merge conflicts:
> 
> Acked-by: Tony Lindgren 

Just wondering if you have already queued this, I see the v4l changes in
linux-next, but not this patch. Also, can you confirm if this series is
making it into 4.3?

regards
Suman

--
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 2/2] iommu/omap: Add support for configuring dsp iommus on DRA7xx

[Suman Anna]

Hi Tony,

Sorry for the long delay in getting back on this. I will repost the
series once 4.3-rc1 is out, but at the moment I do not think any changes
are required. Let me know if you still need any additional details.

 On 07/23/2015 02:24 AM, Tony Lindgren wrote:
> * Suman Anna  [150722 09:25]:
>> On 07/22/2015 12:26 AM, Tony Lindgren wrote:
>>>
>>> I don't like using syscon for tinkering directly with SoC registers.
>>
>> This is not a SoC-level register, but a register within a sub-module of
>> the DSP processor sub-system. The DSP_SYSTEM sub-module in general is
>> described in Section 5.3.3 of the TRM [1], and it implements different
>> functionalities like the PRCM handshaking, wakeup logic and DSP
>> subsystem top-level configuration. It is a module present within the DSP
>> processor sub-system, so can only be accessed when the sub-system is
>> clocked and the appropriate reset is released.
>
> OK so if it's specific to the DSP driver along the lines of sysc and
> syss registers.

 There will be those registers too within the MMU config register space,
 even for DRA7xx MMUs. This is different, think of it like a register in
 the Control module except that it is present within the DSP sub-system
 instead of at the SoC level.
>>>
>>> And what is taking care of pm_runtime_get here to ensure the module
>>> is powered and clocked?
>>
>> pm_runtime_get_sync is indeed getting invoked, its just the current
>> patch doesn't include the code block that invokes it. The function that
>> invokes omap2_iommu_enable does so after a call to the
>> pm_runtime_get_sync() call.
> 
> OK 
> 
>>> I think you are missing a layer here and it's the Linux kernel side
>>> device driver for DSP that initializes things.
>>
>> We already have separate drivers for MMUs (omap-iommu) and the processor
>> management (omap-rproc). The former manages all the low-level
>> programming sequences for the MMUs, while the latter manages the
>> low-level reset etc, and is a client user of the respective IOMMU
>> device. Both integrate into the respective frameworks. The IOMMU API
>> invocations are handled in the remoteproc core, with the OMAP remoteproc
>> driver publishing itself as having an MMU with the remoteproc core. The
>> IOMMU API invoke the appropriate iommu_ops.
>>
>> You can lookup the functions rproc_enable_iommu()/rproc_disable_iommu()
>> in the remoteproc core. The IOMMU enabling sequences happen within the
>> iommu_attach_device() API. The call flow is
>> iommu_attach_device()->omap_iommu_attach_dev()->omap_iommu_attach()->
>> iommu_enable()->
>>omap_device_deassert_hardreset, pm_runtime_get_sync, omap2_iommu_enable.
> 
> OK. The thing to check here is that you have a separate device driver
> for each sysc/syss device registers. This is because each hardware module
> can be independently clocked and idled. Otherwise things will break at
> some point. And no "things are configured for autoidle" or "we're not
> doing PM is not a good excuse here" :)
> 
> Can you please check that? If the remoteproc driver and iommu driver
> are tinkering with registers in separate hardware modules, we have
> a layering violation. My guess is that we have at least two hardware
> modules involved here, one for the iommu and one for the DSP device.

Only the IOMMU has a SYSC/SYSS device register. It has both a soft-reset
as well as a hard-reset line. The IOMMU stays in reset, and its state
machine/programming is controlled through the remoteproc driver. The
clock source is also single clock going into the remote processor
subsystem, and split up internally to feed the memories and the
processors. For the PRCM to auto-gate the clocks, we also need the
processor to be executing a IDLE (DSPs) or WFI/WFE (Cortex M3/M4s). Just
the IOMMU will allow the OCP idle because of the associated sysc/syss
registers. Depending on the remote processor, there might be a separate
internal module (like the DSPs usually have a separate SYSC module), but
that programming is left to the software running on the DSP.

>  
> Typically we handle these registers by mapping them to the PM runtime
> functions for the interconnect so we can reset and idle the hardware
> modules even if there is no driver, see for example
> omap54xx_mmu_dsp_hwmod.

 I haven't yet submitted the DRA7xx hwmods, but they will look almost
 exactly like the OMAP5 ones. The reset and idle on these are in general
 not effective at boot time since these are also controlled by a
 hard-reset line, so that's left to the drivers to deal with it through
 the omap_device_deassert_hardreset API.
>>>
>>> If the MMU configuration is one time init, it may make sense to add
>>> it to the hwmod reset function. However, if the Linux kernel side
>>> driver needs to configure things depending on the DSP firmware, it
>>> should be done in the kernel side device driver.
>>
>> 

Re: [RFC PATCH 1/4] ARM: OMAP2: DRA7: Modify optimize string comparisons in soc_is calls

[Keerthy]

On Thursday 03 September 2015 09:45 PM, Tony Lindgren wrote:

* Keerthy  [150902 03:23]:

Currently everytime soc_is calls are made, firstly device tree nodes
are parsed and then string comparisons are made to determine the
soc version. Optimizing it to be done one time and store the result.
Use the stored value in all the subsequent checks for soc_is calls.

...


--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -44,12 +44,29 @@ static char soc_name[OMAP_SOC_MAX_NAME_LENGTH];
  static char soc_rev[OMAP_SOC_MAX_NAME_LENGTH];
  u32 omap_features;

+static int soc_ids[MAX_ID];


Hmm why would we need to keep an array of the non-booted
socs? We know they're all false after booting..

A bitmask is usually used here?


Yes. This will be more optimal. I will implement using a bit mask.



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


--
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 2/3][v4] drivers: usb: dwc3: Add frame length adjustment quirk

[Nikhil Badola]

Add adjust_frame_length_quirk for writing to fladj register
which adjusts (micro)frame length to value provided by
"snps,quirk-frame-length-adjustment" property thus avoiding
USB 2.0 devices to time-out over a longer run

Signed-off-by: Nikhil Badola 
---
Changes for v4: Removed mixed declerations and code

 drivers/usb/dwc3/core.c  | 34 ++
 drivers/usb/dwc3/core.h  |  5 +
 drivers/usb/dwc3/platform_data.h |  2 ++
 3 files changed, 41 insertions(+)

diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 064123e..6270581 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -143,6 +143,32 @@ static int dwc3_soft_reset(struct dwc3 *dwc)
return 0;
 }
 
+/*
+ * dwc3_frame_length_adjustment - Adjusts frame length if required
+ * @dwc3: Pointer to our controller context structure
+ * @fladj: Value of GFLADJ_30MHZ to adjust frame length
+ */
+static void dwc3_frame_length_adjustment(struct dwc3 *dwc, u32 fladj)
+{
+   u32 reg;
+   u32 dft;
+
+   if (dwc->revision < DWC3_REVISION_250A)
+   return;
+
+   if (fladj == 0)
+   return;
+
+   reg = dwc3_readl(dwc->regs, DWC3_GFLADJ);
+   dft = reg & DWC3_GFLADJ_30MHZ_MASK;
+   if (!dev_WARN_ONCE(dwc->dev, dft == fladj,
+   "request value same as default, ignoring\n")) {
+   reg &= ~DWC3_GFLADJ_30MHZ_MASK;
+   reg |= DWC3_GFLADJ_30MHZ_SDBND_SEL | fladj;
+   dwc3_writel(dwc->regs, DWC3_GFLADJ, reg);
+   }
+}
+
 /**
  * dwc3_free_one_event_buffer - Frees one event buffer
  * @dwc: Pointer to our controller context structure
@@ -779,6 +805,7 @@ static int dwc3_probe(struct platform_device *pdev)
u8  lpm_nyet_threshold;
u8  tx_de_emphasis;
u8  hird_threshold;
+   u32 fladj = 0;
 
int ret;
 
@@ -886,6 +913,9 @@ static int dwc3_probe(struct platform_device *pdev)
_de_emphasis);
of_property_read_string(node, "snps,hsphy_interface",
>hsphy_interface);
+   of_property_read_u32(node,
+"snps,quirk-frame-length-adjustment",
+);
} else if (pdata) {
dwc->maximum_speed = pdata->maximum_speed;
dwc->has_lpm_erratum = pdata->has_lpm_erratum;
@@ -915,6 +945,7 @@ static int dwc3_probe(struct platform_device *pdev)
tx_de_emphasis = pdata->tx_de_emphasis;
 
dwc->hsphy_interface = pdata->hsphy_interface;
+   fladj = pdata->fladj_value;
}
 
/* default to superspeed if no maximum_speed passed */
@@ -971,6 +1002,9 @@ static int dwc3_probe(struct platform_device *pdev)
goto err1;
}
 
+   /* Adjust Frame Length */
+   dwc3_frame_length_adjustment(dwc, fladj);
+
usb_phy_set_suspend(dwc->usb2_phy, 0);
usb_phy_set_suspend(dwc->usb3_phy, 0);
ret = phy_power_on(dwc->usb2_generic_phy);
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 0447788..9188745 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -124,6 +124,7 @@
 #define DWC3_GEVNTCOUNT(n) (0xc40c + (n * 0x10))
 
 #define DWC3_GHWPARAMS80xc600
+#define DWC3_GFLADJ0xc630
 
 /* Device Registers */
 #define DWC3_DCFG  0xc700
@@ -234,6 +235,10 @@
 /* Global HWPARAMS6 Register */
 #define DWC3_GHWPARAMS6_EN_FPGA(1 << 7)
 
+/* Global Frame Length Adjustment Register */
+#define DWC3_GFLADJ_30MHZ_SDBND_SEL(1 << 7)
+#define DWC3_GFLADJ_30MHZ_MASK 0x3f
+
 /* Device Configuration Register */
 #define DWC3_DCFG_DEVADDR(addr)((addr) << 3)
 #define DWC3_DCFG_DEVADDR_MASK DWC3_DCFG_DEVADDR(0x7f)
diff --git a/drivers/usb/dwc3/platform_data.h b/drivers/usb/dwc3/platform_data.h
index d3614ec..400b197 100644
--- a/drivers/usb/dwc3/platform_data.h
+++ b/drivers/usb/dwc3/platform_data.h
@@ -46,5 +46,7 @@ struct dwc3_platform_data {
unsigned tx_de_emphasis_quirk:1;
unsigned tx_de_emphasis:2;
 
+   u32 fladj_value;
+
const char *hsphy_interface;
 };
-- 
2.1.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 v2] security: device_cgroup: fix RCU lockdep splat

[Paul E. McKenney]

On Thu, Sep 03, 2015 at 08:48:39AM -0500, Serge E. Hallyn wrote:
> On Wed, Sep 02, 2015 at 05:14:33PM -0700, Paul E. McKenney wrote:
> > On Wed, Sep 02, 2015 at 12:24:50PM -0400, Tejun Heo wrote:
> > > cc'ing Paul.
> > > 
> > > On Wed, Sep 02, 2015 at 08:12:28AM -0500, Felipe Balbi wrote:
> > > > 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.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)
> > > 
> > > This shouldn't be happening because devcgroup_access_write() always
> > > grabs devcgroup_mutex.  Looking at the log, the culprit seems to be
> > > f78f5b90c4ff ("rcu: Rename rcu_lockdep_assert() to
> > > RCU_LOCKDEP_WARN()").  It missed the bang for the second test while
> > > inverting it, so adding rcu_read_lock() isn't the right fix here.
> > > 
> > > Paul, can you please fix it?
> > 
> > Gah!  Please see below.
> > 
> > Thanx, Paul
> > 
> > 
> > 
> > security/device_cgroup: Fix RCU_LOCKDEP_WARN() condition
> > 
> > f78f5b90c4ff ("rcu: Rename rcu_lockdep_assert() to RCU_LOCKDEP_WARN()")
> > introduced a bug by incorrectly inverting the condition when moving from
> > rcu_lockdep_assert() to RCU_LOCKDEP_WARN().  This commit therefore fixes
> > the inversion.
> > 
> > Reported-by: Felipe Balbi 
> > Reported-by: Tejun Heo 
> > Signed-off-by: Paul E. McKenney 
> > Cc: Serge Hallyn 
> 
> Oh, makes sense :)  (didn't see the original patch when it came by, sorry)

I should have CCed you, apologies for failing to do so.

> Acked-by: Serge Hallyn 

Added, thank you!

Thanx, Paul

> > diff --git a/security/device_cgroup.c b/security/device_cgroup.c
> > index 73455089feef..03c1652c9a1f 100644
> > --- a/security/device_cgroup.c
> > +++ b/security/device_cgroup.c
> > @@ -401,7 +401,7 @@ static bool verify_new_ex(struct dev_cgroup *dev_cgroup,
> > bool match = false;
> >  
> > RCU_LOCKDEP_WARN(!rcu_read_lock_held() &&
> > -lockdep_is_held(_mutex),
> > +!lockdep_is_held(_mutex),
> >  "device_cgroup:verify_new_ex called without proper 
> > synchronization");
> >  
> > if (dev_cgroup->behavior == DEVCG_DEFAULT_ALLOW) {
> 

--
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 v4 4/9] usb: dwc3: core: Adapt to named interrupts

[Roger Quadros]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 02/09/15 17:34, Felipe Balbi wrote:
> On Wed, Sep 02, 2015 at 05:24:19PM +0300, Roger Quadros wrote:
>> From: Felipe Balbi 
>>
>> Add support to use interrupt names,
>>
>> Following are the interrupt names
>>
>> Peripheral Interrupt - peripheral
>> HOST Interrupt - host
>> OTG Interrupt - otg
>>
>> [Roger Q]
>> - If any of these are missing we use the
>> first available IRQ resource so that we don't
>> break with older DTBs.
> 
> this is what original commit did:
> 
> commit ecd5f71cfd663bcd4efd2f29824acd8b2ba9715d
> Author: Felipe Balbi 
> Date:   Fri Jan 3 13:49:38 2014 -0600
> 
> usb: dwc3: cleanup IRQ resources
> 
> In order to make it easier for the driver to
> figure out which modes of operation it has,
> and because some dwc3 integrations have rather
> fuzzy IRQ routing, we now require three different
> IRQ numbers (peripheral, host, otg).
> 
> In order to do that and maintain backwards compatibility,
> we still maintain support for the old IRQ resource name,
> but if you *really* want to have proper peripheral/host/otg
> support, you should make sure your resources are correct.
> 
> Signed-off-by: Felipe Balbi 

This is better since we request the resource only if needed and bail out
if it is not present.

> 
> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
> index 60580a01cdd2..1f01031873b7 100644
> --- a/drivers/usb/dwc3/core.c
> +++ b/drivers/usb/dwc3/core.c
> @@ -556,10 +556,22 @@ static int dwc3_core_get_phy(struct dwc3 *dwc)
>  static int dwc3_core_init_mode(struct dwc3 *dwc)
>  {
>   struct device *dev = dwc->dev;
> + struct platform_device *pdev = to_platform_device(dev);
>   int ret;
>  
>   switch (dwc->dr_mode) {
>   case USB_DR_MODE_PERIPHERAL:
> + dwc->gadget_irq = platform_get_irq_byname(pdev, 
> "dwc3_peripheral");

Shall we just name it just "peripheral"?

> + if (dwc->gadget_irq < 0) {
> + dwc->gadget_irq = platform_get_irq_byname(pdev, 
> "dwc_usb3");

How will this work? Currently we don't have a name for the IRQ in the DT.

> + if (dwc->gadget_irq < 0) {
> + dev_err(dev, "missing IRQ\n");
> + return dwc->gadget_irq;
> + } else {
> + dev_warn(dev, "dwc_usb3 resource is 
> deprecated\n");

Do we want to warn about legacy nodes?

> + }
> + }
> +
>   dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_DEVICE);
>   ret = dwc3_gadget_init(dwc);
>   if (ret) {
> @@ -568,6 +580,22 @@ static int dwc3_core_init_mode(struct dwc3 *dwc)
>   }
>   break;
>   case USB_DR_MODE_HOST:
> + dwc->xhci_irq = platform_get_irq_byname(pdev, "dwc3_host");
> + if (dwc->xhci_irq < 0) {
> + dwc->xhci_irq = platform_get_irq_byname(pdev, 
> "dwc_usb3");
> + if (dwc->xhci_irq < 0) {
> + dev_err(dev, "missing Host IRQ\n");
> + return dwc->xhci_irq;
> + } else {
> + dev_warn(dev, "dwc_usb3 resource is 
> deprecated\n");
> + }
> +
> + dwc->xhci_resources[1].start = dwc->xhci_irq;
> + dwc->xhci_resources[1].end = dwc->xhci_irq;
> + dwc->xhci_resources[1].flags = IORESOURCE_IRQ;
> + dwc->xhci_resources[1].name = "xhci";
> + }
> +
>   dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_HOST);
>   ret = dwc3_host_init(dwc);
>   if (ret) {
> @@ -576,6 +604,28 @@ static int dwc3_core_init_mode(struct dwc3 *dwc)
>   }
>   break;
>   case USB_DR_MODE_OTG:
> + dwc->gadget_irq = platform_get_irq_byname(pdev, 
> "dwc3_peripheral");
> + if (dwc->gadget_irq < 0) {
> + dwc->gadget_irq = platform_get_irq_byname(pdev, 
> "dwc_usb3");
> + if (dwc->gadget_irq < 0) {
> + dev_err(dev, "missing IRQ\n");
> + return dwc->gadget_irq;
> + } else {
> + dev_warn(dev, "dwc_usb3 resource is 
> deprecated\n");
> + }
> +
> + dwc->xhci_irq = dwc->gadget_irq;
> + dwc->otg_irq = dwc->gadget_irq;
> + } else {
> + dwc->xhci_irq = platform_get_irq_byname(pdev, 
> "dwc3_host");
> + if (dwc->xhci_irq < 0) {
> + dev_err(dev, "missing Host IRQ\n");
> + return dwc->xhci_irq;
> + }
> +
> + dwc->otg_irq = platform_get_irq_byname(pdev, 
> 

Re: [PATCH v2] security: device_cgroup: fix RCU lockdep splat

[Paul E. McKenney]

On Thu, Sep 03, 2015 at 09:56:05AM -0400, Josh Boyer wrote:
> On Wed, Sep 2, 2015 at 8:14 PM, Paul E. McKenney
>  wrote:
> > On Wed, Sep 02, 2015 at 12:24:50PM -0400, Tejun Heo wrote:
> >> cc'ing Paul.
> >>
> >> On Wed, Sep 02, 2015 at 08:12:28AM -0500, Felipe Balbi wrote:
> >> > 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.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)
> >>
> >> This shouldn't be happening because devcgroup_access_write() always
> >> grabs devcgroup_mutex.  Looking at the log, the culprit seems to be
> >> f78f5b90c4ff ("rcu: Rename rcu_lockdep_assert() to
> >> RCU_LOCKDEP_WARN()").  It missed the bang for the second test while
> >> inverting it, so adding rcu_read_lock() isn't the right fix here.
> >>
> >> Paul, can you please fix it?
> >
> > Gah!  Please see below.
> >
> > Thanx, Paul
> >
> > 
> >
> > security/device_cgroup: Fix RCU_LOCKDEP_WARN() condition
> >
> > f78f5b90c4ff ("rcu: Rename rcu_lockdep_assert() to RCU_LOCKDEP_WARN()")
> > introduced a bug by incorrectly inverting the condition when moving from
> > rcu_lockdep_assert() to RCU_LOCKDEP_WARN().  This commit therefore fixes
> > the inversion.
> >
> > Reported-by: Felipe Balbi 
> > Reported-by: Tejun Heo 
> > Signed-off-by: Paul E. McKenney 
> > Cc: Serge Hallyn 
> 
> Just tested this patch without Felipe's previous version on all my
> machines.  The splat is indeed gone.
> 
> Tested-by: Josh Boyer 

Thank you, added!

Thanx, Paul

> josh
> 
> >
> > diff --git a/security/device_cgroup.c b/security/device_cgroup.c
> > index 73455089feef..03c1652c9a1f 100644
> > --- a/security/device_cgroup.c
> > +++ b/security/device_cgroup.c
> > @@ -401,7 +401,7 @@ static bool verify_new_ex(struct dev_cgroup *dev_cgroup,
> > bool match = false;
> >
> > RCU_LOCKDEP_WARN(!rcu_read_lock_held() &&
> > -lockdep_is_held(_mutex),
> > +!lockdep_is_held(_mutex),
> >  "device_cgroup:verify_new_ex called without proper 
> > synchronization");
> >
> > if (dev_cgroup->behavior == DEVCG_DEFAULT_ALLOW) {
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
> 

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