[PATCH 1/2] ARM: OMAP1: Remove device creation for omap-pcm-audio

[Peter Ujfalusi]

The omap-pcm in ASoC is no longer a platform device. No need to create this
device anymore.

Signed-off-by: Peter Ujfalusi 
---
 arch/arm/mach-omap1/devices.c | 19 ---
 1 file changed, 19 deletions(-)

diff --git a/arch/arm/mach-omap1/devices.c b/arch/arm/mach-omap1/devices.c
index 263c07a566cb..8c8be861fff2 100644
--- a/arch/arm/mach-omap1/devices.c
+++ b/arch/arm/mach-omap1/devices.c
@@ -33,24 +33,6 @@
 #include "mmc.h"
 #include "sram.h"
 
-#if defined(CONFIG_SND_SOC) || defined(CONFIG_SND_SOC_MODULE)
-
-static struct platform_device omap_pcm = {
-   .name   = "omap-pcm-audio",
-   .id = -1,
-};
-
-static void omap_init_audio(void)
-{
-   platform_device_register(_pcm);
-}
-
-#else
-static inline void omap_init_audio(void) {}
-#endif
-
-/*-*/
-
 #if defined(CONFIG_RTC_DRV_OMAP) || defined(CONFIG_RTC_DRV_OMAP_MODULE)
 
 #defineOMAP_RTC_BASE   0xfffb4800
@@ -425,7 +407,6 @@ static int __init omap1_init_devices(void)
 * in alphabetical order so they're easier to sort through.
 */
 
-   omap_init_audio();
omap_init_mbox();
omap_init_rtc();
omap_init_spi100k();
-- 
2.6.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

Re: [PATCH v4 01/58] mtd: nand: denali: add missing nand_release() call in denali_remove()

[Dan Carpenter]

On Fri, Dec 11, 2015 at 02:53:20PM +0100, Boris Brezillon wrote:
> Hi Brian,
> 
> On Thu, 10 Dec 2015 16:40:08 -0800
> Brian Norris  wrote:
> 
> > On Thu, Dec 10, 2015 at 08:59:45AM +0100, Boris Brezillon wrote:
> > > Unregister the NAND device from the NAND subsystem when removing a denali
> > > NAND controller, otherwise the MTD attached to the NAND device is still
> > > exposed by the MTD layer, and accesses to this device will likely crash
> > > the system.
> > > 
> > > Signed-off-by: Boris Brezillon 
> > > Cc:  #3.8+
> > 
> > Does this follow these rules, from
> > Documentation/stable_kernel_rules.txt?
> > 
> >  - It must be obviously correct and tested.
> > 
> >  - It must fix a real bug that bothers people (not a, "This could be a
> >problem..." type thing).
> 
> As you wish, I'll remove those Cc and Fixes tags, or just drop the
> patch if you think it's useless...

The fixes tag is a separate thing from CCing stable.  It's useful on by
itself.  I always put the person who wrote the original patch in the To:
header so they can review and comment if I have made a mistake.

regards,
dan carpenter

--
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 v5 41/58] mtd: nand: socrates: use the mtd instance embedded in struct nand_chip

[Boris Brezillon]

struct nand_chip now embeds an mtd device. Make use of this mtd instance.

Signed-off-by: Boris Brezillon 
---
Changes since v4:
- fix build error

---
Changes generated with the following coccinelle script

--->8---
virtual patch

@fix1@
identifier __chipfield, __mtdfield;
type __type;
@@
(
__type {
...
struct nand_chip __chipfield;
...
-   struct mtd_info __mtdfield;
...
};
|
__type {
...
-   struct mtd_info __mtdfield;
...
struct nand_chip __chipfield;
...
};
)

@fix2 depends on fix1@
identifier fix1.__chipfield, fix1.__mtdfield;
identifier __subfield;
type fix1.__type;
__type *__priv;
@@
(
-   __priv->__mtdfield.__subfield
+   nand_to_mtd(&__priv->__chipfield)->__subfield
|
-   &(__priv->__mtdfield)
+   nand_to_mtd(&__priv->__chipfield)
)
--->8---
---
 drivers/mtd/nand/socrates_nand.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/mtd/nand/socrates_nand.c b/drivers/mtd/nand/socrates_nand.c
index 2dfb1e0..925761c 100644
--- a/drivers/mtd/nand/socrates_nand.c
+++ b/drivers/mtd/nand/socrates_nand.c
@@ -30,7 +30,6 @@
 
 struct socrates_nand_host {
struct nand_chipnand_chip;
-   struct mtd_info mtd;
void __iomem*io_base;
struct device   *dev;
 };
@@ -159,8 +158,8 @@ static int socrates_nand_probe(struct platform_device 
*ofdev)
return -EIO;
}
 
-   mtd = >mtd;
nand_chip = >nand_chip;
+   mtd = nand_to_mtd(nand_chip);
host->dev = >dev;
 
nand_chip->priv = host; /* link the private data structures */
@@ -216,7 +215,7 @@ out:
 static int socrates_nand_remove(struct platform_device *ofdev)
 {
struct socrates_nand_host *host = dev_get_drvdata(>dev);
-   struct mtd_info *mtd = >mtd;
+   struct mtd_info *mtd = nand_to_mtd(>nand_chip);
 
nand_release(mtd);
 
-- 
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 v5 15/58] mtd: nand: denali: use the mtd instance embedded in struct nand_chip

[Boris Brezillon]

struct nand_chip now embeds an mtd device. Make use of this mtd instance.

Signed-off-by: Boris Brezillon 
---
Changes since v4:
- fix conflict after changes brought in v5 of patch 1

---
Changes generated with the following coccinelle script

--->8---
virtual patch

@fix1@
identifier __chipfield, __mtdfield;
type __type;
@@
(
__type {
...
struct nand_chip __chipfield;
...
-   struct mtd_info __mtdfield;
...
};
|
__type {
...
-   struct mtd_info __mtdfield;
...
struct nand_chip __chipfield;
...
};
)

@fix2 depends on fix1@
identifier fix1.__chipfield, fix1.__mtdfield;
identifier __subfield;
type fix1.__type;
__type *__priv;
@@
(
-   __priv->__mtdfield.__subfield
+   nand_to_mtd(&__priv->__chipfield)->__subfield
|
-   &(__priv->__mtdfield)
+   nand_to_mtd(&__priv->__chipfield)
)
--->8---

Conflicts:
drivers/mtd/nand/denali.c
---
 drivers/mtd/nand/denali.c | 69 ++-
 drivers/mtd/nand/denali.h |  1 -
 2 files changed, 38 insertions(+), 32 deletions(-)

diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c
index fdfea05..ccab8bc 100644
--- a/drivers/mtd/nand/denali.c
+++ b/drivers/mtd/nand/denali.c
@@ -75,7 +75,10 @@ MODULE_PARM_DESC(onfi_timing_mode,
  * this macro allows us to convert from an MTD structure to our own
  * device context (denali) structure.
  */
-#define mtd_to_denali(m) container_of(m, struct denali_nand_info, mtd)
+static inline struct denali_nand_info *mtd_to_denali(struct mtd_info *mtd)
+{
+   return container_of(mtd_to_nand(mtd), struct denali_nand_info, nand);
+}
 
 /*
  * These constants are defined by the driver to enable common driver
@@ -986,6 +989,8 @@ static bool handle_ecc(struct denali_nand_info *denali, 
uint8_t *buf,
 * than one NAND connected.
 */
if (err_byte < ECC_SECTOR_SIZE) {
+   struct mtd_info *mtd =
+   nand_to_mtd(>nand);
int offset;
 
offset = (err_sector *
@@ -995,7 +1000,7 @@ static bool handle_ecc(struct denali_nand_info *denali, 
uint8_t *buf,
err_device;
/* correct the ECC error */
buf[offset] ^= err_correction_value;
-   denali->mtd.ecc_stats.corrected++;
+   mtd->ecc_stats.corrected++;
bitflips++;
}
} else {
@@ -1062,7 +1067,7 @@ static int write_page(struct mtd_info *mtd, struct 
nand_chip *chip,
 {
struct denali_nand_info *denali = mtd_to_denali(mtd);
dma_addr_t addr = denali->buf.dma_buf;
-   size_t size = denali->mtd.writesize + denali->mtd.oobsize;
+   size_t size = mtd->writesize + mtd->oobsize;
uint32_t irq_status;
uint32_t irq_mask = INTR_STATUS__DMA_CMD_COMP |
INTR_STATUS__PROGRAM_FAIL;
@@ -1160,7 +1165,7 @@ static int denali_read_page(struct mtd_info *mtd, struct 
nand_chip *chip,
struct denali_nand_info *denali = mtd_to_denali(mtd);
 
dma_addr_t addr = denali->buf.dma_buf;
-   size_t size = denali->mtd.writesize + denali->mtd.oobsize;
+   size_t size = mtd->writesize + mtd->oobsize;
 
uint32_t irq_status;
uint32_t irq_mask = INTR_STATUS__ECC_TRANSACTION_DONE |
@@ -1193,14 +1198,14 @@ static int denali_read_page(struct mtd_info *mtd, 
struct nand_chip *chip,
denali_enable_dma(denali, false);
 
if (check_erased_page) {
-   read_oob_data(>mtd, chip->oob_poi, denali->page);
+   read_oob_data(mtd, chip->oob_poi, denali->page);
 
/* check ECC failures that may have occurred on erased pages */
if (check_erased_page) {
-   if (!is_erased(buf, denali->mtd.writesize))
-   denali->mtd.ecc_stats.failed++;
-   if (!is_erased(buf, denali->mtd.oobsize))
-   denali->mtd.ecc_stats.failed++;
+   if (!is_erased(buf, mtd->writesize))
+   mtd->ecc_stats.failed++;
+   if (!is_erased(buf, mtd->oobsize))
+   mtd->ecc_stats.failed++;
}
}
return max_bitflips;
@@ -1211,7 +1216,7 @@ static int denali_read_page_raw(struct mtd_info *mtd, 
struct nand_chip *chip,
 {
struct denali_nand_info *denali = 

[PATCH v5 01/58] mtd: nand: denali: add missing nand_release() call in denali_remove()

[Boris Brezillon]

Unregister the NAND device from the NAND subsystem when removing a denali
NAND controller, otherwise the MTD attached to the NAND device is still
exposed by the MTD layer, and accesses to this device will likely crash
the system.

Signed-off-by: Boris Brezillon 
---
Changes since v4:
- remove Cc stable and fixes tags
- calculate the dma buffer size before calling nand_release()

 drivers/mtd/nand/denali.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c
index 67eb2be..fdfea05 100644
--- a/drivers/mtd/nand/denali.c
+++ b/drivers/mtd/nand/denali.c
@@ -1622,9 +1622,11 @@ EXPORT_SYMBOL(denali_init);
 /* driver exit point */
 void denali_remove(struct denali_nand_info *denali)
 {
+   int bufsize = denali->mtd.writesize + denali->mtd.oobsize;
+
+   nand_release(>mtd);
denali_irq_cleanup(denali->irq, denali);
-   dma_unmap_single(denali->dev, denali->buf.dma_buf,
-denali->mtd.writesize + denali->mtd.oobsize,
+   dma_unmap_single(denali->dev, denali->buf.dma_buf, bufsize,
 DMA_BIDIRECTIONAL);
 }
 EXPORT_SYMBOL(denali_remove);
-- 
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

Re: [PATCH v5 01/58] mtd: nand: denali: add missing nand_release() call in denali_remove()

[Dinh Nguyen]

Hi Boris,

On Fri, Dec 11, 2015 at 9:10 AM, Boris Brezillon
 wrote:
> + Dinh (who made commit 2a0a288ec258)
>
> Also added back the Fixes tag.
>
> On Fri, 11 Dec 2015 15:02:34 +0100
> Boris Brezillon  wrote:
>
>> Unregister the NAND device from the NAND subsystem when removing a denali
>> NAND controller, otherwise the MTD attached to the NAND device is still
>> exposed by the MTD layer, and accesses to this device will likely crash
>> the system.
>>
>> Signed-off-by: Boris Brezillon 
>
> Fixes: 2a0a288ec258 ("mtd: denali: split the generic driver and PCI layer")
>
>> ---
>> Changes since v4:
>> - remove Cc stable and fixes tags
>> - calculate the dma buffer size before calling nand_release()
>>
>>  drivers/mtd/nand/denali.c | 6 --
>>  1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c
>> index 67eb2be..fdfea05 100644
>> --- a/drivers/mtd/nand/denali.c
>> +++ b/drivers/mtd/nand/denali.c
>> @@ -1622,9 +1622,11 @@ EXPORT_SYMBOL(denali_init);
>>  /* driver exit point */
>>  void denali_remove(struct denali_nand_info *denali)
>>  {
>> + int bufsize = denali->mtd.writesize + denali->mtd.oobsize;
>> +
>> + nand_release(>mtd);
>>   denali_irq_cleanup(denali->irq, denali);
>> - dma_unmap_single(denali->dev, denali->buf.dma_buf,
>> -  denali->mtd.writesize + denali->mtd.oobsize,
>> + dma_unmap_single(denali->dev, denali->buf.dma_buf, bufsize,
>>DMA_BIDIRECTIONAL);

Not sure what is the need to add bufsize here, but the commit message
doesn't reflect the change.

Dinh
--
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] clk: ti: omap5+: dpll: implement errata i810

[Tony Lindgren]

* Tero Kristo  [151211 00:42]:
> On 12/03/2015 06:48 PM, Tony Lindgren wrote:
> >* Tero Kristo  [151130 06:44]:
> >>+   /*
> >>+* Errata i810 - DPLL controller can get stuck while transitioning
> >>+* to a power saving state. Software must ensure the DPLL can not
> >>+* transition to a low power state while changing M/N values.
> >>+* Easiest way to accomplish this is to prevent DPLL autoidle
> >>+* before doing the M/N re-program.
> >>+*/
> >>+   errata_i810 = ti_clk_get_features()->flags & TI_CLK_ERRATA_I810;
> >>+
> >>+   if (errata_i810) {
> >>+   ai = omap3_dpll_autoidle_read(clk);
> >>+   if (ai) {
> >>+   omap3_dpll_deny_idle(clk);
> >>+
> >>+   /* OCP barrier */
> >>+   omap3_dpll_autoidle_read(clk);
> >>+   }
> >>+   }
> >
> >Should we just do this unconditionally? It seems like disabling the
> >autoidle always before reprogramming is a good idea.
> 
> Well, that is a few extra register accesses, but given the DPLL
> re-programming is a slow operation it probably does not matter. Let me spin
> a new version of this patch, it will avoid the need for the errata flag
> also.

OK thanks,

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] clk: ti: Add support for dm814x ADPLL

[Tony Lindgren]

* Tero Kristo  [151210 23:45]:
> On 12/11/2015 04:26 AM, Tony Lindgren wrote:
> 
> Looks mostly good to me, added some minor comments inline below. Sorry again
> for latencies in my replies.

No problme, thanks for looking.

> >+static bool ti_adpll_clock_is_bypass(struct ti_adpll_data *d)
> >+{
> >+unsigned long flags;
> >+u32 v;
> >+
> >+spin_lock_irqsave(>lock, flags);
> >+v = readl_relaxed(d->status);
> >+spin_unlock_irqrestore(>lock, flags);
> 
> What do you need the lock for in here?

Yeah seems pointless, will remove.

> >+static int ti_adpll_clkout_set_parent(struct clk_hw *hw, u8 index)
> >+{
> >+struct ti_adpll_clkout_data *co = to_clkout(hw);
> >+struct ti_adpll_data *d = co->adpll;
> >+
> >+return ti_adpll_clock_is_bypass(d) == index;

Hmm yeah that seems broken. I need to check what all really goes
to bypass mode with ulowclken signal.

> What is the point of this? It doesn't seem to set anything.

> >+/* Internal mux, sources sources from DCO and clkinphf */
> 
> Double "sources" in comment?
> 
> >+/* Output clkout clkout, sources M2 or ulow */
> 
> Double "clkout" in comment?

Oops will fix.

> >+d->pwrctrl = d->base + register_offset + ADPLL_PWRCTRL_OFFSET;
> >+d->clkctrl = d->base + register_offset + ADPLL_CLKCTRL_OFFSET;
> >+d->tenable = d->base + register_offset + ADPLL_TENABLE_OFFSET;
> >+d->tenablediv = d->base + register_offset + ADPLL_TENABLEDIV_OFFSET;
> >+d->m2ndiv = d->base + register_offset + ADPLL_M2NDIV_OFFSET;
> >+d->mn2div = d->base + register_offset + ADPLL_MN2DIV_OFFSET;
> >+d->fracdiv = d->base + register_offset + ADPLL_FRACDIV_OFFSET;
> >+d->bwctrl = d->base + register_offset + ADPLL_BWCTRL_OFFSET;
> >+d->status = d->base + register_offset + ADPLL_STATUS_OFFSET;
> >+d->m3div = d->base + register_offset + ADPLL_M3DIV_OFFSET;
> >+d->rampctrl = d->base + register_offset + ADPLL_RAMPCTRL_OFFSET;
> 
> Do you need the individual pointers to each of these registers within the
> struct? Seems the offsets are pretty static so could just use d->base +
> offset + MAGIC calculation where used.
> 
> Most of these registers are not used for anything either at the moment it
> seems.

Well I guess I was initially thinking that we can set up separate instances
for the children and don't need locking for the registers.. But all of them
really share the clkctl register so that did not work out.

Yeah I can change these to use offsets no problem.

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] clk: ti: Add support for dm814x ADPLL

[Russell King - ARM Linux]

On Fri, Dec 11, 2015 at 07:48:54AM -0800, Tony Lindgren wrote:
> There's a problem with MAX_CON_ID 16 hardcoded allocated name length.

Absolutely right...

> In this case I have 13 instances of plls with 3 - 4 outputs each and I'd
> like to use "481c5040.adpll.clkout" style naming starting with the instance
> address. Also "adpll5.clkdcoldo" style naming would work,

Because it's a connection ID, not a clock _name_.  I see that we're still
making all the same mistakes with clocks that were made years ago, and
which lead down the path of amazingly complex drivers having conditional
clock names and the like.

Is there a reason why you can't split this into separate device and input
names, and use clk_get_sys() rather than passing NULL as the device to
clk_get().  This is exactly why we've ended up with clk_get_sys(), to
cater for the cases where there is no struct device to associate with the
connection ID: the idea behind clk_get_sys() is that you pass the device
name explicitly, along with the connection ID.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
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] clk: ti: Add support for dm814x ADPLL

[Tony Lindgren]

* Russell King - ARM Linux  [151211 08:16]:
> On Fri, Dec 11, 2015 at 07:48:54AM -0800, Tony Lindgren wrote:
> > There's a problem with MAX_CON_ID 16 hardcoded allocated name length.
> 
> Absolutely right...

Well adding the warning there allows people to at least see what's going
on.

> > In this case I have 13 instances of plls with 3 - 4 outputs each and I'd
> > like to use "481c5040.adpll.clkout" style naming starting with the instance
> > address. Also "adpll5.clkdcoldo" style naming would work,
> 
> Because it's a connection ID, not a clock _name_.  I see that we're still
> making all the same mistakes with clocks that were made years ago, and
> which lead down the path of amazingly complex drivers having conditional
> clock names and the like.

Yeah we certainly want to get out of the conditional name business.

> Is there a reason why you can't split this into separate device and input
> names, and use clk_get_sys() rather than passing NULL as the device to
> clk_get().  This is exactly why we've ended up with clk_get_sys(), to
> cater for the cases where there is no struct device to associate with the
> connection ID: the idea behind clk_get_sys() is that you pass the device
> name explicitly, along with the connection ID.

For most code yes, there's still a pile of shared legacy code relying on
the clock connection ID only.

So what do you envision people using for the connection ID in cases like
this? It needs to be unique, should relate to the documentation and fit
MAX_CON_ID. Something like "pll5.clkdcoldo" will still overflow for pll13
unless also the dot is left out :)

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 2/2] gpio: omap: convert to use generic irq handler

[Sebastian Andrzej Siewior]

* Grygorii Strashko | 2015-10-15 19:33:43 [+0300]:

>Hi Thomas,
>
>On 10/13/2015 09:33 PM, Thomas Gleixner wrote:
>>Grygorii,
>>
>>On Tue, 13 Oct 2015, Grygorii Strashko wrote:
>>>I'd very appreciate for any advice of how to better proceed with your 
>>>request.
>>>  - I can try to apply and re-send only patches marked by '*'
>>>  - I can prepare branch with all above patches
>>
>>Please provide a branch on top of 4.1.10 which contains the whole
>>lot. I have a look at it and decide then how to go from there.
>
>I've prepared branch linux-4.1.10-ti-gpio:
>in g...@git.ti.com:~gragst/ti-linux-kernel/gragsts-ti-linux-kernel.git

could you please provide a git URL for that?

>based on top of
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
> branch : linux-4.1.y
> commit : 27f1b7f Linux 4.1.10

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

Re: [PATCH 1/2] regulator: tps65917: Add bypass ops for ldo1 and ldo2 regulators

[Nishanth Menon]

On 12/11/2015 12:28 AM, Keerthy wrote:
> set/get_bypass ops were missing for ldo1/ldo2 regulators which
> support bypass mode. Adding the bypass ops for ldo1 and ldo2.
> This helps consumers configure ldo1 and ldo2 in bypass mode or
> remove bypass mode if need be.
> 
> Signed-off-by: Keerthy 
> Reported-by: Kishon Vijay Abraham I 
> ---
>  drivers/regulator/palmas-regulator.c | 20 
>  1 file changed, 20 insertions(+)
> 
> diff --git a/drivers/regulator/palmas-regulator.c 
> b/drivers/regulator/palmas-regulator.c
> index 8217613..776b59a 100644
> --- a/drivers/regulator/palmas-regulator.c
> +++ b/drivers/regulator/palmas-regulator.c
> @@ -389,6 +389,7 @@ static unsigned int palmas_smps_ramp_delay[4] = {0, 
> 1, 5000, 2500};
>  #define SMPS10_BOOST_EN  (1<<2)
>  #define SMPS10_BYPASS_EN (1<<1)
>  #define SMPS10_SWITCH_EN (1<<0)
> +#define TPS65917_LDO_1_2_BYPASS_EN   BIT(6)


This also applies to TWL6035/37, TPS659038 LDO9 as well.
why not do it for all? considering the bit definition is the same as well?

>  
>  #define REGULATOR_SLAVE  0
>  
> @@ -639,6 +640,19 @@ static struct regulator_ops tps65917_ops_ldo = {
>   .set_voltage_time_sel   = regulator_set_voltage_time_sel,
>  };
>  
> +static struct regulator_ops tps65917_ops_ldo_1_2 = {
> + .is_enabled = palmas_is_enabled_ldo,
> + .enable = regulator_enable_regmap,
> + .disable= regulator_disable_regmap,
> + .get_voltage_sel= regulator_get_voltage_sel_regmap,
> + .set_voltage_sel= regulator_set_voltage_sel_regmap,
> + .list_voltage   = regulator_list_voltage_linear,
> + .map_voltage= regulator_map_voltage_linear,
> + .set_voltage_time_sel   = regulator_set_voltage_time_sel,
> + .set_bypass = regulator_set_bypass_regmap,
> + .get_bypass = regulator_get_bypass_regmap,
> +};
> +
>  static int palmas_regulator_config_external(struct palmas *palmas, int id,
>   struct palmas_reg_init *reg_init)
>  {
> @@ -1019,6 +1033,12 @@ static int tps65917_ldo_registration(struct 
> palmas_pmic *pmic,
>* It is of the order of ~60mV/uS.
>*/
>   desc->ramp_delay = 2500;
> + if (id == TPS65917_REG_LDO1 ||
> + id == TPS65917_REG_LDO2) {
> + desc->ops = _ops_ldo_1_2;
> + desc->bypass_reg = desc->enable_reg;
> + desc->bypass_mask = TPS65917_LDO_1_2_BYPASS_EN;
> + }
>   } else {
>   desc->n_voltages = 1;
>   if (reg_init && reg_init->roof_floor)
> 


-- 
Regards,
Nishanth Menon
--
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 v5 01/58] mtd: nand: denali: add missing nand_release() call in denali_remove()

[Boris Brezillon]

Hi Dinh,

On Fri, 11 Dec 2015 10:50:21 -0600
Dinh Nguyen  wrote:

> Hi Boris,
> 
> On Fri, Dec 11, 2015 at 9:10 AM, Boris Brezillon
>  wrote:
> > + Dinh (who made commit 2a0a288ec258)
> >
> > Also added back the Fixes tag.
> >
> > On Fri, 11 Dec 2015 15:02:34 +0100
> > Boris Brezillon  wrote:
> >
> >> Unregister the NAND device from the NAND subsystem when removing a denali
> >> NAND controller, otherwise the MTD attached to the NAND device is still
> >> exposed by the MTD layer, and accesses to this device will likely crash
> >> the system.
> >>
> >> Signed-off-by: Boris Brezillon 
> >
> > Fixes: 2a0a288ec258 ("mtd: denali: split the generic driver and PCI layer")
> >
> >> ---
> >> Changes since v4:
> >> - remove Cc stable and fixes tags
> >> - calculate the dma buffer size before calling nand_release()
> >>
> >>  drivers/mtd/nand/denali.c | 6 --
> >>  1 file changed, 4 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c
> >> index 67eb2be..fdfea05 100644
> >> --- a/drivers/mtd/nand/denali.c
> >> +++ b/drivers/mtd/nand/denali.c
> >> @@ -1622,9 +1622,11 @@ EXPORT_SYMBOL(denali_init);
> >>  /* driver exit point */
> >>  void denali_remove(struct denali_nand_info *denali)
> >>  {
> >> + int bufsize = denali->mtd.writesize + denali->mtd.oobsize;
> >> +
> >> + nand_release(>mtd);
> >>   denali_irq_cleanup(denali->irq, denali);
> >> - dma_unmap_single(denali->dev, denali->buf.dma_buf,
> >> -  denali->mtd.writesize + denali->mtd.oobsize,
> >> + dma_unmap_single(denali->dev, denali->buf.dma_buf, bufsize,
> >>DMA_BIDIRECTIONAL);
> 
> Not sure what is the need to add bufsize here, but the commit message
> doesn't reflect the change.

You were not in Cc of the first version (my fault), but Brian pointed
that the mtd fields could be in an unknown state after the
nand_release() call (this is currently not the case, but it change in
the future). The idea is to pre-compute the DMA buffer size before
releasing the mtd/nand device to prevent any future issues.

I don't think it is worth mentioning this in the commit message,
because these are just implementation details, but I can add the
following comment before the bufsize declaration:

/*
 * Pre-compute DMA buffer size to avoid any problems in case
 * nand_release() ever changes in a way that mtd->writesize and
 * mtd->oobsize are not reliable after this call.
 */

What do you think?

Best Regards,

Boris

> 
> Dinh



-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
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 v5 4/5] ARM: dts: DRA7: add entry for qspi mmap region

[Rob Herring]

On Fri, Dec 11, 2015 at 09:39:59AM +0530, Vignesh R wrote:
> Add qspi memory mapped region entries for DRA7xx based SoCs. Also,
> update the binding documents for the controller to document this change.
> 
> Signed-off-by: Vignesh R 

Acked-by: Rob Herring 

> ---
> 
> v5: use syscon to access scm register.
> 
>  Documentation/devicetree/bindings/spi/ti_qspi.txt | 17 +
>  arch/arm/boot/dts/dra7.dtsi   |  6 --
>  2 files changed, 21 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/spi/ti_qspi.txt 
> b/Documentation/devicetree/bindings/spi/ti_qspi.txt
> index 601a360531a5..809c3f334316 100644
> --- a/Documentation/devicetree/bindings/spi/ti_qspi.txt
> +++ b/Documentation/devicetree/bindings/spi/ti_qspi.txt
> @@ -15,6 +15,10 @@ Recommended properties:
>  - spi-max-frequency: Definition as per
>   Documentation/devicetree/bindings/spi/spi-bus.txt
>  
> +Optional properties:
> +- syscon-chipselects: Handle to system control region contains QSPI
> +   chipselect register and offset of that register.
> +
>  Example:
>  
>  qspi: qspi@4b30 {
> @@ -26,3 +30,16 @@ qspi: qspi@4b30 {
>   spi-max-frequency = <2500>;
>   ti,hwmods = "qspi";
>  };
> +
> +For dra7xx:
> +qspi: qspi@4b30 {
> + compatible = "ti,dra7xxx-qspi";
> + reg = <0x4b30 0x100>,
> +   <0x5c00 0x400>,
> + reg-names = "qspi_base", "qspi_mmap";
> + syscon-chipselects = <_conf 0x558>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + spi-max-frequency = <4800>;
> + ti,hwmods = "qspi";
> +};
> diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
> index fe99231cbde5..be91c7781c07 100644
> --- a/arch/arm/boot/dts/dra7.dtsi
> +++ b/arch/arm/boot/dts/dra7.dtsi
> @@ -1153,8 +1153,10 @@
>  
>   qspi: qspi@4b30 {
>   compatible = "ti,dra7xxx-qspi";
> - reg = <0x4b30 0x100>;
> - reg-names = "qspi_base";
> + reg = <0x4b30 0x100>,
> +   <0x5c00 0x400>;
> + reg-names = "qspi_base", "qspi_mmap";
> + syscon-chipselects = <_conf 0x558>;
>   #address-cells = <1>;
>   #size-cells = <0>;
>   ti,hwmods = "qspi";
> -- 
> 2.6.3
> 
--
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 v5 01/58] mtd: nand: denali: add missing nand_release() call in denali_remove()

[Boris Brezillon]

+ Dinh (who made commit 2a0a288ec258)

Also added back the Fixes tag.

On Fri, 11 Dec 2015 15:02:34 +0100
Boris Brezillon  wrote:

> Unregister the NAND device from the NAND subsystem when removing a denali
> NAND controller, otherwise the MTD attached to the NAND device is still
> exposed by the MTD layer, and accesses to this device will likely crash
> the system.
> 
> Signed-off-by: Boris Brezillon 

Fixes: 2a0a288ec258 ("mtd: denali: split the generic driver and PCI layer")

> ---
> Changes since v4:
> - remove Cc stable and fixes tags
> - calculate the dma buffer size before calling nand_release()
> 
>  drivers/mtd/nand/denali.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c
> index 67eb2be..fdfea05 100644
> --- a/drivers/mtd/nand/denali.c
> +++ b/drivers/mtd/nand/denali.c
> @@ -1622,9 +1622,11 @@ EXPORT_SYMBOL(denali_init);
>  /* driver exit point */
>  void denali_remove(struct denali_nand_info *denali)
>  {
> + int bufsize = denali->mtd.writesize + denali->mtd.oobsize;
> +
> + nand_release(>mtd);
>   denali_irq_cleanup(denali->irq, denali);
> - dma_unmap_single(denali->dev, denali->buf.dma_buf,
> -  denali->mtd.writesize + denali->mtd.oobsize,
> + dma_unmap_single(denali->dev, denali->buf.dma_buf, bufsize,
>DMA_BIDIRECTIONAL);
>  }
>  EXPORT_SYMBOL(denali_remove);



-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
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 01/58] mtd: nand: denali: add missing nand_release() call in denali_remove()

[Boris Brezillon]

Hi Dan,

On Fri, 11 Dec 2015 17:39:47 +0300
Dan Carpenter  wrote:

> On Fri, Dec 11, 2015 at 02:53:20PM +0100, Boris Brezillon wrote:
> > Hi Brian,
> > 
> > On Thu, 10 Dec 2015 16:40:08 -0800
> > Brian Norris  wrote:
> > 
> > > On Thu, Dec 10, 2015 at 08:59:45AM +0100, Boris Brezillon wrote:
> > > > Unregister the NAND device from the NAND subsystem when removing a 
> > > > denali
> > > > NAND controller, otherwise the MTD attached to the NAND device is still
> > > > exposed by the MTD layer, and accesses to this device will likely crash
> > > > the system.
> > > > 
> > > > Signed-off-by: Boris Brezillon 
> > > > Cc:  #3.8+
> > > 
> > > Does this follow these rules, from
> > > Documentation/stable_kernel_rules.txt?
> > > 
> > >  - It must be obviously correct and tested.
> > > 
> > >  - It must fix a real bug that bothers people (not a, "This could be a
> > >problem..." type thing).
> > 
> > As you wish, I'll remove those Cc and Fixes tags, or just drop the
> > patch if you think it's useless...
> 
> The fixes tag is a separate thing from CCing stable.  It's useful on by
> itself.  I always put the person who wrote the original patch in the To:
> header so they can review and comment if I have made a mistake.

Noted. I added back the Fixes tag and added Dinh Nguyen (the commit
author) in the loop.

Thanks,

Boris

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
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] clk: ti: Add support for dm814x ADPLL

[Tony Lindgren]

* Russell King - ARM Linux  [151211 05:53]:
> On Thu, Dec 10, 2015 at 06:26:32PM -0800, Tony Lindgren wrote:
> > +   /* Released with kfree() by clkdev_drop() */
> > +   cl = kzalloc(sizeof(*cl), GFP_KERNEL);
> > +   if (!cl)
> > +   return -ENOMEM;
> > +
> > +   /* Use clkdev_add, clk_register_clkdev limits length to MAX_CON_ID */
> > +   cl->con_id = name;
> > +   cl->clk = clock;
> > +   cl->clk_hw = __clk_get_hw(clock);
> > +   clkdev_add(cl);
> > +   d->clocks[index].cl = cl;
> 
> NAK.  I've no idea why you're open-coding the clkdev internals (which
> seems to have been a historical habbit in OMAP code.)  Please stop
> doing this.
>
> You are provided with clkdev_alloc() which will allocate the structure
> and initialise it for you, and clkdev_add() which will add the allocated
> and initialised struct to the list of lookups.  Everything you're doing
> above can be done with clkdev_alloc() + clkdev_add() which have been
> there for a _very_ long time.  They're even documented (thanks for
> providing me with more proof that documentation is nothing but a waste
> of time. :))

I tried, but I was seeing mysterious silent failures for some clocks.

> Even better is clkdev_create() which eliminates the two step clkdev_alloc()
> and clkdev_add() process.
> 
> So, the whole of the above can be reduced down to:
> 
>   cl = clkdev_create(clock, name, NULL);
>   if (!cl)
>   return -ENOMEM;
> 

There's a problem with MAX_CON_ID 16 hardcoded allocated name length.

In this case I have 13 instances of plls with 3 - 4 outputs each and I'd
like to use "481c5040.adpll.clkout" style naming starting with the instance
address. Also "adpll5.clkdcoldo" style naming would work,

Below is a patch we should probably apply as a band aid to produce a proper
warning.

Naturally we don't want to allocate longer names for all the clocks.. And
we already do have some const names coming from device tree we could use.

What if we optionally allow passing a name to clkdev and add some flag
that tells clkdev code not to attempt to free it? Or do you have better
ideas in mind to fix the issue?

Regards,

Tony

8< 
From: Tony Lindgren 
Date: Fri, 11 Dec 2015 07:28:36 -0800
Subject: [PATCH] clkdev: Make silent failures of clk_get() produce a proper
 warning

Otherwise we can see mysterious failures with some clocks where
the name is longer than MAX_CON_ID 16. This can easily happen with
clock names coming from device tree for example in the form of
"481c5040.adpll.clkout" or "adpll1.clkdcoldo".

Let's make things a bit easier to debug by adding a warning for
the clock name. Note that we don't want to error out here as the
string matching still probably does the right thing for most
clocks.

Also note that we should also remove the hardcoded name allocation
in clkdev by adding functions that allow passing a name to clkdev
optionally.

Signed-off-by: Tony Lindgren 

--- a/drivers/clk/clkdev.c
+++ b/drivers/clk/clkdev.c
@@ -256,6 +256,10 @@ vclkdev_alloc(struct clk_hw *hw, const char *con_id, const 
char *dev_fmt,
 {
struct clk_lookup_alloc *cla;
 
+   if (strlen(con_id) > MAX_CON_ID)
+   pr_warn("%s length of %s > %i, clock lookup can fail\n",
+   __func__, con_id, MAX_CON_ID);
+
cla = __clkdev_alloc(sizeof(*cla));
if (!cla)
return NULL;
--
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: [GIT PULL 2/2] omap device tree changes for v4.5, part 1

[Arnd Bergmann]

On Thursday 10 December 2015 16:03:09 Tony Lindgren wrote:
> Device tree changes for omaps for v4.5 merge window:
> 
> - Update all omaps to use pinctrl macros. This makes comparing the pinmux
>   settings against the documentation much earlier. Javier compared the
>   checksums of the generated dtb files to make sure nothing changed for
>   the dtb files.
> 
> - Updates for dm816x
> 
> - Add GPMC DMA channels for am437x
> 
> - Updates for LogicPD Torpedo
> 
> - Basic support for CompuLab cm-t335
> 
> - Remove tps65217.dtsi file, we're better off adding SoC generic board
>   dtsi files for the common features
> 
> - Add support for ELM on am33xx
> 
> - Add support for Bosch shc c3 board
> 
> - Add qspi aliases for am437x and dra7
> 
> - Wake-up support for dra7-evm uart1
> 
> - Basic support for CompuLab sbc-t43
> 
> - Basic support for CompuLab cl-som-am57x
> 
> - Use MMC pwrseq for libertas WLAN on igep0020 and igep0030

Pulled into next/dt, thanks!

Arnd
--
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 01/58] mtd: nand: denali: add missing nand_release() call in denali_remove()

[Brian Norris]

Hi Boris,

On Fri, Dec 11, 2015 at 11:03:05PM +0100, Boris Brezillon wrote:
> On Thu, 10 Dec 2015 16:40:08 -0800
> Brian Norris  wrote:
> > On Thu, Dec 10, 2015 at 08:59:45AM +0100, Boris Brezillon wrote:
> > > Unregister the NAND device from the NAND subsystem when removing a denali
> > > NAND controller, otherwise the MTD attached to the NAND device is still
> > > exposed by the MTD layer, and accesses to this device will likely crash
> > > the system.
> > > 
> > > Signed-off-by: Boris Brezillon 
> > > Cc:  #3.8+
> > 
> > Does this follow these rules, from
> > Documentation/stable_kernel_rules.txt?
> > 
> >  - It must be obviously correct and tested.
> > 
> >  - It must fix a real bug that bothers people (not a, "This could be a
> >problem..." type thing).
> 
> Sorry to bring the "stable or not stable (that is the question :-))"
> debate back, but after thinking a bit more about the implications of
> this missing nand_release() call, I think it is worth backporting the
> fix to all stable kernels.
> The reason is, it can potentially introduce a security hole, because if
> the mtd device is not unregister but the underlying mtd object is freed
> and the kernel reuses the same memory region for a different object,
> the MTD layer will possibly call one of the mtd->_method() function,
> and this field might point to another completely different function.
> 
> You'll say that denali devices are probably never removed and this is
> the reason why people have never seen this problem before, which would
> be a good reason to not bother backporting the patch.
> But, given that the driver can be compiled as a module (the user can
> possibly load/unload it, which will in turn create/destroy the
> NAND/MTD device), and that the denali controller can be exposed through
> a PCI bus (which, AFAIK is hotpluggable), I really think this fix
> should be sent to stable.

That's all well and good, but still nobody has told me they've tested
this.

I've pushed your v5 (+ comments, + ack) to l2-mtd.git. If it gets
testing and this request is made again at that point, we can easily send
it to stable after it hits Linus' tree. See option 2 in
Documentation/stable_kernel_rules.txt. You can even send the email
yourself, just CC me and anyone else relevant. I'll ack it if it's been
tested.

Regards,
Brian
--
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 01/58] mtd: nand: denali: add missing nand_release() call in denali_remove()

[Boris Brezillon]

Hi Brian,

On Thu, 10 Dec 2015 16:40:08 -0800
Brian Norris  wrote:

> On Thu, Dec 10, 2015 at 08:59:45AM +0100, Boris Brezillon wrote:
> > Unregister the NAND device from the NAND subsystem when removing a denali
> > NAND controller, otherwise the MTD attached to the NAND device is still
> > exposed by the MTD layer, and accesses to this device will likely crash
> > the system.
> > 
> > Signed-off-by: Boris Brezillon 
> > Cc:  #3.8+
> 
> Does this follow these rules, from
> Documentation/stable_kernel_rules.txt?
> 
>  - It must be obviously correct and tested.
> 
>  - It must fix a real bug that bothers people (not a, "This could be a
>problem..." type thing).

Sorry to bring the "stable or not stable (that is the question :-))"
debate back, but after thinking a bit more about the implications of
this missing nand_release() call, I think it is worth backporting the
fix to all stable kernels.
The reason is, it can potentially introduce a security hole, because if
the mtd device is not unregister but the underlying mtd object is freed
and the kernel reuses the same memory region for a different object,
the MTD layer will possibly call one of the mtd->_method() function,
and this field might point to another completely different function.

You'll say that denali devices are probably never removed and this is
the reason why people have never seen this problem before, which would
be a good reason to not bother backporting the patch.
But, given that the driver can be compiled as a module (the user can
possibly load/unload it, which will in turn create/destroy the
NAND/MTD device), and that the denali controller can be exposed through
a PCI bus (which, AFAIK is hotpluggable), I really think this fix
should be sent to stable.

Best Regards,

Boris

> 
> > Fixes: 2a0a288ec258 ("mtd: denali: split the generic driver and PCI layer")
> > ---
> >  drivers/mtd/nand/denali.c | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c
> > index 67eb2be..8feece3 100644
> > --- a/drivers/mtd/nand/denali.c
> > +++ b/drivers/mtd/nand/denali.c
> > @@ -1622,6 +1622,7 @@ EXPORT_SYMBOL(denali_init);
> >  /* driver exit point */
> >  void denali_remove(struct denali_nand_info *denali)
> >  {
> > +   nand_release(>mtd);
> > denali_irq_cleanup(denali->irq, denali);
> > dma_unmap_single(denali->dev, denali->buf.dma_buf,
> >  denali->mtd.writesize + denali->mtd.oobsize,
> 
> It feels a bit odd to allow usage of MTD fields after it has been
> unregistered. Maybe precompute this before the nand_release()?
> 
> Brian



-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
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] mtd: omap_elm: print interrupt resource using %pr

[Brian Norris]

Hi Arnd,

On Tue, Dec 08, 2015 at 04:39:45PM +0100, Arnd Bergmann wrote:
> When CONFIG_LPAE is set on ARM, resource_size_t is 64-bit wide
> and we get a warning about an incorrect format string for printing
> the interrupt number in elm_probe:
> 
> drivers/mtd/nand/omap_elm.c: In function 'elm_probe':
> drivers/mtd/nand/omap_elm.c:417:23: warning: format '%i' expects argument of 
> type 'int', but argument 3 has type 'resource_size_t {aka long long unsigned 
> int}' [-Wformat=]
> 
> This patch avoids the type mismatch by printing the interrupt as
> a resource using the %pr format string.
> 
> Signed-off-by: Arnd Bergmann 
> ---
>  drivers/mtd/nand/omap_elm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/mtd/nand/omap_elm.c b/drivers/mtd/nand/omap_elm.c
> index 235ec7992b4c..11f174b07217 100644
> --- a/drivers/mtd/nand/omap_elm.c
> +++ b/drivers/mtd/nand/omap_elm.c
> @@ -414,7 +414,7 @@ static int elm_probe(struct platform_device *pdev)
>   ret = devm_request_irq(>dev, irq->start, elm_isr, 0,
>   pdev->name, info);
>   if (ret) {
> - dev_err(>dev, "failure requesting irq %i\n", irq->start);
> + dev_err(>dev, "failure requesting %pr\n", );

drivers/mtd/nand/omap_elm.c:417 elm_probe() error: '%pr' expects argument of 
type struct resource *, but argument 3 has type 'struct resource**' [smatch]

>   return ret;
>   }
>  

Brian
--
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 v5 01/58] mtd: nand: denali: add missing nand_release() call in denali_remove()

[Dinh Nguyen]

On Fri, Dec 11, 2015 at 11:08 AM, Boris Brezillon
 wrote:
> Hi Dinh,
>
> On Fri, 11 Dec 2015 10:50:21 -0600
> Dinh Nguyen  wrote:
>
>> Hi Boris,
>>
>> On Fri, Dec 11, 2015 at 9:10 AM, Boris Brezillon
>>  wrote:
>> > + Dinh (who made commit 2a0a288ec258)
>> >
>> > Also added back the Fixes tag.
>> >
>> > On Fri, 11 Dec 2015 15:02:34 +0100
>> > Boris Brezillon  wrote:
>> >
>> >> Unregister the NAND device from the NAND subsystem when removing a denali
>> >> NAND controller, otherwise the MTD attached to the NAND device is still
>> >> exposed by the MTD layer, and accesses to this device will likely crash
>> >> the system.
>> >>
>> >> Signed-off-by: Boris Brezillon 
>> >
>> > Fixes: 2a0a288ec258 ("mtd: denali: split the generic driver and PCI layer")
>> >
>> >> ---
>> >> Changes since v4:
>> >> - remove Cc stable and fixes tags
>> >> - calculate the dma buffer size before calling nand_release()
>> >>
>> >>  drivers/mtd/nand/denali.c | 6 --
>> >>  1 file changed, 4 insertions(+), 2 deletions(-)
>> >>
>> >> diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c
>> >> index 67eb2be..fdfea05 100644
>> >> --- a/drivers/mtd/nand/denali.c
>> >> +++ b/drivers/mtd/nand/denali.c
>> >> @@ -1622,9 +1622,11 @@ EXPORT_SYMBOL(denali_init);
>> >>  /* driver exit point */
>> >>  void denali_remove(struct denali_nand_info *denali)
>> >>  {
>> >> + int bufsize = denali->mtd.writesize + denali->mtd.oobsize;
>> >> +
>> >> + nand_release(>mtd);
>> >>   denali_irq_cleanup(denali->irq, denali);
>> >> - dma_unmap_single(denali->dev, denali->buf.dma_buf,
>> >> -  denali->mtd.writesize + denali->mtd.oobsize,
>> >> + dma_unmap_single(denali->dev, denali->buf.dma_buf, bufsize,
>> >>DMA_BIDIRECTIONAL);
>>
>> Not sure what is the need to add bufsize here, but the commit message
>> doesn't reflect the change.
>
> You were not in Cc of the first version (my fault), but Brian pointed
> that the mtd fields could be in an unknown state after the
> nand_release() call (this is currently not the case, but it change in
> the future). The idea is to pre-compute the DMA buffer size before
> releasing the mtd/nand device to prevent any future issues.
>
> I don't think it is worth mentioning this in the commit message,
> because these are just implementation details, but I can add the
> following comment before the bufsize declaration:
>
> /*
>  * Pre-compute DMA buffer size to avoid any problems in case
>  * nand_release() ever changes in a way that mtd->writesize and
>  * mtd->oobsize are not reliable after this call.
>  */
>
> What do you think?
>

Ah, perfect! With the updated comment,

Acked-by: Dinh Nguyen 

Thanks,
Dinh
--
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: OMAP2+: Remove device creation for omap-pcm-audio

[Peter Ujfalusi]

The omap-pcm in ASoC is no longer a platform device. No need to create this
device anymore.

Signed-off-by: Peter Ujfalusi 
---
 arch/arm/mach-omap2/devices.c | 25 -
 1 file changed, 4 insertions(+), 21 deletions(-)

diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 9374da313e8e..9cda974a3009 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -94,22 +94,6 @@ static inline void omap_init_mbox(void) { }
 
 static inline void omap_init_sti(void) {}
 
-#if defined(CONFIG_SND_SOC) || defined(CONFIG_SND_SOC_MODULE)
-
-static struct platform_device omap_pcm = {
-   .name   = "omap-pcm-audio",
-   .id = -1,
-};
-
-static void omap_init_audio(void)
-{
-   platform_device_register(_pcm);
-}
-
-#else
-static inline void omap_init_audio(void) {}
-#endif
-
 #if defined(CONFIG_SPI_OMAP24XX) || defined(CONFIG_SPI_OMAP24XX_MODULE)
 
 #include 
@@ -239,13 +223,12 @@ static int __init omap2_init_devices(void)
if (!of_have_populated_dt())
pinctrl_provide_dummies();
 
-   /*
-* please keep these calls, and their implementations above,
-* in alphabetical order so they're easier to sort through.
-*/
-   omap_init_audio();
/* If dtb is there, the devices will be created dynamically */
if (!of_have_populated_dt()) {
+   /*
+* please keep these calls, and their implementations above,
+* in alphabetical order so they're easier to sort through.
+*/
omap_init_mbox();
omap_init_mcspi();
omap_init_sham();
-- 
2.6.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 0/2] ARM: OMAP1/2+: DO not create omap-pcm-audio device

[Peter Ujfalusi]

Hi,

The ASoC omap-pcm has been converted to be non platform device a long time ago,
so it is no longer needed to create the device for it since there will be no
driver to be loaded for it.

Regards,
Peter
---
Peter Ujfalusi (2):
  ARM: OMAP1: Remove device creation for omap-pcm-audio
  ARM: OMAP2+: Remove device creation for omap-pcm-audio

 arch/arm/mach-omap1/devices.c | 19 ---
 arch/arm/mach-omap2/devices.c | 25 -
 2 files changed, 4 insertions(+), 40 deletions(-)

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

Re: [PATCH v2] clk: ti: Add support for dm814x ADPLL

[Russell King - ARM Linux]

On Thu, Dec 10, 2015 at 06:26:32PM -0800, Tony Lindgren wrote:
> + /* Released with kfree() by clkdev_drop() */
> + cl = kzalloc(sizeof(*cl), GFP_KERNEL);
> + if (!cl)
> + return -ENOMEM;
> +
> + /* Use clkdev_add, clk_register_clkdev limits length to MAX_CON_ID */
> + cl->con_id = name;
> + cl->clk = clock;
> + cl->clk_hw = __clk_get_hw(clock);
> + clkdev_add(cl);
> + d->clocks[index].cl = cl;

NAK.  I've no idea why you're open-coding the clkdev internals (which
seems to have been a historical habbit in OMAP code.)  Please stop
doing this.

You are provided with clkdev_alloc() which will allocate the structure
and initialise it for you, and clkdev_add() which will add the allocated
and initialised struct to the list of lookups.  Everything you're doing
above can be done with clkdev_alloc() + clkdev_add() which have been
there for a _very_ long time.  They're even documented (thanks for
providing me with more proof that documentation is nothing but a waste
of time. :))

Even better is clkdev_create() which eliminates the two step clkdev_alloc()
and clkdev_add() process.

So, the whole of the above can be reduced down to:

cl = clkdev_create(clock, name, NULL);
if (!cl)
return -ENOMEM;

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
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 01/58] mtd: nand: denali: add missing nand_release() call in denali_remove()

[Boris Brezillon]

Hi Brian,

On Thu, 10 Dec 2015 16:40:08 -0800
Brian Norris  wrote:

> On Thu, Dec 10, 2015 at 08:59:45AM +0100, Boris Brezillon wrote:
> > Unregister the NAND device from the NAND subsystem when removing a denali
> > NAND controller, otherwise the MTD attached to the NAND device is still
> > exposed by the MTD layer, and accesses to this device will likely crash
> > the system.
> > 
> > Signed-off-by: Boris Brezillon 
> > Cc:  #3.8+
> 
> Does this follow these rules, from
> Documentation/stable_kernel_rules.txt?
> 
>  - It must be obviously correct and tested.
> 
>  - It must fix a real bug that bothers people (not a, "This could be a
>problem..." type thing).

As you wish, I'll remove those Cc and Fixes tags, or just drop the
patch if you think it's useless...
I just noticed the bug while reworking this series, and thought it
would be useful to fix it, but I honestly don't care if it's applied
or not (I don't use this platform).

> 
> > Fixes: 2a0a288ec258 ("mtd: denali: split the generic driver and PCI layer")
> > ---
> >  drivers/mtd/nand/denali.c | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c
> > index 67eb2be..8feece3 100644
> > --- a/drivers/mtd/nand/denali.c
> > +++ b/drivers/mtd/nand/denali.c
> > @@ -1622,6 +1622,7 @@ EXPORT_SYMBOL(denali_init);
> >  /* driver exit point */
> >  void denali_remove(struct denali_nand_info *denali)
> >  {
> > +   nand_release(>mtd);
> > denali_irq_cleanup(denali->irq, denali);
> > dma_unmap_single(denali->dev, denali->buf.dma_buf,
> >  denali->mtd.writesize + denali->mtd.oobsize,
> 
> It feels a bit odd to allow usage of MTD fields after it has been
> unregistered. Maybe precompute this before the nand_release()?

nand_realease() is not releasing the mtd instance or re-initialazing
its field, so it should be safe, but I agree that pre-computing the DMA
buffer size is more future-proof.

I'll fix that, send a v5 and let you decide whether it's needed or not.

Best Regards,

Boris

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
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] clk: ti: omap5+: dpll: implement errata i810

[Tero Kristo]

On 12/03/2015 06:48 PM, Tony Lindgren wrote:

* Tero Kristo  [151130 06:44]:

+   /*
+* Errata i810 - DPLL controller can get stuck while transitioning
+* to a power saving state. Software must ensure the DPLL can not
+* transition to a low power state while changing M/N values.
+* Easiest way to accomplish this is to prevent DPLL autoidle
+* before doing the M/N re-program.
+*/
+   errata_i810 = ti_clk_get_features()->flags & TI_CLK_ERRATA_I810;
+
+   if (errata_i810) {
+   ai = omap3_dpll_autoidle_read(clk);
+   if (ai) {
+   omap3_dpll_deny_idle(clk);
+
+   /* OCP barrier */
+   omap3_dpll_autoidle_read(clk);
+   }
+   }


Should we just do this unconditionally? It seems like disabling the
autoidle always before reprogramming is a good idea.


Well, that is a few extra register accesses, but given the DPLL 
re-programming is a slow operation it probably does not matter. Let me 
spin a new version of this patch, it will avoid the need for the errata 
flag also.


-Tero

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