[PATCH v2 2/5] phy: Add Vitesse 8211 phy ID

[Michal Simek]

Phy is compatible with Vitesse 8221.

Signed-off-by: Michal Simek 
---
Changes in v2: None

 drivers/net/phy/vitesse.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/drivers/net/phy/vitesse.c b/drivers/net/phy/vitesse.c
index d6e988f..69b482b 100644
--- a/drivers/net/phy/vitesse.c
+++ b/drivers/net/phy/vitesse.c
@@ -56,6 +56,7 @@

 #define PHY_ID_VSC8244 0x000fc6c0
 #define PHY_ID_VSC8221 0x000fc550
+#define PHY_ID_VSC8211 0x000fc4b0

 MODULE_DESCRIPTION("Vitesse PHY driver");
 MODULE_AUTHOR("Kriston Carson");
@@ -175,6 +176,19 @@ static struct phy_driver vsc82xx_driver[] = {
.ack_interrupt  = _ack_interrupt,
.config_intr= _config_intr,
.driver = { .owner = THIS_MODULE,},
+}, {
+   /* Vitesse 8211 */
+   .phy_id = PHY_ID_VSC8211,
+   .phy_id_mask= 0x0000,
+   .name   = "Vitesse VSC8211",
+   .features   = PHY_GBIT_FEATURES,
+   .flags  = PHY_HAS_INTERRUPT,
+   .config_init= _config_init,
+   .config_aneg= _config_aneg,
+   .read_status= _read_status,
+   .ack_interrupt  = _ack_interrupt,
+   .config_intr= _config_intr,
+   .driver = { .owner = THIS_MODULE,},
 } };

 static int __init vsc82xx_init(void)
@@ -195,6 +209,7 @@ module_exit(vsc82xx_exit);
 static struct mdio_device_id __maybe_unused vitesse_tbl[] = {
{ PHY_ID_VSC8244, 0x000fffc0 },
{ PHY_ID_VSC8221, 0x0000 },
+   { PHY_ID_VSC8211, 0x0000 },
{ }
 };

--
1.8.2.3



pgpATbmSfPx1S.pgp
Description: PGP signature

[PATCH v2 1/5] phy: Clean coding style in vitesse phy

[Michal Simek]

- Remove trailing white space
- Remove spaces before tag
- Fix comments

Signed-off-by: Michal Simek 
---
Changes in v2: None

 drivers/net/phy/vitesse.c | 23 +++
 1 file changed, 11 insertions(+), 12 deletions(-)

diff --git a/drivers/net/phy/vitesse.c b/drivers/net/phy/vitesse.c
index 3492b53..d6e988f 100644
--- a/drivers/net/phy/vitesse.c
+++ b/drivers/net/phy/vitesse.c
@@ -44,12 +44,12 @@
 #define MII_VSC8244_ISTAT_DUPLEX   0x1000

 /* Vitesse Auxiliary Control/Status Register */
-#define MII_VSC8244_AUX_CONSTAT0x1c
-#define MII_VSC8244_AUXCONSTAT_INIT0x
-#define MII_VSC8244_AUXCONSTAT_DUPLEX  0x0020
-#define MII_VSC8244_AUXCONSTAT_SPEED   0x0018
-#define MII_VSC8244_AUXCONSTAT_GBIT0x0010
-#define MII_VSC8244_AUXCONSTAT_100 0x0008
+#define MII_VSC8244_AUX_CONSTAT0x1c
+#define MII_VSC8244_AUXCONSTAT_INIT0x
+#define MII_VSC8244_AUXCONSTAT_DUPLEX  0x0020
+#define MII_VSC8244_AUXCONSTAT_SPEED   0x0018
+#define MII_VSC8244_AUXCONSTAT_GBIT0x0010
+#define MII_VSC8244_AUXCONSTAT_100 0x0008

 #define MII_VSC8221_AUXCONSTAT_INIT0x0004 /* need to set this bit? */
 #define MII_VSC8221_AUXCONSTAT_RESERVED0x0004
@@ -100,9 +100,8 @@ static int vsc824x_config_init(struct phy_device *phydev)
 static int vsc824x_ack_interrupt(struct phy_device *phydev)
 {
int err = 0;
-   
-   /*
-* Don't bother to ACK the interrupts if interrupts
+
+   /* Don't bother to ACK the interrupts if interrupts
 * are disabled.  The 824x cannot clear the interrupts
 * if they are disabled.
 */
@@ -122,8 +121,7 @@ static int vsc82xx_config_intr(struct phy_device *phydev)
MII_VSC8244_IMASK_MASK :
MII_VSC8221_IMASK_MASK);
else {
-   /*
-* The Vitesse PHY cannot clear the interrupt
+   /* The Vitesse PHY cannot clear the interrupt
 * once it has disabled them, so we clear them first
 */
err = phy_read(phydev, MII_VSC8244_ISTAT);
@@ -146,7 +144,8 @@ static int vsc8221_config_init(struct phy_device *phydev)
return err;

/* Perhaps we should set EXT_CON1 based on the interface?
-  Options are 802.3Z SerDes or SGMII */
+* Options are 802.3Z SerDes or SGMII
+*/
 }

 /* Vitesse 824x */
--
1.8.2.3



pgpJxdTBFfTaF.pgp
Description: PGP signature

Re: [tip:x86/microcode] x86, microcode, amd: Early microcode patch loading support for AMD

[Yinghai Lu]

On Thu, May 30, 2013 at 8:31 PM, tip-bot for Jacob Shin
 wrote:
> Commit-ID:  757885e94a22bcc82beb9b1445c95218cb20ceab
> Gitweb: http://git.kernel.org/tip/757885e94a22bcc82beb9b1445c95218cb20ceab
> Author: Jacob Shin 
> AuthorDate: Thu, 30 May 2013 14:09:19 -0500
> Committer:  H. Peter Anvin 
> CommitDate: Thu, 30 May 2013 20:19:25 -0700
>
> x86, microcode, amd: Early microcode patch loading support for AMD
>
> Add early microcode patch loading support for AMD.
>
> Signed-off-by: Jacob Shin 
> Link: 
> http://lkml.kernel.org/r/1369940959-2077-5-git-send-email-jacob.s...@amd.com
> Signed-off-by: H. Peter Anvin 
> Cc: Fenghua Yu 
> ---
>  Documentation/x86/early-microcode.txt  |  11 +-
>  arch/x86/Kconfig   |  14 ++-
>  arch/x86/include/asm/microcode_amd.h   |  14 +++
>  arch/x86/kernel/Makefile   |   1 +
>  arch/x86/kernel/microcode_amd.c|  22 
>  arch/x86/kernel/microcode_amd_early.c  | 222 
> +
>  arch/x86/kernel/microcode_core_early.c |  43 ++-
>  7 files changed, 310 insertions(+), 17 deletions(-)
>

WARNING: arch/x86/kernel/built-in.o(.cpuinit.text+0x7115): Section
mismatch in reference from the function load_ucode_amd_ap() to the
function .init.text:find_ucode_in_initrd()
The function __cpuinit load_ucode_amd_ap() references
a function __init find_ucode_in_initrd().
If find_ucode_in_initrd is only used by load_ucode_amd_ap then
annotate find_ucode_in_initrd with a matching annotation.
--
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/

Re: [PATCH 1/2] sched: Use do_div() for 64 bit division at power utilization calculation (putil)

[Lukasz Majewski]

Hi Alex,

> On 05/23/2013 04:34 PM, Lukasz Majewski wrote:
> > Now explicit casting is done when power usage variable (putil) is
> > calculated
> > 
> > Signed-off-by: Lukasz Majewski 
> > Signed-off-by: Kyungmin Park 
> > ---
> > This patch was developed on top of the following Alex's repository:
> > https://github.com/alexshi/power-scheduling/commits/power-scheduling
> > ---
> >  kernel/sched/fair.c |6 --
> >  1 file changed, 4 insertions(+), 2 deletions(-)
> > 
> 
> 
> Thanks for catch this issue. seems use div_u64 is better, and there
> are 2 same bugs. so, could I rewrite the patch like following?

Yes, no problem. 

> ---
> 
> From 9f72c25607351981898d99822f5a66e0ca67a3da Mon Sep 17 00:00:00 2001
> From: Alex Shi 
> Date: Wed, 29 May 2013 11:09:39 +0800
> Subject: [PATCH 1/2] sched: fix cast on power utilization calculation
> and use div_u64
> 
> Now explicit casting is done when power usage variable (putil) is
> calculated.
> div_u64 is optimized on u32.
> 
> Signed-off-by: Lukasz Majewski 
> Signed-off-by: Kyungmin Park 
> Signed-off-by: Alex Shi 
> ---
>  kernel/sched/fair.c | 14 --
>  1 file changed, 8 insertions(+), 6 deletions(-)
> 
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 09ae48a..3a4917c 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -1504,8 +1504,8 @@ static inline void
> update_rq_runnable_avg(struct rq *rq, int runnable)
> __update_tg_runnable_avg(>avg, >cfs); 
>   period = rq->avg.runnable_avg_period ?
> rq->avg.runnable_avg_period : 1;
> - rq->util = (u64)(rq->avg.runnable_avg_sum <<
> SCHED_POWER_SHIFT)
> - / period;
> + rq->util = div_u64(((u64)rq->avg.runnable_avg_sum <<
> SCHED_POWER_SHIFT),
> + period);
>  }
>  
>  /* Add the load generated by se into cfs_rq's child load-average */
> @@ -3407,8 +3407,8 @@ static int is_sd_full(struct sched_domain *sd,
>   /* p maybe a new forked task */
>   putil = FULL_UTIL;
>   else
> - putil = (u64)(p->se.avg.runnable_avg_sum <<
> SCHED_POWER_SHIFT)
> - / (p->se.avg.runnable_avg_period +
> 1);
> + putil = div_u64(((u64)p->se.avg.runnable_avg_sum <<
> SCHED_POWER_SHIFT),
> + p->se.avg.runnable_avg_period + 1);
>  
>   /* Try to collect the domain's utilization */
>   group = sd->groups;
> @@ -3463,9 +3463,11 @@ find_leader_cpu(struct sched_group *group,
> struct task_struct *p, int this_cpu, int vacancy, min_vacancy =
> INT_MAX; int leader_cpu = -1;
>   int i;
> +
>   /* percentage of the task's util */
> - unsigned putil = (u64)(p->se.avg.runnable_avg_sum <<
> SCHED_POWER_SHIFT)
> - / (p->se.avg.runnable_avg_period +
> 1);
> + unsigned putil;
> + putil = div_u64(((u64)p->se.avg.runnable_avg_sum <<
> SCHED_POWER_SHIFT),
> + p->se.avg.runnable_avg_period + 1);
>  
>   /* bias toward local cpu */
>   if (cpumask_test_cpu(this_cpu, tsk_cpus_allowed(p)) &&



-- 
Best regards,

Lukasz Majewski

Samsung R Poland (SRPOL) | Linux Platform Group
--
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/

[PATCH] cpufreq: remove unnecessary cpufreq_cpu_{get|put}() calls

[Viresh Kumar]

struct cpufreq_policy is already passed as argument to some routines like:
__cpufreq_driver_getavg() and so we don't really need to do cpufreq_cpu_get()
before and cpufreq_cpu_put() in them to get policy structure.

Remove them.

Signed-off-by: Viresh Kumar 
---
 drivers/cpufreq/cpufreq.c | 19 ++-
 1 file changed, 2 insertions(+), 17 deletions(-)

diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index ce9273a7..f8c2860 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1572,10 +1572,6 @@ int cpufreq_driver_target(struct cpufreq_policy *policy,
 {
int ret = -EINVAL;
 
-   policy = cpufreq_cpu_get(policy->cpu);
-   if (!policy)
-   goto no_policy;
-
if (unlikely(lock_policy_rwsem_write(policy->cpu)))
goto fail;
 
@@ -1584,30 +1580,19 @@ int cpufreq_driver_target(struct cpufreq_policy *policy,
unlock_policy_rwsem_write(policy->cpu);
 
 fail:
-   cpufreq_cpu_put(policy);
-no_policy:
return ret;
 }
 EXPORT_SYMBOL_GPL(cpufreq_driver_target);
 
 int __cpufreq_driver_getavg(struct cpufreq_policy *policy, unsigned int cpu)
 {
-   int ret = 0;
-
if (cpufreq_disabled())
-   return ret;
+   return 0;
 
if (!cpufreq_driver->getavg)
return 0;
 
-   policy = cpufreq_cpu_get(policy->cpu);
-   if (!policy)
-   return -EINVAL;
-
-   ret = cpufreq_driver->getavg(policy, cpu);
-
-   cpufreq_cpu_put(policy);
-   return ret;
+   return cpufreq_driver->getavg(policy, cpu);
 }
 EXPORT_SYMBOL_GPL(__cpufreq_driver_getavg);
 
-- 
1.7.12.rc2.18.g61b472e

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

Re: [PATCH] ALSA: sis7019: fix error return code in sis_chip_create()

[Takashi Iwai]

At Thu, 30 May 2013 19:55:34 +0800,
Wei Yongjun wrote:
> 
> From: Wei Yongjun 
> 
> Fix to return a negative error code in the pci_set_dma_mask() error
> handling case instead of 0, as done elsewhere in this function.
> 
> Signed-off-by: Wei Yongjun 

Thanks, applied.


Takashi

> ---
>  sound/pci/sis7019.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/sound/pci/sis7019.c b/sound/pci/sis7019.c
> index f2639a0..e413b4e 100644
> --- a/sound/pci/sis7019.c
> +++ b/sound/pci/sis7019.c
> @@ -1341,7 +1341,8 @@ static int sis_chip_create(struct snd_card *card,
>   if (rc)
>   goto error_out;
>  
> - if (pci_set_dma_mask(pci, DMA_BIT_MASK(30)) < 0) {
> + rc = pci_set_dma_mask(pci, DMA_BIT_MASK(30));
> + if (rc < 0) {
>   dev_err(>dev, "architecture does not support 30-bit PCI 
> busmaster DMA");
>   goto error_out_enabled;
>   }
> 
--
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/

Re: [PATCH 1/1] ALSA: hda - add dock support for Thinkpad T431s

[Takashi Iwai]

At Wed, 29 May 2013 22:27:18 -0600,
Ebben Aries wrote:
> 
> Add a model/fixup string "lenovo-dock", for Thinkpad T431s, to allow sound in 
> docking station.
> 
> Tested on Lenovo T431s with ThinkPad Mini Dock Plus Series 3
> 
> Signed-off-by: Ebben Aries 

Thanks, applied now.


Takashi

> ---
>  sound/pci/hda/patch_realtek.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
> index 59d2e91..9658faf 100644
> --- a/sound/pci/hda/patch_realtek.c
> +++ b/sound/pci/hda/patch_realtek.c
> @@ -3530,6 +3530,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
>   SND_PCI_QUIRK(0x17aa, 0x21fa, "Thinkpad X230", 
> ALC269_FIXUP_LENOVO_DOCK),
>   SND_PCI_QUIRK(0x17aa, 0x21f3, "Thinkpad T430", 
> ALC269_FIXUP_LENOVO_DOCK),
>   SND_PCI_QUIRK(0x17aa, 0x21fb, "Thinkpad T430s", 
> ALC269_FIXUP_LENOVO_DOCK),
> + SND_PCI_QUIRK(0x17aa, 0x2208, "Thinkpad T431s", 
> ALC269_FIXUP_LENOVO_DOCK),
>   SND_PCI_QUIRK(0x17aa, 0x2203, "Thinkpad X230 Tablet", 
> ALC269_FIXUP_LENOVO_DOCK),
>   SND_PCI_QUIRK(0x17aa, 0x3bf8, "Quanta FL1", ALC269_FIXUP_PCM_44K),
>   SND_PCI_QUIRK(0x17aa, 0x9e54, "LENOVO NB", ALC269_FIXUP_LENOVO_EAPD),
> -- 
> 1.7.12.1
> 
--
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/

Re: [PATCH] net: wireless: iwlegacy: fix build error for il_pm_ops

[Jingoo Han]

On Friday, May 31, 2013 3:06 PM, Yijing Wang wrote:
> 
> Fix build error for il_pm_ops if CONFIG_PM is set
> but CONFIG_PM_SLEEP is not set.
> 
> ERROR: "il_pm_ops" [drivers/net/wireless/iwlegacy/iwl4965.ko] undefined!
> ERROR: "il_pm_ops" [drivers/net/wireless/iwlegacy/iwl3945.ko] undefined!
> make[1]: *** [__modpost] Error 1
> make: *** [modules] Error 2
> 
> Signed-off-by: Yijing Wang 
> Cc: Stanislaw Gruszka 
> Cc: "John W. Linville" 
> Cc: net...@vger.kernel.org
> Cc: linux-wirel...@vger.kernel.org
> Cc: Jingoo Han 

It looks good.
As you did, 'struct dev_pm_ops il_pm_ops' should be protected
by CONFIG_PM_SLEEP.

Acked-by: Jingoo Han 

Best regards,
Jingoo Han

> ---
>  drivers/net/wireless/iwlegacy/common.h |6 +++---
>  1 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/net/wireless/iwlegacy/common.h 
> b/drivers/net/wireless/iwlegacy/common.h
> index f8246f2..4caaf52 100644
> --- a/drivers/net/wireless/iwlegacy/common.h
> +++ b/drivers/net/wireless/iwlegacy/common.h
> @@ -1832,16 +1832,16 @@ u32 il_usecs_to_beacons(struct il_priv *il, u32 usec, 
> u32 beacon_interval);
>  __le32 il_add_beacon_time(struct il_priv *il, u32 base, u32 addon,
> u32 beacon_interval);
> 
> -#ifdef CONFIG_PM
> +#ifdef CONFIG_PM_SLEEP
>  extern const struct dev_pm_ops il_pm_ops;
> 
>  #define IL_LEGACY_PM_OPS (_pm_ops)
> 
> -#else /* !CONFIG_PM */
> +#else /* !CONFIG_PM_SLEEP */
> 
>  #define IL_LEGACY_PM_OPS NULL
> 
> -#endif /* !CONFIG_PM */
> +#endif /* !CONFIG_PM_SLEEP */
> 
>  /*
>  *  Error Handling Debugging
> --
> 1.7.1


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

Re: [PATCH v5 00/13] net: mv643xx_eth DT support and fixes

[Sebastian Hesselbarth]

On 05/31/2013 02:55 AM, David Miller wrote:

From: Sebastian Hesselbarth
Date: Wed, 29 May 2013 21:32:42 +0200


For the patches above I suggest to take Patches 1-6 through David
Miller's branch, and Patches 7-12 through Jason Cooper's when the
former have appeared on mainline linux. The patch set has been based
on v3.10-rc3.


Patches 1-6 applied to net-next, and patch #1 queued up for -stable.


David,

thanks for pulling these in. I finally found how to check if a patch
already went into -stable. As Jason already said, the mdio patch that
#1 fixes did not yet went into -stable. Can you unqueue it? Sorry for
the confusion.

Sebastian

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

[PATCH 1/2] rtc: omap: add option to indicate wakeup support through DT

[Hebbar Gururaja]

Even though RTC-IP is wakeup capable, Not all Boards support it.

For example
The rtc alarm wakeup is available in rtc-ip since omap1 days but alarm
was not wired properly in previous ompa1 boards.

commit fa5b07820fe3a0fc06ac368516e71f10a59b9539
Author: Sekhar Nori 
Date:   Wed Oct 27 15:33:05 2010 -0700

rtc: omap: let device wakeup capability be configured from chip
init logic

The rtc-omap driver currently hardcodes the RTC wakeup
capability to be "not capable".  While this seems to be true for
existing OMAP1 boards which are not wired for this, the
DA850/OMAP-L138 SoC, the RTC can always be wake up source from
its "deep sleep" mode.

Current rtc-omap driver expects the rtc module wake-up capabilities to
be set up by board specific code. However, in case of DT, this is not
possible.

So, add a DT property "ti,wakeup_capable" to indicate that the module is
wake-up capable.

Signed-off-by: Hebbar Gururaja 
---
:100644 100644 b47aa41... 108a629... M  
Documentation/devicetree/bindings/rtc/rtc-omap.txt
:100644 100644 b0ba3fc... 000a02f... M  drivers/rtc/rtc-omap.c
 Documentation/devicetree/bindings/rtc/rtc-omap.txt |4 
 drivers/rtc/rtc-omap.c |5 +
 2 files changed, 9 insertions(+)

diff --git a/Documentation/devicetree/bindings/rtc/rtc-omap.txt 
b/Documentation/devicetree/bindings/rtc/rtc-omap.txt
index b47aa41..108a629 100644
--- a/Documentation/devicetree/bindings/rtc/rtc-omap.txt
+++ b/Documentation/devicetree/bindings/rtc/rtc-omap.txt
@@ -6,6 +6,10 @@ Required properties:
 - interrupts: rtc timer, alarm interrupts in order
 - interrupt-parent: phandle for the interrupt controller
 
+Optional properties:
+- ti,wakeup_capable: Inform the rtc driver that this module is wake-up
+  capable so that rtcwake and suspend tests can work.
+
 Example:
 
 rtc@1c23000 {
diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
index b0ba3fc..000a02f 100644
--- a/drivers/rtc/rtc-omap.c
+++ b/drivers/rtc/rtc-omap.c
@@ -423,6 +423,11 @@ static int __init omap_rtc_probe(struct platform_device 
*pdev)
 *is write-only, and always reads as zero...)
 */
 
+   /* Fixup wakeup-enable feature based on the device tree */
+   if (of_id && of_find_property(pdev->dev.of_node,
+ "ti,wakeup_capable", NULL))
+   device_init_wakeup(>dev, 1);
+
if (new_ctrl & (u8) OMAP_RTC_CTRL_SPLIT)
pr_info("%s: split power mode\n", pdev->name);
 
-- 
1.7.9.5

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

[PATCH 2/2] rtc: omap: add rtc wakeup support to alarm events

[Hebbar Gururaja]

On some platforms (like AM33xx), a special register (RTC_IRQWAKEEN)
is available to enable Wakeup feature for Alarm Events.

Since new platforms/Boards are now added through DT only, this feature
is supported via DT property only.

Platforms using such IP should add the property "ti,has_irq_wake_enb"
in rtc DT node.

Signed-off-by: Hebbar Gururaja 
---
:100644 100644 108a629... b870d87... M  
Documentation/devicetree/bindings/rtc/rtc-omap.txt
:100644 100644 000a02f... 5e9c0dd... M  drivers/rtc/rtc-omap.c
 Documentation/devicetree/bindings/rtc/rtc-omap.txt |2 +
 drivers/rtc/rtc-omap.c |   47 
 2 files changed, 41 insertions(+), 8 deletions(-)

diff --git a/Documentation/devicetree/bindings/rtc/rtc-omap.txt 
b/Documentation/devicetree/bindings/rtc/rtc-omap.txt
index 108a629..b870d87 100644
--- a/Documentation/devicetree/bindings/rtc/rtc-omap.txt
+++ b/Documentation/devicetree/bindings/rtc/rtc-omap.txt
@@ -9,6 +9,8 @@ Required properties:
 Optional properties:
 - ti,wakeup_capable: Inform the rtc driver that this module is wake-up
   capable so that rtcwake and suspend tests can work.
+- ti,has_irq_wake_enb: Inform rtc driver that this module has a a
+  special register to enable Wakeup feature for Alarm events.
 
 Example:
 
diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
index 000a02f..5e9c0dd 100644
--- a/drivers/rtc/rtc-omap.c
+++ b/drivers/rtc/rtc-omap.c
@@ -72,6 +72,8 @@
 #define OMAP_RTC_KICK0_REG 0x6c
 #define OMAP_RTC_KICK1_REG 0x70
 
+#define OMAP_RTC_IRQWAKEEN 0x7C
+
 /* OMAP_RTC_CTRL_REG bit fields: */
 #define OMAP_RTC_CTRL_SPLIT(1<<7)
 #define OMAP_RTC_CTRL_DISABLE  (1<<6)
@@ -96,6 +98,9 @@
 #define OMAP_RTC_INTERRUPTS_IT_ALARM(1<<3)
 #define OMAP_RTC_INTERRUPTS_IT_TIMER(1<<2)
 
+/* OMAP_RTC_IRQWAKEEN bit fields: */
+#define OMAP_RTC_IRQWAKEEN_ALARM_WAKEEN(1<<1)
+
 /* OMAP_RTC_KICKER values */
 #defineKICK0_VALUE 0x83e70b13
 #defineKICK1_VALUE 0x95a4f1e0
@@ -103,6 +108,7 @@
 #defineOMAP_RTC_HAS_KICKER 0x1
 
 static void __iomem*rtc_base;
+static unsigned inthas_irq_wake_enb_bit;
 
 #define rtc_read(addr) readb(rtc_base + (addr))
 #define rtc_write(val, addr)   writeb(val, rtc_base + (addr))
@@ -425,9 +431,14 @@ static int __init omap_rtc_probe(struct platform_device 
*pdev)
 
/* Fixup wakeup-enable feature based on the device tree */
if (of_id && of_find_property(pdev->dev.of_node,
- "ti,wakeup_capable", NULL))
+ "ti,wakeup_capable", NULL)) {
device_init_wakeup(>dev, 1);
 
+   if (of_find_property(pdev->dev.of_node,
+"ti,has_irq_wake_enb", NULL))
+   has_irq_wake_enb_bit = true;
+   }
+
if (new_ctrl & (u8) OMAP_RTC_CTRL_SPLIT)
pr_info("%s: split power mode\n", pdev->name);
 
@@ -469,16 +480,26 @@ static u8 irqstat;
 
 static int omap_rtc_suspend(struct device *dev)
 {
+   u8 irqwake_stat;
+
irqstat = rtc_read(OMAP_RTC_INTERRUPTS_REG);
 
-   /* FIXME the RTC alarm is not currently acting as a wakeup event
-* source, and in fact this enable() call is just saving a flag
-* that's never used...
+   /*
+* FIXME. On some platforms the RTC alarm is not currently acting as a
+* wakeup event source, and in fact this enable() call is just saving a
+* flag that's never used...
 */
-   if (device_may_wakeup(dev))
+   if (device_may_wakeup(dev)) {
enable_irq_wake(omap_rtc_alarm);
-   else
+
+   if (has_irq_wake_enb_bit == true) {
+   irqwake_stat = rtc_read(OMAP_RTC_IRQWAKEEN);
+   irqwake_stat |= OMAP_RTC_IRQWAKEEN_ALARM_WAKEEN;
+   rtc_write(irqwake_stat, OMAP_RTC_IRQWAKEEN);
+   }
+   } else {
rtc_write(0, OMAP_RTC_INTERRUPTS_REG);
+   }
 
/* Disable the clock/module */
pm_runtime_put_sync(dev);
@@ -488,13 +509,23 @@ static int omap_rtc_suspend(struct device *dev)
 
 static int omap_rtc_resume(struct device *dev)
 {
+   u8 irqwake_stat;
+
/* Enable the clock/module so that we can access the registers */
pm_runtime_get_sync(dev);
 
-   if (device_may_wakeup(dev))
+   if (device_may_wakeup(dev)) {
disable_irq_wake(omap_rtc_alarm);
-   else
+
+   if (has_irq_wake_enb_bit == true) {
+   irqwake_stat = rtc_read(OMAP_RTC_IRQWAKEEN);
+   irqwake_stat &= ~OMAP_RTC_IRQWAKEEN_ALARM_WAKEEN;
+   rtc_write(irqwake_stat, OMAP_RTC_IRQWAKEEN);
+   }
+   } else {
rtc_write(irqstat, OMAP_RTC_INTERRUPTS_REG);
+   }
+
return 0;
 }

[PATCH 0/2] rtc: rtc-omap: add support for DT wakeup & alarm events

[Hebbar Gururaja]

Current rtc-omap driver expects the rtc module wake-up capabilities to
be set up by board specific code. However, in case of DT, this is not
possible.

So, add a DT property "ti,wakeup_capable" to indicate that the module
is wake-up capable.

Also, on some platforms (like AM33xx), a special register
(RTC_IRQWAKEEN) is available to enable Wakeup feature for Alarm Events.

Since new platforms/Boards are now added through DT only, this feature
is supported via DT property only. Platforms using such IP should add
the property "ti,has_irq_wake_enb" in rtc DT node.

Kernel Base for the series is
> git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/
linux-omap-dt.git
> linux-omap-git/for_3.11/dts

Hebbar Gururaja (2):
  rtc: omap: add option to indicate wakeup support through DT
  rtc: omap: add rtc wakeup support to alarm events

 Documentation/devicetree/bindings/rtc/rtc-omap.txt |6 +++
 drivers/rtc/rtc-omap.c |   50 +---
 2 files changed, 49 insertions(+), 7 deletions(-)

-- 
1.7.9.5

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

Re: [alsa-devel] Improving or replacing snd_printk()

[Takashi Iwai]

At Thu, 30 May 2013 20:49:09 +0200,
Jaroslav Kysela wrote:
> 
> Date 30.5.2013 20:14, Alan Stern wrote:
> > On Wed, 29 May 2013, Joe Perches wrote:
> > 
> >> On Wed, 2013-05-29 at 15:27 -0400, Alan Stern wrote:
> >>> Has there been any thought of improving snd_printk(), or even better,
> >>> changing the call sites to use the dev_*() routines instead?
> >>
> >> Perhaps better would be to add and use some combination of
> >> type specific logging message functions/macros like:
> >>
> >> void snd_(const struct snd_device *dev, const char *fmt, ...)
> >> void snd_card_(const struct snd_card *card, const char *fmt, ...)
> >> void snd_ac97_(const struct snd_ac97 *ac97, const char *fmt, ...)
> >>
> >> allowing NULL as the type pointer when necessary/appropriate.
> > 
> > Almost anything would be better than the current situation.  The only 
> > enhancement provided by CONFIG_SND_VERBOSE_PRINTK is to print the 
> > filename and line number, which is relatively unhelpful (unless there 
> > are multiple copies of the same message in several places).
> 
> I don't think that it's useless to see the origin of the source message
> from the first glance. It may be improved, of course, but adding more
> and more functions with minor benefits is another step to another hell.

Agreed.  Especially the debug messages would be better to be precise.

The problem is that many messages with snd_printk() like below have
too little information without CONFIG_SND_VERBOSE_PRINTK:
snd_printk(KERN_ERR "cannot submit urb (err = %d)\n", err);

It's a problem only with snd_printk(), as CONFIG_SND_VERBOSE_PRINTK
influences on the behavior of snd_printk() and not on the debug prints
with snd_printd() & co.

Hence, the goal we should achieve is rather to drop
CONFIG_SND_VERBOSE_PRINTK.  *This* is the useless thing.

Meanwhile, many snd_printk() messages might start looking annoying
with the extra information.  If so, such lines should be replaced with
the standard prints like dev_*().  I think almost all snd_printk()
like below are better replaced with standard ones.

So, alternatively, we can begin with replacing some snd_printk() with
the standard functions, then dropping CONFIG_SND_VERBOSE_PRINTK.

I think most of snd_printd() and snd_printdd() can be kept as is.
These are just debug messages, after all.

Thoughts?


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

Re: [RFC] regmap: Add regmap_field APIs

[Srinivas KANDAGATLA]

Hi Mark,

We have pretty much completed reworking the patch-set we sent recently
for the STiH41x SOC support. We are waiting for your feedback on this patch.

Thanks,
srini

On 28/05/13 15:58, Srinivas KANDAGATLA wrote:
> From: Srinivas Kandagatla 
> 
> It is common to access regmap registers at bit level, using
> regmap_update_bits or regmap_read functions, however the end user has to
> take care of a mask or shifting. This becomes overhead when such use
> cases are high. Having a common function to do this is much convient and less
> error prone.
> 
> The idea of regmap_field is simple, regmap_field gives a logical structure to
> bits of the regmap register, and the driver can use this logical entity 
> without
> the knowledge of the bit postions and masks all over the code. This way code
> looks much neat and it need not handle the masks, shifts every time it access
> the those entities.
> 
> With this new regmap_field_read/write apis the end user can setup a
> regmap field using regmap_field_init and use the return regmap_field to
> read write the register field without worrying about the masks or
> shifts.
> Also this apis will be usefull for drivers which are based on regmaps,
> like some clocks or pinctrls which can work on the regmap_fields
> directly without having to worry about bit positions.
> 
> Signed-off-by: Srinivas Kandagatla 
> ---
> Hi Mark,
> 
> I have been looking at using regmap mmio directly for ST "System Configuration
> registers". One thing which we discussed 2 weeks back in syscon patch was, if
> this new functionality would benifit others. Having thought about it, I think
> that if regmap had a concept like regmap_field we would have used it straight 
> way
> without a new driver.
> 
> I generated this patch mainly to get your opinion on these new APIs, Is this 
> the
> right place for these APIs, or do you suggest that these APIs should go in SOC
> Specific driver?
> 
> Comments?
> 
> Thanks,
> srini
> 
> 
> 
>  drivers/base/regmap/regmap.c |   47 
> ++
>  include/linux/regmap.h   |   28 +
>  2 files changed, 75 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c
> index a941dcf..4512df7 100644
> --- a/drivers/base/regmap/regmap.c
> +++ b/drivers/base/regmap/regmap.c
> @@ -1249,6 +1249,27 @@ int regmap_raw_write(struct regmap *map, unsigned int 
> reg,
>  }
>  EXPORT_SYMBOL_GPL(regmap_raw_write);
>  
> +/**
> + * regmap_field_write(): Write a value to a single register field
> + *
> + * @field: Register field to write to
> + * @val: Value to be written
> + *
> + * A value of zero will be returned on success, a negative errno will
> + * be returned in error cases.
> + */
> +
> +int regmap_field_write(struct regmap_field *field, unsigned int val)
> +{
> + int field_bits;
> + unsigned int reg_mask;
> + field_bits = field->msb - field->lsb + 1;
> + reg_mask = ((BIT(field_bits) - 1) << field->lsb);
> + return regmap_update_bits(field->regmap, field->reg,
> + reg_mask, val << field->lsb);
> +}
> +EXPORT_SYMBOL_GPL(regmap_field_write);
> +
>  /*
>   * regmap_bulk_write(): Write multiple registers to the device
>   *
> @@ -1532,6 +1553,32 @@ int regmap_raw_read(struct regmap *map, unsigned int 
> reg, void *val,
>  EXPORT_SYMBOL_GPL(regmap_raw_read);
>  
>  /**
> + * regmap_field_read(): Read a value to a single register field
> + *
> + * @field: Register field to read from
> + * @val: Pointer to store read value
> + *
> + * A value of zero will be returned on success, a negative errno will
> + * be returned in error cases.
> + */
> +
> +int regmap_field_read(struct regmap_field *field, unsigned int *val)
> +{
> + int field_bits;
> + int ret;
> + ret = regmap_read(field->regmap, field->reg, val);
> + if (ret != 0)
> + return ret;
> +
> + field_bits = field->msb - field->lsb + 1;
> + *val >>= field->lsb;
> + *val &= (BIT(field_bits) - 1);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(regmap_field_read);
> +
> +/**
>   * regmap_bulk_read(): Read multiple registers from the device
>   *
>   * @map: Register map to write to
> diff --git a/include/linux/regmap.h b/include/linux/regmap.h
> index 02d84e2..f8dba11 100644
> --- a/include/linux/regmap.h
> +++ b/include/linux/regmap.h
> @@ -411,6 +411,34 @@ bool regmap_reg_in_ranges(unsigned int reg,
> const struct regmap_range *ranges,
> unsigned int nranges);
>  
> +struct regmap_field {
> + struct regmap *regmap;
> + unsigned int reg;
> + unsigned int lsb;
> + unsigned int msb;
> +};
> +
> +#define REGMAP_FIELD_INIT(regmap, reg, lsb, msb) {   \
> + .regmap = regmap,   \
> + .reg = reg, \
> + .lsb = lsb, \
> + .msb = msb,   

Re: [alsa-devel] [PATCH] [resend] snd-es1968: Add radio support for MediaForte M56VAP

[Takashi Iwai]

At Thu, 30 May 2013 16:13:09 +0200,
Ondrej Zary wrote:
> 
> Add support for TEA5757 tuner on MediaForte M56VAP sound+modem+radio card.
> The GPIO connection type is automatically detected (like snd-fm801 driver).
> 
> Also add a safety subsystem vendor check to skip radio detection if vendor
> differs from ESS (so we don't touch GPIOs on laptops).
> 
> Tested with SF64-PCE2 and M56VAP cards.
> 
> Signed-off-by: Ondrej Zary 

Thanks, applied.

At the next time, please add maintainers to Cc.


Takashi

> ---
>  sound/pci/es1968.c |   73 +++
>  1 files changed, 50 insertions(+), 23 deletions(-)
> 
> diff --git a/sound/pci/es1968.c b/sound/pci/es1968.c
> index a1f32b5..db08641 100644
> --- a/sound/pci/es1968.c
> +++ b/sound/pci/es1968.c
> @@ -564,6 +564,7 @@ struct es1968 {
>  #ifdef CONFIG_SND_ES1968_RADIO
>   struct v4l2_device v4l2_dev;
>   struct snd_tea575x tea;
> + unsigned int tea575x_tuner;
>  #endif
>  };
>  
> @@ -2557,37 +2558,47 @@ static int snd_es1968_input_register(struct es1968 
> *chip)
>   bits 1=unmask write to given bit */
>  #define IO_DIR   8  /* direction register offset from 
> GPIO_DATA
>   bits 0/1=read/write direction */
> -/* mask bits for GPIO lines */
> -#define STR_DATA 0x0040 /* GPIO6 */
> -#define STR_CLK  0x0080 /* GPIO7 */
> -#define STR_WREN 0x0100 /* GPIO8 */
> -#define STR_MOST 0x0200 /* GPIO9 */
> +
> +/* GPIO to TEA575x maps */
> +struct snd_es1968_tea575x_gpio {
> + u8 data, clk, wren, most;
> + char *name;
> +};
> +
> +static struct snd_es1968_tea575x_gpio snd_es1968_tea575x_gpios[] = {
> + { .data = 6, .clk = 7, .wren = 8, .most = 9, .name = "SF64-PCE2" },
> + { .data = 7, .clk = 8, .wren = 6, .most = 10, .name = "M56VAP" },
> +};
> +
> +#define get_tea575x_gpio(chip) \
> + (_es1968_tea575x_gpios[(chip)->tea575x_tuner])
> +
>  
>  static void snd_es1968_tea575x_set_pins(struct snd_tea575x *tea, u8 pins)
>  {
>   struct es1968 *chip = tea->private_data;
> - unsigned long io = chip->io_port + GPIO_DATA;
> + struct snd_es1968_tea575x_gpio gpio = *get_tea575x_gpio(chip);
>   u16 val = 0;
>  
> - val |= (pins & TEA575X_DATA) ? STR_DATA : 0;
> - val |= (pins & TEA575X_CLK)  ? STR_CLK  : 0;
> - val |= (pins & TEA575X_WREN) ? STR_WREN : 0;
> + val |= (pins & TEA575X_DATA) ? (1 << gpio.data) : 0;
> + val |= (pins & TEA575X_CLK)  ? (1 << gpio.clk)  : 0;
> + val |= (pins & TEA575X_WREN) ? (1 << gpio.wren) : 0;
>  
> - outw(val, io);
> + outw(val, chip->io_port + GPIO_DATA);
>  }
>  
>  static u8 snd_es1968_tea575x_get_pins(struct snd_tea575x *tea)
>  {
>   struct es1968 *chip = tea->private_data;
> - unsigned long io = chip->io_port + GPIO_DATA;
> - u16 val = inw(io);
> - u8 ret;
> + struct snd_es1968_tea575x_gpio gpio = *get_tea575x_gpio(chip);
> + u16 val = inw(chip->io_port + GPIO_DATA);
> + u8 ret = 0;
>  
> - ret = 0;
> - if (val & STR_DATA)
> + if (val & (1 << gpio.data))
>   ret |= TEA575X_DATA;
> - if (val & STR_MOST)
> + if (val & (1 << gpio.most))
>   ret |= TEA575X_MOST;
> +
>   return ret;
>  }
>  
> @@ -2596,13 +2607,18 @@ static void snd_es1968_tea575x_set_direction(struct 
> snd_tea575x *tea, bool outpu
>   struct es1968 *chip = tea->private_data;
>   unsigned long io = chip->io_port + GPIO_DATA;
>   u16 odir = inw(io + IO_DIR);
> + struct snd_es1968_tea575x_gpio gpio = *get_tea575x_gpio(chip);
>  
>   if (output) {
> - outw(~(STR_DATA | STR_CLK | STR_WREN), io + IO_MASK);
> - outw(odir | STR_DATA | STR_CLK | STR_WREN, io + IO_DIR);
> + outw(~((1 << gpio.data) | (1 << gpio.clk) | (1 << gpio.wren)),
> + io + IO_MASK);
> + outw(odir | (1 << gpio.data) | (1 << gpio.clk) | (1 << 
> gpio.wren),
> + io + IO_DIR);
>   } else {
> - outw(~(STR_CLK | STR_WREN | STR_DATA | STR_MOST), io + IO_MASK);
> - outw((odir & ~(STR_DATA | STR_MOST)) | STR_CLK | STR_WREN, io + 
> IO_DIR);
> + outw(~((1 << gpio.clk) | (1 << gpio.wren) | (1 << gpio.data) | 
> (1 << gpio.most)),
> + io + IO_MASK);
> + outw((odir & ~((1 << gpio.data) | (1 << gpio.most)))
> + | (1 << gpio.clk) | (1 << gpio.wren), io + IO_DIR);
>   }
>  }
>  
> @@ -2772,6 +2788,9 @@ static int snd_es1968_create(struct snd_card *card,
>   snd_card_set_dev(card, >dev);
>  
>  #ifdef CONFIG_SND_ES1968_RADIO
> + /* don't play with GPIOs on laptops */
> + if (chip->pci->subsystem_vendor != 0x125d)
> + goto no_radio;
>   err = v4l2_device_register(>dev, >v4l2_dev);
>   if (err < 0) {
>   snd_es1968_free(chip);
> @@ -2781,10 +2800,18 @@ static int snd_es1968_create(struct snd_card *card,
>  

Re: [PATCH 1/2] rtc: omap: add option to indicate wakeup support through DT

[Prabhakar Lad]

Hi Gururaja,

Thanks for the patch.

On Fri, May 31, 2013 at 12:03 PM, Hebbar Gururaja
 wrote:
> Even though RTC-IP is wakeup capable, Not all Boards support it.
>
> For example
> The rtc alarm wakeup is available in rtc-ip since omap1 days but alarm
> was not wired properly in previous ompa1 boards.
>
[snip]
>
> +Optional properties:
> +- ti,wakeup_capable: Inform the rtc driver that this module is wake-up
For devicetree properties '-' is preferred over '_'.

Regards,
--Prabhakar Lad
--
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/

Regression introduced by commit "lib/bitmap.c: speed up bitmap_find_free_region"

[Sachin Kamat]

Hi,

While testing MFC decoder on Exynos machines, I encountered some
memory allocation errors due to failure of dma_alloc_coherent().
File: drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c Line: 38.

Git bisect pointed me to the following commit as the first bad commit
(linux-next tree of 20130531):

commit 3d5272d9b289cd0930b2ea9984406d757a72f4dd
Author: Chanho Min 
Date:   Thu May 23 10:37:28 2013 +1000
lib/bitmap.c: speed up bitmap_find_free_region

Reverting this (and the commit 197e1cf7
("ib-bitmapc-speed-up-bitmap_find_free_region-fix") ) fixes this
issue.

Looks like some regression has been introduced by the above patch?

---
With warm regards,
Sachin
--
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/

RE: [PATCH 1/2] rtc: omap: add option to indicate wakeup support through DT

[Hebbar, Gururaja]

On Fri, May 31, 2013 at 12:14:44, Prabhakar Lad wrote:
> Hi Gururaja,
> 
> Thanks for the patch.
> 
> On Fri, May 31, 2013 at 12:03 PM, Hebbar Gururaja
>  wrote:
> > Even though RTC-IP is wakeup capable, Not all Boards support it.
> >
> > For example
> > The rtc alarm wakeup is available in rtc-ip since omap1 days but alarm
> > was not wired properly in previous ompa1 boards.
> >
> [snip]
> >
> > +Optional properties:
> > +- ti,wakeup_capable: Inform the rtc driver that this module is wake-up
> For devicetree properties '-' is preferred over '_'.

Thanks for the review. I will make the correction. But will wait for some 
more time (so others can review) and then send V2

> 
> Regards,
> --Prabhakar Lad
> 


Regards, 
Gururaja
--
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/

Re: [PATCH 2/2] rtc: omap: add rtc wakeup support to alarm events

[Prabhakar Lad]

Hi Gururaja,

Thanks for the patch.

On Fri, May 31, 2013 at 12:03 PM, Hebbar Gururaja
 wrote:
> On some platforms (like AM33xx), a special register (RTC_IRQWAKEEN)
[snip]
>  - ti,wakeup_capable: Inform the rtc driver that this module is wake-up
>capable so that rtcwake and suspend tests can work.
> +- ti,has_irq_wake_enb: Inform rtc driver that this module has a a
same comment applies here as well.
s/has a a/ has a

> +  special register to enable Wakeup feature for Alarm events.
>
>  Example:
>
> diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
> index 000a02f..5e9c0dd 100644
> --- a/drivers/rtc/rtc-omap.c
> +++ b/drivers/rtc/rtc-omap.c
> @@ -72,6 +72,8 @@
>  #define OMAP_RTC_KICK0_REG 0x6c
>  #define OMAP_RTC_KICK1_REG 0x70
>
> +#define OMAP_RTC_IRQWAKEEN 0x7C
> +
why not have the hex values in smaller case as done in the rest of the file ?

Regards,
--Prabhakar Lad
--
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/

Re: [PATCH v2] ata: increase retry count but shorten duration for Calxeda controller

[Clemens Ladisch]

Sergei Shtylyov wrote:
> On 30-05-2013 18:26, Timur Tabi wrote:
>>> +const unsigned long timing[] = { 5, 100, 500};
>
>> You'll save space and time if you also make this array "static",
>> otherwise the compiler will build the array every time this function is
>> called.
>
> No, *const* specifier is enough to not build this array every time. It will 
> be put into the .const section.

gcc disagrees:

$ cat const_static.c
int f(int x) {
const unsigned long timing[] = { 5, 100, 500};
static const unsigned long timing2[] = { 5, 100, 500};
return timing[x] + timing2[x];
}
$ gcc -Os -S const_static.c
$ cat const_static.s
...
timing2.0:
.long   5
.long   100
.long   500
...
movl8(%ebp), %edx
movl$5, -16(%ebp)
movl$100, -12(%ebp)
movl$500, -8(%ebp)
movltiming2.0(,%edx,4), %eax
addl-16(%ebp,%edx,4), %eax


Regards,
Clemens
--
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/

[PATCH] MAINTAINERS: update path for drm tegra driver

[Ying Xue]

Since 4231c6b01af9f0f3eeca4b8d0d87125d78233b41 commit, drm tegra
driver was moved to host1x, however, its correspding entry in
MAINTAINERS is not updated in time.

Signed-off-by: Ying Xue 
---
 MAINTAINERS |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 7714c3c..d672968 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2702,7 +2702,7 @@ L:dri-de...@lists.freedesktop.org
 L: linux-te...@vger.kernel.org
 T: git git://gitorious.org/thierryreding/linux.git
 S: Maintained
-F: drivers/gpu/drm/tegra/
+F: drivers/gpu/host1x/drm/
 F: Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt
 
 DSBR100 USB FM RADIO DRIVER
-- 
1.7.9.5

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

Re: [PATCH 0/4] clk, mfd: u8540 clock tree definition

[Lee Jones]

On Thu, 30 May 2013, Mike Turquette wrote:

> Quoting Philippe Begnic (2013-05-27 05:41:28)
> > From: Philippe Begnic 
> > 
> > Create U8540 clock tree definitions for common clock framework
> > 
> 
> The clock changes look good to me.  How did you want to merge the
> patches?

You may as well take them through your tree Mike.

> > Philippe Begnic (4):
> >   clk: ux500: Pass clock base adresses in initcall for u8540 and u9540
> >   mfd: db8500: Update register definition for u8540 clock
> >   mfd: db8500: Update BML clock register for db8580
> >   clk: ux500: Clocks definition for u8540
> > 
> >  arch/arm/mach-ux500/cpu.c |6 +-
> >  drivers/clk/ux500/u8540_clk.c |  564 
> > -
> >  drivers/clk/ux500/u9540_clk.c |4 +-
> >  drivers/mfd/db8500-prcmu.c|1 +
> >  drivers/mfd/dbx500-prcmu-regs.h   |1 +
> >  include/linux/mfd/abx500/ab8500-sysctrl.h |4 +-
> >  include/linux/mfd/dbx500-prcmu.h  |   12 +
> >  include/linux/platform_data/clk-ux500.h   |6 +-
> >  8 files changed, 587 insertions(+), 11 deletions(-)
> > 

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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/

Re: [tip:x86/microcode] x86, microcode, amd: Early microcode patch loading support for AMD

[Jacob Shin]

On Thu, May 30, 2013 at 11:10:23PM -0700, Yinghai Lu wrote:
> On Thu, May 30, 2013 at 8:31 PM, tip-bot for Jacob Shin
>  wrote:
> > Commit-ID:  757885e94a22bcc82beb9b1445c95218cb20ceab
> > Gitweb: 
> > http://git.kernel.org/tip/757885e94a22bcc82beb9b1445c95218cb20ceab
> > Author: Jacob Shin 
> > AuthorDate: Thu, 30 May 2013 14:09:19 -0500
> > Committer:  H. Peter Anvin 
> > CommitDate: Thu, 30 May 2013 20:19:25 -0700
> >
> > x86, microcode, amd: Early microcode patch loading support for AMD
> >
> > Add early microcode patch loading support for AMD.
> >
> > Signed-off-by: Jacob Shin 
> > Link: 
> > http://lkml.kernel.org/r/1369940959-2077-5-git-send-email-jacob.s...@amd.com
> > Signed-off-by: H. Peter Anvin 
> > Cc: Fenghua Yu 
> > ---
> >  Documentation/x86/early-microcode.txt  |  11 +-
> >  arch/x86/Kconfig   |  14 ++-
> >  arch/x86/include/asm/microcode_amd.h   |  14 +++
> >  arch/x86/kernel/Makefile   |   1 +
> >  arch/x86/kernel/microcode_amd.c|  22 
> >  arch/x86/kernel/microcode_amd_early.c  | 222 
> > +
> >  arch/x86/kernel/microcode_core_early.c |  43 ++-
> >  7 files changed, 310 insertions(+), 17 deletions(-)
> >
> 
> WARNING: arch/x86/kernel/built-in.o(.cpuinit.text+0x7115): Section
> mismatch in reference from the function load_ucode_amd_ap() to the
> function .init.text:find_ucode_in_initrd()
> The function __cpuinit load_ucode_amd_ap() references
> a function __init find_ucode_in_initrd().
> If find_ucode_in_initrd is only used by load_ucode_amd_ap then
> annotate find_ucode_in_initrd with a matching annotation.

Sorry about that, should have turned on CONFIG_DEBUG_SECTION_MISMATCH=y

This should fix the warnings:

>From 5c7ec96f218f08db25e449d7d5789ee2f66f2f92 Mon Sep 17 00:00:00 2001
From: Jacob Shin 
Date: Fri, 31 May 2013 01:53:24 -0500
Subject: [PATCH 1/1] x86/microcode/amd: fix section mismatch warnings on
 microcode_amd_early.c

Fix section mismatch warnings on microcode_amd_early.c

Signed-off-by: Jacob Shin 
---
 arch/x86/include/asm/microcode_amd.h  |2 +-
 arch/x86/kernel/microcode_amd_early.c |8 
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/x86/include/asm/microcode_amd.h 
b/arch/x86/include/asm/microcode_amd.h
index 24254aa..c6b043f 100644
--- a/arch/x86/include/asm/microcode_amd.h
+++ b/arch/x86/include/asm/microcode_amd.h
@@ -64,7 +64,7 @@ extern enum ucode_state load_microcode_amd(int cpu, const u8 
*data, size_t size)
 #ifdef CONFIG_MICROCODE_AMD_EARLY
 #ifdef CONFIG_X86_32
 #define MPB_MAX_SIZE PAGE_SIZE
-extern u8 __cpuinitdata amd_bsp_mpb[MPB_MAX_SIZE];
+extern u8 amd_bsp_mpb[MPB_MAX_SIZE];
 #endif
 extern void __init load_ucode_amd_bsp(void);
 extern void __cpuinit load_ucode_amd_ap(void);
diff --git a/arch/x86/kernel/microcode_amd_early.c 
b/arch/x86/kernel/microcode_amd_early.c
index 7e54d97..9618805 100644
--- a/arch/x86/kernel/microcode_amd_early.c
+++ b/arch/x86/kernel/microcode_amd_early.c
@@ -21,9 +21,9 @@ static u32 ucode_new_rev;
  * Microcode patch container file is prepended to the initrd in cpio format.
  * See Documentation/x86/early-microcode.txt
  */
-static __initdata char ucode_path[] = "kernel/x86/microcode/AuthenticAMD.bin";
+static __cpuinitdata char ucode_path[] = 
"kernel/x86/microcode/AuthenticAMD.bin";
 
-static struct cpio_data __init find_ucode_in_initrd(void)
+static struct cpio_data __cpuinit find_ucode_in_initrd(void)
 {
long offset = 0;
struct cpio_data cd;
@@ -62,7 +62,7 @@ static struct cpio_data __init find_ucode_in_initrd(void)
  * load_microcode_amd() to save equivalent cpu table and microcode patches in
  * kernel heap memory.
  */
-static void __init apply_ucode_in_initrd(void)
+static void __cpuinit apply_ucode_in_initrd(void)
 {
struct cpio_data cd;
struct equiv_cpu_entry *eq;
@@ -133,7 +133,7 @@ void __init load_ucode_amd_bsp(void)
 }
 
 #ifdef CONFIG_X86_32
-u8 __cpuinitdata amd_bsp_mpb[MPB_MAX_SIZE];
+u8 amd_bsp_mpb[MPB_MAX_SIZE];
 
 /*
  * On 32-bit, since AP's early load occurs before paging is turned on, we
-- 
1.7.9.5


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

Re: [PATCHv2 0/7] Miscellaneous fixes to host1x

[Terje Bergström]

On 29.05.2013 13:26, Arto Merilainen wrote:
> This patch series fixes two issues in the host1x driver: First, the
> command buffer validation routine had vulnerabilities that were not
> detected in earlier testing. Second, the return codes of some
> functions were misleading or completely missing. This caused the
> driver to give wrong return codes also to the userspace.
> 
> The series is based on top of 3.10rc3. I have tested the patch series
> on cardhu by running host1x and gr2d test cases (available at [0]).
> I would appreciate any help in testing/reviewing these patches.
> 
> Changes from v1:
>  * Rebased on top of 3.10rc3
>  * Split firewall fixes to smaller patches
>  * Reworked no-reloc case in firewall code. Fix in v1 was not
>sufficient in all cases
>  * Dropped patch "Fix syncpoint wait return value" as it is not
>critical and discussion on it has not yet settled.
>  * Fixed style and whitespace issues
> 
> [0] https://gitorious.org/linux-host1x/libdrm-host1x
> 
> Arto Merilainen (5):
>   gpu: host1x: Check reloc table before usage
>   gpu: host1x: Copy gathers before verification
>   gpu: host1x: Fix memory access in syncpt request
>   gpu: host1x: Fix client_managed type
>   gpu: host1x: Rework CPU syncpoint increment
> 
> Terje Bergstrom (2):
>   gpu: host1x: Check INCR opcode correctly
>   gpu: host1x: Don't reset firewall between gathers
> 
>  drivers/gpu/host1x/dev.h  |   8 +--
>  drivers/gpu/host1x/drm/drm.c  |   3 +-
>  drivers/gpu/host1x/drm/gr2d.c |   2 +-
>  drivers/gpu/host1x/hw/cdma_hw.c   |   2 +-
>  drivers/gpu/host1x/hw/syncpt_hw.c |  12 ++--
>  drivers/gpu/host1x/job.c  | 135 
> +-
>  drivers/gpu/host1x/syncpt.c   |  26 +++-
>  drivers/gpu/host1x/syncpt.h   |  13 ++--
>  8 files changed, 85 insertions(+), 116 deletions(-)
> 

Arto's patches above,

Acked-By: Terje Bergstrom 

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

Re: [PATCH v2 0/5] Zynq: revised CCF code

[Michal Simek]

On 05/31/2013 08:32 AM, Mike Turquette wrote:
> Quoting Michal Simek (2013-05-30 22:17:59)
>> On 05/30/2013 08:44 PM, Mike Turquette wrote:
>>> Quoting Michal Simek (2013-05-17 05:14:47)
 Hi Mike,

 I have sent email to Greg to take this patch from this series
 though his serial tree because it is unrelated to this clock stuff.

 Can you please give me your ACK for these patches or add them
 to your CLK tree?

>>>
>>> For the four clock-related patches:
>>>
>>> Acked-by: Mike Turquette 
>>
>> I have already sent pull request to Arnd and Olof.
>> Or is it you who should take these patches through your tree?
>>
> 
> Either way is fine.  Since you have already sent the pull request to the
> arm-soc tree then that is probably the best path.

ok. I will keep my eyes on it.

Thanks,
Michal

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform




signature.asc
Description: OpenPGP digital signature

Re: [alsa-devel] Improving or replacing snd_printk()

[Joe Perches]

On Fri, 2013-05-31 at 08:37 +0200, Takashi Iwai wrote:
> It's a problem only with snd_printk(), as CONFIG_SND_VERBOSE_PRINTK
> influences on the behavior of snd_printk() and not on the debug prints
> with snd_printd() & co.

Are you're perhaps confused about how CONFIG_SND_VERBOSE_PRINTK
works with or varies between snd_printd and snd_printk?

#if defined(CONFIG_SND_DEBUG) || defined(CONFIG_SND_VERBOSE_PRINTK)
__printf(4, 5)
void __snd_printk(unsigned int level, const char *file, int line,
  const char *format, ...);

...

#define snd_printk(fmt, args...) \
__snd_printk(0, __FILE__, __LINE__, fmt, ##args)

#ifdef CONFIG_SND_DEBUG
[...]
#define snd_printd(fmt, args...) \
__snd_printk(1, __FILE__, __LINE__, fmt, ##args)

I don't see a difference.

> Hence, the goal we should achieve is rather to drop
> CONFIG_SND_VERBOSE_PRINTK.  *This* is the useless thing.

Maybe.

> Meanwhile, many snd_printk() messages might start looking annoying
> with the extra information.  If so, such lines should be replaced with
> the standard prints like dev_*().  I think almost all snd_printk()
> like below are better replaced with standard ones.

below?  Was there something that was supposed to be below?
Are you referring to the KERN_ERR/urb example above?

> So, alternatively, we can begin with replacing some snd_printk() with
> the standard functions, then dropping CONFIG_SND_VERBOSE_PRINTK.

Dropping CONFIG_SND_VERBOSE_PRINTK would simplify code a bit.

> I think most of snd_printd() and snd_printdd() can be kept as is.
> These are just debug messages, after all.

Some of those are emitted at levels other than KERN_DEBUG.
I think that odd.

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

Re: [PATCH] net: skbuff: use _RET_IP_

[Bjørn Mork]

Joe Perches  writes:
> On Thu, 2013-05-30 at 18:11 -0700, Davidlohr Bueso wrote:
>> On Thu, 2013-05-30 at 13:08 +0200, Bjørn Mork wrote:
>> > Sergei Shtylyov  writes:
>> > 
>> > > Why not "text:%#lx" as already used in this string? It's
>> > > equivalent to "0x%lx".
>> > 
>> > Well, I don't know the reasoning in this case, but I'd like to note that
>> > those are not strictly equivalent.  Personally I find the formatting of 0
>> > annoying enough to avoid %#x for any value which may be 0.  It's
>> > especially bad if you try to line up things by adding leading zeros.
>> 
>> Yep, I found that 0x%lx produced the same output as %p.
>
> Don't use a standalone gcc compiled program to
> determine what the kernel outputs.

That's a very good point.  Sorry for mixing this up.  You are of course
right.  The kernel does everything correctly, so there is no reason not
to use %#x



Bjørn
--
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/

[PATCH] There is no /sys/parameters

[Jean Delvare]

There is no such path as /sys/parameters, module parameters live in
/sys/module/*/parameters.

Signed-off-by: Jean Delvare 
Cc: Rusty Russell 
---
 include/linux/moduleparam.h |2 +-
 kernel/params.c |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

--- linux-3.10-rc3.orig/include/linux/moduleparam.h 2013-04-29 
02:36:01.0 +0200
+++ linux-3.10-rc3/include/linux/moduleparam.h  2013-05-30 10:41:37.417314420 
+0200
@@ -439,7 +439,7 @@ extern struct kernel_param_ops param_ops
 extern int param_set_copystring(const char *val, const struct kernel_param *);
 extern int param_get_string(char *buffer, const struct kernel_param *kp);
 
-/* for exporting parameters in /sys/parameters */
+/* for exporting parameters in /sys/module/.../parameters */
 
 struct module;
 
--- linux-3.10-rc3.orig/kernel/params.c 2013-05-13 15:27:49.883223693 +0200
+++ linux-3.10-rc3/kernel/params.c  2013-05-30 10:43:40.411316243 +0200
@@ -787,7 +787,7 @@ static void __init kernel_add_sysfs_para
 }
 
 /*
- * param_sysfs_builtin - add contents in /sys/parameters for built-in modules
+ * param_sysfs_builtin - add sysfs parameters for built-in modules
  *
  * Add module_parameters to sysfs for "modules" built into the kernel.
  *


-- 
Jean Delvare
--
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/

Re: [PATCH 1/2] GPIO: Add support for dual channel in gpio-xilinx.c

[Linus Walleij]

On Fri, May 31, 2013 at 7:43 AM, Michal Simek  wrote:
> On 05/30/2013 09:46 PM, Linus Walleij wrote:

>> (...)
>>> +/* Read/Write access to the GPIO registers */
>>> +#define xgpio_readreg(offset)  __raw_readl(offset)
>>> +#define xgpio_writereg(offset, val)__raw_writel(val, offset)
>>
>> So you're swithing in_be32/out_be32 to the CPU-dependent
>> __raw_readl/__raw_writel functions? Why?
>
> The reason is that this driver can be used on ARM where in_be32/out_be32
> is not implemented.

OK I buy this (and the following explanation).

I think readl/writel is always in LE (PCI) endianness anyway, which
is likely not what you want. (I suspect the next point was about
that.)

>> Have you documented these new bindings? It doesn't seem so.
>> Documentation/devicetree/bindings/gpio/*...
>>
>> If it's undocumented so far, this is a good oppotunity to add it.
>
> Isn't it enough what it is in 2/2?

I didn't see 2/2, I guess I wasn't on CC...

Anyway I guess it's this:
http://marc.info/?l=linux-kernel=136982686732560=2

It's OK, but fix the boolean member so as to just needing to
be present:

xlnx,is-dual;

Rather than

xlnx,is-dual = <1>;

> Or do you want to describe current binding in the first patch
> and then extend it in this patch when dual channel is added?

Nah. 2/2 is fine.

>> This is basically a jam table (hardware set-up) in the device tree.
>
> Not sure what you mean by that. Xilinx GPIO is soft IP which can be configured
> to different configurations before bitstream is generated.
> At the end you will get different setting/addresses setup for every pin
> which is described by these xlnx,X descriptions.
>
>> I don't exactly like this. Is this necessary?
>
> If you mean names or values in there that all of them are autogenerated
> from design tools and they are reflect IP hardware description and all
> configuration options which you can have there.
> It means that all these values give you exact hardware description.
>
> Do I answer your question?

Yes, this is OK, I buy that explanation. I thought it was
something else.

I think the overall problem is that I do not understand what a
"channel" is in this context, and thus it is hard to understand the
patch as a whole. 2/2 could add some more verbose explanation
about the HW IP so I get comfortable and can understand the
whole hardware block...

Yours,
Linus Walleij
--
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/

Re: [PATCH] ARM: OMAP2+: omap-usb-host: Fix memory leaks

[Roger Quadros]

Hi Tony,

On 05/31/2013 12:00 AM, Tony Lindgren wrote:
> Hi Roger,
> 
> * Roger Quadros  [130524 06:12]:
>> Fix memory leaks in the error path.
>> Also, use platform_device_register_full() to allocate
>> the platform devices and set platform data.
> 
> If you need this for the v3.10-rc, you should describe why this patch
> is needed and ideally have some oops or regression causing commit
> listed. Care to update the description for that?

There is no oops or regression happening. Just that there will be a
small memory leak if any of the memory allocations fail or if the
platform device is destroyed.

If it doesn't look that serious to you then it can wait.
But if we move to device tree only boot then this patch and the file
"usb-host.c" might not be required at all.

cheers,
-roger

>  
>> Signed-off-by: Roger Quadros 
>> ---
>>  arch/arm/mach-omap2/usb-host.c |  106 
>> +---
>>  1 files changed, 56 insertions(+), 50 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/usb-host.c b/arch/arm/mach-omap2/usb-host.c
>> index aa27d7f..609b330 100644
>> --- a/arch/arm/mach-omap2/usb-host.c
>> +++ b/arch/arm/mach-omap2/usb-host.c
>> @@ -28,6 +28,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  
>>  #include "soc.h"
>>  #include "omap_device.h"
>> @@ -560,7 +561,8 @@ static int usbhs_add_regulator(char *name, char *dev_id, 
>> char *dev_supply,
>>  struct regulator_init_data *reg_data;
>>  struct fixed_voltage_config *config;
>>  struct platform_device *pdev;
>> -int ret;
>> +struct platform_device_info pdevinfo;
>> +int ret = -ENOMEM;
>>  
>>  supplies = kzalloc(sizeof(*supplies), GFP_KERNEL);
>>  if (!supplies)
>> @@ -571,7 +573,7 @@ static int usbhs_add_regulator(char *name, char *dev_id, 
>> char *dev_supply,
>>  
>>  reg_data = kzalloc(sizeof(*reg_data), GFP_KERNEL);
>>  if (!reg_data)
>> -return -ENOMEM;
>> +goto err_data;
>>  
>>  reg_data->constraints.valid_ops_mask = REGULATOR_CHANGE_STATUS;
>>  reg_data->consumer_supplies = supplies;
>> @@ -580,39 +582,53 @@ static int usbhs_add_regulator(char *name, char 
>> *dev_id, char *dev_supply,
>>  config = kmemdup(_reg_config, sizeof(hsusb_reg_config),
>>  GFP_KERNEL);
>>  if (!config)
>> -return -ENOMEM;
>> +goto err_config;
>> +
>> +config->supply_name = kstrdup(name, GFP_KERNEL);
>> +if (!config->supply_name)
>> +goto err_supplyname;
>>  
>> -config->supply_name = name;
>>  config->gpio = gpio;
>>  config->enable_high = polarity;
>>  config->init_data = reg_data;
>>  
>>  /* create a regulator device */
>> -pdev = kzalloc(sizeof(*pdev), GFP_KERNEL);
>> -if (!pdev)
>> -return -ENOMEM;
>> +memset(, 0, sizeof(pdevinfo));
>> +pdevinfo.name = reg_name;
>> +pdevinfo.id = PLATFORM_DEVID_AUTO;
>> +pdevinfo.data = config;
>> +pdevinfo.size_data = sizeof(*config);
>>  
>> -pdev->id = PLATFORM_DEVID_AUTO;
>> -pdev->name = reg_name;
>> -pdev->dev.platform_data = config;
>> +pdev = platform_device_register_full();
>> +if (IS_ERR(pdev)) {
>> +ret = PTR_ERR(pdev);
>> +pr_err("%s: Failed registering regulator %s for %s : %d\n",
>> +__func__, name, dev_id, ret);
>> +goto err_register;
>> +}
>>  
>> -ret = platform_device_register(pdev);
>> -if (ret)
>> -pr_err("%s: Failed registering regulator %s for %s\n",
>> -__func__, name, dev_id);
>> +return 0;
>>  
>> +err_register:
>> +kfree(config->supply_name);
>> +err_supplyname:
>> +kfree(config);
>> +err_config:
>> +kfree(reg_data);
>> +err_data:
>> +kfree(supplies);
>>  return ret;
>>  }
>>  
>> +#define MAX_STR 20
>> +
>>  int usbhs_init_phys(struct usbhs_phy_data *phy, int num_phys)
>>  {
>> -char *rail_name;
>> -int i, len;
>> +char rail_name[MAX_STR];
>> +int i;
>>  struct platform_device *pdev;
>>  char *phy_id;
>> -
>> -/* the phy_id will be something like "nop_usb_xceiv.1" */
>> -len = strlen(nop_name) + 3; /* 3 -> ".1" and NULL terminator */
>> +struct platform_device_info pdevinfo;
>>  
>>  for (i = 0; i < num_phys; i++) {
>>  
>> @@ -627,25 +643,26 @@ int usbhs_init_phys(struct usbhs_phy_data *phy, int 
>> num_phys)
>>  !gpio_is_valid(phy->vcc_gpio))
>>  continue;
>>  
>> -/* create a NOP PHY device */
>> -pdev = kzalloc(sizeof(*pdev), GFP_KERNEL);
>> -if (!pdev)
>> -return -ENOMEM;
>> -
>> -pdev->id = phy->port;
>> -pdev->name = nop_name;
>> -pdev->dev.platform_data = phy->platform_data;
>> -
>> -phy_id = kmalloc(len, GFP_KERNEL);
>> -if (!phy_id)
>> +phy_id = kmalloc(MAX_STR, GFP_KERNEL);
>> +

Re: [alsa-devel] Improving or replacing snd_printk()

[Takashi Iwai]

At Fri, 31 May 2013 00:06:07 -0700,
Joe Perches wrote:
> 
> On Fri, 2013-05-31 at 08:37 +0200, Takashi Iwai wrote:
> > It's a problem only with snd_printk(), as CONFIG_SND_VERBOSE_PRINTK
> > influences on the behavior of snd_printk() and not on the debug prints
> > with snd_printd() & co.
> 
> Are you're perhaps confused about how CONFIG_SND_VERBOSE_PRINTK
> works with or varies between snd_printd and snd_printk?
> 
> #if defined(CONFIG_SND_DEBUG) || defined(CONFIG_SND_VERBOSE_PRINTK)
> __printf(4, 5)
> void __snd_printk(unsigned int level, const char *file, int line,
> const char *format, ...);
> 
> ...
> 
> #define snd_printk(fmt, args...) \
>   __snd_printk(0, __FILE__, __LINE__, fmt, ##args)
> 
> #ifdef CONFIG_SND_DEBUG
> [...]
> #define snd_printd(fmt, args...) \
>   __snd_printk(1, __FILE__, __LINE__, fmt, ##args)
> 
> I don't see a difference.

Erm, indeed.  I thought we enabled the verobse prinkt always for debug
prints.  But it's not.  It's more reason for dropping
CONFIG_SND_VERBOSE_PRINTK :)

> > Hence, the goal we should achieve is rather to drop
> > CONFIG_SND_VERBOSE_PRINTK.  *This* is the useless thing.
> 
> Maybe.
> 
> > Meanwhile, many snd_printk() messages might start looking annoying
> > with the extra information.  If so, such lines should be replaced with
> > the standard prints like dev_*().  I think almost all snd_printk()
> > like below are better replaced with standard ones.
> 
> below?  Was there something that was supposed to be below?
> Are you referring to the KERN_ERR/urb example above?

Sorry, scratch it.  Just a typo during changing the lines.

> > So, alternatively, we can begin with replacing some snd_printk() with
> > the standard functions, then dropping CONFIG_SND_VERBOSE_PRINTK.
> 
> Dropping CONFIG_SND_VERBOSE_PRINTK would simplify code a bit.
> 
> > I think most of snd_printd() and snd_printdd() can be kept as is.
> > These are just debug messages, after all.
> 
> Some of those are emitted at levels other than KERN_DEBUG.
> I think that odd.

Yeah, they aren't good, but it's a different topic.


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

Re: [alsa-devel] Improving or replacing snd_printk()

[Joe Perches]

On Fri, 2013-05-31 at 09:23 +0200, Takashi Iwai wrote:
> At Fri, 31 May 2013 00:06:07 -0700, Joe Perches wrote:
> > On Fri, 2013-05-31 at 08:37 +0200, Takashi Iwai wrote:
> > > I think most of snd_printd() and snd_printdd() can be kept as is.
> > > These are just debug messages, after all.
> > Some of those are emitted at levels other than KERN_DEBUG.
> > I think that odd.
> Yeah, they aren't good, but it's a different topic.

Not really, I think it's systemic and fallout from
accretive implementation rather than design.


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

Re: [alsa-devel] Improving or replacing snd_printk()

[Takashi Iwai]

At Fri, 31 May 2013 00:30:09 -0700,
Joe Perches wrote:
> 
> On Fri, 2013-05-31 at 09:23 +0200, Takashi Iwai wrote:
> > At Fri, 31 May 2013 00:06:07 -0700, Joe Perches wrote:
> > > On Fri, 2013-05-31 at 08:37 +0200, Takashi Iwai wrote:
> > > > I think most of snd_printd() and snd_printdd() can be kept as is.
> > > > These are just debug messages, after all.
> > > Some of those are emitted at levels other than KERN_DEBUG.
> > > I think that odd.
> > Yeah, they aren't good, but it's a different topic.
> 
> Not really, I think it's systemic and fallout from
> accretive implementation rather than design.

Maybe.

But you shouldn't mix up with the fix for the missing verbosity and
the fix for wrong KERN_ prefix, at least, in the patch level.  They
need to be fixed individually.


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

Re: [PATCH 1/2] GPIO: Add support for dual channel in gpio-xilinx.c

[Michal Simek]

On 05/31/2013 09:14 AM, Linus Walleij wrote:
> On Fri, May 31, 2013 at 7:43 AM, Michal Simek  wrote:
>> On 05/30/2013 09:46 PM, Linus Walleij wrote:
> 
>>> (...)
 +/* Read/Write access to the GPIO registers */
 +#define xgpio_readreg(offset)  __raw_readl(offset)
 +#define xgpio_writereg(offset, val)__raw_writel(val, offset)
>>>
>>> So you're swithing in_be32/out_be32 to the CPU-dependent
>>> __raw_readl/__raw_writel functions? Why?
>>
>> The reason is that this driver can be used on ARM where in_be32/out_be32
>> is not implemented.
> 
> OK I buy this (and the following explanation).
> 
> I think readl/writel is always in LE (PCI) endianness anyway, which
> is likely not what you want. (I suspect the next point was about
> that.)

readl/writel yes it is all the time little endian
but __raw_readl/__raw_writel is just *(u32 *)ptr access
without any endian checking and barriers.

Probably the best way how to handle is to write
#ifdef ARCH_ZYNQ
# define xgpio_readreg(offset)  readl(offset)
# define xgpio_writereg(offset, val)writel(val, offset)
#else
# define xgpio_readreg(offset)  __raw_readl(offset)
# define xgpio_writereg(offset, val)__raw_writel(val, offset)
#endif

But still it is not correct in sense that I shouldn't pretend
that __raw_readl is ok to run on ppc and microblaze big endian.
But using another ifdef BIG_ENDIAN or ARCH don't improve it.

If there is one more register which I can use for autodetection,
it will be easy to choose but that's not this case.

>>> Have you documented these new bindings? It doesn't seem so.
>>> Documentation/devicetree/bindings/gpio/*...
>>>
>>> If it's undocumented so far, this is a good oppotunity to add it.
>>
>> Isn't it enough what it is in 2/2?
> 
> I didn't see 2/2, I guess I wasn't on CC...
> 
> Anyway I guess it's this:
> http://marc.info/?l=linux-kernel=136982686732560=2

Yes. it is. I am using patman and you are probably not listed
in MAINTAINERS for this folder to automatically add you.
Will add you manually.

> It's OK, but fix the boolean member so as to just needing to
> be present:
> 
> xlnx,is-dual;
> 
> Rather than
> 
> xlnx,is-dual = <1>;

Surely I can do it but it means to change our BSP and because
this IP is used on Microblaze from beginning this change
breaks all DTSes from past.
That's why I would prefer not to change logic here because
it just breaks all Microblaze DTSes which were generated
till this change (All of them contains xlnx,is-dual = <0>
if dual channel is not used).

I will definitely look at dt function in the whole driver
and use the

>> Or do you want to describe current binding in the first patch
>> and then extend it in this patch when dual channel is added?
> 
> Nah. 2/2 is fine.

ok.

>>> This is basically a jam table (hardware set-up) in the device tree.
>>
>> Not sure what you mean by that. Xilinx GPIO is soft IP which can be 
>> configured
>> to different configurations before bitstream is generated.
>> At the end you will get different setting/addresses setup for every pin
>> which is described by these xlnx,X descriptions.
>>
>>> I don't exactly like this. Is this necessary?
>>
>> If you mean names or values in there that all of them are autogenerated
>> from design tools and they are reflect IP hardware description and all
>> configuration options which you can have there.
>> It means that all these values give you exact hardware description.
>>
>> Do I answer your question?
> 
> Yes, this is OK, I buy that explanation. I thought it was
> something else.

ok

> I think the overall problem is that I do not understand what a
> "channel" is in this context, and thus it is hard to understand the
> patch as a whole. 2/2 could add some more verbose explanation
> about the HW IP so I get comfortable and can understand the
> whole hardware block...

ok. Good.

Thanks,
Michal

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform




signature.asc
Description: OpenPGP digital signature

Re: [alsa-devel] Improving or replacing snd_printk()

[Joe Perches]

On Fri, 2013-05-31 at 09:35 +0200, Takashi Iwai wrote:
> At Fri, 31 May 2013 00:30:09 -0700, Joe Perches wrote:
> > On Fri, 2013-05-31 at 09:23 +0200, Takashi Iwai wrote:
> > > At Fri, 31 May 2013 00:06:07 -0700, Joe Perches wrote:
> > > > On Fri, 2013-05-31 at 08:37 +0200, Takashi Iwai wrote:
> > > > > I think most of snd_printd() and snd_printdd() can be kept as is.
> > > > > These are just debug messages, after all.
> > > > Some of those are emitted at levels other than KERN_DEBUG.
> > > > I think that odd.
> > > Yeah, they aren't good, but it's a different topic.
> > 
> > Not really, I think it's systemic and fallout from
> > accretive implementation rather than design.
> 
> Maybe.
> 
> But you shouldn't mix up with the fix for the missing verbosity and
> the fix for wrong KERN_ prefix, at least, in the patch level.  They
> need to be fixed individually.

I think that's best too.

I don't see the complexity/hell in adding functions
for specific types of struct * to reduce the complexity
of the code though.  Centralizing those indirections
into functions also generally reduces overall code size.


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

Re: [PATCH v2 2/3] video: xilinxfb: Do not use out_be32 IO function

[Michal Simek]

On 05/31/2013 12:04 AM, Arnd Bergmann wrote:
> On Thursday 30 May 2013 11:41:01 Michal Simek wrote:
>>   * To perform the read/write on the registers we need to check on
>>   * which bus its connected and call the appropriate write API.
>>   */
>> -static void xilinx_fb_out_be32(struct xilinxfb_drvdata *drvdata, u32 offset,
>> +static void xilinx_fb_out32(struct xilinxfb_drvdata *drvdata, u32 offset,
>> u32 val)
>>  {
>> if (drvdata->flags & PLB_ACCESS_FLAG)
>> -   out_be32(drvdata->regs + (offset << 2), val);
>> +   __raw_writel(val, drvdata->regs + (offset << 2));
>>  #ifdef CONFIG_PPC_DCR
>> else
>> dcr_write(drvdata->dcr_host, offset, val);
>>
> 
> This is probably missing barriers, and is wrong on systems on which
> the endianess of the device is different from the CPU.
> 
> You already have an indirection in there, so I guess it won't hurt
> to create a third case for little-endian registers and add
> another bit in drvdata->flags, or make it depend on the architecture,
> if the endianess of the device registers is known at compile time.

The PLB_ACCESS_FLAGS is incorrectly named. It means BUS_ACCESS.
But I will find a way how to autodetect endianess directly on IP
as I have done it for uartlite and will send v3.

Thanks,
Michal

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform




signature.asc
Description: OpenPGP digital signature

Re: [PATCH v3] aerdrv: Move cper_print_aer() call out of interrupt context

[Borislav Petkov]

On Thu, May 30, 2013 at 02:04:42PM +, Ortiz, Lance E wrote:
> Steve, you do have a good point here. I am wondering if that is why
> we should consider changing the output to match aer_print_error().
> The code path to aer_print_error() is the more common path where not
> as many platforms support the cper_print_error() path (firmware first
> AER). So it is more likely that any tools written would know how to
> parse the output from aer_print_error(). It would be good for those
> tools to support firmware first AER when it becomes more common. Of
> course this is purely conjecture. I have no idea if there are any
> tools that parse this text output.

Whatever you end up doing, just make sure you've hammered out the
information going out to userspace to be clear, succinct and complete
(as far as possible, of course). Because once you cast it in stone and
tools start using it, changing its format is a huge PITA, if at all
possible.

And if the error formats are compatible, then sharing the format is
obviously advantageous.
--
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/

Re: [PATCH v2] ata: increase retry count but shorten duration for Calxeda controller

[Tejun Heo]

On Fri, May 31, 2013 at 08:53:37AM +0200, Clemens Ladisch wrote:
> Sergei Shtylyov wrote:
> > On 30-05-2013 18:26, Timur Tabi wrote:
> >>> +const unsigned long timing[] = { 5, 100, 500};
> >
> >> You'll save space and time if you also make this array "static",
> >> otherwise the compiler will build the array every time this function is
> >> called.
> >
> > No, *const* specifier is enough to not build this array every time. It will 
> > be put into the .const section.
> 
> gcc disagrees:

Doesn't really matter this or that way but let's do static const as,
more than anything else, that's what other places are doing.

Thanks.

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

Re: [PATCH 8/8] perf, x86: Enable PEBS mode automatically for mem-{loads,stores} v2

[Stephane Eranian]

On Fri, May 31, 2013 at 1:01 AM, Andi Kleen  wrote:
> From: Andi Kleen 
>
> With the earlier patches to automatically try cpu// and add
> a precise sys attribute, we can now enable PEBS for the mem-loads,
> mem-stores events everywhere.
>
> This allows to use
>
> perf record -e mem-loads ...
>
> instead of
>
> perf record -e cpu/mem-loads/p ...
>
> Nehalem and Sandy Bridge only use precise mode == 1 as the off-by-one
> IP correction is quite expensive here (user can still override)
> On Haswell as it's basically free always use precise=2
>
I think overhead should not guide the choice here. You want to expose
a uniform behavior across CPUs as much as possible. I suggest you
use precise=2 whenever it is available. In other words, try to return
the load/store instruction address each time you can.

> Cc: eran...@google.com
> v2: Different white space
> Signed-off-by: Andi Kleen 
> ---
>  arch/x86/kernel/cpu/perf_event_intel.c | 14 +-
>  1 file changed, 9 insertions(+), 5 deletions(-)
>
> diff --git a/arch/x86/kernel/cpu/perf_event_intel.c 
> b/arch/x86/kernel/cpu/perf_event_intel.c
> index b1d4966..914243c 100644
> --- a/arch/x86/kernel/cpu/perf_event_intel.c
> +++ b/arch/x86/kernel/cpu/perf_event_intel.c
> @@ -176,9 +176,12 @@ static struct extra_reg intel_snbep_extra_regs[] 
> __read_mostly = {
> EVENT_EXTRA_END
>  };
>
> -EVENT_ATTR_STR(mem-loads, mem_ld_nhm, "event=0x0b,umask=0x10,ldlat=3");
> -EVENT_ATTR_STR(mem-loads, mem_ld_snb, "event=0xcd,umask=0x1,ldlat=3");
> -EVENT_ATTR_STR(mem-stores, mem_st_snb, "event=0xcd,umask=0x2");
> +EVENT_ATTR_STR(mem-loads, mem_ld_nhm,
> +   "event=0x0b,umask=0x10,ldlat=3,precise=1");
> +EVENT_ATTR_STR(mem-loads, mem_ld_snb,
> +   "event=0xcd,umask=0x1,ldlat=3,precise=1");
> +EVENT_ATTR_STR(mem-stores, mem_st_snb,
> +   "event=0xcd,umask=0x2,precise=1");
>
>  struct attribute *nhm_events_attrs[] = {
> EVENT_PTR(mem_ld_nhm),
> @@ -2033,8 +2036,9 @@ static __init void intel_nehalem_quirk(void)
> }
>  }
>
> -EVENT_ATTR_STR(mem-loads,  mem_ld_hsw, 
> "event=0xcd,umask=0x1,ldlat=3");
> -EVENT_ATTR_STR(mem-stores, mem_st_hsw, "event=0xd0,umask=0x82")
> +EVENT_ATTR_STR(mem-loads,  mem_ld_hsw,
> +   "event=0xcd,umask=0x1,ldlat=3,precise=2");
> +EVENT_ATTR_STR(mem-stores, mem_st_hsw,  
> "event=0xd0,umask=0x82,precise=2")
>
>  static struct attribute *hsw_events_attrs[] = {
> EVENT_PTR(mem_ld_hsw),
> --
> 1.8.1.4
>
--
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/

Re: [RFC PATCHv4 0/6] arm: Initial TI-Nspire support

[Laurent Pinchart]

Hi Pawel,

Sorry for the late reply, I'm currently attending LinuxCon Japan, my mail 
backlog is growing.

On Tuesday 28 May 2013 11:52:52 Pawel Moll wrote:
> On Mon, 2013-05-27 at 11:31 +0100, Arnd Bergmann wrote:
> > On Monday 27 May 2013, Daniel Tang wrote:
> > > > The one remaining bit that sticks out is the clcd platform data. As I
> > > > said before, I won't require you to convert that to DT in order to
> > > > get your code merged, but I'd also really like to see that happen,
> > > > as we will also need that to get rid of auxdata on the ARM reference
> > > > platforms (integrator, versatile, realview, vexpress).
> > > 
> > > How would you like me to convert the platform data to DT? AFAIK, the
> > > clcd driver isn't aware of DT so the only way is to use the AUXDATA
> > > right now.
> > 
> > Linus Walleij mentioned on IRC that Pawel Moll already posted a series
> > that adds DT support for clcd:
> > 
> > http://lists.freedesktop.org/archives/dri-devel/2013-April/037519.html
> > 
> > The series does a few more things, but you can probbly split out the
> > parts you need and base on that.
> 
> The main "issue" with the series is its dependency on Laurent Pinchart's
> Common Display Framework (or rather on the progress of its upstreaming).
> I'm planning to discuss this in details in during the Linaro Connect in
> Dublin, but generally, if it's not getting merged in the next window,
> I'll spin the series to use the standard video modes bindings instead of
> CDF. This will make me hurt on Versatile Express, but should work for
> others.

I've met with Tomi Valkeinen (TI), Alexandre Courbot (NVidia) and Tomasz Figa 
(Samsung) recently, For the first time the meetings helped narrowing the 
options *down*. It seems a path is slowly unfolding, and I would like to 
target v3.13 for a first (possibly limited) version.

Regarding the DT bindings, Alexandre and Tomasz will look into the V4L2 DT 
bindings to see whether/how they can be reused/leveraged for the CDF bindings. 
In both case we need to describe a graph of connected entities, and there's 
not much in the V4L2 DT bindings that is V4L2-specific in that regard.

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH v2 0/5] Phylib changes

[David Miller]

From: Michal Simek 
Date: Fri, 31 May 2013 08:08:22 +0200

> We have these changes in our tree for quite a long
> time and I would like to ask you for review.
> All phys are used on xilinx zynq boards.

All applied to net-next, thanks.
--
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/

Re: [Xen-devel] [PATCHv3 0/2] xen: maintain an accurate persistent clock in more cases

[Jan Beulich]

>>> On 31.05.13 at 01:55, John Stultz  wrote:
> The first is probably the easiest, but I do want to make sure that Xen 
> maintainers agree that Xen really needs to be special here compared to 
> every other platform and always enforce the RTC is synced with system time.

Actually, during the v2 discussion I think we made clear that this
is not the goal: Sync-ing of the RTC should be just like native
does it. The only special thing Xen wants is that the hypervisor's
software wall clock wants to be kept up to date when NTP or
whatever else updates Dom0's wall clock.

Jan

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

Re: [PATCH v3 0/5] rtc-at91rm9200: add shadow interrupt mask

[Nicolas Ferre]

On 31/05/2013 01:17, Douglas Gilbert :

On 13-05-30 03:36 PM, Andrew Morton wrote:

On Thu, 30 May 2013 09:50:27 +0200 Nicolas Ferre
 wrote:


The review of this patch series was in my TODO list for some time...

Today, I magically took time to review it ;-)
The patch series is good and I (even if it is too late) here is my:

Acked-by: Nicolas Ferre 

I do not know if the series can be stacked for inclusion in 3.10-rc but
the resolution of this bug can help a lot (as Douglas is saying in
subsequent email...).


We can do that, but looking through the discussion and changelogs I
can't seem to find a usable description of what impact the bug (and its
fix) have upon end-users.

A nicely packaged description of that impact would help grease the
wheels, please.


How about this:

The members of Atmel's at91sam9x5 family (9x5) have
a broken RTC interrupt mask register (AT91_RTC_IMR).
It does not reflect enabled interrupts but instead
always returns zero.

The kernel's rtc-at91rm9200 driver handles the RTC
for the 9x5 family. Currently when the date/time is
set, an interrupt is generated and this driver neglects
to handle the interrupt. The kernel complains about the
un-handled interrupt and disables it henceforth. This
not only breaks the RTC function, but since that
interrupt is shared (Atmel's SYS interrupt) then other
things break as well (e.g. the debug port no longer
accepts characters).

Tested on the at91sam9g25. Bug confirmed by Atmel.


Absolutely. Thank you Douglas for the detailed description.



Edit as you please.

Doug Gilbert





--
Nicolas Ferre
--
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/

Re: [PATCH v3 3/5] gpio-langwell: use managed functions pcim_* and devm_*

[Andy Shevchenko]

On Thu, 2013-05-30 at 19:25 +0200, Linus Walleij wrote: 
> On Wed, May 22, 2013 at 12:20 PM, Andy Shevchenko
>  wrote:
> 
> > This makes the error handling much more simpler than open-coding everything 
> > and
> > in addition makes the probe function smaller an tidier.
> >
> > Signed-off-by: Andy Shevchenko 
> 
> Applied with Mika's ACK.
> 
> I had to rebase this thing since there was a patch removing the line
> setting platform data to NULL on remove(), check that I did the right
> thing in the result.

Yes, that is correct. Thanks!

-- 
Andy Shevchenko 
Intel Finland Oy
--
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/

Re: [PATCH RESEND 1/2] mtd: bcm47: convert kzalloc to avoid invalid access

[Rafał Miłecki]

2013/5/30 Libo Chen :
> mtd is just member of bcm47xxsflash, so we should free bcm47xxsflash not its 
> member.
> So I use devm_kazlloc instead of kazlloc to avoid it.

I think you should use
mtd: bcm47xxsflash:
prefix for both patches, but Artem or David may want to comment on that.

Nice trick with that devm_kzalloc, I didn't know it.

-- 
Rafał
--
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/

Re: [alsa-devel] Improving or replacing snd_printk()

[Takashi Iwai]

At Fri, 31 May 2013 00:38:01 -0700,
Joe Perches wrote:
> 
> On Fri, 2013-05-31 at 09:35 +0200, Takashi Iwai wrote:
> > At Fri, 31 May 2013 00:30:09 -0700, Joe Perches wrote:
> > > On Fri, 2013-05-31 at 09:23 +0200, Takashi Iwai wrote:
> > > > At Fri, 31 May 2013 00:06:07 -0700, Joe Perches wrote:
> > > > > On Fri, 2013-05-31 at 08:37 +0200, Takashi Iwai wrote:
> > > > > > I think most of snd_printd() and snd_printdd() can be kept as is.
> > > > > > These are just debug messages, after all.
> > > > > Some of those are emitted at levels other than KERN_DEBUG.
> > > > > I think that odd.
> > > > Yeah, they aren't good, but it's a different topic.
> > > 
> > > Not really, I think it's systemic and fallout from
> > > accretive implementation rather than design.
> > 
> > Maybe.
> > 
> > But you shouldn't mix up with the fix for the missing verbosity and
> > the fix for wrong KERN_ prefix, at least, in the patch level.  They
> > need to be fixed individually.
> 
> I think that's best too.
> 
> I don't see the complexity/hell in adding functions
> for specific types of struct * to reduce the complexity
> of the code though.  Centralizing those indirections
> into functions also generally reduces overall code size.

I don't mind to add the struct pointer to new snd_*() -- if we really
introduce them.  The bigger question is whether we really need to
introduce such, and if yes, what variants.  And for that, I don't
think we need to add many functions.  Maybe snd_card_() would
be good.  But others don't seem to make sense to me (remember that I
suggest dropping CONFIG_SND_VERBOSE_PRINTK).


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

Re: [patch] mm, memcg: add oom killer delay

[Michal Hocko]

On Thu 30-05-13 13:47:30, David Rientjes wrote:
> On Thu, 30 May 2013, Michal Hocko wrote:
> 
> > > Completely disabling the oom killer for a memcg is problematic if
> > > userspace is unable to address the condition itself, usually because it
> > > is unresponsive. 
> > 
> > Isn't this a bug in the userspace oom handler? Why is it unresponsive? It
> > shouldn't allocated any memory so nothing should prevent it from running (if
> > other tasks are preempting it permanently then the priority of the handler
> > should be increased).
> > 
> 
> Unresponsiveness isn't necessarily only because of memory constraints, you 
> may have your oom notifier in a parent cgroup that isn't oom. 

I have always discouraged people from running oom handler in the same
memcg (or even in the same hierarchy).

> If a process is stuck on mm->mmap_sem in the oom cgroup, though, the
> oom notifier may not be able to scrape /proc/pid and attain necessary
> information in making an oom kill decision.

Yes, mmap_sem is tricky. Nothing in the proc code should take it for
writing and charges are done with mmap_sem held for reading but that
doesn't prevent from non-oom thread to try to get it for writing which
would block also all future readers. We have also seen i_mutex being
held during charge so you have to be careful about that one as well but
I am not aware of other locks that could be a problem.

The question is, do you really need to open any /proc// files which
depend on mmap_sem (e.g. maps, smaps). /proc//status should tell you
about used memory. Or put it another way around. What kind of data you
need for your OOM handler?

I might be thinking about different use cases but user space OOM
handlers I have seen so far had quite a good idea what is going on
in the group and who to kill. So it was more a decision based on the
workload and its semantic rather than based on the used memory (which
is done quite sensibly with the in kernel handler already) or something
that would trip over mmap_sem when trying to get information.

> If the oom notifier is in the oom cgroup, it may not be able to   
> successfully read the memcg "tasks" file to even determine the set of 
> eligible processes.

It would have to use preallocated buffer and have mlocked all the memory
that will be used during oom event.

> There is also no guarantee that the userspace oom handler will have
> the necessary memory to even re-enable the oom killer in the memcg
> under oom which would allow the kernel to make forward progress.

Why it wouldn't have enough memory to write to the file? Assuming that
the oom handler has the file handle (for limit_in_bytes) open, it has
mlocked all the necessary memory (code + buffers) then I do not see what
would prevent it from writing it to limit_in_bytes.

> We've used this for a few years as a complement to oom notifiers so that a 
> process would have a grace period to deal with the oom condition itself 
> before allowing the kernel to terminate a process and free memory.  We've 
> simply had no alternative in the presence of kernel constraints that 
> prevent it from being done in any other way.  We _want_ userspace to deal 
> with the issue but when it cannot collect the necessary information (and 
> we're not tracing every fork() that every process in a potentially oom 
> memcg does) to deal with the condition, we want the kernel to step in 
> instead of relying on an admin to login or a global oom condition.
> 
> If you'd like to debate this issue, I'd be more than happy to do so and 
> show why this patch is absolutely necessary for inclusion, but I'd ask 
> that you'd present the code from your userspace oom handler so I can 
> understand how it works without needing such backup support.

I usually do not write those things myself as I am supporting others so
I do not have any code handy right now. But I can come up with a simple
handler which implements your timeout based killer for peak workloads
you have mentioned earlier. That one should be quite easy to do.
-- 
Michal Hocko
SUSE Labs
--
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/

Re: [PATCH] of: Export of_irq_count for using in modules

[Michal Simek]

Hi Jean-Christophe,

On 05/30/2013 10:17 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 15:49 Thu 30 May , Michal Simek wrote:
>> Export of_irq_count for modules.
> 
> can you explain why do you need to call of_irq_count

I need to count number of irq written in the DTS node.
It is not fixed size that's why I need to proper way how to
find it out.

I am using this loop.
count = of_irq_count(pdev->dev.of_node);
/* Alloc IRQ based on DTS to be sure that no other driver will use it */
while (count--) {
tmp->irq = irq_of_parse_and_map(pdev->dev.of_node, count);
dev_info(>dev, "%d: Alloc irq: %d\n", count, tmp->irq);
ret = request_irq(tmp->irq, zynq_remoteproc_interrupt, 0,
dev_name(>dev), >dev);
if (ret) {
...
}
}

But of course if you think that this is incorrect to export it
I can use what it is in of_irq_count body
368 int of_irq_count(struct device_node *dev)
369 {
370 int nr = 0;
371
372 while (of_irq_to_resource(dev, nr, NULL))
373 nr++;
374
375 return nr;
376 }

Because of_irq_to_resource is exported for modules.
Or is there any better way how to loop over all interrupts in DT node?

Thanks,
Michal

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform




signature.asc
Description: OpenPGP digital signature

Re: [PATCH v2 1/1] i2c: omap: correct usage of the interrupt enable register

[Oleksandr Dmytryshyn]

On 05/30/2013 07:46 PM, Kevin Hilman wrote:

Oleksandr Dmytryshyn  writes:


If the i2c controller during suspend will generate an interrupt, it
can lead to unpredictable behaviour in the kernel.

Based on the logic of the kernel code interrupts from i2c should be
prohibited during suspend. Kernel writes 0 to the I2C_IE register in
the omap_i2c_runtime_suspend() function. In the other side kernel
writes saved interrupt flags to the I2C_IE register in
omap_i2c_runtime_resume() function. I.e. interrupts should be disabled
during suspend.

This works for chips with version1 registers scheme. Interrupts are
disabled during suspend. For chips with version2 scheme registers
writting 0 to the I2C_IE register does nothing (because now the
I2C_IRQENABLE_SET register is located at this address). This register
is used to enable interrupts. For disabling interrupts
I2C_IRQENABLE_CLR register should be used.

Because the registers I2C_IRQENABLE_SET and I2C_IE have the same
addresses, the interrupt enabling procedure is unchanged.

Signed-off-by: Oleksandr Dmytryshyn 

Much better, but still doesn't explain how/why this has been working up
until now.  Have we just been lucky?

Yes, this has been working up until now because we've just been lucky.



---
  drivers/i2c/busses/i2c-omap.c | 15 +++
  1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index e02f9e3..2419899 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -180,6 +180,8 @@ enum {
  #define I2C_OMAP_ERRATA_I207  (1 << 0)
  #define I2C_OMAP_ERRATA_I462  (1 << 1)
  
+#define OMAP_I2C_INTERRUPTS_MASK	0x6FFF

To be more clear, this should probably have v2 in the name.

I'll rename this mask in the patch-set v3


Kevin




--

Best regards,
Oleksandr Dmytryshyn | OMAP4 Platform
GlobalLogic Inc. | Innovation by Design
--
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/

Re: [PATCH] dmatest: add ability to disable pq and xor

[Andy Shevchenko]

On Fri, May 17, 2013 at 8:54 PM, Jon Mason  wrote:
> dmatest would create a thread to stress XOR and PQ, if the capability is
> present in the hardware.  Add the ability to disable XOR and PQ by
> disabling it if *_sources are set to zero.

Sorry, didn't comment this earlier.

Those threads are independent including MEMCPY stuff.
I think it's better to have one additional parameter let's say
type_of_test where you can set
1 for MEMCPY
2 for XOR
4 for PQ

Share this parameter via debugfs and use 0x07 as default value.
I doubt we need this as a module parameter.

--
With Best Regards,
Andy Shevchenko
--
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/

Re: [PATCH v4 1/2] watchdog: New watchdog driver for MEN A21 watchdogs

[Johannes Thumshirn]

Hi Guenther,

On Thu, May 30, 2013 at 03:02:47PM -0700, Guenter Roeck wrote:
> On Thu, May 30, 2013 at 11:59:28PM +0200, Wim Van Sebroeck wrote:
> > Hi Guenter,
> >
[...]
>
> I even thought about adding this capability to the infrastructure.

Actually this would be pretty nice to have
>
> Thanks,
> Guenter

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

[PATCH] dma: mmp_pdma: support for getting residual bytes

[Xiang Wang]

From: Xiang Wang 

In some of our drivers (e.g. UART) we may stop a running DMA
before it finishes. So we need to know how many bytes have
been transferred.

Signed-off-by: Xiang Wang 
---
 drivers/dma/mmp_pdma.c |   77 +++-
 1 files changed, 69 insertions(+), 8 deletions(-)

diff --git a/drivers/dma/mmp_pdma.c b/drivers/dma/mmp_pdma.c
index 76a8dcf..0c623cc 100644
--- a/drivers/dma/mmp_pdma.c
+++ b/drivers/dma/mmp_pdma.c
@@ -104,7 +104,8 @@ struct mmp_pdma_chan {
spinlock_t desc_lock;   /* Descriptor list lock */
struct list_head chain_pending; /* Link descriptors queue for pending */
struct list_head chain_running; /* Link descriptors queue for running */
-   bool idle;  /* channel statue machine */
+   enum dma_status status; /* channel status machine */
+   u32 bytes_residue;
 
struct dma_pool *desc_pool; /* Descriptors pool */
 };
@@ -270,7 +271,7 @@ static void start_pending_queue(struct mmp_pdma_chan *chan)
struct mmp_pdma_desc_sw *desc;
 
/* still in running, irq will start the pending list */
-   if (!chan->idle) {
+   if (chan->status == DMA_IN_PROGRESS) {
dev_dbg(chan->dev, "DMA controller still busy\n");
return;
}
@@ -307,7 +308,55 @@ static void start_pending_queue(struct mmp_pdma_chan *chan)
 */
set_desc(chan->phy, desc->async_tx.phys);
enable_chan(chan->phy);
-   chan->idle = false;
+   chan->status = DMA_IN_PROGRESS;
+   chan->bytes_residue = 0;
+}
+
+/*
+ * Get the number of bytes untransferred by DMA.
+ */
+static u32 mmp_pdma_get_bytes_residue(struct mmp_pdma_chan *chan)
+{
+   u32 reg, orig_pos, cur_pos, residue = 0;
+   struct mmp_pdma_desc_sw *desc_sw;
+   struct list_head *list_chain = NULL;
+
+   /*
+* When a phy channel is unavailable, maybe its destroied, return last
+* stored value for safe.
+*/
+   if (!chan || !chan->phy)
+   return chan->bytes_residue;
+
+   if (!list_empty(>chain_running))
+   list_chain = >chain_running;
+   else
+   return 0;
+
+   desc_sw = list_first_entry(list_chain, struct mmp_pdma_desc_sw, node);
+
+   switch (chan->dir) {
+   case DMA_DEV_TO_MEM:
+   reg = (chan->phy->idx << 4) + DTADR;
+   cur_pos = readl_relaxed(chan->phy->base + reg);
+   orig_pos = desc_sw->desc.dtadr;
+   break;
+   case DMA_MEM_TO_DEV:
+   reg = (chan->phy->idx << 4) + DSADR;
+   cur_pos = readl_relaxed(chan->phy->base + reg);
+   orig_pos = desc_sw->desc.dsadr;
+   break;
+   case DMA_MEM_TO_MEM:
+   reg = (chan->phy->idx << 4) + DTADR;
+   cur_pos = readl_relaxed(chan->phy->base + reg);
+   orig_pos = desc_sw->desc.dtadr;
+   break;
+   default:
+   return 0;
+   }
+
+   residue = (u32)(desc_sw->desc.dcmd & DCMD_LENGTH) + orig_pos - cur_pos;
+   return residue;
 }
 
 
@@ -381,7 +430,7 @@ static int mmp_pdma_alloc_chan_resources(struct dma_chan 
*dchan)
chan->phy->vchan = NULL;
chan->phy = NULL;
}
-   chan->idle = true;
+   chan->status = DMA_SUCCESS;
chan->dev_addr = 0;
return 1;
 }
@@ -409,7 +458,7 @@ static void mmp_pdma_free_chan_resources(struct dma_chan 
*dchan)
 
dma_pool_destroy(chan->desc_pool);
chan->desc_pool = NULL;
-   chan->idle = true;
+   chan->status = DMA_SUCCESS;
chan->dev_addr = 0;
if (chan->phy) {
chan->phy->vchan = NULL;
@@ -589,7 +638,13 @@ static int mmp_pdma_control(struct dma_chan *dchan, enum 
dma_ctrl_cmd cmd,
mmp_pdma_free_desc_list(chan, >chain_pending);
mmp_pdma_free_desc_list(chan, >chain_running);
spin_unlock_irqrestore(>desc_lock, flags);
-   chan->idle = true;
+   chan->status = DMA_SUCCESS;
+   chan->bytes_residue = 0;
+   break;
+   case DMA_PAUSE:
+   disable_chan(chan->phy);
+   chan->status = DMA_PAUSED;
+   chan->bytes_residue = mmp_pdma_get_bytes_residue(chan);
break;
case DMA_SLAVE_CONFIG:
if (cfg->direction == DMA_DEV_TO_MEM) {
@@ -637,7 +692,8 @@ static enum dma_status mmp_pdma_tx_status(struct dma_chan 
*dchan,
unsigned long flags;
 
spin_lock_irqsave(>desc_lock, flags);
-   ret = dma_cookie_status(dchan, cookie, txstate);
+   ret = chan->status;
+   dma_set_residue(txstate, chan->bytes_residue);
spin_unlock_irqrestore(>desc_lock, flags);
 
return ret;
@@ -684,6 +740,8 @@ static void dma_do_tasklet(unsigned long data)
dev_dbg(chan->dev, "completed_cookie=%d\n", cookie);
}
 
+   /* 

Re: [RFC] Comparison of power-efficient scheduling patch sets

[Alex Shi]

On 05/31/2013 09:17 AM, Alex Shi wrote:
>> > Kernel: 3.9
>> > 
>> > Patch sets:
>> > rlb-v4: sched: use runnable load based balance (Alex Shi)
>> > 
> Thanks for the valuable comparison!
> 
> The runnable load balance target is performance. It is still try to
> disperse tasks to as much as possible CPUs. :)
> The latest v7 version remove the 6th patch(wake_affine change) in v4.
> and plus fix a slept time double counting issue, and remove
> blocked_load_avg in tg load.
> http://comments.gmane.org/gmane.linux.kernel/1498988

Even the rlb patch set target is performance, Maybe the power benefit is
due to better balancing?

Anyway I appreciate if you like to test the latest v7 version. :)
https://github.com/alexshi/power-scheduling.git runnablelb

-- 
Thanks
Alex
--
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/

Re: [PATCH v1 11/13] sfi: fix compiler warnings

[Andy Shevchenko]

On Thu, May 30, 2013 at 5:45 AM, Sathyanarayanan Kuppuswamy
 wrote:
> From: Andy Shevchenko 

Can you use newer version [1] of this patch?

[1] https://lkml.org/lkml/2013/5/28/83

--
With Best Regards,
Andy Shevchenko
--
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/

Re: [PATCH, resend 1/3] sfi: fix compiler warnings

[Andy Shevchenko]

Please, drop this one away.
Sathyanarayanan Kuppuswamy will take care of this in his patch series.
--
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/

[PATCH v3 1/1] i2c: omap: correct usage of the interrupt enable register

[Oleksandr Dmytryshyn]

If the i2c controller during suspend will generate an interrupt, it
can lead to unpredictable behaviour in the kernel.

Based on the logic of the kernel code interrupts from i2c should be
prohibited during suspend. Kernel writes 0 to the I2C_IE register in
the omap_i2c_runtime_suspend() function. In the other side kernel
writes saved interrupt flags to the I2C_IE register in
omap_i2c_runtime_resume() function. I.e. interrupts should be disabled
during suspend.

This works for chips with version1 registers scheme. Interrupts are
disabled during suspend. For chips with version2 scheme registers
writting 0 to the I2C_IE register does nothing (because now the
I2C_IRQENABLE_SET register is located at this address). This register
is used to enable interrupts. For disabling interrupts
I2C_IRQENABLE_CLR register should be used.

Because the registers I2C_IRQENABLE_SET and I2C_IE have the same
addresses, the interrupt enabling procedure is unchanged.

Change-Id: Ie49165990a4e7c67a4ccf2e4a66cd3b78f2e2b70
Signed-off-by: Oleksandr Dmytryshyn 
---
 drivers/i2c/busses/i2c-omap.c | 15 +++
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index e02f9e3..64c26f9 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -180,6 +180,8 @@ enum {
 #define I2C_OMAP_ERRATA_I207   (1 << 0)
 #define I2C_OMAP_ERRATA_I462   (1 << 1)
 
+#define OMAP_I2C_IP_V2_INTERRUPTS_MASK 0x6FFF
+
 struct omap_i2c_dev {
spinlock_t  lock;   /* IRQ synchronization */
struct device   *dev;
@@ -193,6 +195,7 @@ struct omap_i2c_dev {
long latency);
u32 speed;  /* Speed of bus in kHz */
u32 flags;
+   u16 scheme;
u16 cmd_err;
u8  *buf;
u8  *regs;
@@ -1082,7 +1085,7 @@ omap_i2c_probe(struct platform_device *pdev)
int irq;
int r;
u32 rev;
-   u16 minor, major, scheme;
+   u16 minor, major;
 
/* NOTE: driver uses the static register mapping */
mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -1159,8 +1162,8 @@ omap_i2c_probe(struct platform_device *pdev)
 */
rev = __raw_readw(dev->base + 0x04);
 
-   scheme = OMAP_I2C_SCHEME(rev);
-   switch (scheme) {
+   dev->scheme = OMAP_I2C_SCHEME(rev);
+   switch (dev->scheme) {
case OMAP_I2C_SCHEME_0:
dev->regs = (u8 *)reg_map_ip_v1;
dev->rev = omap_i2c_read_reg(dev, OMAP_I2C_REV_REG);
@@ -1289,7 +1292,11 @@ static int omap_i2c_runtime_suspend(struct device *dev)
 
_dev->iestate = omap_i2c_read_reg(_dev, OMAP_I2C_IE_REG);
 
-   omap_i2c_write_reg(_dev, OMAP_I2C_IE_REG, 0);
+   if (_dev->scheme == OMAP_I2C_SCHEME_0)
+   omap_i2c_write_reg(_dev, OMAP_I2C_IE_REG, 0);
+   else
+   omap_i2c_write_reg(_dev, OMAP_I2C_IP_V2_IRQENABLE_CLR,
+  OMAP_I2C_IP_V2_INTERRUPTS_MASK);
 
if (_dev->rev < OMAP_I2C_OMAP1_REV_2) {
omap_i2c_read_reg(_dev, OMAP_I2C_IV_REG); /* Read clears */
-- 
1.8.2.rc2

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

[PATCH v3 0/1] i2c: omap: correct usage of the interrupt enable register

[Oleksandr Dmytryshyn]

I've just renamed OMAP_I2C_INTERRUPTS_MASK to the
OMAP_I2C_IP_V2_INTERRUPTS_MASK.

If the i2c controller during suspend will generate an interrupt, it
can lead to unpredictable behaviour in the kernel.

Based on the logic of the kernel code interrupts from i2c should be
prohibited during suspend. Kernel writes 0 to the I2C_IE register in
the omap_i2c_runtime_suspend() function. In the other side kernel
writes saved interrupt flags to the I2C_IE register in
omap_i2c_runtime_resume() function. I.e. interrupts should be disabled
during suspend.

This works for chips with version1 registers scheme. Interrupts are
disabled during suspend. For chips with version2 scheme registers
writting 0 to the I2C_IE register does nothing (because now the
I2C_IRQENABLE_SET register is located at this address). This register
is used to enable interrupts. For disabling interrupts
I2C_IRQENABLE_CLR register should be used.

Because the registers I2C_IRQENABLE_SET and I2C_IE have the same
addresses, the interrupt enabling procedure is unchanged.

I've checked that interrupts in the i2c controller are still enabled
after writting 0 to the I2C_IE register. But with my patch interrupts
are disabled in the omap_i2c_runtime_suspend() function. 

This has been working up until now because we've just been lucky. 

Next patch fixes it.

Patch is based on:
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
tag: v3.10-rc2

Verified on OMAP4430.

Oleksandr Dmytryshyn (1):
  i2c: omap: correct usage of the interrupt enable register

 drivers/i2c/busses/i2c-omap.c | 15 +++
 1 file changed, 11 insertions(+), 4 deletions(-)

-- 
1.8.2.rc2

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

Re: Network issue on 3.10 rcs, bisected

[Joao Correia]

On Fri, May 31, 2013 at 12:13 AM, Pravin Shelar  wrote:
> On Thu, May 30, 2013 at 2:14 PM, Joao Correia
>  wrote:
>> On Thu, May 30, 2013 at 5:48 PM, Pravin Shelar  wrote:
>>> On Wed, May 29, 2013 at 12:53 PM, Joao Correia
>>>  wrote:
 On Wed, May 29, 2013 at 7:59 PM, Pravin Shelar  wrote:
>
> On Wed, May 29, 2013 at 4:37 AM, Joao Correia
>  wrote:
> > Hello list
> >
> > While trying the rc's for 3.10, i've stumbled upon a problem where
> > networking does not work at all. Iptables will show packet counts going 
> > up,
> > but nothing actually reaches the programs.
> >
> > I'm running fedora under hyper-v 3 (a windows 2012 host). Only tested 
> > ipv4
> > traffic, and everything times out (ping, telnet to open ports) on both
> > directions. The networking devices come up apparently ok - has static ip
> > set, and dmesg shows no errors (although i don't have many debugging 
> > options
> > enabled).
> >
> > I bisected this, and git blames commit
> > ec5f061564238892005257c83565a0b58ec79295 (net: ill link between CSUM 
> > and SG
> > features.). I can't revert it cleanly on current rc's.
> >
> Can you also send network features set on the device?
> ethtool -k 


 As requested:
 Features for eth0:
 rx-checksumming: off [fixed]
 tx-checksumming: off
 tx-checksum-ipv4: off [fixed]
 tx-checksum-ip-generic: off [fixed]
 tx-checksum-ipv6: off [fixed]
 tx-checksum-fcoe-crc: off [fixed]
 tx-checksum-sctp: off [fixed]
 scatter-gather: on
 tx-scatter-gather: on
 tx-scatter-gather-fraglist: off [fixed]
 tcp-segmentation-offload: off
 tx-tcp-segmentation: off [fixed]
 tx-tcp-ecn-segmentation: off [fixed]
 tx-tcp6-segmentation: off [fixed]
 udp-fragmentation-offload: off [fixed]
 generic-segmentation-offload: on
 generic-receive-offload: on
 large-receive-offload: off [fixed]
 rx-vlan-offload: off
 tx-vlan-offload: on
 ntuple-filters: off [fixed]
 receive-hashing: off [fixed]
 highdma: off [fixed]
 tx-vlan-ctag-hw-insert: on [fixed]
 rx-vlan-ctag-hw-parse: off [fixed]
 rx-vlan-ctag-filter: off [fixed]
 tx-vlan-stag-hw-insert: off [fixed]
 rx-vlan-stag-hw-parse: off [fixed]
 rx-vlan-stag-filter: off [fixed]
 vlan-challenged: off [fixed]
 tx-lockless: off [fixed]
 netns-local: off [fixed]
 tx-gso-robust: off [fixed]
 tx-fcoe-segmentation: off [fixed]
 tx-gre-segmentation: off [fixed]
 tx-udp_tnl-segmentation: off [fixed]
 fcoe-mtu: off [fixed]
 tx-nocache-copy: off
 loopback: off [fixed]
 rx-fcs: off [fixed]
 rx-all: off [fixed]

 The output is similar on a working (3.9) and a bad (3.10) kernel.
 diff-ing both outputs shows:
 tx-vlan-stag-hw-insert: off [fixed]
 rx-vlan-stag-hw-parse: off [fixed]
 rx-vlan-stag-filter: off [fixed]
 as last on the broken kernels.

>>>
>>> I could not reproduce it, I will try it on VM. Meanwhile can you turn
>>> off feature "sg" and try same test ?
>>
>> Hello
>>
>> Your hint was spot-on. With sg off, i can't reproduce the problem and
>> networking seems fine. It works fine either way on 3.9, so this is a
>> regression for 3.10.
>>
> Nice.
> but still this does not look right. Can you tell me driver for the nic?
> `ethtool -i `

ethtool -i eth0:
driver: hv_netvsc
version: 3.1
firmware-version: N/A
bus-info:
supports-statistics: no
supports-test: no
supports-eeprom-access: no
supports-register-dump: no
supports-priv-flags: no

>
> Thanks,
> Pravin.
--
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/

Re: [PATCH] dma: mmp_pdma: support for getting residual bytes

[Andy Shevchenko]

On Fri, May 31, 2013 at 11:21 AM, Xiang Wang  wrote:
> In some of our drivers (e.g. UART) we may stop a running DMA
> before it finishes. So we need to know how many bytes have
> been transferred.

Couple of comments below.

> --- a/drivers/dma/mmp_pdma.c
> +++ b/drivers/dma/mmp_pdma.c

> @@ -589,7 +638,13 @@ static int mmp_pdma_control(struct dma_chan *dchan, enum 
> dma_ctrl_cmd cmd,
> mmp_pdma_free_desc_list(chan, >chain_pending);
> mmp_pdma_free_desc_list(chan, >chain_running);
> spin_unlock_irqrestore(>desc_lock, flags);
> -   chan->idle = true;
> +   chan->status = DMA_SUCCESS;
> +   chan->bytes_residue = 0;
> +   break;
> +   case DMA_PAUSE:
> +   disable_chan(chan->phy);
> +   chan->status = DMA_PAUSED;
> +   chan->bytes_residue = mmp_pdma_get_bytes_residue(chan);

Does it mean user has to do DMA_PAUSE first to get more or less
accurate residue?
Logically that sound correct, but in general we may allow user to get
approximate residue value of on going transfer.

> break;
> case DMA_SLAVE_CONFIG:
> if (cfg->direction == DMA_DEV_TO_MEM) {
> @@ -637,7 +692,8 @@ static enum dma_status mmp_pdma_tx_status(struct dma_chan 
> *dchan,
> unsigned long flags;
>
> spin_lock_irqsave(>desc_lock, flags);
> -   ret = dma_cookie_status(dchan, cookie, txstate);
> +   ret = chan->status;
> +   dma_set_residue(txstate, chan->bytes_residue);
> spin_unlock_irqrestore(>desc_lock, flags);

Besides my patch which removes this spinlock I think the workflow
should be something like

status = dma_cookie_status()
if status == DMA_SUCCESS or !txstate:
return status

dma_set_residue()
return status

Because there is no reason to return residue of successfully finished
transfer. It should be 0.

--
With Best Regards,
Andy Shevchenko
--
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/

Re: [PATCH 7/7] tulip: remove redundant D0 power state set

[David Miller]

From: Grant Grundler 
Date: Thu, 30 May 2013 08:31:38 -0700

> On Thu, May 30, 2013 at 3:27 AM, Yijing Wang  wrote:
>> Pci_enable_device() will set device power state to D0,
>> so it's no need to do it again in tulip_init_one().
>>
>> Signed-off-by: Yijing Wang 
> 
> Ack-by: Grant Grundler 

(it's Acked-by)  Applied, thanks.
--
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/

Re: [PATCH v1 00/13] mrst refactoring patches

[Andy Shevchenko]

On Thu, May 30, 2013 at 5:45 AM, Sathyanarayanan Kuppuswamy
 wrote:
> As Intel rolling out more SoC's after Moorestown, we need to re-structure
> the code in a way that is backward compatible and easy to expand.This
> patch set implements a flexible way to support multiple boards and devices.
>
> Patch 1 - 5 fixes some indentation issue, compiler warnings and renames.
> Patch 6 - 13 refactors mrst code.

First of all, please, remove Gerrit IDs from the commit messages.

> Andy Shevchenko (2):
>   sfi: fix compiler warnings
>   gpiolib: append SFI helpers for GPIO API

I still insist you may move my patches before you do split to the device_lib.

Now you do some cleaning up, than split, than move to new GPIO API.
In proposed case you will have one step less.

Other comments are provided by patch.

P.S. There are new versions of my patches. One of them was published
already, I put a link in the comment, the other will be ready soon
(addressing Linus' comments).

-- 
With Best Regards,
Andy Shevchenko
--
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/

Re: [tip:x86/microcode] x86, microcode, amd: Early microcode patch loading support for AMD

[Borislav Petkov]

On Thu, May 30, 2013 at 08:31:08PM -0700, tip-bot for Jacob Shin wrote:
> Commit-ID:  757885e94a22bcc82beb9b1445c95218cb20ceab
> Gitweb: http://git.kernel.org/tip/757885e94a22bcc82beb9b1445c95218cb20ceab
> Author: Jacob Shin 
> AuthorDate: Thu, 30 May 2013 14:09:19 -0500
> Committer:  H. Peter Anvin 
> CommitDate: Thu, 30 May 2013 20:19:25 -0700
> 
> x86, microcode, amd: Early microcode patch loading support for AMD
> 
> Add early microcode patch loading support for AMD.
> 
> Signed-off-by: Jacob Shin 
> Link: 
> http://lkml.kernel.org/r/1369940959-2077-5-git-send-email-jacob.s...@amd.com
> Signed-off-by: H. Peter Anvin 
> Cc: Fenghua Yu 
> ---

...

> diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
> index 7bd3bd3..6c3fcea 100644
> --- a/arch/x86/kernel/Makefile
> +++ b/arch/x86/kernel/Makefile
> @@ -93,6 +93,7 @@ obj-$(CONFIG_MICROCODE_INTEL_LIB)   += microcode_intel_lib.o
>  microcode-y  := microcode_core.o
>  microcode-$(CONFIG_MICROCODE_INTEL)  += microcode_intel.o
>  microcode-$(CONFIG_MICROCODE_AMD)+= microcode_amd.o
> +obj-$(CONFIG_MICROCODE_AMD_EARLY)+= microcode_amd_early.o
>  obj-$(CONFIG_MICROCODE)  += microcode.o

This can't be right:

WARNING: modpost: Found 1 section mismatch(es).
To see full details build your kernel with:
'make CONFIG_DEBUG_SECTION_MISMATCH=y'
arch/x86/built-in.o: In function `apply_ucode_in_initrd':
/home/boris/kernel/linux-2.6/arch/x86/kernel/microcode_amd_early.c:118: 
undefined reference to `__apply_microcode_amd'
arch/x86/built-in.o: In function `save_microcode_in_initrd_amd':
/home/boris/kernel/linux-2.6/arch/x86/kernel/microcode_amd_early.c:216: 
undefined reference to `load_microcode_amd'
arch/x86/built-in.o: In function `collect_cpu_info_amd_early':
/home/boris/kernel/linux-2.6/arch/x86/kernel/microcode_amd_early.c:171: 
undefined reference to `ucode_cpu_info'
/home/boris/kernel/linux-2.6/arch/x86/kernel/microcode_amd_early.c:172: 
undefined reference to `ucode_cpu_info'
arch/x86/built-in.o: In function `load_ucode_amd_ap':
/home/boris/kernel/linux-2.6/arch/x86/kernel/microcode_amd_early.c:185: 
undefined reference to `load_microcode_amd'
/home/boris/kernel/linux-2.6/arch/x86/kernel/microcode_amd_early.c:190: 
undefined reference to `apply_microcode_amd'
make: *** [vmlinux] Error 1

$ grep MICROCODE .config
CONFIG_MICROCODE=m
CONFIG_MICROCODE_INTEL=y
CONFIG_MICROCODE_AMD=y
CONFIG_MICROCODE_OLD_INTERFACE=y
CONFIG_MICROCODE_INTEL_LIB=y
CONFIG_MICROCODE_INTEL_EARLY=y
CONFIG_MICROCODE_AMD_EARLY=y
CONFIG_MICROCODE_EARLY=y

Jacob, as a tip for you: before sending out patches, always do a

for ARCH in "i386" "x86_64"
do
for cfg in "defconfig" "allnoconfig" "allyesconfig" "allmodconfig"
do
make -j $ARCH $cfg
done
done

to smoke-test your patches. I'm not saying this should catch all build
errors but still...

Thanks.
--
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/

Re: [PATCH net/3.9] ipv6: ndisc: fix ndisc_send_redirect writing to the wrong skb

[David Miller]

From: Cong Wang 
Date: Fri, 31 May 2013 11:23:11 +0800

> On Fri, May 31, 2013 at 9:27 AM, Matthias Schiffer
>  wrote:
>> Since some refactoring in 5f5a011, ndisc_send_redirect called
>> ndisc_fill_redirect_hdr_option on the wrong skb, leading to data corruption 
>> or
>> in the worst case a panic when the skb_put failed.
>>
>> Signed-off-by: Matthias Schiffer 
> 
> 
> Good catch!
> 
> Reviewed-by: Cong Wang 

I've queued this up for -stable.
--
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/

Re: [PATCH v2 1/4] ARM: davinci: dm365 evm: remove init_enable from ths7303 pdata

[Prabhakar Lad]

Hi Sekhar,

On Sat, May 25, 2013 at 11:13 PM, Prabhakar Lad
 wrote:
> Hi Sekhar,
>
> On Sat, May 25, 2013 at 11:09 PM, Prabhakar Lad
>  wrote:
>> From: Lad, Prabhakar 
>>
>> remove init_enable from ths7303 pdata as it is being dropped
>> from ths7303_platform_data.
>>
> Can you please ack this patch as I intend to take this patch via media
> tree.
gentle ping.

Regards,
--Prabhakar
--
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/

Re: A bug about system call on ARM

[Will Deacon]

On Fri, May 31, 2013 at 04:54:56AM +0100, Nicolas Pitre wrote:
> On Thu, 30 May 2013, Will Deacon wrote:
> 
> > On Thu, May 30, 2013 at 10:09:49AM +0100, Will Deacon wrote:
> > > On Thu, May 30, 2013 at 02:41:42AM +0100, Wang, Yalin wrote:
> > > > If you have some patch for this issue,
> > > > I can do the test for it .
> > > 
> > > I'll have a look at cooking something which uses an exception table entry
> > > to rewind the PC and retry the system call. That's simpler than directly
> > > injecting a user page fault from the system call path.
> > 
> > Ok, please can you try the following?
> > 
> > Will
> > 
> > --->8
> > 
> > diff --git a/arch/arm/kernel/entry-common.S b/arch/arm/kernel/entry-common.S
> > index bc5bc0a..855926e 100644
> > --- a/arch/arm/kernel/entry-common.S
> > +++ b/arch/arm/kernel/entry-common.S
> > @@ -361,6 +361,15 @@ ENTRY(vector_swi)
> > str r8, [sp, #S_PSR]@ Save CPSR
> > str r0, [sp, #S_OLD_R0] @ Save OLD_R0
> > zero_fp
> > +   enable_irq
> > +   ct_user_exit
> > +
> > +#ifdef CONFIG_ALIGNMENT_TRAP
> > +   ldr ip, __cr_alignment
> > +   ldr ip, [ip]
> > +   mcr p15, 0, ip, c1, c0  @ update control register
> > +#endif
> 
> This is wrong.  you must set up the align bit in the control register 
> _before_ enabling IRQs or an IRQ handler might run without alignment 
> fixup.

Okey doke, I can fix that up. I thought it was only needed for the network
layer, but I suppose they have interrupts over there too :)

> Otherwise the patch looks good to me.

Thanks Nicolas.

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

Re: [PATCH 2/2] spi: convert drivers to use bits_per_word_mask

[Arnd Bergmann]

Can you check this part again:

On Tuesday 21 May 2013 20:36:35 Stephen Warren wrote:
> diff --git a/drivers/spi/spi-pxa2xx.c b/drivers/spi/spi-pxa2xx.c
> index f5d84d6..7de2ca1 100644
> --- a/drivers/spi/spi-pxa2xx.c
> +++ b/drivers/spi/spi-pxa2xx.c
> @@ -881,21 +881,6 @@ static int setup(struct spi_device *spi)
> rx_thres = RX_THRESH_DFLT;
> }
>  
> -   if (!pxa25x_ssp_comp(drv_data)
> -   && (spi->bits_per_word < 4 || spi->bits_per_word > 32)) {
> -   dev_err(>dev, "failed setup: ssp_type=%d, bits/wrd=%d "
> -   "b/w not 4-32 for type non-PXA25x_SSP\n",
> -   drv_data->ssp_type, spi->bits_per_word);
> -   return -EINVAL;
> -   } else if (pxa25x_ssp_comp(drv_data)
> -   && (spi->bits_per_word < 4
> -   || spi->bits_per_word > 16)) {
> -   dev_err(>dev, "failed setup: ssp_type=%d, bits/wrd=%d "
> -   "b/w not 4-16 for type PXA25x_SSP\n",
> -   drv_data->ssp_type, spi->bits_per_word);
> -   return -EINVAL;
> -   }
> -
> /* Only alloc on first setup */
> chip = spi_get_ctldata(spi);
> if (!chip) {
> @@ -1011,9 +996,6 @@ static int setup(struct spi_device *spi)
> chip->n_bytes = 4;
> chip->read = u32_reader;
> chip->write = u32_writer;
> -   } else {
> -   dev_err(>dev, "invalid wordsize\n");
> -   return -ENODEV;
> }
> chip->bits_per_word = spi->bits_per_word;
>  
> @@ -1190,11 +1172,13 @@ static int pxa2xx_spi_probe(struct platform_device 
> *pdev)
> drv_data->ioaddr = ssp->mmio_base;
> drv_data->ssdr_physical = ssp->phys_base + SSDR;
> if (pxa25x_ssp_comp(drv_data)) {
> +   master->bits_per_word_mask = SPI_BPW_RANGE_MASK(4, 16);
> drv_data->int_cr1 = SSCR1_TIE | SSCR1_RIE;
> drv_data->dma_cr1 = 0;
> drv_data->clear_sr = SSSR_ROR;
> drv_data->mask_sr = SSSR_RFS | SSSR_TFS | SSSR_ROR;
> } else {
> +   master->bits_per_word_mask = SPI_BPW_RANGE_MASK(4, 32);
> drv_data->int_cr1 = SSCR1_TIE | SSCR1_RIE | SSCR1_TINTE;
> drv_data->dma_cr1 = DEFAULT_DMA_CR1;
> drv_data->clear_sr = SSSR_ROR | SSSR_TINT;

I get a new build warning

drivers/spi/spi-pxa2xx.c: In function 'pxa2xx_spi_probe':
drivers/spi/spi-pxa2xx.c:1152:3: warning: left shift count >= width of type 
[enabled by default]
   master->bits_per_word_mask = SPI_BPW_RANGE_MASK(4, 32);
   ^

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

[PATCH 05/16] perf, persistent: Return resonable error code

[Robert Richter]

From: Robert Richter 

Returning -ENODEV if no file descriptor is found. An error code of -1
(-EPERM) is misleading in this case.

Signed-off-by: Robert Richter 
---
 kernel/events/persistent.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/events/persistent.c b/kernel/events/persistent.c
index 6612eb77..190aa75 100644
--- a/kernel/events/persistent.c
+++ b/kernel/events/persistent.c
@@ -165,7 +165,7 @@ int perf_get_persistent_event_fd(unsigned cpu, struct 
perf_event_attr *attr)
if (desc->attr->config == attr->config)
return __alloc_persistent_event_fd(desc);
 
-   return -1;
+   return -ENODEV;
 }
 
 
-- 
1.8.1.1

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

Re: A bug about system call on ARM

[Will Deacon]

On Fri, May 31, 2013 at 03:56:31AM +0100, Wang, Yalin wrote:
> Hi Will,
> 
> Thanks for your patch ,
> 
> But I found  I don't have ct_user_exit  macro 
> In my arch/arm/kernel/entry-common.S 
> 
> My kernel version is 3.4.0 

Well things have moved on this since then (we're approaching 3.10, so you
might consider an upgrade!).

For the purposes of this patch, you can just delete the ct_user_exit line.

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

[PATCH 01/16] perf, persistent: Fix build error for no-tracepoints configs

[Robert Richter]

From: Robert Richter 

The mce_record tracepoint needs tracepoints to be enabled. Fixing
build error for no-tracepoints configs.

Signed-off-by: Robert Richter 
---
 arch/x86/kernel/cpu/mcheck/mce.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index 0ecf4a2..d421937 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -1987,6 +1987,8 @@ int __init mcheck_init(void)
return 0;
 }
 
+#ifdef CONFIG_TRACEPOINTS
+
 int __init mcheck_init_tp(void)
 {
if (perf_add_persistent_event_by_id(event_mce_record.event.type)) {
@@ -2001,6 +2003,8 @@ int __init mcheck_init_tp(void)
  */
 fs_initcall_sync(mcheck_init_tp);
 
+#endif /* CONFIG_TRACEPOINTS */
+
 /*
  * mce_syscore: PM support
  */
-- 
1.8.1.1

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

[PATCH 16/16] perf, persistent: Allow multiple users for an event

[Robert Richter]

From: Robert Richter 

Usually a fd close leads to the release of the event too. For
persistent events this is different as the events should be
permanently enabled in the system. Using reference counting to avoid
releasing an event during a fd close. This also allows it to have
multiple users (open file descriptors) for a single persistent event.

While at this, we don't need desc->fd any longer. The fd is attached
to a task and reference counting keeps the event. Removing desc->fd.

Signed-off-by: Robert Richter 
---
 kernel/events/persistent.c | 46 --
 1 file changed, 36 insertions(+), 10 deletions(-)

diff --git a/kernel/events/persistent.c b/kernel/events/persistent.c
index a764144..4920702 100644
--- a/kernel/events/persistent.c
+++ b/kernel/events/persistent.c
@@ -11,7 +11,6 @@
 struct pers_event_desc {
struct perf_event *event;
struct list_head plist;
-   int fd;
 };
 
 struct pers_event {
@@ -88,6 +87,18 @@ out:
return event;
 }
 
+static void detach_persistent_event(struct pers_event_desc *desc)
+{
+   list_del(>plist);
+   kfree(desc);
+}
+
+static void release_persistent_event(struct perf_event *event)
+{
+   perf_event_disable(event);
+   perf_event_release_kernel(event);
+}
+
 static void del_persistent_event(int cpu, struct perf_event_attr *attr)
 {
struct pers_event_desc *desc;
@@ -100,12 +111,14 @@ static void del_persistent_event(int cpu, struct 
perf_event_attr *attr)
goto out;
event = desc->event;
 
-   list_del(>plist);
-
-   perf_event_disable(event);
-   perf_event_release_kernel(event);
-   put_unused_fd(desc->fd);
-   kfree(desc);
+   /*
+* We primarily want to remove desc from the list. If there
+* are no open files, the refcount is 0 and we need to release
+* the event too.
+*/
+   detach_persistent_event(desc);
+   if (atomic_long_dec_and_test(>refcount))
+   release_persistent_event(event);
 out:
mutex_unlock(_cpu(pers_events_lock, cpu));
 }
@@ -182,18 +195,31 @@ fail:
 int perf_get_persistent_event_fd(unsigned cpu, struct perf_event_attr *attr)
 {
struct pers_event_desc *desc;
+   struct perf_event *event;
int event_fd = -ENODEV;
 
mutex_lock(_cpu(pers_events_lock, cpu));
 
desc = get_persistent_event(cpu, attr);
-   if (!desc)
+
+   /* Increment refcount to keep event on put_event() */
+   if (!desc || !atomic_long_inc_not_zero(>event->refcount))
goto out;
 
event_fd = anon_inode_getfd("[pers_event]", _fops,
desc->event, O_RDONLY);
-   if (event_fd >= 0)
-   desc->fd = event_fd;
+
+   if (event_fd < 0) {
+   event = desc->event;
+   if (WARN_ON(atomic_long_dec_and_test(>refcount))) {
+   /*
+* May not happen since decrementing refcount is
+* protected by pers_events_lock.
+*/
+   detach_persistent_event(desc);
+   release_persistent_event(event);
+   }
+   }
 out:
mutex_unlock(_cpu(pers_events_lock, cpu));
 
-- 
1.8.1.1

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

[PATCH 06/16] perf, persistent: Return -EACCES if mapped buffers must be readonly

[Robert Richter]

From: Robert Richter 

mmap should return EACCES error if fd can not be opened writable.
This error code also helps userland to map buffers readonly on
failure.

Signed-off-by: Robert Richter 
---
 kernel/events/core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/events/core.c b/kernel/events/core.c
index 0730f36..a9b6470 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -3761,7 +3761,7 @@ static int perf_mmap(struct file *file, struct 
vm_area_struct *vma)
return -EINVAL;
 
if (event->attr.persistent && (vma->vm_flags & VM_WRITE))
-   return -EINVAL;
+   return -EACCES;
 
vma_size = vma->vm_end - vma->vm_start;
nr_pages = (vma_size / PAGE_SIZE) - 1;
-- 
1.8.1.1

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

[PATCH 07/16] perf, persistent: Rework struct pers_event_desc

[Robert Richter]

From: Robert Richter 

Struct pers_event_desc is only used in kernel/events/persistent.c.
Moving it there. Also, removing attr member as this is a copy of
event->attr.

Signed-off-by: Robert Richter 
---
 include/linux/perf_event.h |  7 ---
 kernel/events/persistent.c | 12 
 2 files changed, 8 insertions(+), 11 deletions(-)

diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index d2a42b7..dc72c93 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -518,13 +518,6 @@ struct perf_output_handle {
int page;
 };
 
-struct pers_event_desc {
-   struct perf_event_attr *attr;
-   struct perf_event *event;
-   struct list_head plist;
-   int fd;
-};
-
 #ifdef CONFIG_PERF_EVENTS
 
 extern int perf_pmu_register(struct pmu *pmu, char *name, int type);
diff --git a/kernel/events/persistent.c b/kernel/events/persistent.c
index 190aa75..22297e5 100644
--- a/kernel/events/persistent.c
+++ b/kernel/events/persistent.c
@@ -8,6 +8,12 @@
 /* 512 kiB: default perf tools memory size, see perf_evlist__mmap() */
 #define CPU_BUFFER_NR_PAGES((512 * 1024) / PAGE_SIZE)
 
+struct pers_event_desc {
+   struct perf_event *event;
+   struct list_head plist;
+   int fd;
+};
+
 static DEFINE_PER_CPU(struct list_head, pers_events);
 
 static struct perf_event *
@@ -33,7 +39,6 @@ add_persistent_event_on_cpu(unsigned int cpu, struct 
perf_event_attr *attr,
rcu_assign_pointer(event->rb, buf);
 
desc->event = event;
-   desc->attr  = attr;
 
INIT_LIST_HEAD(>plist);
list_add_tail(>plist, _cpu(pers_events, cpu));
@@ -59,7 +64,7 @@ static void del_persistent_event(int cpu, struct 
perf_event_attr *attr)
struct perf_event *event = NULL;
 
list_for_each_entry_safe(desc, tmp, _cpu(pers_events, cpu), plist) {
-   if (desc->attr->config == attr->config) {
+   if (desc->event->attr.config == attr->config) {
event = desc->event;
break;
}
@@ -78,7 +83,6 @@ static void del_persistent_event(int cpu, struct 
perf_event_attr *attr)
 
perf_event_release_kernel(event);
put_unused_fd(desc->fd);
-   kfree(desc->attr);
kfree(desc);
 }
 
@@ -162,7 +166,7 @@ int perf_get_persistent_event_fd(unsigned cpu, struct 
perf_event_attr *attr)
struct pers_event_desc *desc;
 
list_for_each_entry(desc, _cpu(pers_events, cpu), plist)
-   if (desc->attr->config == attr->config)
+   if (desc->event->attr.config == attr->config)
return __alloc_persistent_event_fd(desc);
 
return -ENODEV;
-- 
1.8.1.1

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

[PATCH 15/16] perf, persistent: Exposing persistent events using sysfs

[Robert Richter]

From: Robert Richter 

Expose persistent events in the system to userland using sysfs. Perf
tools are able to read existing pmu events from sysfs. Now we use a
persistent pmu as an event container containing all registered
persistent events of the system. This patch adds dynamically
registration of persistent events to sysfs. E.g. something like this:

 
/sys/bus/event_source/devices/persistent/events/mce_record:persistent,config=106
 /sys/bus/event_source/devices/persistent/format/persistent:attr5:23

Perf tools need to support the attr syntax that is added in a
separate patch set. With it we are able to run perf tool commands to
read persistent events, e.g.:

 # perf record -e persistent/mce_record/ sleep 10
 # perf top -e persistent/mce_record/

Signed-off-by: Robert Richter 
---
 kernel/events/persistent.c | 55 +-
 1 file changed, 54 insertions(+), 1 deletion(-)

diff --git a/kernel/events/persistent.c b/kernel/events/persistent.c
index d5093a3..a764144 100644
--- a/kernel/events/persistent.c
+++ b/kernel/events/persistent.c
@@ -17,8 +17,10 @@ struct pers_event_desc {
 struct pers_event {
char*name;
struct perf_event_attr  attr;
+   struct perf_pmu_events_attr sysfs;
 };
 
+static struct pmu persistent_pmu;
 static DEFINE_PER_CPU(struct list_head, pers_events);
 static DEFINE_PER_CPU(struct mutex, pers_events_lock);
 
@@ -137,6 +139,8 @@ unwind:
return PTR_ERR(event);
 }
 
+static int pers_event_sysfs_register(struct pers_event *event);
+
 int perf_add_persistent_event_by_id(char* name, int id)
 {
struct pers_event   *event;
@@ -150,6 +154,8 @@ int perf_add_persistent_event_by_id(char* name, int id)
if (!event->name)
goto fail;
 
+   event->sysfs.id = id;
+
attr = >attr;
attr->sample_period = 1;
attr->wakeup_events = 1;
@@ -163,6 +169,8 @@ int perf_add_persistent_event_by_id(char* name, int id)
if (ret)
goto fail;
 
+   pers_event_sysfs_register(event);
+
return 0;
 fail:
kfree(event->name);
@@ -204,12 +212,57 @@ static struct attribute_group persistent_format_group = {
.attrs = persistent_format_attrs,
 };
 
+#define MAX_EVENTS 16
+
+static struct attribute *persistent_events_attr[MAX_EVENTS + 1] = { };
+
+static struct attribute_group persistent_events_group = {
+   .name = "events",
+   .attrs = persistent_events_attr,
+};
+
 static const struct attribute_group *persistent_attr_groups[] = {
_format_group,
+   NULL, /* placeholder: _events_group */
NULL,
 };
+#define EVENTS_GROUP   (persistent_attr_groups[1])
 
-static struct pmu persistent_pmu;
+static ssize_t pers_event_sysfs_show(struct device *dev,
+   struct device_attribute *__attr, char *page)
+{
+   struct perf_pmu_events_attr *attr =
+   container_of(__attr, struct perf_pmu_events_attr, attr);
+   return sprintf(page, "persistent,config=%lld",
+   (unsigned long long)attr->id);
+}
+
+static int pers_event_sysfs_register(struct pers_event *event)
+{
+   struct device_attribute *attr = >sysfs.attr;
+   int idx;
+
+   *attr = (struct device_attribute)__ATTR(, 0444, pers_event_sysfs_show,
+   NULL);
+   attr->attr.name = event->name;
+
+   /* add sysfs attr to events: */
+   for (idx = 0; idx < MAX_EVENTS; idx++) {
+   if (!cmpxchg(persistent_events_attr + idx, NULL, >attr))
+   break;
+   }
+
+   if (idx >= MAX_EVENTS)
+   return -ENOSPC;
+   if (!idx)
+   EVENTS_GROUP = _events_group;
+   if (!persistent_pmu.dev)
+   return 0;   /* sysfs not yet initialized */
+   if (idx)
+   return sysfs_update_group(_pmu.dev->kobj,
+   EVENTS_GROUP);
+   return sysfs_create_group(_pmu.dev->kobj, EVENTS_GROUP);
+}
 
 static int persistent_pmu_init(struct perf_event *event)
 {
-- 
1.8.1.1

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

[PATCH 12/16] perf, persistent: Avoid adding identical events

[Robert Richter]

From: Robert Richter 

Check if an event already exists before adding it.

Signed-off-by: Robert Richter 
---
 kernel/events/persistent.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/kernel/events/persistent.c b/kernel/events/persistent.c
index ebef089..1e93b51 100644
--- a/kernel/events/persistent.c
+++ b/kernel/events/persistent.c
@@ -40,6 +40,12 @@ add_persistent_event_on_cpu(unsigned int cpu, struct 
perf_event_attr *attr,
 
mutex_lock(_cpu(pers_events_lock, cpu));
 
+   desc = get_persistent_event(cpu, attr);
+   if (desc) {
+   event = ERR_PTR(-EEXIST);
+   goto out;
+   }
+
desc = kzalloc(sizeof(*desc), GFP_KERNEL);
if (!desc) {
event = ERR_PTR(-ENOMEM);
-- 
1.8.1.1

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

[PATCH 13/16] perf, persistent: Implementing a persistent pmu

[Robert Richter]

From: Robert Richter 

We want to use the kernel's pmu design to later expose persistent
events via sysfs to userland. Initially implement a persistent pmu.

The format syntax is introduced allowing to set bits anywhere in
struct perf_event_attr. This is used in this case to set the
persistent flag (attr5:23). The syntax is attr where num is the
index of the u64 array in struct perf_event_attr. Otherwise syntax is
same as for config.

Patches that implement this functionality for perf tools are sent in a
separate patchset.

Signed-off-by: Robert Richter 
---
 kernel/events/persistent.c | 35 +++
 1 file changed, 35 insertions(+)

diff --git a/kernel/events/persistent.c b/kernel/events/persistent.c
index 1e93b51..95d6943 100644
--- a/kernel/events/persistent.c
+++ b/kernel/events/persistent.c
@@ -172,10 +172,45 @@ out:
return event_fd;
 }
 
+PMU_FORMAT_ATTR(persistent, "attr5:23");
+
+static struct attribute *persistent_format_attrs[] = {
+   _attr_persistent.attr,
+   NULL,
+};
+
+static struct attribute_group persistent_format_group = {
+   .name = "format",
+   .attrs = persistent_format_attrs,
+};
+
+static const struct attribute_group *persistent_attr_groups[] = {
+   _format_group,
+   NULL,
+};
+
+static struct pmu persistent_pmu;
+
+static int persistent_pmu_init(struct perf_event *event)
+{
+   if (persistent_pmu.type != event->attr.type)
+   return -ENOENT;
+
+   /* Not a persistent event. */
+   return -EFAULT;
+}
+
+static struct pmu persistent_pmu = {
+   .event_init = persistent_pmu_init,
+   .attr_groups= persistent_attr_groups,
+};
+
 void __init persistent_events_init(void)
 {
int cpu;
 
+   perf_pmu_register(_pmu, "persistent", -1);
+
for_each_possible_cpu(cpu) {
INIT_LIST_HEAD(_cpu(pers_events, cpu));
mutex_init(_cpu(pers_events_lock, cpu));
-- 
1.8.1.1

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

[PATCH 08/16] perf, persistent: Remove rb_put()

[Robert Richter]

From: Robert Richter 

rb_put() is called already in perf_event_release_kernel(), so no need
to do the same in del_persistent_event(). We also don't need it in
add_persistent_event_on_cpu() after a rework. Since there are no users
of rb_put() anymore, we can make it private again to only
events/core.c.

Signed-off-by: Robert Richter 
---
 kernel/events/core.c   |  4 +++-
 kernel/events/internal.h   |  1 -
 kernel/events/persistent.c | 29 +++--
 3 files changed, 14 insertions(+), 20 deletions(-)

diff --git a/kernel/events/core.c b/kernel/events/core.c
index a9b6470..8f85caa 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -3021,6 +3021,8 @@ static void free_event_rcu(struct rcu_head *head)
kfree(event);
 }
 
+static void rb_put(struct ring_buffer *rb);
+
 static void free_event(struct perf_event *event)
 {
irq_work_sync(>pending);
@@ -3680,7 +3682,7 @@ static struct ring_buffer *rb_get(struct perf_event 
*event)
return rb;
 }
 
-void rb_put(struct ring_buffer *rb)
+static void rb_put(struct ring_buffer *rb)
 {
struct perf_event *event, *n;
unsigned long flags;
diff --git a/kernel/events/internal.h b/kernel/events/internal.h
index 3b481be..3647289 100644
--- a/kernel/events/internal.h
+++ b/kernel/events/internal.h
@@ -38,7 +38,6 @@ struct ring_buffer {
 extern void rb_free(struct ring_buffer *rb);
 extern struct ring_buffer *
 rb_alloc(int nr_pages, long watermark, int cpu, int flags);
-extern void rb_put(struct ring_buffer *rb);
 extern void perf_event_wakeup(struct perf_event *event);
 
 extern void
diff --git a/kernel/events/persistent.c b/kernel/events/persistent.c
index 22297e5..ff1ce3b 100644
--- a/kernel/events/persistent.c
+++ b/kernel/events/persistent.c
@@ -20,22 +20,22 @@ static struct perf_event *
 add_persistent_event_on_cpu(unsigned int cpu, struct perf_event_attr *attr,
unsigned nr_pages)
 {
-   struct perf_event *event = ERR_PTR(-ENOMEM);
+   struct perf_event *event;
struct pers_event_desc *desc;
struct ring_buffer *buf;
 
desc = kzalloc(sizeof(*desc), GFP_KERNEL);
if (!desc)
-   goto out;
-
-   buf = rb_alloc(nr_pages, 0, cpu, 0);
-   if (!buf)
-   goto err_rb;
+   return ERR_PTR(-ENOMEM);
 
event = perf_event_create_kernel_counter(attr, cpu, NULL, NULL, NULL);
if (IS_ERR(event))
goto err_event;
 
+   buf = rb_alloc(nr_pages, 0, cpu, 0);
+   if (!buf)
+   goto err_rb;
+
rcu_assign_pointer(event->rb, buf);
 
desc->event = event;
@@ -47,14 +47,12 @@ add_persistent_event_on_cpu(unsigned int cpu, struct 
perf_event_attr *attr,
perf_event_enable(event);
 
goto out;
-
- err_event:
-   rb_put(buf);
-
- err_rb:
+err_rb:
+   perf_event_release_kernel(event);
+   event = ERR_PTR(-ENOMEM);
+err_event:
kfree(desc);
-
- out:
+out:
return event;
 }
 
@@ -76,11 +74,6 @@ static void del_persistent_event(int cpu, struct 
perf_event_attr *attr)
list_del(>plist);
 
perf_event_disable(event);
-   if (event->rb) {
-   rb_put(event->rb);
-   rcu_assign_pointer(event->rb, NULL);
-   }
-
perf_event_release_kernel(event);
put_unused_fd(desc->fd);
kfree(desc);
-- 
1.8.1.1

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

[PATCH 14/16] perf, persistent: Name each persistent event

[Robert Richter]

From: Robert Richter 

For later adding persistent events to sysfs we need a name for each
event. Adding a name to each persistent event.

Signed-off-by: Robert Richter 
---
 arch/x86/kernel/cpu/mcheck/mce.c |  3 ++-
 include/linux/perf_event.h   |  4 ++--
 kernel/events/persistent.c   | 30 +-
 3 files changed, 29 insertions(+), 8 deletions(-)

diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index d421937..833eb7a 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -1991,7 +1991,8 @@ int __init mcheck_init(void)
 
 int __init mcheck_init_tp(void)
 {
-   if (perf_add_persistent_event_by_id(event_mce_record.event.type)) {
+   if (perf_add_persistent_event_by_id(event_mce_record.name,
+   event_mce_record.event.type)) {
pr_err("Error adding MCE persistent event.\n");
return -EINVAL;
}
diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index dc72c93..06b4357b 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -751,7 +751,7 @@ extern void perf_event_disable(struct perf_event *event);
 extern int __perf_event_disable(void *info);
 extern void perf_event_task_tick(void);
 extern int perf_add_persistent_event(struct perf_event_attr *, unsigned);
-extern int perf_add_persistent_event_by_id(int id);
+extern int perf_add_persistent_event_by_id(char *name, int id);
 #else /* !CONFIG_PERF_EVENTS */
 static inline void
 perf_event_task_sched_in(struct task_struct *prev,
@@ -794,7 +794,7 @@ static inline int __perf_event_disable(void *info)  
{ return -1; }
 static inline void perf_event_task_tick(void)  { }
 static inline int perf_add_persistent_event(struct perf_event_attr *attr,
unsigned nr_pages)  { 
return -EINVAL; }
-static inline int perf_add_persistent_event_by_id(int id)  { 
return -EINVAL; }
+static inline int perf_add_persistent_event_by_id(char *name, int id)  { 
return -EINVAL; }
 #endif /* !CONFIG_PERF_EVENTS */
 
 #if defined(CONFIG_PERF_EVENTS) && defined(CONFIG_NO_HZ_FULL)
diff --git a/kernel/events/persistent.c b/kernel/events/persistent.c
index 95d6943..d5093a3 100644
--- a/kernel/events/persistent.c
+++ b/kernel/events/persistent.c
@@ -14,6 +14,11 @@ struct pers_event_desc {
int fd;
 };
 
+struct pers_event {
+   char*name;
+   struct perf_event_attr  attr;
+};
+
 static DEFINE_PER_CPU(struct list_head, pers_events);
 static DEFINE_PER_CPU(struct mutex, pers_events_lock);
 
@@ -132,14 +137,20 @@ unwind:
return PTR_ERR(event);
 }
 
-int perf_add_persistent_event_by_id(int id)
+int perf_add_persistent_event_by_id(char* name, int id)
 {
-   struct perf_event_attr *attr;
+   struct pers_event   *event;
+   struct perf_event_attr  *attr;
+   int ret = -ENOMEM;
 
-   attr = kzalloc(sizeof(*attr), GFP_KERNEL);
-   if (!attr)
+   event = kzalloc(sizeof(*event), GFP_KERNEL);
+   if (!event)
return -ENOMEM;
+   event->name = kstrdup(name, GFP_KERNEL);
+   if (!event->name)
+   goto fail;
 
+   attr = >attr;
attr->sample_period = 1;
attr->wakeup_events = 1;
attr->sample_type   = PERF_SAMPLE_RAW;
@@ -148,7 +159,16 @@ int perf_add_persistent_event_by_id(int id)
attr->type  = PERF_TYPE_TRACEPOINT;
attr->size  = sizeof(*attr);
 
-   return perf_add_persistent_event(attr, CPU_BUFFER_NR_PAGES);
+   ret = perf_add_persistent_event(attr, CPU_BUFFER_NR_PAGES);
+   if (ret)
+   goto fail;
+
+   return 0;
+fail:
+   kfree(event->name);
+   kfree(event);
+
+   return ret;
 }
 
 int perf_get_persistent_event_fd(unsigned cpu, struct perf_event_attr *attr)
-- 
1.8.1.1

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

[PATCH 11/16] perf, persistent: Protect event lists with mutex

[Robert Richter]

From: Robert Richter 

Protect esp. access to struct pers_event_desc *desc. There are race
conditions possible where the descriptor could be removed from list
while it is used.

Signed-off-by: Robert Richter 
---
 kernel/events/persistent.c | 36 ++--
 1 file changed, 26 insertions(+), 10 deletions(-)

diff --git a/kernel/events/persistent.c b/kernel/events/persistent.c
index 4ecbdab..ebef089 100644
--- a/kernel/events/persistent.c
+++ b/kernel/events/persistent.c
@@ -15,6 +15,7 @@ struct pers_event_desc {
 };
 
 static DEFINE_PER_CPU(struct list_head, pers_events);
+static DEFINE_PER_CPU(struct mutex, pers_events_lock);
 
 static struct pers_event_desc
 *get_persistent_event(int cpu, struct perf_event_attr *attr)
@@ -37,9 +38,13 @@ add_persistent_event_on_cpu(unsigned int cpu, struct 
perf_event_attr *attr,
struct pers_event_desc *desc;
struct ring_buffer *buf;
 
+   mutex_lock(_cpu(pers_events_lock, cpu));
+
desc = kzalloc(sizeof(*desc), GFP_KERNEL);
-   if (!desc)
-   return ERR_PTR(-ENOMEM);
+   if (!desc) {
+   event = ERR_PTR(-ENOMEM);
+   goto out;
+   }
 
event = perf_event_create_kernel_counter(attr, cpu, NULL, NULL, NULL);
if (IS_ERR(event))
@@ -66,6 +71,7 @@ err_rb:
 err_event:
kfree(desc);
 out:
+   mutex_unlock(_cpu(pers_events_lock, cpu));
return event;
 }
 
@@ -74,9 +80,11 @@ static void del_persistent_event(int cpu, struct 
perf_event_attr *attr)
struct pers_event_desc *desc;
struct perf_event *event;
 
+   mutex_lock(_cpu(pers_events_lock, cpu));
+
desc = get_persistent_event(cpu, attr);
if (!desc)
-   return;
+   goto out;
event = desc->event;
 
list_del(>plist);
@@ -85,6 +93,8 @@ static void del_persistent_event(int cpu, struct 
perf_event_attr *attr)
perf_event_release_kernel(event);
put_unused_fd(desc->fd);
kfree(desc);
+out:
+   mutex_unlock(_cpu(pers_events_lock, cpu));
 }
 
 /*
@@ -137,25 +147,31 @@ int perf_add_persistent_event_by_id(int id)
 
 int perf_get_persistent_event_fd(unsigned cpu, struct perf_event_attr *attr)
 {
-   struct pers_event_desc *desc = get_persistent_event(cpu, attr);
-   int event_fd;
+   struct pers_event_desc *desc;
+   int event_fd = -ENODEV;
 
+   mutex_lock(_cpu(pers_events_lock, cpu));
+
+   desc = get_persistent_event(cpu, attr);
if (!desc)
-   return -ENODEV;
+   goto out;
 
event_fd = anon_inode_getfd("[pers_event]", _fops,
desc->event, O_RDONLY);
if (event_fd >= 0)
desc->fd = event_fd;
+out:
+   mutex_unlock(_cpu(pers_events_lock, cpu));
 
return event_fd;
 }
 
-
 void __init persistent_events_init(void)
 {
-   int i;
+   int cpu;
 
-   for_each_possible_cpu(i)
-   INIT_LIST_HEAD(_cpu(pers_events, i));
+   for_each_possible_cpu(cpu) {
+   INIT_LIST_HEAD(_cpu(pers_events, cpu));
+   mutex_init(_cpu(pers_events_lock, cpu));
+   }
 }
-- 
1.8.1.1

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

[PATCH 03/16] perf, persistent: Setting default buffer size to 512k as in perf tools

[Robert Richter]

From: Robert Richter 

The default buffer size used to setup event buffers with perf tools is
512k. Using the same buffer size for persistent events. This also
avoids failed mmap calls due to different buffer sizes.

Signed-off-by: Robert Richter 
---
 kernel/events/persistent.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/kernel/events/persistent.c b/kernel/events/persistent.c
index 9075164..1e6c03a 100644
--- a/kernel/events/persistent.c
+++ b/kernel/events/persistent.c
@@ -5,6 +5,9 @@
 
 #include "internal.h"
 
+/* 512 kiB: default perf tools memory size, see perf_evlist__mmap() */
+#define CPU_BUFFER_NR_PAGES((512 * 1024) / PAGE_SIZE)
+
 static DEFINE_PER_CPU(struct list_head, pers_events);
 
 static struct perf_event *
@@ -151,7 +154,7 @@ int perf_add_persistent_event_by_id(int id)
attr->type  = PERF_TYPE_TRACEPOINT;
attr->size  = sizeof(*attr);
 
-   return perf_add_persistent_event(attr, 4);
+   return perf_add_persistent_event(attr, CPU_BUFFER_NR_PAGES);
 }
 
 int perf_get_persistent_event_fd(unsigned cpu, struct perf_event_attr *attr)
-- 
1.8.1.1

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

[PATCH 10/16] perf, persistent: Reworking perf_get_persistent_event_fd()

[Robert Richter]

From: Robert Richter 

There is already a function anon_inode_getfd() that does already all
the work. Reworking and simplifying code.

Signed-off-by: Robert Richter 
---
 kernel/events/persistent.c | 35 +++
 1 file changed, 7 insertions(+), 28 deletions(-)

diff --git a/kernel/events/persistent.c b/kernel/events/persistent.c
index 7d1aff3..4ecbdab 100644
--- a/kernel/events/persistent.c
+++ b/kernel/events/persistent.c
@@ -87,33 +87,6 @@ static void del_persistent_event(int cpu, struct 
perf_event_attr *attr)
kfree(desc);
 }
 
-static int __alloc_persistent_event_fd(struct pers_event_desc *desc)
-{
-   struct file *event_file = NULL;
-   int event_fd = -1;
-
-   event_fd = get_unused_fd();
-   if (event_fd < 0)
-   goto out;
-
-   event_file = anon_inode_getfile("[pers_event]", _fops,
-   desc->event, O_RDONLY);
-   if (IS_ERR(event_file))
-   goto err_event_file;
-
-   desc->fd = event_fd;
-   fd_install(event_fd, event_file);
-
-   goto out;
-
-
- err_event_file:
-   put_unused_fd(event_fd);
-
- out:
-   return event_fd;
-}
-
 /*
  * Create and enable the persistent version of the perf event described by
  * @attr.
@@ -165,11 +138,17 @@ int perf_add_persistent_event_by_id(int id)
 int perf_get_persistent_event_fd(unsigned cpu, struct perf_event_attr *attr)
 {
struct pers_event_desc *desc = get_persistent_event(cpu, attr);
+   int event_fd;
 
if (!desc)
return -ENODEV;
 
-   return __alloc_persistent_event_fd(desc);
+   event_fd = anon_inode_getfd("[pers_event]", _fops,
+   desc->event, O_RDONLY);
+   if (event_fd >= 0)
+   desc->fd = event_fd;
+
+   return event_fd;
 }
 
 
-- 
1.8.1.1

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

[PATCH 04/16] perf, persistent: Print error code on failure when adding events

[Robert Richter]

From: Robert Richter 

Improve error reporting.

Signed-off-by: Robert Richter 
---
 kernel/events/persistent.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/kernel/events/persistent.c b/kernel/events/persistent.c
index 1e6c03a..6612eb77 100644
--- a/kernel/events/persistent.c
+++ b/kernel/events/persistent.c
@@ -123,15 +123,15 @@ int perf_add_persistent_event(struct perf_event_attr 
*attr, unsigned nr_pages)
 
for_each_possible_cpu(i) {
event = add_persistent_event_on_cpu(i, attr, nr_pages);
-   if (IS_ERR(event)) {
-   pr_err("%s: Error adding persistent event on cpu %d\n",
-   __func__, i);
+   if (IS_ERR(event))
goto unwind;
-   }
}
return 0;
 
 unwind:
+   pr_err("%s: Error adding persistent event on cpu %d: %ld\n",
+   __func__, i, PTR_ERR(event));
+
while (--i >= 0)
del_persistent_event(i, attr);
 
-- 
1.8.1.1

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

[PATCH 00/16] perf, persistent: Kernel updates for perf tool integration

[Robert Richter]

From: Robert Richter 

This patch set implements out of the box support of perf tools for
persistent events. For this the kernel must provide necessary
information about existing persistent events via sysfs to userland.
Persistent events are provided by the kernel with readonly event
buffers. To allow the independent usage of the event buffers by any
process without limiting other processes, multiple users of a single
event must be handled too.

The basic concept is to use a pmu as an event container for persistent
events. The pmu registers events in sysfs and provides format and
event information for the userland. The persistent event framework
requires to add events to the pmu dynamically.

With the information in sysfs userland knows about how to setup the
perf_event attribute of a persistent event. Since a persistent event
always has the persistent flag set, a way is needed to express this in
sysfs. A new syntax is used for this. With 'attr:' any bit
in the attribute structure may be set in a similar way as using
'config', but  is an index that points to the u64 value to
change within the attribute.

For persistent events the persistent flag (bit 23 of flag field in
struct perf_event_attr) needs to be set which is expressed in sysfs
with "attr5:23". E.g. the mce_record event is described in sysfs as
follows:

 
/sys/bus/event_source/devices/persistent/events/mce_record:persistent,config=106
 /sys/bus/event_source/devices/persistent/format/persistent:attr5:23

Note that perf tools need to support the 'attr' syntax that is
added in a separate patch set. With it we are able to run perf tool
commands to read persistent events, e.g.:

 # perf record -e persistent/mce_record/ sleep 10
 # perf top -e persistent/mce_record/

In general the new syntax is flexible to describe with sysfs any event
to be setup by perf tools.

First patches contain also fixes and reworks made after reviewing
code. Could be applied separately.

Patches base on Boris' patches which I have rebased to latest
tip/perf/core. All patches can be found here:

 git://git.kernel.org/pub/scm/linux/kernel/git/rric/oprofile.git persistent

-Robert



Robert Richter (16):
  perf, persistent: Fix build error for no-tracepoints configs
  perf, persistent: Fix attr size
  perf, persistent: Setting default buffer size to 512k as in perf tools
  perf, persistent: Print error code on failure when adding events
  perf, persistent: Return resonable error code
  perf, persistent: Return -EACCES if mapped buffers must be readonly
  perf, persistent: Rework struct pers_event_desc
  perf, persistent: Remove rb_put()
  perf, persistent: Introduce get_persistent_event()
  perf, persistent: Reworking perf_get_persistent_event_fd()
  perf, persistent: Protect event lists with mutex
  perf, persistent: Avoid adding identical events
  perf, persistent: Implementing a persistent pmu
  perf, persistent: Name each persistent event
  perf, persistent: Exposing persistent events using sysfs
  perf, persistent: Allow multiple users for an event

 arch/x86/kernel/cpu/mcheck/mce.c |   7 +-
 include/linux/perf_event.h   |  11 +-
 kernel/events/core.c |   6 +-
 kernel/events/internal.h |   1 -
 kernel/events/persistent.c   | 292 +--
 5 files changed, 229 insertions(+), 88 deletions(-)

-- 
1.8.1.1

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

[PATCH 09/16] perf, persistent: Introduce get_persistent_event()

[Robert Richter]

From: Robert Richter 

Reducing duplicate code by introducing function get_persistent_event()
to get the descriptor of an persistent event.

Signed-off-by: Robert Richter 
---
 kernel/events/persistent.c | 37 ++---
 1 file changed, 22 insertions(+), 15 deletions(-)

diff --git a/kernel/events/persistent.c b/kernel/events/persistent.c
index ff1ce3b..7d1aff3 100644
--- a/kernel/events/persistent.c
+++ b/kernel/events/persistent.c
@@ -16,6 +16,19 @@ struct pers_event_desc {
 
 static DEFINE_PER_CPU(struct list_head, pers_events);
 
+static struct pers_event_desc
+*get_persistent_event(int cpu, struct perf_event_attr *attr)
+{
+   struct pers_event_desc *desc;
+
+   list_for_each_entry(desc, _cpu(pers_events, cpu), plist) {
+   if (desc->event->attr.config == attr->config)
+   return desc;
+   }
+
+   return NULL;
+}
+
 static struct perf_event *
 add_persistent_event_on_cpu(unsigned int cpu, struct perf_event_attr *attr,
unsigned nr_pages)
@@ -58,18 +71,13 @@ out:
 
 static void del_persistent_event(int cpu, struct perf_event_attr *attr)
 {
-   struct pers_event_desc *desc, *tmp;
-   struct perf_event *event = NULL;
-
-   list_for_each_entry_safe(desc, tmp, _cpu(pers_events, cpu), plist) {
-   if (desc->event->attr.config == attr->config) {
-   event = desc->event;
-   break;
-   }
-   }
+   struct pers_event_desc *desc;
+   struct perf_event *event;
 
-   if (!event)
+   desc = get_persistent_event(cpu, attr);
+   if (!desc)
return;
+   event = desc->event;
 
list_del(>plist);
 
@@ -156,13 +164,12 @@ int perf_add_persistent_event_by_id(int id)
 
 int perf_get_persistent_event_fd(unsigned cpu, struct perf_event_attr *attr)
 {
-   struct pers_event_desc *desc;
+   struct pers_event_desc *desc = get_persistent_event(cpu, attr);
 
-   list_for_each_entry(desc, _cpu(pers_events, cpu), plist)
-   if (desc->event->attr.config == attr->config)
-   return __alloc_persistent_event_fd(desc);
+   if (!desc)
+   return -ENODEV;
 
-   return -ENODEV;
+   return __alloc_persistent_event_fd(desc);
 }
 
 
-- 
1.8.1.1

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

Re: [PATCH] cpufreq: ondemand: Change the calculation of target frequency

[Viresh Kumar]

Sorry for joining the party so late.. I was running away from reviewing it :(

On 31 May 2013 02:37, Stratos Karafotis  wrote:
> Ondemand calculates load in terms of frequency and increases it only
> if the load_freq is greater than up_threshold multiplied by current
> or average frequency. This seems to produce oscillations of frequency
> between min and max because, for example, a relatively small load can
> easily saturate minimum frequency and lead the CPU to max. Then, the
> CPU will decrease back to min due to a small load_freq.
>
> This patch changes the calculation method of load and target frequency
> considering 2 points:
> - Load computation should be independent from current or average
> measured frequency. For example an absolute load 80% at 100MHz is not
> necessarily equivalent to 8% at 1000MHz in the next sampling interval.
> - Target frequency should be increased to any value of frequency table
> proportional to absolute load, instead to only the max.
>
> The patch also removes the unused code as a result of the above changes.
>
> Tested on Intel i7-3770 CPU @ 3.40GHz and on Quad core 1500MHz Krait.
> Phoronix benchmark of Linux Kernel Compilation 3.1 test shows an
> increase ~1.5% in performance. cpufreq_stats (time_in_state) shows
> that middle frequencies are used more, with this patch. Highest
> and lowest frequencies were used less by ~9%
>
> Signed-off-by: Stratos Karafotis 
> ---
>  arch/x86/include/asm/processor.h   | 29 --
>  drivers/cpufreq/Makefile   |  2 +-
>  drivers/cpufreq/acpi-cpufreq.c |  5 
>  drivers/cpufreq/cpufreq.c  | 21 
>  drivers/cpufreq/cpufreq_governor.c | 10 +---
>  drivers/cpufreq/cpufreq_governor.h |  1 -
>  drivers/cpufreq/cpufreq_ondemand.c | 39 ++---
>  drivers/cpufreq/mperf.c| 51 
> --
>  drivers/cpufreq/mperf.h|  9 ---
>  include/linux/cpufreq.h|  6 -
>  10 files changed, 9 insertions(+), 164 deletions(-)
>  delete mode 100644 drivers/cpufreq/mperf.c
>  delete mode 100644 drivers/cpufreq/mperf.h

I believe you should have removed other users of getavg() in a separate
patch and also cc'd relevant people so that you can some review comments
from  them.

> diff --git a/arch/x86/include/asm/processor.h 
> b/arch/x86/include/asm/processor.h
> index 4b3..2874a3b 100644
> --- a/arch/x86/include/asm/processor.h
> +++ b/arch/x86/include/asm/processor.h
> @@ -941,35 +941,6 @@ extern int set_tsc_mode(unsigned int val);
>
>  extern u16 amd_get_nb_id(int cpu);
>
> -struct aperfmperf {
> -   u64 aperf, mperf;
> -};
> -
> -static inline void get_aperfmperf(struct aperfmperf *am)
> -{
> -   WARN_ON_ONCE(!boot_cpu_has(X86_FEATURE_APERFMPERF));
> -
> -   rdmsrl(MSR_IA32_APERF, am->aperf);
> -   rdmsrl(MSR_IA32_MPERF, am->mperf);
> -}
> -
> -#define APERFMPERF_SHIFT 10
> -
> -static inline
> -unsigned long calc_aperfmperf_ratio(struct aperfmperf *old,
> -   struct aperfmperf *new)
> -{
> -   u64 aperf = new->aperf - old->aperf;
> -   u64 mperf = new->mperf - old->mperf;
> -   unsigned long ratio = aperf;
> -
> -   mperf >>= APERFMPERF_SHIFT;
> -   if (mperf)
> -   ratio = div64_u64(aperf, mperf);
> -
> -   return ratio;
> -}
> -
>  extern unsigned long arch_align_stack(unsigned long sp);
>  extern void free_init_pages(char *what, unsigned long begin, unsigned long 
> end);
>
> diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
> index 315b923..4519fb1 100644
> --- a/drivers/cpufreq/Makefile
> +++ b/drivers/cpufreq/Makefile
> @@ -23,7 +23,7 @@ obj-$(CONFIG_GENERIC_CPUFREQ_CPU0)+= cpufreq-cpu0.o
>  # powernow-k8 can load then. ACPI is preferred to all other 
> hardware-specific drivers.
>  # speedstep-* is preferred over p4-clockmod.
>
> -obj-$(CONFIG_X86_ACPI_CPUFREQ) += acpi-cpufreq.o mperf.o
> +obj-$(CONFIG_X86_ACPI_CPUFREQ) += acpi-cpufreq.o
>  obj-$(CONFIG_X86_POWERNOW_K8)  += powernow-k8.o
>  obj-$(CONFIG_X86_PCC_CPUFREQ)  += pcc-cpufreq.o
>  obj-$(CONFIG_X86_POWERNOW_K6)  += powernow-k6.o
> diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c
> index 11b8b4b..0025cdd 100644
> --- a/drivers/cpufreq/acpi-cpufreq.c
> +++ b/drivers/cpufreq/acpi-cpufreq.c
> @@ -45,7 +45,6 @@
>  #include 
>  #include 
>  #include 
> -#include "mperf.h"
>
>  MODULE_AUTHOR("Paul Diefenbaugh, Dominik Brodowski");
>  MODULE_DESCRIPTION("ACPI Processor P-States Driver");
> @@ -842,10 +841,6 @@ static int acpi_cpufreq_cpu_init(struct cpufreq_policy 
> *policy)
> /* notify BIOS that we exist */
> acpi_processor_notify_smm(THIS_MODULE);
>
> -   /* Check for APERF/MPERF support in hardware */
> -   if (boot_cpu_has(X86_FEATURE_APERFMPERF))
> -   acpi_cpufreq_driver.getavg = cpufreq_get_measured_perf;
> -
> pr_debug("CPU%u - 

[PATCH 02/16] perf, persistent: Fix attr size

[Robert Richter]

From: Robert Richter 

Fixing wrongly determined attribute size.

Signed-off-by: Robert Richter 
---
 kernel/events/persistent.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/events/persistent.c b/kernel/events/persistent.c
index 5335644..9075164 100644
--- a/kernel/events/persistent.c
+++ b/kernel/events/persistent.c
@@ -149,7 +149,7 @@ int perf_add_persistent_event_by_id(int id)
attr->persistent= 1;
attr->config= id;
attr->type  = PERF_TYPE_TRACEPOINT;
-   attr->size  = sizeof(attr);
+   attr->size  = sizeof(*attr);
 
return perf_add_persistent_event(attr, 4);
 }
-- 
1.8.1.1

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

[RFC][PATCH 0/2] dma-buf: add importer private data for reimporting

[Seung-Woo Kim]

importer private data in dma-buf attachment can be used by importer to
reimport same dma-buf.

Seung-Woo Kim (2):
  dma-buf: add importer private data to attachment
  drm/prime: find gem object from the reimported dma-buf

 drivers/base/dma-buf.c |   31 
 drivers/gpu/drm/drm_prime.c|   19 
 drivers/gpu/drm/exynos/exynos_drm_dmabuf.c |1 +
 drivers/gpu/drm/i915/i915_gem_dmabuf.c |1 +
 drivers/gpu/drm/udl/udl_gem.c  |1 +
 include/linux/dma-buf.h|4 +++
 6 files changed, 52 insertions(+), 5 deletions(-)

-- 
1.7.4.1

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

[RFC][PATCH 2/2] drm/prime: find gem object from the reimported dma-buf

[Seung-Woo Kim]

Reimported dma-buf can reuse same gem object only when prime import
is done with same drm open context. So prime import is done with
other drm open context, gem object is newly created and mapped even
there is already mapped gem object. To avoid recreating gem object,
importer private data can be used at reimport time if it is assigned
with drm gem object at first import.
This can also remove remapping dma address for the hardware having
its own iommu.

Signed-off-by: Seung-Woo Kim 
---
 drivers/gpu/drm/drm_prime.c|   19 ++-
 drivers/gpu/drm/exynos/exynos_drm_dmabuf.c |1 +
 drivers/gpu/drm/i915/i915_gem_dmabuf.c |1 +
 drivers/gpu/drm/udl/udl_gem.c  |1 +
 4 files changed, 17 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index dcde352..78a3c7d 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -294,6 +294,7 @@ struct drm_gem_object *drm_gem_prime_import(struct 
drm_device *dev,
}
 
obj->import_attach = attach;
+   attach->importer_priv = obj;
 
return obj;
 
@@ -312,6 +313,7 @@ int drm_gem_prime_fd_to_handle(struct drm_device *dev,
 {
struct dma_buf *dma_buf;
struct drm_gem_object *obj;
+   struct dma_buf_attachment *attach;
int ret;
 
dma_buf = dma_buf_get(prime_fd);
@@ -327,11 +329,18 @@ int drm_gem_prime_fd_to_handle(struct drm_device *dev,
goto out_put;
}
 
-   /* never seen this one, need to import */
-   obj = dev->driver->gem_prime_import(dev, dma_buf);
-   if (IS_ERR(obj)) {
-   ret = PTR_ERR(obj);
-   goto out_put;
+   attach = dma_buf_get_attachment(dma_buf, dev->dev);
+   if (IS_ERR(attach)) {
+   /* never seen this one, need to import */
+   obj = dev->driver->gem_prime_import(dev, dma_buf);
+   if (IS_ERR(obj)) {
+   ret = PTR_ERR(obj);
+   goto out_put;
+   }
+   } else {
+   /* found attachment to same device */
+   obj = attach->importer_priv;
+   drm_gem_object_reference(obj);
}
 
ret = drm_gem_handle_create(file_priv, obj, handle);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c 
b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
index ff7f2a8..268da36 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
@@ -285,6 +285,7 @@ struct drm_gem_object *exynos_dmabuf_prime_import(struct 
drm_device *drm_dev,
exynos_gem_obj->buffer = buffer;
buffer->sgt = sgt;
exynos_gem_obj->base.import_attach = attach;
+   attach->importer_priv = _gem_obj->base;
 
DRM_DEBUG_PRIME("dma_addr = 0x%x, size = 0x%lx\n", buffer->dma_addr,
buffer->size);
diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c 
b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
index dc53a52..75ef28c 100644
--- a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
@@ -297,6 +297,7 @@ struct drm_gem_object *i915_gem_prime_import(struct 
drm_device *dev,
 
i915_gem_object_init(obj, _gem_object_dmabuf_ops);
obj->base.import_attach = attach;
+   attach->importer_priv = >base;
 
return >base;
 
diff --git a/drivers/gpu/drm/udl/udl_gem.c b/drivers/gpu/drm/udl/udl_gem.c
index ef034fa..0652db1 100644
--- a/drivers/gpu/drm/udl/udl_gem.c
+++ b/drivers/gpu/drm/udl/udl_gem.c
@@ -317,6 +317,7 @@ struct drm_gem_object *udl_gem_prime_import(struct 
drm_device *dev,
}
 
uobj->base.import_attach = attach;
+   attach->importer_priv = >base;
 
return >base;
 
-- 
1.7.4.1

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

[RFC][PATCH 1/2] dma-buf: add importer private data to attachment

[Seung-Woo Kim]

dma-buf attachment has only exporter private data, but importer private data
can be useful for importer especially to re-import the same dma-buf.
To use importer private data in attachment of the device, the function to
search attachment in the attachment list of dma-buf is also added.

Signed-off-by: Seung-Woo Kim 
---
 drivers/base/dma-buf.c  |   31 +++
 include/linux/dma-buf.h |4 
 2 files changed, 35 insertions(+), 0 deletions(-)

diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
index 08fe897..a1eaaf2 100644
--- a/drivers/base/dma-buf.c
+++ b/drivers/base/dma-buf.c
@@ -259,6 +259,37 @@ err_attach:
 EXPORT_SYMBOL_GPL(dma_buf_attach);
 
 /**
+ * dma_buf_get_attachment - Get attachment with the device from dma_buf's
+ * attachments list
+ * @dmabuf:[in]buffer to find device from.
+ * @dev:   [in]device to be found.
+ *
+ * Returns struct dma_buf_attachment * attaching the device; may return
+ * negative error codes.
+ *
+ */
+struct dma_buf_attachment *dma_buf_get_attachment(struct dma_buf *dmabuf,
+ struct device *dev)
+{
+   struct dma_buf_attachment *attach;
+
+   if (WARN_ON(!dmabuf || !dev))
+   return ERR_PTR(-EINVAL);
+
+   mutex_lock(>lock);
+   list_for_each_entry(attach, >attachments, node) {
+   if (attach->dev == dev) {
+   mutex_unlock(>lock);
+   return attach;
+   }
+   }
+   mutex_unlock(>lock);
+
+   return ERR_PTR(-ENODEV);
+}
+EXPORT_SYMBOL_GPL(dma_buf_get_attachment);
+
+/**
  * dma_buf_detach - Remove the given attachment from dmabuf's attachments list;
  * optionally calls detach() of dma_buf_ops for device-specific detach
  * @dmabuf:[in]buffer to detach from.
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index dfac5ed..09cff0f 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -136,6 +136,7 @@ struct dma_buf {
  * @dev: device attached to the buffer.
  * @node: list of dma_buf_attachment.
  * @priv: exporter specific attachment data.
+ * @importer_priv: importer specific attachment data.
  *
  * This structure holds the attachment information between the dma_buf buffer
  * and its user device(s). The list contains one attachment struct per device
@@ -146,6 +147,7 @@ struct dma_buf_attachment {
struct device *dev;
struct list_head node;
void *priv;
+   void *importer_priv;
 };
 
 /**
@@ -164,6 +166,8 @@ static inline void get_dma_buf(struct dma_buf *dmabuf)
 
 struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
struct device *dev);
+struct dma_buf_attachment *dma_buf_get_attachment(struct dma_buf *dmabuf,
+   struct device *dev);
 void dma_buf_detach(struct dma_buf *dmabuf,
struct dma_buf_attachment *dmabuf_attach);
 
-- 
1.7.4.1

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

Re: [PATCH] cpufreq: ondemand: Change the calculation of target frequency

[Viresh Kumar]

On 31 May 2013 02:37, Stratos Karafotis  wrote:

Ahh.. earlier mail got sent without me doing complete review :(

> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> +static void od_check_cpu(int cpu, unsigned int load)
>  {
> struct od_cpu_dbs_info_s *dbs_info = _cpu(od_cpu_dbs_info, cpu);
> struct cpufreq_policy *policy = dbs_info->cdbs.cur_policy;
> @@ -176,29 +170,17 @@ static void od_check_cpu(int cpu, unsigned int 
> load_freq)
> dbs_info->freq_lo = 0;
>
> /* Check for frequency increase */
> -   if (load_freq > od_tuners->up_threshold * policy->cur) {
> +   if (load > od_tuners->up_threshold) {

Chances of this getting hit are minimal now.. I don't know if keeping
this will change anything now :)

> /* If switching to max speed, apply sampling_down_factor */
> if (policy->cur < policy->max)
> dbs_info->rate_mult =
> od_tuners->sampling_down_factor;
> dbs_freq_increase(policy, policy->max);
> return;
> -   }
> -
> -   /* Check for frequency decrease */
> -   /* if we cannot reduce the frequency anymore, break out early */
> -   if (policy->cur == policy->min)
> -   return;
> -
> -   /*
> -* The optimal frequency is the frequency that is the lowest that can
> -* support the current CPU usage without triggering the up policy. To 
> be
> -* safe, we focus 10 points under the threshold.
> -*/
> -   if (load_freq < od_tuners->adj_up_threshold
> -   * policy->cur) {
> +   } else {
> +   /* Calculate the next frequency proportional to load */
> unsigned int freq_next;
> -   freq_next = load_freq / od_tuners->adj_up_threshold;
> +   freq_next = load * policy->max / 100;

Rafael asked why you believe this is the right formula and I really couldn't
find an appropriate answer to that, sorry :(
--
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/

[PATCH v5 1/2] watchdog: New watchdog driver for MEN A21 watchdogs

[Johannes Thumshirn]

This patch adds the driver for the watchdog devices found on MEN Mikro
Elektronik A21 VMEbus CPU Carrier Boards. It has DT-support and uses the
watchdog framework.

Revision 2:
* Removed unneeded open flag in struct a21_wdt_drv
* Corrected 3bit reason code from gpio
* Additional sysfs files are now part of watchdog sysfs
* Changed OFF/ON delay in ping from 400ms to 10ns
* Reworked timeout setting
* Removed a21_wdt_ioctl(...)

Revision 3:
* Changed pr_{err,info} to dev_{err,info}
* Removed out of memory error print
* Transition from "fast" to "slow" mode not allowed by chip

Revision 4:
* Remove reboot_notifier and place disable code into platform_device's shutdown 
function
* Removed sysfs interface

Revision 5:

* Added setting of .bootstatus on driver init
* Added initial timeout on driver init

Signed-off-by: Johannes Thumshirn 
---
 MAINTAINERS   |6 ++
 drivers/watchdog/Kconfig  |8 ++
 drivers/watchdog/Makefile |1 +
 drivers/watchdog/mena21_wdt.c |  234 +
 4 files changed, 249 insertions(+)
 create mode 100644 drivers/watchdog/mena21_wdt.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 7714c3c..023945a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5307,6 +5307,12 @@ F:   drivers/mtd/
 F: include/linux/mtd/
 F: include/uapi/mtd/

+MEN A21 WATCHDOG DRIVER
+M: Johannes Thumshirn 
+L: linux-watch...@vger.kernel.org
+S: Supported
+F: drivers/watchdog/mena21_wdt.c
+
 METAG ARCHITECTURE
 M: James Hogan 
 S: Supported
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index e89fc31..192b84d 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -1172,6 +1172,14 @@ config BOOKE_WDT_DEFAULT_TIMEOUT

  The value can be overridden by the wdt_period command-line parameter.

+config MEN_A21_WDT
+   tristate "MEN A21 VME CPU Carrier Board Watchdog Timer"
+   select WATCHDOG_CORE
+   help
+Watchdog driver for MEN A21 VMEbus CPU Carrier Boards.
+
+   If unsure select N here.
+
 # PPC64 Architecture

 config WATCHDOG_RTAS
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index a300b94..bffdcb1 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -143,6 +143,7 @@ obj-$(CONFIG_8xxx_WDT) += mpc8xxx_wdt.o
 obj-$(CONFIG_MV64X60_WDT) += mv64x60_wdt.o
 obj-$(CONFIG_PIKA_WDT) += pika_wdt.o
 obj-$(CONFIG_BOOKE_WDT) += booke_wdt.o
+obj-$(CONFIG_MEN_A21_WDT) += mena21_wdt.o

 # PPC64 Architecture
 obj-$(CONFIG_WATCHDOG_RTAS) += wdrtas.o
diff --git a/drivers/watchdog/mena21_wdt.c b/drivers/watchdog/mena21_wdt.c
new file mode 100644
index 000..e586c2e
--- /dev/null
+++ b/drivers/watchdog/mena21_wdt.c
@@ -0,0 +1,234 @@
+/*
+ * Watchdog driver for the A21 VME CPU Boards
+ *
+ * Copyright (C) 2013 MEN Mikro Elektronik Nuernberg GmbH
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define GPIO_WD_ENAB   169
+#define GPIO_WD_FAST   170
+#define GPIO_WD_TRIG   171
+
+#define GPIO_RST_CAUSE_BASE 166
+
+struct a21_wdt_drv {
+   struct watchdog_device wdt;
+   struct mutex lock;
+};
+
+static bool nowayout = WATCHDOG_NOWAYOUT;
+module_param(nowayout, bool, 0);
+MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once started (default="
+   __MODULE_STRING(WATCHDOG_NOWAYOUT) ")");
+
+static int a21_wdt_get_bootstatus(unsigned int *reset)
+{
+   int i;
+
+   for (i = 0; i < 3; i++)
+   *reset |= gpio_get_value(GPIO_RST_CAUSE_BASE + i)
+   ? (1 << i) : 0;
+
+   if (*reset >= 8)
+   return -EINVAL;
+
+   return 0;
+}
+
+static int a21_wdt_start(struct watchdog_device *wdt)
+{
+   struct a21_wdt_drv *drv = watchdog_get_drvdata(wdt);
+
+   mutex_lock(>lock);
+
+   gpio_set_value(GPIO_WD_ENAB, 1);
+
+   mutex_unlock(>lock);
+
+   return 0;
+}
+
+static int a21_wdt_stop(struct watchdog_device *wdt)
+{
+   struct a21_wdt_drv *drv = watchdog_get_drvdata(wdt);
+
+   /* We don't stop if WDOG_NO_WAY_OUT is set */
+   if (test_bit(WDOG_NO_WAY_OUT, >status))
+   return -EINVAL;
+
+   mutex_lock(>lock);
+
+   gpio_set_value(GPIO_WD_ENAB, 0);
+
+   mutex_unlock(>lock);
+
+   return 0;
+}
+
+static int a21_wdt_ping(struct watchdog_device *wdt)
+{
+   struct a21_wdt_drv *drv = watchdog_get_drvdata(wdt);
+
+   mutex_lock(>lock);
+
+   gpio_set_value(GPIO_WD_TRIG, 0);
+   ndelay(10);
+   gpio_set_value(GPIO_WD_TRIG, 1);
+
+   mutex_unlock(>lock);
+
+   return 0;
+}
+
+static int a21_wdt_set_timeout(struct watchdog_device *wdt,
+  unsigned int timeout)
+{
+   struct a21_wdt_drv 

[PATCH v2 2/2] This patch adds a sysfs interface for the watchdog device found on MEN A21 Boards.

[Johannes Thumshirn]

The newly generated files are:
* rebootcause:
Can be one of:
Power on Reset,
CPU Reset Request,
Push Button,
FPGA Reset Request,
Watchdog,
Local Power Bad,
Invalid or
BDI
and shows the reason of the boards last reboot.

* active:
Shows if the watchdog CPLD is actually running

* allow_disable:
Shows if the watchdog is allowed to be disabled (NOWAYOUT disabled)

* fastmode:
Shows if the CPLD is running in fast mode (1s timeout), once it is in
fastmode it can't be switched back to slow mode (30s timeout) until the
next reboot.

Revision 2:
* Re-worked sysfs patch to apply on re-worked base

Signed-off-by: Johannes Thumshirn 
---
 drivers/watchdog/mena21_wdt.c |   88 +
 1 file changed, 88 insertions(+)

diff --git a/drivers/watchdog/mena21_wdt.c b/drivers/watchdog/mena21_wdt.c
index e586c2e..e11d869 100644
--- a/drivers/watchdog/mena21_wdt.c
+++ b/drivers/watchdog/mena21_wdt.c
@@ -19,6 +19,17 @@
 #include 
 #include 

+static char *reset_causes[] = {
+   "Power On Reset",
+   "CPU Reset Request",
+   "Push Button",
+   "FPGA Reset Request",
+   "Watchdog",
+   "Local Power Bad",
+   "Invalid",
+   "BDI",
+};
+
 #define GPIO_WD_ENAB   169
 #define GPIO_WD_FAST   170
 #define GPIO_WD_TRIG   171
@@ -49,6 +60,74 @@ static int a21_wdt_get_bootstatus(unsigned int *reset)
return 0;
 }

+static ssize_t rebootcause_show(struct device *dev,
+   struct device_attribute *attr,
+   char *buf)
+{
+   unsigned int reset = 0;
+   int i;
+
+   for (i = 0; i < 3; i++)
+   reset |= gpio_get_value(GPIO_RST_CAUSE_BASE + i)
+? (1 << i) : 0;
+
+   if (reset >= 8)
+   return -EIO;
+
+   return sprintf(buf, "%s\n", reset_causes[reset]);
+}
+static DEVICE_ATTR(rebootcause, S_IRUGO, rebootcause_show, NULL);
+
+static ssize_t active_show(struct device *dev, struct device_attribute *attr,
+  char *buf)
+{
+   return sprintf(buf, "%d\n", !!gpio_get_value(GPIO_WD_ENAB));
+}
+static DEVICE_ATTR(active, S_IRUGO, active_show, NULL);
+
+static ssize_t allow_disable_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+   return sprintf(buf, "%d\n", !nowayout);
+}
+static DEVICE_ATTR(allow_disable, S_IRUGO, allow_disable_show, NULL);
+
+static ssize_t fastmode_show(struct device *dev, struct device_attribute *attr,
+char *buf)
+{
+   return sprintf(buf, "%d\n", !!gpio_get_value(GPIO_WD_FAST));
+}
+static DEVICE_ATTR(fastmode, S_IRUGO, fastmode_show, NULL);
+
+static int a21_wdt_create_files(struct watchdog_device *wdev)
+{
+   int ret;
+
+   ret = device_create_file(wdev->dev, _attr_rebootcause);
+   if (ret)
+   return ret;
+   ret = device_create_file(wdev->dev, _attr_active);
+   if (ret)
+   return ret;
+   ret = device_create_file(wdev->dev, _attr_allow_disable);
+   if (ret)
+   return ret;
+   ret = device_create_file(wdev->dev, _attr_fastmode);
+   if (ret)
+   return ret;
+
+   return 0;
+}
+
+static void a21_wdt_remove_files(struct watchdog_device *wdev)
+{
+   device_remove_file(wdev->dev, _attr_rebootcause);
+   device_remove_file(wdev->dev, _attr_active);
+   device_remove_file(wdev->dev, _attr_allow_disable);
+   device_remove_file(wdev->dev, _attr_fastmode);
+}
+
 static int a21_wdt_start(struct watchdog_device *wdt)
 {
struct a21_wdt_drv *drv = watchdog_get_drvdata(wdt);
@@ -181,10 +260,18 @@ static int a21_wdt_probe(struct platform_device *pdev)
a21_wdt.bootstatus |= WDIOF_EXTERN2;
}

+   ret = a21_wdt_create_files(_wdt);
+   if (ret) {
+   dev_err(>dev, "Cannot create sysfs entries\n");
+   goto err_create_sysfs;
+   }
+
dev_set_drvdata(>dev, drv);

return 0;

+err_create_sysfs:
+   watchdog_unregister_device(>wdt);
 err_register_wd:
mutex_destroy(>lock);

@@ -198,6 +285,7 @@ static int a21_wdt_remove(struct platform_device *pdev)
dev_warn(>dev,
"Unregistering A21 watchdog driver, board may reboot\n");

+   a21_wdt_remove_files(>wdt);

watchdog_unregister_device(>wdt);

--
1.7.9.5

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

Re: [PATCH v5 1/2] watchdog: New watchdog driver for MEN A21 watchdogs

[Johannes Thumshirn]

On Fri, May 31, 2013 at 10:58:48AM +0200, Johannes Thumshirn wrote:
> This patch adds the driver for the watchdog devices found on MEN Mikro
> Elektronik A21 VMEbus CPU Carrier Boards. It has DT-support and uses the
> watchdog framework.
[...]
> +MODULE_DESCRIPTION("MEN A21 Watchdog");
> +MODULE_LICENSE("GPL");
> +MODULE_ALIAS("platform:a21-watchdog");
> --
> 1.7.9.5
>


Args, sorry messed up the thread :-(.

I'm not so firm with using mutt for patches, but git send-email doesn't seem
to like Exchange here...


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

Re: [PATCH 01/16] perf, persistent: Fix build error for no-tracepoints configs

[Borislav Petkov]

On Fri, May 31, 2013 at 10:47:21AM +0200, Robert Richter wrote:
> From: Robert Richter 
> 
> The mce_record tracepoint needs tracepoints to be enabled. Fixing
> build error for no-tracepoints configs.
> 
> Signed-off-by: Robert Richter 
> ---
>  arch/x86/kernel/cpu/mcheck/mce.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/arch/x86/kernel/cpu/mcheck/mce.c 
> b/arch/x86/kernel/cpu/mcheck/mce.c
> index 0ecf4a2..d421937 100644
> --- a/arch/x86/kernel/cpu/mcheck/mce.c
> +++ b/arch/x86/kernel/cpu/mcheck/mce.c
> @@ -1987,6 +1987,8 @@ int __init mcheck_init(void)
>   return 0;
>  }
>  
> +#ifdef CONFIG_TRACEPOINTS
> +
>  int __init mcheck_init_tp(void)
>  {
>   if (perf_add_persistent_event_by_id(event_mce_record.event.type)) {
> @@ -2001,6 +2003,8 @@ int __init mcheck_init_tp(void)
>   */
>  fs_initcall_sync(mcheck_init_tp);
>  
> +#endif /* CONFIG_TRACEPOINTS */
> +

Right, since my persistent patches are in no tree yet, we should merge
this one with, I think, the last one in my set and keep them all
together.

Thanks.
--
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/

Re: [PATCH 02/16] perf, persistent: Fix attr size

[Borislav Petkov]

On Fri, May 31, 2013 at 10:47:22AM +0200, Robert Richter wrote:
> From: Robert Richter 
> 
> Fixing wrongly determined attribute size.
> 
> Signed-off-by: Robert Richter 
> ---
>  kernel/events/persistent.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/kernel/events/persistent.c b/kernel/events/persistent.c
> index 5335644..9075164 100644
> --- a/kernel/events/persistent.c
> +++ b/kernel/events/persistent.c
> @@ -149,7 +149,7 @@ int perf_add_persistent_event_by_id(int id)
>   attr->persistent= 1;
>   attr->config= id;
>   attr->type  = PERF_TYPE_TRACEPOINT;
> - attr->size  = sizeof(attr);
> + attr->size  = sizeof(*attr);

Ditto for this one.
--
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/

Re: [PATCH 03/16] perf, persistent: Setting default buffer size to 512k as in perf tools

[Borislav Petkov]

On Fri, May 31, 2013 at 10:47:23AM +0200, Robert Richter wrote:
> From: Robert Richter 
> 
> The default buffer size used to setup event buffers with perf tools is
> 512k. Using the same buffer size for persistent events. This also
> avoids failed mmap calls due to different buffer sizes.
> 
> Signed-off-by: Robert Richter 
> ---
>  kernel/events/persistent.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/kernel/events/persistent.c b/kernel/events/persistent.c
> index 9075164..1e6c03a 100644
> --- a/kernel/events/persistent.c
> +++ b/kernel/events/persistent.c
> @@ -5,6 +5,9 @@
>  
>  #include "internal.h"
>  
> +/* 512 kiB: default perf tools memory size, see perf_evlist__mmap() */
> +#define CPU_BUFFER_NR_PAGES  ((512 * 1024) / PAGE_SIZE)
> +
>  static DEFINE_PER_CPU(struct list_head, pers_events);
>  
>  static struct perf_event *
> @@ -151,7 +154,7 @@ int perf_add_persistent_event_by_id(int id)
>   attr->type  = PERF_TYPE_TRACEPOINT;
>   attr->size  = sizeof(*attr);
>  
> - return perf_add_persistent_event(attr, 4);
> + return perf_add_persistent_event(attr, CPU_BUFFER_NR_PAGES);

This one too - the 4 pages I chose then was purely arbitrary for I had
no idea what size to pick. This clearly makes more sense.

Thanks.
--
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/

Re: [PATCH 04/16] perf, persistent: Print error code on failure when adding events

[Borislav Petkov]

On Fri, May 31, 2013 at 10:47:24AM +0200, Robert Richter wrote:
> From: Robert Richter 
> 
> Improve error reporting.
> 
> Signed-off-by: Robert Richter 
> ---
>  kernel/events/persistent.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/kernel/events/persistent.c b/kernel/events/persistent.c
> index 1e6c03a..6612eb77 100644
> --- a/kernel/events/persistent.c
> +++ b/kernel/events/persistent.c
> @@ -123,15 +123,15 @@ int perf_add_persistent_event(struct perf_event_attr 
> *attr, unsigned nr_pages)
>  
>   for_each_possible_cpu(i) {
>   event = add_persistent_event_on_cpu(i, attr, nr_pages);
> - if (IS_ERR(event)) {
> - pr_err("%s: Error adding persistent event on cpu %d\n",
> - __func__, i);
> + if (IS_ERR(event))
>   goto unwind;
> - }
>   }
>   return 0;
>  
>  unwind:
> + pr_err("%s: Error adding persistent event on cpu %d: %ld\n",
> + __func__, i, PTR_ERR(event));
> +
>   while (--i >= 0)
>   del_persistent_event(i, attr);

Should also be merged.

Thanks.
--
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/

Re: [PATCH 05/16] perf, persistent: Return resonable error code

[Borislav Petkov]

On Fri, May 31, 2013 at 10:47:25AM +0200, Robert Richter wrote:
> From: Robert Richter 
> 
> Returning -ENODEV if no file descriptor is found. An error code of -1
> (-EPERM) is misleading in this case.
> 
> Signed-off-by: Robert Richter 
> ---
>  kernel/events/persistent.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/kernel/events/persistent.c b/kernel/events/persistent.c
> index 6612eb77..190aa75 100644
> --- a/kernel/events/persistent.c
> +++ b/kernel/events/persistent.c
> @@ -165,7 +165,7 @@ int perf_get_persistent_event_fd(unsigned cpu, struct 
> perf_event_attr *attr)
>   if (desc->attr->config == attr->config)
>   return __alloc_persistent_event_fd(desc);
>  
> - return -1;
> + return -ENODEV;

Ditto.
--
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/

Re: [PATCH 06/16] perf, persistent: Return -EACCES if mapped buffers must be readonly

[Borislav Petkov]

On Fri, May 31, 2013 at 10:47:26AM +0200, Robert Richter wrote:
> From: Robert Richter 
> 
> mmap should return EACCES error if fd can not be opened writable.
> This error code also helps userland to map buffers readonly on
> failure.
> 
> Signed-off-by: Robert Richter 
> ---
>  kernel/events/core.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/kernel/events/core.c b/kernel/events/core.c
> index 0730f36..a9b6470 100644
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c
> @@ -3761,7 +3761,7 @@ static int perf_mmap(struct file *file, struct 
> vm_area_struct *vma)
>   return -EINVAL;
>  
>   if (event->attr.persistent && (vma->vm_flags & VM_WRITE))
> - return -EINVAL;
> + return -EACCES;
>  
>   vma_size = vma->vm_end - vma->vm_start;
>   nr_pages = (vma_size / PAGE_SIZE) - 1;

Also merge.
--
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/

Re: [PATCH v2] arch: m68k: math-emu: unsigned issue, 'unsigned long' will never be less than zero

[Geert Uytterhoeven]

On Thu, May 30, 2013 at 10:21 AM, Chen Gang  wrote:
> 'oldmant.m32[1]' is 'unsigned long' which never '< 0', and the original
> author wanted to check the highest bit whether set.
>
> So need make the bit test explicit (which is better than type cast form
> 'unsigned long' to 'long').
>
> The related warning: (with EXTRA_CFLAGS=-W ARCH=m68k for allmodconfig)
>   arch/m68k/math-emu/fp_arith.c:522:4: warning: comparison of unsigned 
> expression >= 0 is always true [-Wtype-limits]
>
> Signed-off-by: Chen Gang 

Thanks, applied and queued for 3.11!

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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/

Re: [RFC][PATCH 0/2] dma-buf: add importer private data for reimporting

[Daniel Vetter]

On Fri, May 31, 2013 at 10:54 AM, Seung-Woo Kim  wrote:
> importer private data in dma-buf attachment can be used by importer to
> reimport same dma-buf.
>
> Seung-Woo Kim (2):
>   dma-buf: add importer private data to attachment
>   drm/prime: find gem object from the reimported dma-buf

Self-import should already work (at least with the latest refcount
fixes merged). At least the tests to check both re-import on the same
drm fd and on a different all work as expected now.

Second, the dma_buf_attachment is _definitely_ the wrong place to do
this. If you need iommu mapping caching, that should happen at a lower
level (i.e. in the map_attachment callback somewhere of the exporter,
that's what the priv field in the attachment is for). Snatching away
the attachement from some random other import is certainly not the way
to go - attachements are _not_ refcounted!
-Daniel

>
>  drivers/base/dma-buf.c |   31 
> 
>  drivers/gpu/drm/drm_prime.c|   19 
>  drivers/gpu/drm/exynos/exynos_drm_dmabuf.c |1 +
>  drivers/gpu/drm/i915/i915_gem_dmabuf.c |1 +
>  drivers/gpu/drm/udl/udl_gem.c  |1 +
>  include/linux/dma-buf.h|4 +++
>  6 files changed, 52 insertions(+), 5 deletions(-)
>
> --
> 1.7.4.1
>



--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
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/