Re: [PATCH/RFC 0/4] Deferrable timers support for timerfd API
Hi all, On Sat, Sep 01, 2012 at 10:43:35PM -0700, Anton Vorontsov wrote: > This patch set implements a userland-side API for generic deferrable > timers, per linux/timer.h: > > * A deferrable timer will work normally when the system is busy, but > * will not cause a CPU to come out of idle just to service it; instead, > * the timer will be serviced when the CPU eventually wakes up with a > * subsequent non-deferrable timer. > > These timers are crucial for power saving, i.e. periodic tasks that want > to work in background when the system is under use, but don't want to > cause wakeups themselves. Just a friendly ping. Does anyone had a chance to look into this, whether the idea bad or good, or whether the implementation is OK? Thanks! Anton. -- 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] drivers: phy: add generic PHY framework
Hi, On Mon, Sep 17, 2012 at 6:50 AM, Chen Peter-B29397 wrote: > >> >> The PHY framework provides a set of API's for the PHY drivers to >> create/remove a PHY and the PHY users to obtain a reference to the PHY >> using or without using phandle. If the PHY users has to obtain a >> reference to >> the PHY without using phandle, the platform specfic intialization code >> (say >> from board file) should have already called phy_bind with the binding >> information. The binding information consists of phy's device name, phy >> user device name and an index. The index is used when the same phy user >> binds to mulitple phys. >> > > What's an example of "the same phy user binds to multiple phys"? Single controller using multiple phys.. > I only remembered that Felipe said there are two phy users for one single phy > at > omap5 that is both usb3 and sata uses the same phy. *index* is used when a single controller uses multiple phys. For example it could be used for dwc3 (usb3 controller) where it uses usb2 phy and usb3 phy. Thanks Kishon -- 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: PL330: return ENOMEM instead of 0 from pl330_alloc_chan_resources
On Mon, Sep 17, 2012 at 9:57 AM, Inderpal Singh
wrote:
> Since 0 is not considered as error at dmaengine level, return ENOMEM
> from pl330_alloc_chan_resources in case of failure.
>
> Signed-off-by: Inderpal Singh
Acked-by: Jassi Brar
> ---
> drivers/dma/pl330.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
> index e4feba6..14d881c 100644
> --- a/drivers/dma/pl330.c
> +++ b/drivers/dma/pl330.c
> @@ -2393,7 +2393,7 @@ static int pl330_alloc_chan_resources(struct dma_chan
> *chan)
> pch->pl330_chid = pl330_request_channel(>pif);
> if (!pch->pl330_chid) {
> spin_unlock_irqrestore(>lock, flags);
> - return 0;
> + return -ENOMEM;
> }
>
> tasklet_init(>task, pl330_tasklet, (unsigned long) pch);
> --
> 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] memory cgroup: update root memory cgroup when node is onlined
At 09/14/2012 09:36 AM, Hugh Dickins Wrote:
> On Thu, 13 Sep 2012, Johannes Weiner wrote:
>> On Thu, Sep 13, 2012 at 03:14:28PM +0800, Wen Congyang wrote:
>>> root_mem_cgroup->info.nodeinfo is initialized when the system boots.
>>> But NODE_DATA(nid) is null if the node is not onlined, so
>>> root_mem_cgroup->info.nodeinfo[nid]->zoneinfo[zone].lruvec.zone contains
>>> an invalid pointer. If we use numactl to bind a program to the node
>>> after onlining the node and its memory, it will cause the kernel
>>> panicked:
>>
>> Is there any chance we could get rid of the zone backpointer in lruvec
>> again instead?
>
> It could be done, but it would make me sad :(
>
>> Adding new nodes is a rare event and so updating every
>> single memcg in the system might be just borderline crazy.
>
> Not horribly crazy, but rather ugly, yes.
>
>> But can't
>> we just go back to passing the zone along with the lruvec down
>> vmscan.c paths? I agree it's ugly to pass both, given their
>> relationship. But I don't think the backpointer is any cleaner but in
>> addition less robust.
>
> It's like how we use vma->mm: we could change everywhere to pass mm with
> vma, but it looks cleaner and cuts down on long arglists to have mm in vma.
>>From past experience, one of the things I worried about was adding extra
> args to the reclaim stack.
>
>>
>> That being said, the crashing code in particular makes me wonder:
>>
>> static __always_inline void add_page_to_lru_list(struct page *page,
>> struct lruvec *lruvec, enum lru_list lru)
>> {
>> int nr_pages = hpage_nr_pages(page);
>> mem_cgroup_update_lru_size(lruvec, lru, nr_pages);
>> list_add(>lru, >lists[lru]);
>> __mod_zone_page_state(lruvec_zone(lruvec), NR_LRU_BASE + lru, nr_pages);
>> }
>>
>> Why did we ever pass zone in here and then felt the need to replace it
>> with lruvec->zone in fa9add6 "mm/memcg: apply add/del_page to lruvec"?
>> A page does not roam between zones, its zone is a static property that
>> can be retrieved with page_zone().
>
> Just as in vmscan.c, we have the lruvec to hand, and that's what we
> mainly want to operate upon, but there is also some need for zone.
>
> (Both Konstantin and I were looking towards the day when we move the
> lru_lock into the lruvec, removing more dependence on "zone". Pretty
> much the only reason that hasn't happened yet, is that we have not found
> time to make a performance case convincingly - but that's another topic.)
>
> Yes, page_zone(page) is a static property of the page, but it's not
> necessarily cheap to evaluate: depends on how complex the memory model
> and the spare page flags space, doesn't it? We both preferred to
> derive zone from lruvec where convenient.
>
> How do you feel about this patch, and does it work for you guys?
>
> You'd be right if you guessed that I started out without the
> mem_cgroup_zone_lruvec part of it, but oops in get_scan_count
> told me that's needed too.
>
> Description to be filled in later: would it be needed for -stable,
> or is onlining already broken in other ways that you're now fixing up?
>
> Reported-by: Tang Chen
> Signed-off-by: Hugh Dickins
> ---
>
> include/linux/mmzone.h |2 -
> mm/memcontrol.c| 40 ---
> mm/mmzone.c|6 -
> mm/page_alloc.c|2 -
> 4 files changed, 36 insertions(+), 14 deletions(-)
>
> --- 3.6-rc5/include/linux/mmzone.h2012-08-03 08:31:26.892842267 -0700
> +++ linux/include/linux/mmzone.h 2012-09-13 17:07:51.893772372 -0700
> @@ -744,7 +744,7 @@ extern int init_currently_empty_zone(str
>unsigned long size,
>enum memmap_context context);
>
> -extern void lruvec_init(struct lruvec *lruvec, struct zone *zone);
> +extern void lruvec_init(struct lruvec *lruvec);
>
> static inline struct zone *lruvec_zone(struct lruvec *lruvec)
> {
> --- 3.6-rc5/mm/memcontrol.c 2012-08-03 08:31:27.060842270 -0700
> +++ linux/mm/memcontrol.c 2012-09-13 17:46:36.870804625 -0700
> @@ -1061,12 +1061,25 @@ struct lruvec *mem_cgroup_zone_lruvec(st
> struct mem_cgroup *memcg)
> {
> struct mem_cgroup_per_zone *mz;
> + struct lruvec *lruvec;
>
> - if (mem_cgroup_disabled())
> - return >lruvec;
> + if (mem_cgroup_disabled()) {
> + lruvec = >lruvec;
> + goto out;
> + }
>
> mz = mem_cgroup_zoneinfo(memcg, zone_to_nid(zone), zone_idx(zone));
> - return >lruvec;
> + lruvec = >lruvec;
> +out:
> + /*
> + * Since a node can be onlined after the mem_cgroup was created,
> + * we have to be prepared to initialize lruvec->zone here.
> + */
> + if (unlikely(lruvec->zone != zone)) {
> + VM_BUG_ON(lruvec->zone);
If node is offlined and onlined again, lruvec->zone is not NULL, and not
equal to zone, this line will cause
[PATCH] mfd: tps65090: remove redundant check
Remove redundant check in is_volatile_reg().
Signed-off-by: Venu Byravarasu
---
drivers/mfd/tps65090.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/mfd/tps65090.c b/drivers/mfd/tps65090.c
index 50fd87c..074ae32 100644
--- a/drivers/mfd/tps65090.c
+++ b/drivers/mfd/tps65090.c
@@ -236,7 +236,7 @@ static int __devinit tps65090_irq_init(struct tps65090
*tps65090, int irq,
static bool is_volatile_reg(struct device *dev, unsigned int reg)
{
- if ((reg == TPS65090_INT_STS) || (reg == TPS65090_INT_STS))
+ if (reg == TPS65090_INT_STS)
return true;
else
return false;
--
1.7.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: pull request: wireless 2012-09-14
From: "John W. Linville" Date: Fri, 14 Sep 2012 13:46:55 -0400 > Arend van Spriel sends a simple thinko fix to correct a constant, > preventing the setting of an invalid power level. > > Colin Ian King gives us a simple allocation failure check to avoid a > NULL pointer dereference. > > Felix Fietkau sends another ath9k tx power patch, this time disabling a > feature that has been reported to cause rx problems. > > Hante Meuleman provides a pair of endian fixes for brcmfmac. > > Larry Finger offers an rtlwifi fix that avoids a system lockup related > to loading the wrong firmware for RTL8188CE devices. > > These have been in linux-next for a few days and I think they should be > included in the final 3.6 kernel if possible. Pulled, thanks John. -- 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] ARM: dma-mapping: Fix potential memory leak in atomic_pool_init()
When either of __alloc_from_contiguous or __alloc_remap_buffer fails to provide a valid pointer, allocated memory is freed up and an error is returned. 'pages' was however not freed before returning error. Cc: Arnd Bergmann Cc: Marek Szyprowski Signed-off-by: Sachin Kamat --- arch/arm/mm/dma-mapping.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c index 546a3e8..477a2d2 100644 --- a/arch/arm/mm/dma-mapping.c +++ b/arch/arm/mm/dma-mapping.c @@ -367,6 +367,8 @@ static int __init atomic_pool_init(void) (unsigned)pool->size / 1024); return 0; } + + kfree(pages); no_pages: kfree(bitmap); no_bitmap: -- 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] pwm: Move AB8500 PWM driver to PWM framework
> On Fri, Sep 07, 2012 at 03:22:09PM +0200, Thierry Reding wrote: > > On Mon, Sep 03, 2012 at 01:28:44PM +0200, Arun MURTHY wrote: > > > > On Sun, Sep 2, 2012 at 12:30 PM, Thierry Reding > > > > wrote: > > > > > > > > > This commit moves the driver to drivers/pwm and converts it to > > > > > the new PWM framework. > > > > > > > > > > Signed-off-by: Thierry Reding > > > > > --- > > > > > Note: I'll take this through the PWM tree, but I'd like to have > > > > > it acknowledged by a few people who know the hardware and can > > > > > actually test whether this still works. > > > > > > > > Pls include Arun on these patches, he'll know best if it'll work or not. > > > > > > > > I have one generic question: will this alter the layout of sysfs > > > > so we need to change userspace? I had such issues before when > > > > moving drivers to new busses... > > > > > > > > > > Since this pwm framework is still a set of exported functions in a > > > header file, the file architecture doesn't really matter. > > > Using this driver, either leds-pwm and backlight-pwm is used to > > > register and this is where actual registration happens(sysfs entry is > created). > > > > Hi Arun, > > > > Have you been able to verify, then, that the driver still works after > > this patch? Can I add your Acked-by as well? > > Hi Arun, > > any news on this? > > Thierry Hi Thierry, Works with certain changes in platform data which I can manage to push it later. Acked-by: Arun Murthy Thanks and Regards, Arun R Murthy -- -- 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/
linux-next: manual merge of the drm tree with Linus' tree
Hi Dave,
Today's linux-next merge of the drm tree got a conflict in
drivers/gpu/drm/i915/i915_dma.c between commit 99d0b1db6ccd ("drm/i915:
initialize dpio_lock spin lock") from Linus' tree and commit c6a828d3269a
("drm/i915: move all rps state into dev_priv->rps") from the drm tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/gpu/drm/i915/i915_dma.c
index 914c0df,2c09900..000
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@@ -1586,8 -1606,7 +1606,8 @@@ int i915_driver_load(struct drm_device
spin_lock_init(_priv->irq_lock);
spin_lock_init(_priv->error_lock);
- spin_lock_init(_priv->rps_lock);
+ spin_lock_init(_priv->rps.lock);
+ spin_lock_init(_priv->dpio_lock);
if (IS_IVYBRIDGE(dev) || IS_HASWELL(dev))
dev_priv->num_pipe = 3;
pgp7BPI78gfsY.pgp
Description: PGP signature
[PATCH] DMA: PL330: return ENOMEM instead of 0 from pl330_alloc_chan_resources
Since 0 is not considered as error at dmaengine level, return ENOMEM
from pl330_alloc_chan_resources in case of failure.
Signed-off-by: Inderpal Singh
---
drivers/dma/pl330.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index e4feba6..14d881c 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -2393,7 +2393,7 @@ static int pl330_alloc_chan_resources(struct dma_chan
*chan)
pch->pl330_chid = pl330_request_channel(>pif);
if (!pch->pl330_chid) {
spin_unlock_irqrestore(>lock, flags);
- return 0;
+ return -ENOMEM;
}
tasklet_init(>task, pl330_tasklet, (unsigned long) pch);
--
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 v2 1/2] mfd: max8925: use register offset as REG in backlight
On Thu, Sep 13, 2012 at 4:22 PM, Haojian Zhuang wrote: > Remove the register offset definition. All these register offset > are transfered as IORESOURCE_REG resources. > > Signed-off-by: Haojian Zhuang > --- > drivers/mfd/max8925-core.c | 31 ++--- > drivers/video/backlight/max8925_bl.c | 79 > ++ > 2 files changed, 55 insertions(+), 55 deletions(-) Please ignore this patch series. New version of these two patches are included and sent in another mail loop. Regards Haojian -- 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 9/9] ARM: dts: enable 88pm860x pmic
Signed-off-by: Haojian Zhuang
---
arch/arm/boot/dts/pxa910-dkb.dts | 137 ++
arch/arm/boot/dts/pxa910.dtsi|4 ++
2 files changed, 141 insertions(+)
diff --git a/arch/arm/boot/dts/pxa910-dkb.dts b/arch/arm/boot/dts/pxa910-dkb.dts
index e92be5a..595492a 100644
--- a/arch/arm/boot/dts/pxa910-dkb.dts
+++ b/arch/arm/boot/dts/pxa910-dkb.dts
@@ -29,6 +29,143 @@
};
twsi1: i2c@d4011000 {
status = "okay";
+
+ pmic: 88pm860x@34 {
+ compatible = "marvell,88pm860x";
+ reg = <0x34>;
+ interrupts = <4>;
+ interrupt-parent = <>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ marvell,88pm860x-irq-read-clr;
+ marvell,88pm860x-slave-addr = <0x11>;
+
+ regulators {
+ BUCK1 {
+ regulator-min-microvolt
= <100>;
+ regulator-max-microvolt
= <150>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+ BUCK2 {
+ regulator-min-microvolt
= <100>;
+ regulator-max-microvolt
= <150>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+ BUCK3 {
+ regulator-min-microvolt
= <100>;
+ regulator-max-microvolt
= <300>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+ LDO1 {
+ regulator-min-microvolt
= <120>;
+ regulator-max-microvolt
= <280>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+ LDO2 {
+ regulator-min-microvolt
= <180>;
+ regulator-max-microvolt
= <330>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+ LDO3 {
+ regulator-min-microvolt
= <180>;
+ regulator-max-microvolt
= <330>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+ LDO4 {
+ regulator-min-microvolt
= <180>;
+ regulator-max-microvolt
= <330>;
+ regulator-always-on;
+ };
+ LDO5 {
+ regulator-min-microvolt
= <290>;
+ regulator-max-microvolt
= <330>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+ LDO6 {
+ regulator-min-microvolt
= <180>;
+ regulator-max-microvolt
= <330>;
+ regulator-boot-on;
+
[PATCH 8/9] mfd: 88pm860x: move gpadc init into touch
The initilization of GPADC is moved from core driver to touch driver
with DT support.
Signed-off-by: Haojian Zhuang
---
drivers/input/touchscreen/88pm860x-ts.c | 91 +--
drivers/mfd/88pm860x-core.c | 51 -
2 files changed, 85 insertions(+), 57 deletions(-)
diff --git a/drivers/input/touchscreen/88pm860x-ts.c
b/drivers/input/touchscreen/88pm860x-ts.c
index 4f81e6e..326218d 100644
--- a/drivers/input/touchscreen/88pm860x-ts.c
+++ b/drivers/input/touchscreen/88pm860x-ts.c
@@ -116,9 +116,13 @@ static void pm860x_touch_close(struct input_dev *dev)
#ifdef CONFIG_OF
static int __devinit pm860x_touch_dt_init(struct platform_device *pdev,
+ struct pm860x_chip *chip,
int *res_x)
{
struct device_node *np = pdev->dev.parent->of_node;
+ struct i2c_client *i2c = (chip->id == CHIP_PM8607) ? chip->client \
+: chip->companion;
+ int data, n, ret;
if (!np)
return -ENODEV;
np = of_find_node_by_name(np, "touch");
@@ -126,11 +130,43 @@ static int __devinit pm860x_touch_dt_init(struct
platform_device *pdev,
dev_err(>dev, "Can't find touch node\n");
return -EINVAL;
}
+ /* set GPADC MISC1 register */
+ data = 0;
+ if (!of_property_read_u32(np, "marvell,88pm860x-gpadc-prebias", ))
+ data |= (n << 1) & PM8607_GPADC_PREBIAS_MASK;
+ if (!of_property_read_u32(np, "marvell,88pm860x-gpadc-slot-cycle", ))
+ data |= (n << 3) & PM8607_GPADC_SLOT_CYCLE_MASK;
+ if (!of_property_read_u32(np, "marvell,88pm860x-gpadc-off-scale", ))
+ data |= (n << 5) & PM8607_GPADC_OFF_SCALE_MASK;
+ if (!of_property_read_u32(np, "marvell,88pm860x-gpadc-sw-cal", ))
+ data |= (n << 7) & PM8607_GPADC_SW_CAL_MASK;
+ if (data) {
+ ret = pm860x_reg_write(i2c, PM8607_GPADC_MISC1, data);
+ if (ret < 0)
+ return -EINVAL;
+ }
+ /* set tsi prebias time */
+ if (!of_property_read_u32(np, "marvell,88pm860x-tsi-prebias", )) {
+ ret = pm860x_reg_write(i2c, PM8607_TSI_PREBIAS, data);
+ if (ret < 0)
+ return -EINVAL;
+ }
+ /* set prebias & prechg time of pen detect */
+ data = 0;
+ if (!of_property_read_u32(np, "marvell,88pm860x-pen-prebias", ))
+ data |= n & PM8607_PD_PREBIAS_MASK;
+ if (!of_property_read_u32(np, "marvell,88pm860x-pen-prechg", ))
+ data |= n & PM8607_PD_PRECHG_MASK;
+ if (data) {
+ ret = pm860x_reg_write(i2c, PM8607_PD_PREBIAS, data);
+ if (ret < 0)
+ return -EINVAL;
+ }
of_property_read_u32(np, "marvell,88pm860x-resistor-X", res_x);
return 0;
}
#else
-#define pm860x_touch_dt_init(x, y) (-1)
+#define pm860x_touch_dt_init(x, y, z) (-1)
#endif
static int __devinit pm860x_touch_probe(struct platform_device *pdev)
@@ -138,7 +174,9 @@ static int __devinit pm860x_touch_probe(struct
platform_device *pdev)
struct pm860x_chip *chip = dev_get_drvdata(pdev->dev.parent);
struct pm860x_touch_pdata *pdata = pdev->dev.platform_data;
struct pm860x_touch *touch;
- int irq, ret, res_x = 0;
+ struct i2c_client *i2c = (chip->id == CHIP_PM8607) ? chip->client \
+: chip->companion;
+ int irq, ret, res_x = 0, data = 0;
irq = platform_get_irq(pdev, 0);
if (irq < 0) {
@@ -146,14 +184,55 @@ static int __devinit pm860x_touch_probe(struct
platform_device *pdev)
return -EINVAL;
}
- if (pm860x_touch_dt_init(pdev, _x)) {
- if (pdata)
+ if (pm860x_touch_dt_init(pdev, chip, _x)) {
+ if (pdata) {
+ /* set GPADC MISC1 register */
+ data = 0;
+ data |= (pdata->gpadc_prebias << 1)
+ & PM8607_GPADC_PREBIAS_MASK;
+ data |= (pdata->slot_cycle << 3)
+ & PM8607_GPADC_SLOT_CYCLE_MASK;
+ data |= (pdata->off_scale << 5)
+ & PM8607_GPADC_OFF_SCALE_MASK;
+ data |= (pdata->sw_cal << 7)
+ & PM8607_GPADC_SW_CAL_MASK;
+ if (data) {
+ ret = pm860x_reg_write(i2c,
+ PM8607_GPADC_MISC1, data);
+ if (ret < 0)
+ return -EINVAL;
+ }
+ /* set tsi prebias time */
+ if (pdata->tsi_prebias) {
+ data = pdata->tsi_prebias;
+
[PATCH 7/9] mfd: 88pm860x: support dt
Signed-off-by: Haojian Zhuang
---
drivers/input/touchscreen/88pm860x-ts.c | 46 +++
drivers/leds/leds-88pm860x.c| 33 +++-
drivers/mfd/88pm860x-core.c | 62 ++-
drivers/regulator/88pm8607.c| 35 -
drivers/rtc/rtc-88pm860x.c | 43 -
drivers/video/backlight/88pm860x_bl.c | 39 +--
include/linux/mfd/88pm860x.h|4 +-
7 files changed, 221 insertions(+), 41 deletions(-)
diff --git a/drivers/input/touchscreen/88pm860x-ts.c
b/drivers/input/touchscreen/88pm860x-ts.c
index 05f30b7..4f81e6e 100644
--- a/drivers/input/touchscreen/88pm860x-ts.c
+++ b/drivers/input/touchscreen/88pm860x-ts.c
@@ -10,6 +10,7 @@
*/
#include
#include
+#include
#include
#include
#include
@@ -113,14 +114,31 @@ static void pm860x_touch_close(struct input_dev *dev)
pm860x_set_bits(touch->i2c, MEAS_EN3, data, 0);
}
+#ifdef CONFIG_OF
+static int __devinit pm860x_touch_dt_init(struct platform_device *pdev,
+ int *res_x)
+{
+ struct device_node *np = pdev->dev.parent->of_node;
+ if (!np)
+ return -ENODEV;
+ np = of_find_node_by_name(np, "touch");
+ if (!np) {
+ dev_err(>dev, "Can't find touch node\n");
+ return -EINVAL;
+ }
+ of_property_read_u32(np, "marvell,88pm860x-resistor-X", res_x);
+ return 0;
+}
+#else
+#define pm860x_touch_dt_init(x, y) (-1)
+#endif
+
static int __devinit pm860x_touch_probe(struct platform_device *pdev)
{
struct pm860x_chip *chip = dev_get_drvdata(pdev->dev.parent);
- struct pm860x_platform_data *pm860x_pdata = \
- pdev->dev.parent->platform_data;
- struct pm860x_touch_pdata *pdata = NULL;
+ struct pm860x_touch_pdata *pdata = pdev->dev.platform_data;
struct pm860x_touch *touch;
- int irq, ret;
+ int irq, ret, res_x = 0;
irq = platform_get_irq(pdev, 0);
if (irq < 0) {
@@ -128,15 +146,13 @@ static int __devinit pm860x_touch_probe(struct
platform_device *pdev)
return -EINVAL;
}
- if (!pm860x_pdata) {
- dev_err(>dev, "platform data is missing\n");
- return -EINVAL;
- }
-
- pdata = pm860x_pdata->touch;
- if (!pdata) {
- dev_err(>dev, "touchscreen data is missing\n");
- return -EINVAL;
+ if (pm860x_touch_dt_init(pdev, _x)) {
+ if (pdata)
+ res_x = pdata->res_x;
+ else {
+ dev_err(>dev, "failed to get platform data\n");
+ return -EINVAL;
+ }
}
touch = kzalloc(sizeof(struct pm860x_touch), GFP_KERNEL);
@@ -159,8 +175,8 @@ static int __devinit pm860x_touch_probe(struct
platform_device *pdev)
touch->idev->close = pm860x_touch_close;
touch->chip = chip;
touch->i2c = (chip->id == CHIP_PM8607) ? chip->client : chip->companion;
- touch->irq = irq + chip->irq_base;
- touch->res_x = pdata->res_x;
+ touch->irq = irq;
+ touch->res_x = res_x;
input_set_drvdata(touch->idev, touch);
ret = request_threaded_irq(touch->irq, NULL, pm860x_touch_handler,
diff --git a/drivers/leds/leds-88pm860x.c b/drivers/leds/leds-88pm860x.c
index 70232b1..b7e8cc0 100644
--- a/drivers/leds/leds-88pm860x.c
+++ b/drivers/leds/leds-88pm860x.c
@@ -12,6 +12,7 @@
#include
#include
+#include
#include
#include
#include
@@ -123,6 +124,33 @@ static void pm860x_led_set(struct led_classdev *cdev,
schedule_work(>work);
}
+#ifdef CONFIG_OF
+static int pm860x_led_dt_init(struct platform_device *pdev,
+ struct pm860x_led *data)
+{
+ struct device_node *nproot = pdev->dev.parent->of_node, *np;
+ int iset = 0;
+ if (!nproot)
+ return -ENODEV;
+ nproot = of_find_node_by_name(nproot, "leds");
+ if (!nproot) {
+ dev_err(>dev, "failed to find leds node\n");
+ return -ENODEV;
+ }
+ for_each_child_of_node(nproot, np) {
+ if (!of_node_cmp(np->name, data->name)) {
+ of_property_read_u32(np, "marvell,88pm860x-iset",
+);
+ data->iset = PM8606_LED_CURRENT(iset);
+ break;
+ }
+ }
+ return 0;
+}
+#else
+#define pm860x_led_dt_init(x, y) (-1)
+#endif
+
static int pm860x_led_probe(struct platform_device *pdev)
{
struct pm860x_chip *chip = dev_get_drvdata(pdev->dev.parent);
@@ -179,8 +207,9 @@ static int pm860x_led_probe(struct platform_device *pdev)
data->chip = chip;
data->i2c = (chip->id == CHIP_PM8606) ? chip->client : chip->companion;
[PATCH 6/9] mfd: 88pm860x: use irqdomain
Use irqdomain and allocating interrupts. It's necessary for supporting
DT mode.
Signed-off-by: Haojian Zhuang
---
drivers/mfd/88pm860x-core.c | 65 +--
1 file changed, 38 insertions(+), 27 deletions(-)
diff --git a/drivers/mfd/88pm860x-core.c b/drivers/mfd/88pm860x-core.c
index 797bdb3..a09d790 100644
--- a/drivers/mfd/88pm860x-core.c
+++ b/drivers/mfd/88pm860x-core.c
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -520,15 +521,12 @@ static void pm860x_irq_sync_unlock(struct irq_data *data)
static void pm860x_irq_enable(struct irq_data *data)
{
- struct pm860x_chip *chip = irq_data_get_irq_chip_data(data);
- pm860x_irqs[data->irq - chip->irq_base].enable
- = pm860x_irqs[data->irq - chip->irq_base].offs;
+ pm860x_irqs[data->hwirq].enable = pm860x_irqs[data->hwirq].offs;
}
static void pm860x_irq_disable(struct irq_data *data)
{
- struct pm860x_chip *chip = irq_data_get_irq_chip_data(data);
- pm860x_irqs[data->irq - chip->irq_base].enable = 0;
+ pm860x_irqs[data->hwirq].enable = 0;
}
static struct irq_chip pm860x_irq_chip = {
@@ -539,6 +537,25 @@ static struct irq_chip pm860x_irq_chip = {
.irq_disable= pm860x_irq_disable,
};
+static int pm860x_irq_domain_map(struct irq_domain *d, unsigned int virq,
+irq_hw_number_t hw)
+{
+ irq_set_chip_data(virq, d->host_data);
+ irq_set_chip_and_handler(virq, _irq_chip, handle_edge_irq);
+ irq_set_nested_thread(virq, 1);
+#ifdef CONFIG_ARM
+ set_irq_flags(virq, IRQF_VALID);
+#else
+ irq_set_noprobe(virq);
+#endif
+ return 0;
+}
+
+static struct irq_domain_ops pm860x_irq_domain_ops = {
+ .map= pm860x_irq_domain_map,
+ .xlate = irq_domain_xlate_onetwocell,
+};
+
static int __devinit device_gpadc_init(struct pm860x_chip *chip,
struct pm860x_platform_data *pdata)
{
@@ -593,13 +610,9 @@ static int __devinit device_irq_init(struct pm860x_chip
*chip,
: chip->companion;
unsigned char status_buf[INT_STATUS_NUM];
unsigned long flags = IRQF_TRIGGER_FALLING | IRQF_ONESHOT;
- int i, data, mask, ret = -EINVAL;
- int __irq;
-
- if (!pdata || !pdata->irq_base) {
- dev_warn(chip->dev, "No interrupt support on IRQ base\n");
- return -EINVAL;
- }
+ int data, mask, ret = -EINVAL;
+ int nr_irqs, irq_base = -1;
+ struct device_node *node = i2c->dev.of_node;
mask = PM8607_B0_MISC1_INV_INT | PM8607_B0_MISC1_INT_CLEAR
| PM8607_B0_MISC1_INT_MASK;
@@ -639,25 +652,23 @@ static int __devinit device_irq_init(struct pm860x_chip
*chip,
goto out;
mutex_init(>irq_lock);
- chip->irq_base = pdata->irq_base;
+
+ if (pdata && pdata->irq_base)
+ irq_base = pdata->irq_base;
+ nr_irqs = ARRAY_SIZE(pm860x_irqs);
+ chip->irq_base = irq_alloc_descs(irq_base, 0, nr_irqs, 0);
+ if (chip->irq_base < 0) {
+ dev_err(>dev, "Failed to allocate interrupts, ret:%d\n",
+ chip->irq_base);
+ ret = -EBUSY;
+ goto out;
+ }
+ irq_domain_add_legacy(node, nr_irqs, chip->irq_base, 0,
+ _irq_domain_ops, chip);
chip->core_irq = i2c->irq;
if (!chip->core_irq)
goto out;
- /* register IRQ by genirq */
- for (i = 0; i < ARRAY_SIZE(pm860x_irqs); i++) {
- __irq = i + chip->irq_base;
- irq_set_chip_data(__irq, chip);
- irq_set_chip_and_handler(__irq, _irq_chip,
-handle_edge_irq);
- irq_set_nested_thread(__irq, 1);
-#ifdef CONFIG_ARM
- set_irq_flags(__irq, IRQF_VALID);
-#else
- irq_set_noprobe(__irq);
-#endif
- }
-
ret = request_threaded_irq(chip->core_irq, NULL, pm860x_irq, flags,
"88pm860x", chip);
if (ret) {
--
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 5/9] mfd: 88pm860x: move initilization code
Move probe() and other functions from 88pm860x-i2c.c to 88pm860x-core.c.
Since it could benefit to handle DT information.
Signed-off-by: Haojian Zhuang
---
drivers/mfd/88pm860x-core.c | 162 +-
drivers/mfd/88pm860x-i2c.c | 160 -
include/linux/mfd/88pm860x.h |4 --
3 files changed, 159 insertions(+), 167 deletions(-)
diff --git a/drivers/mfd/88pm860x-core.c b/drivers/mfd/88pm860x-core.c
index d2b0bf8..797bdb3 100644
--- a/drivers/mfd/88pm860x-core.c
+++ b/drivers/mfd/88pm860x-core.c
@@ -11,10 +11,13 @@
#include
#include
+#include
#include
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -1064,8 +1067,8 @@ static void __devinit device_8606_init(struct pm860x_chip
*chip,
device_led_init(chip, pdata);
}
-int __devinit pm860x_device_init(struct pm860x_chip *chip,
- struct pm860x_platform_data *pdata)
+static int __devinit pm860x_device_init(struct pm860x_chip *chip,
+ struct pm860x_platform_data *pdata)
{
chip->core_irq = 0;
@@ -1092,12 +1095,165 @@ int __devinit pm860x_device_init(struct pm860x_chip
*chip,
return 0;
}
-void __devexit pm860x_device_exit(struct pm860x_chip *chip)
+static void __devexit pm860x_device_exit(struct pm860x_chip *chip)
{
device_irq_exit(chip);
mfd_remove_devices(chip->dev);
}
+static const struct i2c_device_id pm860x_id_table[] = {
+ { "88PM860x", 0 },
+ {}
+};
+MODULE_DEVICE_TABLE(i2c, pm860x_id_table);
+
+static int verify_addr(struct i2c_client *i2c)
+{
+ unsigned short addr_8607[] = {0x30, 0x34};
+ unsigned short addr_8606[] = {0x10, 0x11};
+ int size, i;
+
+ if (i2c == NULL)
+ return 0;
+ size = ARRAY_SIZE(addr_8606);
+ for (i = 0; i < size; i++) {
+ if (i2c->addr == *(addr_8606 + i))
+ return CHIP_PM8606;
+ }
+ size = ARRAY_SIZE(addr_8607);
+ for (i = 0; i < size; i++) {
+ if (i2c->addr == *(addr_8607 + i))
+ return CHIP_PM8607;
+ }
+ return 0;
+}
+
+static struct regmap_config pm860x_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+};
+
+static int __devinit pm860x_probe(struct i2c_client *client,
+ const struct i2c_device_id *id)
+{
+ struct pm860x_platform_data *pdata = client->dev.platform_data;
+ struct pm860x_chip *chip;
+ int ret;
+
+ if (!pdata) {
+ pr_info("No platform data in %s!\n", __func__);
+ return -EINVAL;
+ }
+
+ chip = kzalloc(sizeof(struct pm860x_chip), GFP_KERNEL);
+ if (chip == NULL)
+ return -ENOMEM;
+
+ chip->id = verify_addr(client);
+ chip->regmap = regmap_init_i2c(client, _regmap_config);
+ if (IS_ERR(chip->regmap)) {
+ ret = PTR_ERR(chip->regmap);
+ dev_err(>dev, "Failed to allocate register map: %d\n",
+ ret);
+ kfree(chip);
+ return ret;
+ }
+ chip->client = client;
+ i2c_set_clientdata(client, chip);
+ chip->dev = >dev;
+ dev_set_drvdata(chip->dev, chip);
+
+ /*
+* Both client and companion client shares same platform driver.
+* Driver distinguishes them by pdata->companion_addr.
+* pdata->companion_addr is only assigned if companion chip exists.
+* At the same time, the companion_addr shouldn't equal to client
+* address.
+*/
+ if (pdata->companion_addr && (pdata->companion_addr != client->addr)) {
+ chip->companion_addr = pdata->companion_addr;
+ chip->companion = i2c_new_dummy(chip->client->adapter,
+ chip->companion_addr);
+ chip->regmap_companion = regmap_init_i2c(chip->companion,
+ _regmap_config);
+ if (IS_ERR(chip->regmap_companion)) {
+ ret = PTR_ERR(chip->regmap_companion);
+ dev_err(>companion->dev,
+ "Failed to allocate register map: %d\n", ret);
+ return ret;
+ }
+ i2c_set_clientdata(chip->companion, chip);
+ }
+
+ pm860x_device_init(chip, pdata);
+ return 0;
+}
+
+static int __devexit pm860x_remove(struct i2c_client *client)
+{
+ struct pm860x_chip *chip = i2c_get_clientdata(client);
+
+ pm860x_device_exit(chip);
+ if (chip->companion) {
+ regmap_exit(chip->regmap_companion);
+ i2c_unregister_device(chip->companion);
+ }
+ regmap_exit(chip->regmap);
+ kfree(chip);
+ return 0;
+}
+
+#ifdef CONFIG_PM_SLEEP
+static int pm860x_suspend(struct
[PATCH 4/9] mfd: 88pm860x: avoid to check resource for preg regulator
From: Haojian Zhuang
Since PREG regulator is the only one regulator in 88PM8606, and other
regulators are in 88PM8607. Checking resource as identifying regulator
is not a good way. We can use NULL resource to indentify PREG regulator.
Signed-off-by: Haojian Zhuang
---
drivers/mfd/88pm860x-core.c |8 +---
drivers/regulator/88pm8607.c | 32 +++-
2 files changed, 20 insertions(+), 20 deletions(-)
diff --git a/drivers/mfd/88pm860x-core.c b/drivers/mfd/88pm860x-core.c
index 0c01d74..d2b0bf8 100644
--- a/drivers/mfd/88pm860x-core.c
+++ b/drivers/mfd/88pm860x-core.c
@@ -150,10 +150,6 @@ static struct resource charger_resources[] __devinitdata =
{
{PM8607_IRQ_VCHG, PM8607_IRQ_VCHG, "vchg voltage",IORESOURCE_IRQ,},
};
-static struct resource preg_resources[] __devinitdata = {
- {PM8606_ID_PREG, PM8606_ID_PREG, "preg", IORESOURCE_REG,},
-};
-
static struct resource rtc_resources[] __devinitdata = {
{PM8607_IRQ_RTC, PM8607_IRQ_RTC, "rtc", IORESOURCE_IRQ,},
};
@@ -960,10 +956,8 @@ static void __devinit device_power_init(struct pm860x_chip
*chip,
power_devs[2].platform_data = _init_data;
power_devs[2].pdata_size = sizeof(struct regulator_init_data);
- power_devs[2].num_resources = ARRAY_SIZE(preg_resources);
- power_devs[2].resources = _resources[0],
ret = mfd_add_devices(chip->dev, 0, _devs[2], 1,
- _resources[0], chip->irq_base, NULL);
+ NULL, chip->irq_base, NULL);
if (ret < 0)
dev_err(chip->dev, "Failed to add preg subdev\n");
}
diff --git a/drivers/regulator/88pm8607.c b/drivers/regulator/88pm8607.c
index d34bd8c..f96fbe3 100644
--- a/drivers/regulator/88pm8607.c
+++ b/drivers/regulator/88pm8607.c
@@ -358,7 +358,9 @@ static struct pm8607_regulator_info pm8607_regulator_info[]
= {
PM8607_LDO(12,LDO12, 0, SUPPLIES_EN12, 5),
PM8607_LDO(13, VIBRATOR_SET, 1, VIBRATOR_SET, 0),
PM8607_LDO(14,LDO14, 0, SUPPLIES_EN12, 6),
+};
+static struct pm8607_regulator_info pm8606_regulator_info[] = {
PM8606_PREG(PREREGULATORB, 5),
};
@@ -372,19 +374,23 @@ static int __devinit pm8607_regulator_probe(struct
platform_device *pdev)
int i;
res = platform_get_resource(pdev, IORESOURCE_REG, 0);
- if (res == NULL) {
- dev_err(>dev, "No REG resource!\n");
- return -EINVAL;
- }
- for (i = 0; i < ARRAY_SIZE(pm8607_regulator_info); i++) {
- info = _regulator_info[i];
- if (info->desc.vsel_reg == res->start)
- break;
- }
- if (i == ARRAY_SIZE(pm8607_regulator_info)) {
- dev_err(>dev, "Failed to find regulator %llu\n",
- (unsigned long long)res->start);
- return -EINVAL;
+ if (res) {
+ /* There're resources in 88PM8607 regulator driver */
+ for (i = 0; i < ARRAY_SIZE(pm8607_regulator_info); i++) {
+ info = _regulator_info[i];
+ if (info->desc.vsel_reg == res->start)
+ break;
+ }
+ if (i == ARRAY_SIZE(pm8607_regulator_info)) {
+ dev_err(>dev, "Failed to find regulator %llu\n",
+ (unsigned long long)res->start);
+ return -EINVAL;
+ }
+ } else {
+ /* There's no resource in 88PM8606 PREG regulator driver */
+ info = _regulator_info[0];
+ /* i is used to check regulator ID */
+ i = -1;
}
info->i2c = (chip->id == CHIP_PM8607) ? chip->client : chip->companion;
info->i2c_8606 = (chip->id == CHIP_PM8607) ? chip->companion :
--
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 3/9] regulator: 88pm860x: add pre-regulator support for 88pm860x regulator
From: "Jett.Zhou"
Pre-regulator of 88pm8606 is mainly for support charging based on vbus,
it needs to be enabled for charging battery, and will be disabled in
some exception condition like over-temp.
Add the pre-regulator support for 88pm860x regulator driver.
Signed-off-by: Jett.Zhou
Acked-by: Haojian Zhuang
---
drivers/regulator/88pm8607.c | 66 ++
1 file changed, 66 insertions(+)
diff --git a/drivers/regulator/88pm8607.c b/drivers/regulator/88pm8607.c
index 843c89a..d34bd8c 100644
--- a/drivers/regulator/88pm8607.c
+++ b/drivers/regulator/88pm8607.c
@@ -23,6 +23,7 @@ struct pm8607_regulator_info {
struct pm860x_chip *chip;
struct regulator_dev*regulator;
struct i2c_client *i2c;
+ struct i2c_client *i2c_8606;
unsigned int*vol_table;
unsigned int*vol_suspend;
@@ -242,6 +243,35 @@ static int pm8607_set_voltage_sel(struct regulator_dev
*rdev, unsigned selector)
return ret;
}
+static int pm8606_preg_enable(struct regulator_dev *rdev)
+{
+ struct pm8607_regulator_info *info = rdev_get_drvdata(rdev);
+
+ return pm860x_set_bits(info->i2c, rdev->desc->enable_reg,
+ 1 << rdev->desc->enable_mask, 0);
+}
+
+static int pm8606_preg_disable(struct regulator_dev *rdev)
+{
+ struct pm8607_regulator_info *info = rdev_get_drvdata(rdev);
+
+ return pm860x_set_bits(info->i2c, rdev->desc->enable_reg,
+ 1 << rdev->desc->enable_mask,
+ 1 << rdev->desc->enable_mask);
+}
+
+static int pm8606_preg_is_enabled(struct regulator_dev *rdev)
+{
+ struct pm8607_regulator_info *info = rdev_get_drvdata(rdev);
+ int ret;
+
+ ret = pm860x_reg_read(info->i2c, rdev->desc->enable_reg);
+ if (ret < 0)
+ return ret;
+
+ return !((unsigned char)ret & (1 << rdev->desc->enable_mask));
+}
+
static struct regulator_ops pm8607_regulator_ops = {
.list_voltage = pm8607_list_voltage,
.set_voltage_sel = pm8607_set_voltage_sel,
@@ -251,6 +281,25 @@ static struct regulator_ops pm8607_regulator_ops = {
.is_enabled = regulator_is_enabled_regmap,
};
+static struct regulator_ops pm8606_preg_ops = {
+ .enable = pm8606_preg_enable,
+ .disable= pm8606_preg_disable,
+ .is_enabled = pm8606_preg_is_enabled,
+};
+
+#define PM8606_PREG(ereg, ebit)
\
+{ \
+ .desc = { \
+ .name = "PREG", \
+ .ops= _preg_ops, \
+ .type = REGULATOR_CURRENT,\
+ .id = PM8606_ID_PREG, \
+ .owner = THIS_MODULE, \
+ .enable_reg = PM8606_##ereg,\
+ .enable_mask = (ebit), \
+ }, \
+}
+
#define PM8607_DVC(vreg, ureg, ubit, ereg, ebit) \
{ \
.desc = { \
@@ -309,6 +358,8 @@ static struct pm8607_regulator_info pm8607_regulator_info[]
= {
PM8607_LDO(12,LDO12, 0, SUPPLIES_EN12, 5),
PM8607_LDO(13, VIBRATOR_SET, 1, VIBRATOR_SET, 0),
PM8607_LDO(14,LDO14, 0, SUPPLIES_EN12, 6),
+
+ PM8606_PREG(PREREGULATORB, 5),
};
static int __devinit pm8607_regulator_probe(struct platform_device *pdev)
@@ -336,6 +387,8 @@ static int __devinit pm8607_regulator_probe(struct
platform_device *pdev)
return -EINVAL;
}
info->i2c = (chip->id == CHIP_PM8607) ? chip->client : chip->companion;
+ info->i2c_8606 = (chip->id == CHIP_PM8607) ? chip->companion :
+ chip->client;
info->chip = chip;
/* check DVC ramp slope double */
@@ -371,6 +424,18 @@ static int __devexit pm8607_regulator_remove(struct
platform_device *pdev)
return 0;
}
+static struct platform_device_id pm8607_regulator_driver_ids[] = {
+ {
+ .name = "88pm860x-regulator",
+ .driver_data= 0,
+ }, {
+ .name = "88pm860x-preg",
+ .driver_data= 0,
+ },
+ { },
+};
+MODULE_DEVICE_TABLE(platform, pm8607_regulator_driver_ids);
+
static struct platform_driver pm8607_regulator_driver = {
.driver = {
.name = "88pm860x-regulator",
@@ -378,6 +443,7 @@ static struct platform_driver pm8607_regulator_driver = {
},
.probe =
[PATCH 2/9] mfd: max8925: remove array in regulator platform data
Remove array in parent's platform data. Use struct regulator_init_data
as regulator device's platform data directly. So a lot of pdata are
added into parent's platform data. And voltage out register offset
is used as IORESOURCE_REG to distinguish different regualtor devices.
Signed-off-by: Haojian Zhuang
---
drivers/mfd/max8925-core.c| 388 +++--
drivers/regulator/max8925-regulator.c | 35 ++-
include/linux/mfd/max8925.h | 26 ++-
3 files changed, 356 insertions(+), 93 deletions(-)
diff --git a/drivers/mfd/max8925-core.c b/drivers/mfd/max8925-core.c
index b9f1d5c..1e0ab0a 100644
--- a/drivers/mfd/max8925-core.c
+++ b/drivers/mfd/max8925-core.c
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include
#include
@@ -109,71 +110,215 @@ static struct mfd_cell onkey_devs[] = {
},
};
-#define MAX8925_REG_RESOURCE(_start, _end) \
-{ \
- .start = MAX8925_##_start, \
- .end= MAX8925_##_end, \
- .flags = IORESOURCE_REG, \
-}
+static struct resource sd1_resources[] __devinitdata = {
+ {0x06, 0x06, "sdv", IORESOURCE_REG, },
+};
-static struct resource regulator_resources[] = {
- MAX8925_REG_RESOURCE(SDCTL1, SDCTL1),
- MAX8925_REG_RESOURCE(SDCTL2, SDCTL2),
- MAX8925_REG_RESOURCE(SDCTL3, SDCTL3),
- MAX8925_REG_RESOURCE(LDOCTL1, LDOCTL1),
- MAX8925_REG_RESOURCE(LDOCTL2, LDOCTL2),
- MAX8925_REG_RESOURCE(LDOCTL3, LDOCTL3),
- MAX8925_REG_RESOURCE(LDOCTL4, LDOCTL4),
- MAX8925_REG_RESOURCE(LDOCTL5, LDOCTL5),
- MAX8925_REG_RESOURCE(LDOCTL6, LDOCTL6),
- MAX8925_REG_RESOURCE(LDOCTL7, LDOCTL7),
- MAX8925_REG_RESOURCE(LDOCTL8, LDOCTL8),
- MAX8925_REG_RESOURCE(LDOCTL9, LDOCTL9),
- MAX8925_REG_RESOURCE(LDOCTL10, LDOCTL10),
- MAX8925_REG_RESOURCE(LDOCTL11, LDOCTL11),
- MAX8925_REG_RESOURCE(LDOCTL12, LDOCTL12),
- MAX8925_REG_RESOURCE(LDOCTL13, LDOCTL13),
- MAX8925_REG_RESOURCE(LDOCTL14, LDOCTL14),
- MAX8925_REG_RESOURCE(LDOCTL15, LDOCTL15),
- MAX8925_REG_RESOURCE(LDOCTL16, LDOCTL16),
- MAX8925_REG_RESOURCE(LDOCTL17, LDOCTL17),
- MAX8925_REG_RESOURCE(LDOCTL18, LDOCTL18),
- MAX8925_REG_RESOURCE(LDOCTL19, LDOCTL19),
- MAX8925_REG_RESOURCE(LDOCTL20, LDOCTL20),
-};
-
-#define MAX8925_REG_DEVS(_id) \
-{ \
- .name = "max8925-regulator", \
- .num_resources = 1,\
- .resources = _resources[MAX8925_ID_##_id], \
- .id = MAX8925_ID_##_id, \
-}
+static struct resource sd2_resources[] __devinitdata = {
+ {0x09, 0x09, "sdv", IORESOURCE_REG, },
+};
+
+static struct resource sd3_resources[] __devinitdata = {
+ {0x0c, 0x0c, "sdv", IORESOURCE_REG, },
+};
+
+static struct resource ldo1_resources[] __devinitdata = {
+ {0x1a, 0x1a, "ldov", IORESOURCE_REG, },
+};
+
+static struct resource ldo2_resources[] __devinitdata = {
+ {0x1e, 0x1e, "ldov", IORESOURCE_REG, },
+};
+
+static struct resource ldo3_resources[] __devinitdata = {
+ {0x22, 0x22, "ldov", IORESOURCE_REG, },
+};
+
+static struct resource ldo4_resources[] __devinitdata = {
+ {0x26, 0x26, "ldov", IORESOURCE_REG, },
+};
-static struct mfd_cell regulator_devs[] = {
- MAX8925_REG_DEVS(SD1),
- MAX8925_REG_DEVS(SD2),
- MAX8925_REG_DEVS(SD3),
- MAX8925_REG_DEVS(LDO1),
- MAX8925_REG_DEVS(LDO2),
- MAX8925_REG_DEVS(LDO3),
- MAX8925_REG_DEVS(LDO4),
- MAX8925_REG_DEVS(LDO5),
- MAX8925_REG_DEVS(LDO6),
- MAX8925_REG_DEVS(LDO7),
- MAX8925_REG_DEVS(LDO8),
- MAX8925_REG_DEVS(LDO9),
- MAX8925_REG_DEVS(LDO10),
- MAX8925_REG_DEVS(LDO11),
- MAX8925_REG_DEVS(LDO12),
- MAX8925_REG_DEVS(LDO13),
- MAX8925_REG_DEVS(LDO14),
- MAX8925_REG_DEVS(LDO15),
- MAX8925_REG_DEVS(LDO16),
- MAX8925_REG_DEVS(LDO17),
- MAX8925_REG_DEVS(LDO18),
- MAX8925_REG_DEVS(LDO19),
- MAX8925_REG_DEVS(LDO20),
+static struct resource ldo5_resources[] __devinitdata = {
+ {0x2a, 0x2a, "ldov", IORESOURCE_REG, },
+};
+
+static struct resource ldo6_resources[] __devinitdata = {
+ {0x2e, 0x2e, "ldov", IORESOURCE_REG, },
+};
+
+static struct resource ldo7_resources[] __devinitdata = {
+ {0x32, 0x32, "ldov", IORESOURCE_REG, },
+};
+
+static struct resource ldo8_resources[] __devinitdata = {
+ {0x36, 0x36, "ldov", IORESOURCE_REG, },
+};
+
+static struct resource ldo9_resources[] __devinitdata = {
+ {0x3a, 0x3a, "ldov", IORESOURCE_REG, },
+};
+
+static struct resource ldo10_resources[] __devinitdata = {
+ {0x3e, 0x3e, "ldov", IORESOURCE_REG, },
+};
+
[PATCH 1/9] mfd: max8925: use register offset as REG in backlight
Remove the register offset definition. All these register offset
are transfered as IORESOURCE_REG resources.
Signed-off-by: Haojian Zhuang
---
drivers/mfd/max8925-core.c | 31 ++---
drivers/video/backlight/max8925_bl.c | 79 ++
2 files changed, 55 insertions(+), 55 deletions(-)
diff --git a/drivers/mfd/max8925-core.c b/drivers/mfd/max8925-core.c
index f2ff31f..b9f1d5c 100644
--- a/drivers/mfd/max8925-core.c
+++ b/drivers/mfd/max8925-core.c
@@ -18,20 +18,16 @@
#include
#include
-static struct resource backlight_resources[] = {
- {
- .name = "max8925-backlight",
- .start = MAX8925_WLED_MODE_CNTL,
- .end= MAX8925_WLED_CNTL,
- .flags = IORESOURCE_REG,
- },
+static struct resource bk_resources[] __devinitdata = {
+ { 0x84, 0x84, "mode control", IORESOURCE_REG, },
+ { 0x85, 0x85, "control", IORESOURCE_REG, },
};
-static struct mfd_cell backlight_devs[] = {
+static struct mfd_cell bk_devs[] __devinitdata = {
{
.name = "max8925-backlight",
- .num_resources = 1,
- .resources = _resources[0],
+ .num_resources = ARRAY_SIZE(bk_resources),
+ .resources = _resources[0],
.id = -1,
},
};
@@ -623,13 +619,14 @@ int __devinit max8925_device_init(struct max8925_chip
*chip,
}
if (pdata && pdata->backlight) {
- ret = mfd_add_devices(chip->dev, 0, _devs[0],
- ARRAY_SIZE(backlight_devs),
- _resources[0], 0, NULL);
- if (ret < 0) {
- dev_err(chip->dev, "Failed to add backlight subdev\n");
- goto out_dev;
- }
+ bk_devs[0].platform_data = >backlight;
+ bk_devs[0].pdata_size = sizeof(struct max8925_backlight_pdata);
+ }
+ ret = mfd_add_devices(chip->dev, 0, bk_devs, ARRAY_SIZE(bk_devs),
+ NULL, 0, NULL);
+ if (ret < 0) {
+ dev_err(chip->dev, "Failed to add backlight subdev\n");
+ goto out_dev;
}
if (pdata && pdata->power) {
diff --git a/drivers/video/backlight/max8925_bl.c
b/drivers/video/backlight/max8925_bl.c
index 996dadf..f72ba54 100644
--- a/drivers/video/backlight/max8925_bl.c
+++ b/drivers/video/backlight/max8925_bl.c
@@ -27,7 +27,9 @@
struct max8925_backlight_data {
struct max8925_chip *chip;
- int current_brightness;
+ int current_brightness;
+ int reg_mode_cntl;
+ int reg_cntl;
};
static int max8925_backlight_set(struct backlight_device *bl, int brightness)
@@ -42,16 +44,16 @@ static int max8925_backlight_set(struct backlight_device
*bl, int brightness)
else
value = brightness;
- ret = max8925_reg_write(chip->i2c, MAX8925_WLED_CNTL, value);
+ ret = max8925_reg_write(chip->i2c, data->reg_cntl, value);
if (ret < 0)
goto out;
if (!data->current_brightness && brightness)
/* enable WLED output */
- ret = max8925_set_bits(chip->i2c, MAX8925_WLED_MODE_CNTL, 1, 1);
+ ret = max8925_set_bits(chip->i2c, data->reg_mode_cntl, 1, 1);
else if (!brightness)
/* disable WLED output */
- ret = max8925_set_bits(chip->i2c, MAX8925_WLED_MODE_CNTL, 1, 0);
+ ret = max8925_set_bits(chip->i2c, data->reg_mode_cntl, 1, 0);
if (ret < 0)
goto out;
dev_dbg(chip->dev, "set brightness %d\n", value);
@@ -85,7 +87,7 @@ static int max8925_backlight_get_brightness(struct
backlight_device *bl)
struct max8925_chip *chip = data->chip;
int ret;
- ret = max8925_reg_read(chip->i2c, MAX8925_WLED_CNTL);
+ ret = max8925_reg_read(chip->i2c, data->reg_cntl);
if (ret < 0)
return -EINVAL;
data->current_brightness = ret;
@@ -102,69 +104,70 @@ static const struct backlight_ops max8925_backlight_ops =
{
static int __devinit max8925_backlight_probe(struct platform_device *pdev)
{
struct max8925_chip *chip = dev_get_drvdata(pdev->dev.parent);
- struct max8925_platform_data *max8925_pdata;
- struct max8925_backlight_pdata *pdata = NULL;
+ struct max8925_backlight_pdata *pdata = pdev->dev.platform_data;
struct max8925_backlight_data *data;
struct backlight_device *bl;
struct backlight_properties props;
struct resource *res;
- char name[MAX8925_NAME_SIZE];
unsigned char value;
- int ret;
-
- res = platform_get_resource(pdev, IORESOURCE_REG, 0);
- if (res == NULL) {
- dev_err(>dev, "No I/O resource!\n");
- return -EINVAL;
- }
-
- if
[PATCH 0/9] mfd: update on 88pm860x and max8925
1. Updates the patch of max8925 of building issue. 2. Include Jett's PREG regulator patch. 3. Support DT in 88pm860x. -- 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] memory leak fix while calling system_path
Hi,
On Fri, 14 Sep 2012 11:14:13 +0800, liang xie wrote:
> memory leak fix while calling system_path
>
> Since v1: Remove an unnecessary null pointer check per Felipe's comments
> Since v2: Make system_path_exec_path always return dynamically
> allocated string
>
> Signed-off-by: xieliang
> ---
> tools/perf/builtin-help.c | 12 +---
> tools/perf/builtin-script.c | 13 ++---
> tools/perf/perf.c |8 ++--
> tools/perf/util/config.c| 16 +---
> tools/perf/util/exec_cmd.c | 26 +++---
> tools/perf/util/exec_cmd.h |4 ++--
> tools/perf/util/help.c |6 --
> 7 files changed, 51 insertions(+), 34 deletions(-)
>
> diff --git a/tools/perf/builtin-help.c b/tools/perf/builtin-help.c
> index 6d5a8a7..180a5bd 100644
> --- a/tools/perf/builtin-help.c
> +++ b/tools/perf/builtin-help.c
> @@ -321,12 +321,13 @@ static void setup_man_path(void)
> {
> struct strbuf new_path = STRBUF_INIT;
> const char *old_path = getenv("MANPATH");
> + char *man_path = system_path(PERF_MAN_PATH);
I think the return value of system_path and perf_exec_path should be
checked since they can return NULL as strdup() does.
[snip]
> diff --git a/tools/perf/util/exec_cmd.c b/tools/perf/util/exec_cmd.c
> index 7adf4ad..1ace941 100644
> --- a/tools/perf/util/exec_cmd.c
> +++ b/tools/perf/util/exec_cmd.c
> @@ -9,17 +9,19 @@
> static const char *argv_exec_path;
> static const char *argv0_path;
>
> -const char *system_path(const char *path)
> +char *system_path(const char *path)
> {
> - static const char *prefix = PREFIX;
> - struct strbuf d = STRBUF_INIT;
> + char *new_path = NULL;
>
> if (is_absolute_path(path))
> - return path;
> + return strdup(path);
>
> - strbuf_addf(, "%s/%s", prefix, path);
> - path = strbuf_detach(, NULL);
> - return path;
> + new_path = malloc((strlen(PREFIX) + strlen(path) + 2));
> + if (!new_path)
> + die("malloc");
> +
> + sprintf(new_path, "%s/%s", PREFIX, path);
> + return new_path;
AFAIK strbuf allocates memory internally, so why this code is needed?
Thanks,
Namhyung
--
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]power: battery: Generic battery driver using IIO
Hello Lars,
Thanks for the review.All of you comments are valid but
i just have a small question w.r.t one of your comments.
Inline below.
On Sun, Sep 16, 2012 at 9:11 PM, Lars-Peter Clausen wrote:
> On 09/16/2012 09:14 AM, anish kumar wrote:
>> From: anish kumar
>>
>> In last version:
>> Addressed concerns raised by lars:
>> a. made the adc_bat per device.
>> b. get the IIO channel using hardcoded channel names.
>> c. Minor issues related to gpio_is_valid and some code
>>refactoring.
>>
>> In this version:
>> Addressed concerns raised by Anton:
>> a. changed the struct name to gab(generic adc battery).
>> b. Added some functions to neaten the code.
>> c. Some minor coding guidelines changes.
>> d. Used the latest function introduce by lars:
>>iio_read_channel_processed to streamline the code.
>>
>> Signed-off-by: anish kumar
>> ---
>> drivers/power/generic-adc-battery.c | 442
>> +
>> include/linux/power/generic-adc-battery.h | 19 ++
>> 2 files changed, 461 insertions(+), 0 deletions(-)
>> create mode 100644 drivers/power/generic-adc-battery.c
>> create mode 100644 include/linux/power/generic-adc-battery.h
>>
>> diff --git a/drivers/power/generic-adc-battery.c
>> b/drivers/power/generic-adc-battery.c
>> new file mode 100644
>> index 000..fd62916
>> --- /dev/null
>> +++ b/drivers/power/generic-adc-battery.c
>> @@ -0,0 +1,442 @@
>> +/*
>> + * Generic battery driver code using IIO
>> + * Copyright (C) 2012, Anish Kumar
>> + * based on jz4740-battery.c
>> + * based on s3c_adc_battery.c
>> + *
>> + * This file is subject to the terms and conditions of the GNU General
>> Public
>> + * License. See the file COPYING in the main directory of this archive for
>> + * more details.
>> + *
>> + */
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +enum gab_chan_type {
>> + VOLTAGE = 0,
>> + CURRENT,
>> + POWER,
>> + MAX_CHAN_TYPE
>> +};
>> +
>> +/*
>> + * gab_chan_name suggests the standard channel names for commonly used
>> + * channel types.
>> + */
>> +static char *gab_chan_name[] = {
>
> const char *const
>
>> + [VOLTAGE] = "voltage",
>> + [CURRENT] = "current",
>> + [POWER] = "power",
>> +};
>> +
>> +struct gab {
>> + struct power_supply psy;
>> + struct iio_channel **channel;
>> + struct gab_platform_data*pdata;
>> + struct delayed_work bat_work;
>> + int was_plugged;
>> + int volt_value;
>> + int cur_value;
>
> The two above are never really used.
>
>> + int level;
>> + int status;
>> + int cable_plugged:1;
>> +};
> [...]
>> +static enum power_supply_property gab_props[] = {
> const
>> + POWER_SUPPLY_PROP_STATUS,
>> + POWER_SUPPLY_PROP_CHARGE_FULL_DESIGN,
>> + POWER_SUPPLY_PROP_CHARGE_EMPTY_DESIGN,
>> + POWER_SUPPLY_PROP_CHARGE_NOW,
>> + POWER_SUPPLY_PROP_VOLTAGE_NOW,
>> + POWER_SUPPLY_PROP_CURRENT_NOW,
>> + POWER_SUPPLY_PROP_TECHNOLOGY,
>> + POWER_SUPPLY_PROP_VOLTAGE_MIN_DESIGN,
>> + POWER_SUPPLY_PROP_VOLTAGE_MAX_DESIGN,
>> + POWER_SUPPLY_PROP_MODEL_NAME,
>> +};
>> +
>> +/*
>> + * This properties are set based on the received platform data and this
>> + * should correspond one-to-one with enum chan_type.
>> + */
>> +static enum power_supply_property gab_dyn_props[] = {
> const
>> + POWER_SUPPLY_PROP_VOLTAGE_NOW,
>> + POWER_SUPPLY_PROP_CURRENT_NOW,
>> + POWER_SUPPLY_PROP_POWER_NOW,
>> +};
>> +
>> +static bool charge_finished(struct gab *adc_bat)
>
> missing prefix
>
>> +{
>> + bool ret = gpio_get_value(adc_bat->pdata->gpio_charge_finished);
>> + bool inv = adc_bat->pdata->gpio_inverted;
>> +
>> + return ret ^ inv;
>> +}
>> +
>> +int gab_get_status(struct gab *adc_bat)
> static
>> +{
>> + struct gab_platform_data *pdata = adc_bat->pdata;
>> + int chg_gpio = pdata->gpio_charge_finished;
>> +
>> + if (!gpio_is_valid(chg_gpio) || adc_bat->level < 10)
>
> level is never really set, is it? Also the 10 seems to come directly from
> the s3c_adc_battery driver, while this value may be different for every
> battery. I'd use the bat_info->charge_full_design here. Also I'd remove the
> !gpio_is_valid(chg_gpio) I don't see a reason why the battery could not be
> fully charged even though no charger gpio is given.
gpio_is_valid is just a call to check if the particular gpio is valid or not[1].
I don't seem to understand why we are using it everywhere when only in probe it
makes sense as far as my understanding goes.If in probe it is proper then why
this check again and again(?) or is it possible that someone else
does something somewhere which necessitates this gpio_is_valid check.
And we are using charger gpio in the probe function.
[1]
Re: [PATCH] dmaengine: add dmanegine slave map api's
On Fri, 2012-09-14 at 12:18 +0100, Russell King - ARM Linux wrote: > I'm not saying take the slave_id out of the map. I'm saying, let the > DMA engine driver itself figure out what dma_chan to return. But wont that assume the dma controller knows which channel to allocate. And how would it know this information? This can be problematic for hard wired muxes, but can be easily done for controller which have programmable mux. -- ~Vinod -- 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/
linux-next: build failure after merge of the target-updates tree
Hi Nicholas, After merging the target-updates tree, today's linux-next build (x86_64 allmodconfig) failed like this: drivers/target/target_core_transport.c: In function 'transport_get_sense_buffer': drivers/target/target_core_transport.c:582:22: error: 'struct target_core_fabric_ops' has no member named 'set_fabric_sense_len' I can only assume that this has been caused by the (largish) changes that went into Linus' tree recently conflicting with changes in the target-updates tree. I have dropped the target-updates tree for today. Please sort the mess out. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpdMm6IWKPzu.pgp Description: PGP signature
Re: [PATCH] fix ZOMBIE state bug in PPPOE driver
On Sun, Sep 16, 2012 at 10:30 AM, Xiaodong Xu wrote: > Hi All, > > I found a bug in kernel PPPOE driver. > When PPPOE is running over a virtual ethernet interface (e.g., a > bonding interface) and the user tries to delete the interface in case > the PPPOE state is ZOMBIE, the kernel will loop infinitely while > unregistering net_device for the reference count is not reset to zero > which should be done by dev_put(). > > The following patch could fix this issue: You missed your Signed-off-by, please read Documentation/SubmittingPatches and check your patch with scripts/checkpatch.pl before sending. -- 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/
linux-next: manual merge of the target-updates tree with Linus' tree
Hi Nicholas,
Today's linux-next merge of the target-updates tree got a conflict in
drivers/target/target_core_transport.c between commit 6138ed2ab879
("target: move transport_get_sense_data") from Linus' tree and commit
867c8e7dae31 ("target: Simplify fabric sense data length handling") from
the target-updates tree.
I just removed the latter version of transport_get_sense_data() (which
has been renamed to transport_get_sense_buffer() and changed in Linus'
tree) and can carry the fix as necessary - someone should really look at
the result when it is available.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpsCKtVCVbsV.pgp
Description: PGP signature
Re: [RFC] status of execve() work - per-architecture patches solicited
On Mon, Sep 10, 2012 at 06:20:01PM -0400, Mark Salter wrote: > C6X works fine with these patches to switch over to generic code. > > > Mark Salter (2): > c6x: implement ret_from_kernel_execve() and switch to generic > kernel_execve() > c6x: switch to generic sys_execve() > > arch/c6x/include/asm/syscalls.h |5 --- > arch/c6x/include/asm/unistd.h |3 ++ > arch/c6x/kernel/entry.S | 54 +- > arch/c6x/kernel/process.c | 22 > 4 files changed, 27 insertions(+), 57 deletions(-) Applied. There's an alternative variant of that branch; see #experimental-kernel_thread in the same tree. I have *not* attempted to port those patches over there - I don't have anything to test on and architecture is too unfamiliar for me to even attempt it blindly. The main differences between those branches are: * ret_from_fork is usually split in two - ret_from_fork is used for normal processes and ret_from_kernel_thread is its analog for kernel threads; copy_thread() chooses one to use based on user_mode(regs). * ret_from_kernel_thread does *not* go through the normal return-from-syscall codepath; instead of doing that it simply does an equivalent of kernel_thread_helper() itself - i.e. calls the function we'd passed to kernel_thread(), followed by sys_exit(). * ret_from_kernel_execve does *not* bother with memmove(); it's done by generic kernel_execve() itself. Note that the first two changes guarantee that kernel threads will have pt_regs at the bottom of their stack, so we won't have any overlaps - not between the source and destination of copying pt_regs and not between the stack frame and that destination. I.e. that copying can safely be done by generic C implementation of kernel_execve(). I've ported (and tested) execve2 stuff to that model; it's done for alpha, arm, m68k, s390, powerpc, x86 and um. I think it's a better approach: * ret_from_kernel_execve() is simpler that way - one argument, no memmove() call to implement in there. * we get to kill the last remnants of "syscall instruction from the kernel mode" crap (c6x kernel_thread() is free from that already, but for many architectures it's not so) * syscall return codepath is only taken for return to userland now; succeeding kernel_thread() is not sharing it. Seeing that a bunch of things on that path should be avoided when returning to kernel mode, that allows for nice optimizations and simpler logics in the asm glue. * it removes more code. BTW, right now the contents of experimental-kernel_thread + for-next sans execve2 counterparts is probably getting close to Linus' "it removes 1KLoC, piss on all merge window rules and pull it now" threshold ;-) The price is that kernel threads are in the same boat as userland processes now wrt kernel stack consumption - they get pt_regs in the bottom of kernel stack, same as for normal syscall path. That makes for _much_ simpler life, but if there's a kernel thread with really borderline stack footprint, that might push it over the edge. Note, however, that syscalls are where the worst stack footprints tend to happen and for those we can't get rid of pt_regs on stack, no matter what we do. Just as with #execve2 it's not a flagday conversion; however, switching from one to another probably would be messy, so we'd better decide which one we'll be doing before the merge window. Comments? -- 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 00/15] ASoC: OMAP: Convert to use dmaengine
On Fri, 2012-09-14 at 15:05 +0300, Peter Ujfalusi wrote: > Hello, dmaengine parts look good to me. How do you want to get this merged, dmaengine or ASoC tree? > > Changes since v2: > - As it has been discussed the no_wakeup parameter has been replaced with > flags > for the dmaengine APIs > > Changes since v1: > - Support for pause/resume for OMAP audio via dmaengine > - dmaengine: support for NO_PERIOD_WAKEUP in cyclic mode > - OMAP to keep supporting NO_PERIOD_WAKEUP for audio > - Other plaforms can also try to enable this mode since we have now generic >interface to do so. > > This series will switch the OMAP audio to use dmaengine. > The final patch which does the switch was based on Russell King's earlier > patch. > > The first 10 patch is to prepare the OMAP audio drivers for a smooth change to > dmaengine: > - sDMA FRAME sync mode is removed and replaced with PACKET mode > - dai drivers no longer need to configure sDMA sync mode > - dai drivers does not need to specify the DMA word length - with the > exception > of the omap-hdmi driver which requires 32bit word length regardless of the > audio format in use > - the McPDM driver used (to my surprise) hackish way of getting the DMA > channel > and address - via defines from some header files > > After the conversion OMAP audio support should have the same features as > before, > no regressions expected. > > I have tested the series on: > - BeagleBoard (audio via McBSP): > - aplay/arecord. In element mode and in threshold mode with different period >sizes > - mplayer -ao alsa: for direct ALSA access > - mplayer -ao pulse: via PulseAudio to test NO_PERIOD_WAKEUP feature > - OMAP4 Blaze (audio via McPDM and DMIC) > - aplay/arecord > - mplayer -ao alsa: for direct ALSA access > - mplayer -ao pulse: via PulseAudio to test NO_PERIOD_WAKEUP feature > > The patches has been generated against: > git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-3.7 > > Janusz: Can you retest this series on OMAP1 to be sure I have not broken it? > Ricardo: Can you test the omap-hmdi if it is still working? > > Regards, > Peter > --- > Peter Ujfalusi (15): > dmaengine: omap: Support for element mode in cyclic DMA > dmaengine: omap: Add support for pause/resume in cyclic dma mode > dmaengine: Add flags parameter to dmaengine_prep_dma_cyclic() > dmaengine: Pass flags via device_prep_dma_cyclic() callback > dmaengine: omap-dma: Add support to suppress interrupts in cyclic > mode > ASoC: omap-mcbsp: Use sDMA packet mode instead of frame mode > ASoC: omap-pcm: Select sDMA synchronization based on packet_size > ASoC: OMAP: Remove sync_mode from omap_pcm_dma_data struct > ASoC: omap-pcm: Prepare to configure the DMA data_type based on > stream properties > ARM: OMAP4: hwmod_data: Add resource names to McPDM memory ranges > ASoC: omap-mcpdm: Use platform_get_resource_* to get resources > ASoC: OMAP: mcbsp, mcpdm, dmic: Let omap-pcm to pick the dma_type > ASoC: omap-pcm, omap-dmic: Change the use of > omap_pcm_dma_data->data_type > ASoC: OMAP: mcbsp, mcpdm, dmic, hdmi: Set dma_data at startup time > ASoC: omap-pcm: Convert to use dmaengine > > arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 2 + > drivers/dma/at_hdmac.c | 3 +- > drivers/dma/ep93xx_dma.c | 4 +- > drivers/dma/imx-dma.c | 2 +- > drivers/dma/imx-sdma.c | 2 +- > drivers/dma/mmp_tdma.c | 2 +- > drivers/dma/mxs-dma.c | 2 +- > drivers/dma/omap-dma.c | 45 -- > drivers/dma/pl330.c| 2 +- > drivers/dma/sa11x0-dma.c | 2 +- > drivers/dma/sirf-dma.c | 2 +- > drivers/dma/ste_dma40.c| 3 +- > drivers/dma/tegra20-apb-dma.c | 2 +- > include/linux/dmaengine.h | 7 +- > sound/soc/omap/Kconfig | 3 +- > sound/soc/omap/omap-dmic.c | 9 +- > sound/soc/omap/omap-hdmi.c | 17 ++- > sound/soc/omap/omap-mcbsp.c| 60 +++- > sound/soc/omap/omap-mcpdm.c| 40 +++-- > sound/soc/omap/omap-pcm.c | 236 > - > sound/soc/omap/omap-pcm.h | 4 +- > sound/soc/soc-dmaengine-pcm.c | 6 +- > 22 files changed, 186 insertions(+), 269 deletions(-) > -- ~Vinod -- 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 02/15] dmaengine: omap: Add support for pause/resume in cyclic dma mode
On Fri, 2012-09-14 at 15:05 +0300, Peter Ujfalusi wrote: > - /* FIXME: not supported by platform private API */ > - return -EINVAL; > + /* Pause/Resume only allowed with cyclic mode */ > + if (!c->cyclic) > + return -EINVAL; This is not a dma restriction right? -- ~Vinod -- 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/
linux-next: manual merge of the scsi tree with the pci tree
Hi James,
Today's linux-next merge of the scsi tree got a conflict in
drivers/scsi/qla2xxx/qla_nx.c between commit 100924388407 ("[SCSI]
qla4xxx: Use PCI Express Capability accessors") from the pci tree and
commit 8fbb85e5f4c0 ("[SCSI] qla2xxx: Wrong PCIe(2.5Gb/s x8) speed in the
kerenel message for ISP82xx") from the scsi tree.
The latter removes one of the functions updated by the former. So I
removed it and can carry the fix as necessary (no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpdd2FQJnnH4.pgp
Description: PGP signature
Re: [ANNOUNCE] kmod 10
Jan Engelhardt wrote: On Thursday 2012-09-06 21:37, Lucas De Marchi wrote: kmod 10 is out: ftp://ftp.kernel.org/pub/linux/utils/kernel/kmod/kmod-10.tar.xz ftp://ftp.kernel.org/pub/linux/utils/kernel/kmod/kmod-10.tar.sign make check fails here with glibc-2.15, gcc-4.7, x86_64, due to what seems to be duplicated symbols(?) On my LFS system, glibc-2.16, gcc-4.7.1, x86_64, I do not see these errors: ./configure --prefix=/usr --bindir=/bin --libdir=/lib \ --sysconfdir=/etc --with-xz --with-zlib make make check == All 9 tests passed == What is interesting is that if I run the checks again: make check I get: TESTSUITE: running modprobe_softdep_loop, in forked context TESTSUITE: ERR: rootfs /usr/src/kmod/kmod-10/testsuite/rootfs/test-modprobe/softdep-loop is dirty, please run 'make rootfs' before runnning this test TESTSUITE: ERR: 'modprobe_softdep_loop' [16407] exited with return code 1 TESTSUITE: ERR: FAILED: modprobe_softdep_loop FAIL: testsuite/test-modprobe TESTSUITE: running test_insert, in forked context TESTSUITE: ERR: rootfs /usr/src/kmod/kmod-10/testsuite/rootfs/test-init/ is dirty, please run 'make rootfs' before runnning this test TESTSUITE: ERR: 'test_insert' [16373] exited with return code 1 TESTSUITE: ERR: FAILED: test_insert FAIL: testsuite/test-init == 2 of 9 tests failed Please report to linux-modu...@vger.kernel.org == 'make rootfs' does not do anything but make distclean && configure && make && make check is clean for me. -- Bruce -- 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/8] DMA: PL330: use prefix in reg names to build under x86
On Fri, 2012-09-14 at 18:23 +0200, Davide Ciminaghi wrote: > From: Alessandro Rubini > > This driver would not compile if ARM_AMBA is selected under x86, > because "CS" and "DS" are already defined there. But AMBA > is used in the x86 world by a PCI-to-AMBA bridge, to be submitted. > > The patch adds the "PL330_" prefix to all register and bit fields, > so it can be built by randomconfig after ARM_AMBA appears within x86. > > Signed-off-by: Alessandro Rubini > Acked-by: Giancarlo Asnaghi > --- Acked-by: Vinod Koul -- ~Vinod -- 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] ACPI/pci-bind: remove bind/unbind callbacks from acpi_device_ops
On Sun, Sep 16, 2012 at 11:02 AM, Yinghai Lu wrote:
> On Sun, Sep 16, 2012 at 9:49 AM, Yinghai Lu wrote:
>> On Sun, Sep 16, 2012 at 7:09 AM, Jiang Liu wrote:
>>> @@ -160,10 +160,13 @@ static int acpi_bind_one(struct device *dev,
>>> acpi_handle handle)
>>> }
>>> dev->archdata.acpi_handle = handle;
>>>
>>> - acpi_pci_bind_notify(dev->archdata.acpi_handle, dev, true);
>>> -
>>> status = acpi_bus_get_device(handle, _dev);
>>> - if (!ACPI_FAILURE(status)) {
>>> + if (!ACPI_FAILURE(status))
>>> + acpi_dev = NULL;
>>> +
>>> + acpi_pci_bind_notify(dev->archdata.acpi_handle, acpi_dev, dev,
>>> true);
>>
>> It seems you can do
>> acpi_pci_bind_notify(acpi_dev, dev, true);
>> instead.
>>
>> aka:
>> Do you have test case acpi_dev is not created before pci device?
>>
>
> updated your patch, and retrieve handle if needed from acpi_dev->handle or
> pci_dev->dev.archdata.acpi_handle.
please use this updated version.
Also you could add
Reviewed-by: Yinghai Lu
for your patch 1, 2, 4, 5.
Thanks
Yinghai
--
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 5/9] ACPI/pci-bind: remove bind/unbind callbacks from acpi_device_ops
On Sat, Sep 15, 2012 at 4:27 PM, Yinghai Lu wrote: > On Fri, Sep 14, 2012 at 8:05 PM, Jiang Liu wrote: >> From: Jiang Liu >> >> Now ACPI devices are created before/destroyed after corresponding PCI >> devices, and acpi_platform_notify/acpi_platform_notify_remove will >> update PCI<->ACPI binding relationship when creating/destroying PCI >> devices, there's no need to invoke bind/unbind callbacks from ACPI >> device probe/destroy routines anymore. So remove bind/unbind callbacks >> from acpi_device_ops. > for pci root bus, acpi_bus_trim() is used to remove acpi_device. > > and later in acpi_pci_root_remove to stop pci drivers/ioapic driver, > iommu driver then remove pci devices. > > if call back is removed there, then could some functions in > acpi_pci_unbind() will be skipped. > > I really do not want to add pci_stop_bus_devices() in > pci_root_hp.c::handle_root_bridge_removal before > calling acpi_bus_trim... FYI, I solved the problem. will call apci_bus_remove() two times. it will make sure pci devices get removed at first before acpi devices... Thanks Yinghai pci_root_hp_1.patch Description: Binary data
[PATCH] workqueue: fix leak of active
try_to_grab_pending() leave LINKED tagalong in delayed queue when
it deletes a work. This behavior will cause future
cwq_activate_first_delayed() increase the ->nr_active wrongly,
and may cause the whole cwq frozen.
example:
state: cwq->max_active = 1, cwq->nr_active = 1
one work in cwq->pool, many in cwq->delayed_works.
step1: try_to_grab_pending() remove a work from delayed_works but leave
tagalong.
step2: when the work in cwq->pool is finished, cwq_activate_first_delayed()
move the tagalong to cwq->pool and increase the ->nr_active.
current state: cwq->nr_active = 1, but works of the cwq in cwq->pool are all
NO_COLOR,
so even when these works are finished, cwq->nr_active will not be
decreased,
and no work will be moved from cwq->delayed_works. the cwq is frozen.
Fix it by moving the tagalong to cwq->pool in try_to_grab_pending().
Signed-off-by: Lai Jiangshan
---
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index 7b91332..1a268b2 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -1101,11 +1101,26 @@ static int try_to_grab_pending(struct work_struct
*work, bool is_dwork,
*/
smp_rmb();
if (gcwq == get_work_gcwq(work)) {
+ unsigned long delayed;
+
+ /*
+* move LINKED tagalong(if exist) out from
+* delayed queue. Otherwise some future
+* cwq_activate_first_delayed() may move
+* works(which are all NO_COLOR) to cwq->pool
+* and increase the ->nr_active. It may
+* cause the whole cwq frozen.
+*/
+ delayed = *work_data_bits(work) & WORK_STRUCT_DELAYED;
+ if (delayed)
+ move_linked_works(work,
+ _work_cwq(work)->pool->worklist,
+ NULL);
+
debug_work_deactivate(work);
list_del_init(>entry);
cwq_dec_nr_in_flight(get_work_cwq(work),
- get_work_color(work),
- *work_data_bits(work) & WORK_STRUCT_DELAYED);
+ get_work_color(work), delayed);
spin_unlock(>lock);
return 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: [ANNOUNCE] kmod 10
On Thursday 2012-09-06 21:37, Lucas De Marchi wrote: > >kmod 10 is out: > >ftp://ftp.kernel.org/pub/linux/utils/kernel/kmod/kmod-10.tar.xz >ftp://ftp.kernel.org/pub/linux/utils/kernel/kmod/kmod-10.tar.sign make check fails here with glibc-2.15, gcc-4.7, x86_64, due to what seems to be duplicated symbols(?): + make check V=1 Making check in . make --no-print-directory testsuite/uname.la testsuite/path.la testsuite/init_module.la testsuite/delete_module.la testsuite/libtestsuite.la testsuite/test-init testsuite/test-testsuite testsuite/test-loaded testsuite/test-modinfo testsuite/test-alias testsuite/test-new-module testsuite/test-modprobe testsuite/test-blacklist testsuite/test-dependencies depbase=`echo testsuite/uname.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\ /bin/sh ./libtool --tag=CC --mode=compile gcc -std=gnu99 -std=gnu99 -DHAVE_CONFIG_H -I. -include ./config.h -I./libkmod -DROOTPREFIX=\"""\" -DSYSCONFDIR=\""/etc"\" -DLIBEXECDIR=\""/usr/lib"\" -I/usr/local/include -pipe -DANOTHER_BRICK_IN_THE -Wall -W -Wextra -Wno-inline -Wvla -Wundef -Wformat=2 -Wlogical-op -Wsign-compare -Wformat-security -Wmissing-include-dirs -Wformat-nonliteral -Wold-style-definition -Wpointer-arith -Winit-self -Wdeclaration-after-statement -Wfloat-equal -Wmissing-prototypes -Wstrict-prototypes -Wredundant-decls -Wmissing-declarations -Wmissing-noreturn -Wshadow -Wendif-labels -Wstrict-aliasing=2 -Wwrite-strings -Wno-long-long -Wno-overlength-strings -Wno-unused-parameter -Wno-missing-field-initializers -Wno-unused-result -Wnested-externs -Wchar-subscripts -Wtype-limits -Wuninitialized -fno-common -fdiagnostics-show-option -fvisibility=hidden -ffunction-sections -fdata-sections -fomit-frame-pointer -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 - fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -MT testsuite/uname.lo -MD -MP -MF $depbase.Tpo -c -o testsuite/uname.lo testsuite/uname.c &&\ mv -f $depbase.Tpo $depbase.Plo libtool: compile: gcc -std=gnu99 -std=gnu99 -DHAVE_CONFIG_H -I. -include ./config.h -I./libkmod -DROOTPREFIX=\"\" -DSYSCONFDIR=\"/etc\" -DLIBEXECDIR=\"/usr/lib\" -I/usr/local/include -pipe -DANOTHER_BRICK_IN_THE -Wall -W -Wextra -Wno-inline -Wvla -Wundef -Wformat=2 -Wlogical-op -Wsign-compare -Wformat-security -Wmissing-include-dirs -Wformat-nonliteral -Wold-style-definition -Wpointer-arith -Winit-self -Wdeclaration-after-statement -Wfloat-equal -Wmissing-prototypes -Wstrict-prototypes -Wredundant-decls -Wmissing-declarations -Wmissing-noreturn -Wshadow -Wendif-labels -Wstrict-aliasing=2 -Wwrite-strings -Wno-long-long -Wno-overlength-strings -Wno-unused-parameter -Wno-missing-field-initializers -Wno-unused-result -Wnested-externs -Wchar-subscripts -Wtype-limits -Wuninitialized -fno-common -fdiagnostics-show-option -fvisibility=hidden -ffunction-sections -fdata-sections -fomit-frame-pointer -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fa synchronous-unwind-tables -g -MT testsuite/uname.lo -MD -MP -MF testsuite/.deps/uname.Tpo -c testsuite/uname.c -fPIC -DPIC -o testsuite/.libs/uname.o cc1: warning: /usr/local/include: No such file or directory [enabled by default] /bin/sh ./libtool --tag=CC --mode=link gcc -std=gnu99 -std=gnu99 -pipe -DANOTHER_BRICK_IN_THE -Wall -W -Wextra -Wno-inline -Wvla -Wundef -Wformat=2 -Wlogical-op -Wsign-compare -Wformat-security -Wmissing-include-dirs -Wformat-nonliteral -Wold-style-definition -Wpointer-arith -Winit-self -Wdeclaration-after-statement -Wfloat-equal -Wmissing-prototypes -Wstrict-prototypes -Wredundant-decls -Wmissing-declarations -Wmissing-noreturn -Wshadow -Wendif-labels -Wstrict-aliasing=2 -Wwrite-strings -Wno-long-long -Wno-overlength-strings -Wno-unused-parameter -Wno-missing-field-initializers -Wno-unused-result -Wnested-externs -Wchar-subscripts -Wtype-limits -Wuninitialized -fno-common -fdiagnostics-show-option -fvisibility=hidden -ffunction-sections -fdata-sections -fomit-frame-pointer -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g avoid-version -module -shared -export-dynamic -rpath /nowhere -ldl -o testsuite/uname. la testsuite/uname.lo libtool: link: gcc -std=gnu99 -shared -fPIC -DPIC testsuite/.libs/uname.o -ldl -O2 -Wl,-soname -Wl,uname.so.0 -o testsuite/.libs/uname.so.0.0.0 libtool: link: (cd "testsuite/.libs" && rm -f "uname.so.0" && ln -s "uname.so.0.0.0" "uname.so.0") libtool: link: (cd "testsuite/.libs" && rm -f "uname.so" && ln -s "uname.so.0.0.0" "uname.so") libtool: link: ( cd "testsuite/.libs" && rm -f "uname.la" && ln -s "../uname.la" "uname.la" ) depbase=`echo testsuite/path.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\ /bin/sh ./libtool --tag=CC --mode=compile gcc -std=gnu99 -std=gnu99 -DHAVE_CONFIG_H -I. -include ./config.h -I./libkmod -DROOTPREFIX=\"""\" -DSYSCONFDIR=\""/etc"\" -DLIBEXECDIR=\""/usr/lib"\" -I/usr/local/include -pipe
Re: [PATCH] sched: unify the check on atomic sleeping in __might_sleep() and schedule_bug()
On 09/14/2012 11:02 AM, Michael Wang wrote:
> On 09/13/2012 06:04 PM, Peter Zijlstra wrote:
>> On Wed, 2012-08-22 at 10:40 +0800, Michael Wang wrote:
>>> From: Michael Wang
>>>
>>> Fengguang Wu has reported the bug:
>>>
>>> [0.043953] BUG: scheduling while atomic: swapper/0/1/0x1002
>>> [0.044017] no locks held by swapper/0/1.
>>> [0.044692] Pid: 1, comm: swapper/0 Not tainted 3.6.0-rc1-00420-gb7aebb9
>>> #34
>>> [0.045861] Call Trace:
>>> [0.048071] [] __schedule_bug+0x5e/0x70
>>> [0.048890] [] __schedule+0x91/0xb10
>>> [0.049660] [] ? vsnprintf+0x33a/0x450
>>> [0.050444] [] ? lg_local_lock+0x6/0x70
>>> [0.051256] [] ? wait_for_xmitr+0x31/0x90
>>> [0.052019] [] ? do_raw_spin_unlock+0xa5/0xf0
>>> [0.052903] [] ? _raw_spin_unlock+0x22/0x30
>>> [0.053759] [] ? up+0x1b/0x70
>>> [0.054421] [] __cond_resched+0x1b/0x30
>>> [0.055228] [] _cond_resched+0x45/0x50
>>> [0.056020] [] mutex_lock_nested+0x28/0x370
>>> [0.056884] [] ? console_unlock+0x3a2/0x4e0
>>> [0.057741] [] __irq_alloc_descs+0x39/0x1c0
>>> [0.058589] [] io_apic_setup_irq_pin+0x2c/0x310
>>> [0.060042] [] setup_IO_APIC+0x101/0x744
>>> [0.060878] [] ? clear_IO_APIC+0x31/0x50
>>> [0.061695] [] native_smp_prepare_cpus+0x538/0x680
>>> [0.062644] [] ? do_one_initcall+0x12c/0x12c
>>> [0.063517] [] ? do_one_initcall+0x12c/0x12c
>>> [0.064016] [] kernel_init+0x4b/0x17f
>>> [0.064790] [] ? do_one_initcall+0x12c/0x12c
>>> [0.065660] [] kernel_thread_helper+0x6/0x10
>>>
>>> It was caused by that:
>>>
>>> native_smp_prepare_cpus()
>>> preempt_disable() //preempt_count++
>>> mutex_lock()//in __irq_alloc_descs
>>> __might_sleep() //system is booting, avoid check
>>> might_resched()
>>> __schedule()
>>> preempt_disable() //preempt_count++
>>> schedule_bug() //preempt_count > 1, report bug
>>>
>>> The __might_sleep() avoid check on atomic sleeping until the system booted
>>> while the schedule_bug() doesn't, it's the reason for the bug.
>>>
>>> This patch will add one additional check in schedule_bug() to avoid check
>>> until the system booted, so the check on atomic sleeping will be unified.
>>>
>>> Signed-off-by: Michael Wang
>>> Tested-by: Fengguang Wu
>>> ---
>>> kernel/sched/core.c |3 ++-
>>> 1 files changed, 2 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
>>> index 4376c9f..3396c33 100644
>>> --- a/kernel/sched/core.c
>>> +++ b/kernel/sched/core.c
>>> @@ -3321,7 +3321,8 @@ static inline void schedule_debug(struct task_struct
>>> *prev)
>>> * schedule() atomically, we ignore that path for now.
>>> * Otherwise, whine if we are scheduling when we should not be.
>>> */
>>> - if (unlikely(in_atomic_preempt_off() && !prev->exit_state))
>>> + if (unlikely(in_atomic_preempt_off() && !prev->exit_state
>>> + && system_state == SYSTEM_RUNNING))
>>> __schedule_bug(prev);
>>> rcu_sleep_check();
>>>
>>
>>
>> No this is very very wrong.. we avoid the might_sleep bug on !
>> SYSTEM_RUNNING because while we _might_ sleep, we should _never_
>> actually sleep under those conditions.
>>
>> So hitting a schedule() here is an actual bug.
>
> I see, so the rule is that we never allowed invoke schedule() with
> preempt disabled.
>
> The actual reason trigger this bug is that:
> we invoke irq_alloc_descs() which will use mutex_lock() while
> !SYSTEM_RUNNING.
> And mutex_lock() invoke the might_sleep(), which do the schedule()
> without any warning.
>
> So if we want to follow the rule, should_resched() should never return
> true if preempt disabled.
>
> I think we could do changes like:
>
>
>
> index c46a011..36fe510 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -4209,7 +4209,7 @@ SYSCALL_DEFINE0(sched_yield)
>
> static inline int should_resched(void)
> {
> - return need_resched() && !(preempt_count() & PREEMPT_ACTIVE);
> + return need_resched() && !preempt_count();
> }
>
> static void __cond_resched(void)
>
>
>
> Then the should_resched() will return false when the preempt disabled or
> PREEMPT_ACTIVE bit is on.
>
> Could we use this solution?
Let me send out the patch so we could have a thread to discuss, but
please warn me if it's a totally foolish one...
Regards,
Michael Wang
>
> Regards,
> Michael Wang
>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at
Re: [PATCH] dma-debug: New interfaces to debug dma mapping errors
On Sun, Sep 16, 2012 at 06:52:51PM -0600, Shuah Khan wrote:
> +void debug_dma_dump_map_errors(struct device *dev, int all)
> +{
> + if (all) {
> + dev_info(dev,
> + "DMA-API: DMA map error summary:\n"
> + "DMA map errors returned = %d\n"
> + "DMA map errors not checked = %d\n"
> + "DMA unmap errors = %d\n"
> + "SWIOTLB overflow triggers = %d\n",
> + dev->dma_map_errors,
> + dev->dma_map_errors_not_checked,
> + dev->dma_unmap_errors,
> + dev->iotlb_overflow_cnt);
> + return;
> + }
> +
> + if (dev->dma_map_errors_not_checked) {
> + dev_err(dev,
> + "DMA-API: Driver failed to check\n"
> + "%d out of a total of %d DMA map errors returned\n"
> + "by DMA mapping interfaces\n",
> + dev->dma_map_errors_not_checked,
> + dev->dma_map_errors);
> + }
> +
> + if (dev->dma_unmap_errors) {
> + dev_err(dev,
> + "DMA-API: Driver tried to free invalid\n"
> + "DMA addresses %d times\n",
> + dev->dma_unmap_errors);
> + }
> +
> + if (dev->iotlb_overflow_cnt) {
> + dev_err(dev,
> + "DMA-API: SWIOTLB overflow buffer triggered %d times\n",
> + dev->iotlb_overflow_cnt);
> + }
> +}
> +EXPORT_SYMBOL(debug_dma_dump_map_errors);
Don't use syslog for stuff like this, that's not good. Why not use
debugfs?
greg k-h
--
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 03/10] pinctrl: mvebu: kirkwood pinctrl driver
On Sun, 16 Sep 2012, Jason Cooper wrote: > On Sun, Sep 16, 2012 at 09:46:52AM +0200, Andrew Lunn wrote: > > > +++ > > > b/Documentation/devicetree/bindings/pinctrl/marvell,kirkwood-pinctrl.txt > > > @@ -0,0 +1,279 @@ > > > +* Marvell Kirkwood SoC pinctrl driver for mpp > > > + > > > +Please refer to marvell,mvebu-pinctrl.txt in this directory for common > > > binding > > > +part and usage. > > > + > > > +Required properties: > > > +- compatible: "marvell,88f6180-pinctrl", > > > + "marvell,88f6190-pinctrl", "marvell,88f6192-pinctrl", > > > + "marvell,88f6281-pinctrl", "marvell,88f6282-pinctrl" > > > + > > > +This driver supports all kirkwood variants, i.e. 88f6180, 88f619x, and > > > 88f628 > > > > Hi Sebastian > > > > The current MPP code determines for itself what chip it is running on. > > It can then check if a pin configuration is valid for the current > > run time environment. > > > > Here you are suggesting we have to put into the DT what chip we expect > > to be on. > > > > What is the advantage of this, over getting the information from the > > device itself? > > The DT should describe the hardware as accurately as possible. We can't > always assume Linux will be the only thing the DT is handed off to. > > > If i wanted to mass convert all existing kirkwood DT boards over to > > use pinctrl, im stuck at the very first step. I've no idea what chip > > they use, it was not relevant before. > > Let's try to do the DT correctly, and create a migration path for > kirkwood to work first, then migrate to using the DT fully. Beware beware. The DT should of course describe the hardware as accurately as possible. That doesn't necessarily mean it should describe the hardware as _extensively_ as possible. And that doesn't mean that all the information found in the DT has to be consumed by the kernel either. Any information that can be *probed* at run time has no benefit being stuffed in a DT. That's true whether it is Linux or another operating system. The more that can be probed at run time the better. Nicolas -- 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] drivers/tty: Folding Android's keyreset driver in sysRQ
From: "Mathieu J. Poirier"
This patch adds keyreset functionality to the sysrq driver. It
allows certain button/key combinations to be used in order to
trigger device resets.
The first time the key-combo is detected a work function that syncs
the filesystems is scheduled and the kernel rebooted. If all the keys
are released and then pressed again, it calls panic. Reboot on panic
should be set for this to work.
A platform device that specify a reset key-combo should be added to
the board file to trigger the feature. Alternatively keys can be
passed to the driver via the "/sys/module/sysrq" interface.
This functionality comes from the keyreset driver submitted by
Arve Hjønnevåg in the Android kernel.
Cc: a...@android.com
Cc: kernel-t...@android.com
Cc: dmitry.torok...@gmail.com
Cc: john.stu...@linaro.org
Signed-off-by: Mathieu Poirier
---
drivers/tty/sysrq.c | 302 +
include/linux/sysrq.h |8 ++
2 files changed, 310 insertions(+), 0 deletions(-)
diff --git a/drivers/tty/sysrq.c b/drivers/tty/sysrq.c
index 05728894..41122a7 100644
--- a/drivers/tty/sysrq.c
+++ b/drivers/tty/sysrq.c
@@ -41,14 +41,30 @@
#include
#include
#include
+#include
+#include
+#include
+#include
#include
#include
+#include
+
+#define KEY_DOWN_MAX 20 /* how many is enough ? */
+int keyreset_param[KEY_DOWN_MAX];
+struct mutex sysrq_mutex;
+static struct sysrq_state *sysrq_handle;
/* Whether we react on sysrq keys or just ignore them */
static int __read_mostly sysrq_enabled = SYSRQ_DEFAULT_ENABLE;
static bool __read_mostly sysrq_always_enabled;
+static struct input_handler sysrq_handler;
+
+/* Keep track of what has been called */
+static atomic_t restart_requested;
+
+
static bool sysrq_on(void)
{
return sysrq_enabled || sysrq_always_enabled;
@@ -570,6 +586,15 @@ struct sysrq_state {
struct input_handle handle;
struct work_struct reinject_work;
unsigned long key_down[BITS_TO_LONGS(KEY_CNT)];
+ unsigned long keybit[BITS_TO_LONGS(KEY_CNT)];
+ unsigned long upbit[BITS_TO_LONGS(KEY_CNT)];
+ unsigned long key[BITS_TO_LONGS(KEY_CNT)];
+ int (*reset_fn)(void);
+ int key_down_target;
+ int key_down_ctn;
+ int key_up_ctn;
+ int keyreset_data;
+ int restart_disabled;
unsigned int alt;
unsigned int alt_use;
bool active;
@@ -603,6 +628,101 @@ static void sysrq_reinject_alt_sysrq(struct work_struct
*work)
}
}
+
+static int sysrq_probe(struct platform_device *pdev)
+{
+ struct keyreset_platform_data *pdata = pdev->dev.platform_data;
+
+ /*
+* No sequence of keys to trigger on,
+* assuming default sysRQ behavior.
+*/
+ if (pdata) {
+ atomic_set(_requested, 0);
+ sysrq_handler.private = pdata;
+ } else
+ sysrq_handler.private = NULL;
+
+ /* FETCH DT INFO HERE */
+
+ return 0;
+
+}
+
+static void deferred_restart(struct work_struct *dummy)
+{
+ atomic_inc(_requested);
+ sys_sync();
+ atomic_inc(_requested);
+ kernel_restart(NULL);
+}
+static DECLARE_WORK(restart_work, deferred_restart);
+
+static int do_keyreset_event(struct sysrq_state *state,
+unsigned int code, int value)
+{
+ int ret;
+ int processed = 0;
+
+ mutex_lock(_mutex);
+
+ /* Is the code of interest to us */
+ if (!test_bit(code, state->keybit)) {
+ mutex_unlock(_mutex);
+ return processed;
+ }
+
+ /* No need to take care of key up events */
+ if (!test_bit(code, state->key) == !value) {
+ mutex_unlock(_mutex);
+ return processed;
+ }
+
+ /* Record new entry */
+ __change_bit(code, state->key);
+
+ processed = 1;
+
+ if (test_bit(code, state->upbit)) {
+ if (value) {
+ state->restart_disabled = 1;
+ state->key_up_ctn++;
+ } else
+ state->key_up_ctn--;
+ } else {
+ if (value)
+ state->key_down_ctn++;
+ else
+ state->key_down_ctn--;
+ }
+
+ if (state->key_down_ctn == 0 && state->key_up_ctn == 0)
+ state->restart_disabled = 0;
+
+ if (value && !state->restart_disabled &&
+ state->key_down_ctn == state->key_down_target) {
+ state->restart_disabled = 1;
+ if (atomic_read(_requested))
+ panic("keyboard reset failed, %d - panic\n",
+atomic_read(_requested));
+ if (state->reset_fn) {
+ ret = state->reset_fn();
+ atomic_set(_requested, ret);
+ } else {
+ pr_info("keyboard reset\n");
+
[ 115/135] USB: add device quirk for Joss Optical touchboard
3.2-stable review patch. If anyone has any objections, please let me know.
--
From: Alan Stern
commit 92fc7a8b0f20bdb243c706daf42658e8e0cd2ef0 upstream.
This patch (as1604) adds a CONFIG_INTF_STRINGS quirk for the Joss
infrared touchboard device. The device doesn't like to be asked for
its interface strings.
Signed-off-by: Alan Stern
Reported-by: adam ?
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Ben Hutchings
---
drivers/usb/core/quirks.c |4
1 file changed, 4 insertions(+)
diff --git a/drivers/usb/core/quirks.c b/drivers/usb/core/quirks.c
index f15501f4c..e77a8e8 100644
--- a/drivers/usb/core/quirks.c
+++ b/drivers/usb/core/quirks.c
@@ -71,6 +71,10 @@ static const struct usb_device_id usb_quirk_list[] = {
{ USB_DEVICE(0x04b4, 0x0526), .driver_info =
USB_QUIRK_CONFIG_INTF_STRINGS },
+ /* Microchip Joss Optical infrared touchboard device */
+ { USB_DEVICE(0x04d8, 0x000c), .driver_info =
+ USB_QUIRK_CONFIG_INTF_STRINGS },
+
/* Samsung Android phone modem - ID conflict with SPH-I500 */
{ USB_DEVICE(0x04e8, 0x6601), .driver_info =
USB_QUIRK_CONFIG_INTF_STRINGS },
--
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/
[ 134/135] VFS: make vfs_fstat() use f[get|put]_light()
3.2-stable review patch. If anyone has any objections, please let me know.
--
From: Linus Torvalds
commit e994defb7b6813ba6fa7a2a36e86d2455ad1dc35 upstream.
Use the *_light() versions that properly avoid doing the file user count
updates when they are unnecessary.
Signed-off-by: Linus Torvalds
Signed-off-by: Ben Hutchings
---
fs/stat.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/fs/stat.c b/fs/stat.c
index c733dc5..88b36c7 100644
--- a/fs/stat.c
+++ b/fs/stat.c
@@ -57,12 +57,13 @@ EXPORT_SYMBOL(vfs_getattr);
int vfs_fstat(unsigned int fd, struct kstat *stat)
{
- struct file *f = fget(fd);
+ int fput_needed;
+ struct file *f = fget_light(fd, _needed);
int error = -EBADF;
if (f) {
error = vfs_getattr(f->f_path.mnt, f->f_path.dentry, stat);
- fput(f);
+ fput_light(f, fput_needed);
}
return error;
}
--
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/
[ 129/135] drm/radeon: fix up pll selection on DCE5/6
3.2-stable review patch. If anyone has any objections, please let me know.
--
From: Alex Deucher
commit 26fe45a0a76f165425f332a5aaa298f149f9db22 upstream.
Selecting ATOM_PPLL_INVALID should be equivalent as the
DCPLL or PPLL0 are already programmed for the DISPCLK, but
the preferred method is to always specify the PLL selected.
SetPixelClock will check the parameters and skip the
programming if the PLL is already set up.
Signed-off-by: Alex Deucher
Reviewed-by: Christian König
[bwh: Backported to 3.2: drop the DCE6 case]
Signed-off-by: Ben Hutchings
---
drivers/gpu/drm/radeon/atombios_crtc.c |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -1468,7 +1468,9 @@ static int radeon_atom_pick_pll(struct d
* crtc virtual pixel clock.
*/
if
(ENCODER_MODE_IS_DP(atombios_get_encoder_mode(test_encoder))) {
- if (ASIC_IS_DCE5(rdev) ||
rdev->clock.dp_extclk)
+ if (ASIC_IS_DCE5(rdev))
+ return ATOM_DCPLL;
+ else if (rdev->clock.dp_extclk)
return ATOM_PPLL_INVALID;
}
}
--
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/
[ 001/135] [PARISC] Redefine ATOMIC_INIT and ATOMIC64_INIT to drop the casts
3.2-stable review patch. If anyone has any objections, please let me know.
--
From: Mel Gorman
commit bba3d8c3b3c0f2123be5bc687d1cddc13437c923 upstream.
The following build error occured during a parisc build with
swap-over-NFS patches applied.
net/core/sock.c:274:36: error: initializer element is not constant
net/core/sock.c:274:36: error: (near initialization for 'memalloc_socks')
net/core/sock.c:274:36: error: initializer element is not constant
Dave Anglin says:
> Here is the line in sock.i:
>
> struct static_key memalloc_socks = ((struct static_key) { .enabled =
> ((atomic_t) { (0) }) });
The above line contains two compound literals. It also uses a designated
initializer to initialize the field enabled. A compound literal is not a
constant expression.
The location of the above statement isn't fully clear, but if a compound
literal occurs outside the body of a function, the initializer list must
consist of constant expressions.
Reported-by: Fengguang Wu
Signed-off-by: Mel Gorman
Signed-off-by: James Bottomley
Signed-off-by: Ben Hutchings
---
arch/parisc/include/asm/atomic.h |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/parisc/include/asm/atomic.h b/arch/parisc/include/asm/atomic.h
index 6c6defc..af9cf30 100644
--- a/arch/parisc/include/asm/atomic.h
+++ b/arch/parisc/include/asm/atomic.h
@@ -141,7 +141,7 @@ static __inline__ int __atomic_add_unless(atomic_t *v, int
a, int u)
#define atomic_sub_and_test(i,v) (atomic_sub_return((i),(v)) == 0)
-#define ATOMIC_INIT(i) ((atomic_t) { (i) })
+#define ATOMIC_INIT(i) { (i) }
#define smp_mb__before_atomic_dec()smp_mb()
#define smp_mb__after_atomic_dec() smp_mb()
@@ -150,7 +150,7 @@ static __inline__ int __atomic_add_unless(atomic_t *v, int
a, int u)
#ifdef CONFIG_64BIT
-#define ATOMIC64_INIT(i) ((atomic64_t) { (i) })
+#define ATOMIC64_INIT(i) { (i) }
static __inline__ s64
__atomic64_add_return(s64 i, atomic64_t *v)
--
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/
[ 130/135] drm/radeon: fix ordering in pll picking on dce4+
3.2-stable review patch. If anyone has any objections, please let me know.
--
From: Alex Deucher
commit ecd67955fd4c8e66e4df312098989d5fa7da624c upstream.
No functional change, but re-order the cases so they
evaluate properly due to the way the DCE macros work.
Noticed by kallisti5 on IRC.
Signed-off-by: Alex Deucher
[bwh: Backported to 3.2: drop the DCE6 case]
Signed-off-by: Ben Hutchings
---
drivers/gpu/drm/radeon/atombios_crtc.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -1468,10 +1468,10 @@ static int radeon_atom_pick_pll(struct d
* crtc virtual pixel clock.
*/
if
(ENCODER_MODE_IS_DP(atombios_get_encoder_mode(test_encoder))) {
- if (ASIC_IS_DCE5(rdev))
- return ATOM_DCPLL;
- else if (rdev->clock.dp_extclk)
+ if (rdev->clock.dp_extclk)
return ATOM_PPLL_INVALID;
+ else if (ASIC_IS_DCE5(rdev))
+ return ATOM_DCPLL;
}
}
}
--
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/
linux-next: build failure after merge of the arm64 tree
Hi Catalin,
After merging the arm64 tree, today's linux-next build ()
failed like this:
arch/powerpc/kernel/sys_ppc32.c:146:17: error: conflicting types for
'compat_sys_sendfile'
include/linux/compat.h:593:16: note: previous declaration of
'compat_sys_sendfile' was here
arch/powerpc/kernel/sys_ppc32.c:231:17: error: conflicting types for
'compat_sys_sched_rr_get_interval'
include/linux/compat.h:596:16: note: previous declaration of
'compat_sys_sched_rr_get_interval' was here
Caused by commits 2a23f0dba0c6 ("fs: Add generic compat_sys_sendfile
implementation") and a0c6fc489bf6 ("compat: Add generic
compat_sys_sched_rr_get_interval implementation"). Grep is your friend.
I have used the arm64 tree from next-20120914 for today.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpgpgqYmOmvs.pgp
Description: PGP signature
[ 119/135] ARM: 7513/1: Make sure dtc is built before running it
3.2-stable review patch. If anyone has any objections, please let me know. -- From: David Brown commit 70b0476a2394de4f4e32e0b67288d80ff71ca963 upstream. 'make dtbs' in a clean tree will try running the dtc before actually building it. Make these rules depend upon the scripts to build it. Signed-off-by: David Brown Signed-off-by: Russell King Signed-off-by: Ben Hutchings --- arch/arm/Makefile |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/Makefile b/arch/arm/Makefile index 30eae87..a051dfb 100644 --- a/arch/arm/Makefile +++ b/arch/arm/Makefile @@ -284,10 +284,10 @@ zImage Image xipImage bootpImage uImage: vmlinux zinstall uinstall install: vmlinux $(Q)$(MAKE) $(build)=$(boot) MACHINE=$(MACHINE) $@ -%.dtb: +%.dtb: scripts $(Q)$(MAKE) $(build)=$(boot) MACHINE=$(MACHINE) $(boot)/$@ -dtbs: +dtbs: scripts $(Q)$(MAKE) $(build)=$(boot) MACHINE=$(MACHINE) $(boot)/$@ # We use MRPROPER_FILES and CLEAN_FILES now -- 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/
[ 110/135] tty: serial: imx: console write routing is unsafe on SMP
3.2-stable review patch. If anyone has any objections, please let me know.
--
From: Xinyu Chen
commit 9ec1882df244c4ee1baa692676fef5e8b0f5487d upstream.
The console feature's write routing is unsafe on SMP with
the startup/shutdown call.
There could be several consumers of the console
* the kernel printk
* the init process using /dev/kmsg to call printk to show log
* shell, which open /dev/console and write with sys_write()
The shell goes into the normal uart open/write routing,
but the other two go into the console operations.
The open routing calls imx serial startup, which will write USR1/2
register without any lock and critical with imx_console_write call.
Add a spin_lock for startup/shutdown/console_write routing.
This patch is a port from Freescale's Android kernel.
Signed-off-by: Xinyu Chen
Tested-by: Dirk Behme
CC: Sascha Hauer
Acked-by: Shawn Guo
Signed-off-by: Greg Kroah-Hartman
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings
---
drivers/tty/serial/imx.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -725,6 +725,7 @@ static int imx_startup(struct uart_port
}
}
+ spin_lock_irqsave(>port.lock, flags);
/*
* Finally, clear and enable interrupts
*/
@@ -778,7 +779,6 @@ static int imx_startup(struct uart_port
/*
* Enable modem status interrupts
*/
- spin_lock_irqsave(>port.lock,flags);
imx_enable_ms(>port);
spin_unlock_irqrestore(>port.lock,flags);
@@ -808,10 +808,13 @@ static void imx_shutdown(struct uart_por
{
struct imx_port *sport = (struct imx_port *)port;
unsigned long temp;
+ unsigned long flags;
+ spin_lock_irqsave(>port.lock, flags);
temp = readl(sport->port.membase + UCR2);
temp &= ~(UCR2_TXEN);
writel(temp, sport->port.membase + UCR2);
+ spin_unlock_irqrestore(>port.lock, flags);
if (USE_IRDA(sport)) {
struct imxuart_platform_data *pdata;
@@ -840,12 +843,14 @@ static void imx_shutdown(struct uart_por
* Disable all interrupts, port and break condition.
*/
+ spin_lock_irqsave(>port.lock, flags);
temp = readl(sport->port.membase + UCR1);
temp &= ~(UCR1_TXMPTYEN | UCR1_RRDYEN | UCR1_RTSDEN | UCR1_UARTEN);
if (USE_IRDA(sport))
temp &= ~(UCR1_IREN);
writel(temp, sport->port.membase + UCR1);
+ spin_unlock_irqrestore(>port.lock, flags);
}
static void
@@ -1119,6 +1124,9 @@ imx_console_write(struct console *co, co
{
struct imx_port *sport = imx_ports[co->index];
unsigned int old_ucr1, old_ucr2, ucr1;
+ unsigned long flags;
+
+ spin_lock_irqsave(>port.lock, flags);
/*
* First, save UCR1/2 and then disable interrupts
@@ -1145,6 +1153,8 @@ imx_console_write(struct console *co, co
writel(old_ucr1, sport->port.membase + UCR1);
writel(old_ucr2, sport->port.membase + UCR2);
+
+ spin_unlock_irqrestore(>port.lock, flags);
}
/*
--
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/
[ 131/135] drm/radeon: rework pll selection (v3)
3.2-stable review patch. If anyone has any objections, please let me know.
--
From: Alex Deucher
commit 985f61f7ee647ad570c05eab0b74915da2ac8e19 upstream.
For DP we can use the same PPLL for all active DP
encoders. Take advantage of that to prevent cases
where we may end up sharing a PPLL between DP and
non-DP which won't work. Also clean up the code
a bit.
v2: - fix missing pll_id assignment in crtc init
v3: - fix DP PPLL check
- document functions
- break in main encoder search loop after matching.
no need to keep checking additional encoders.
fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=54471
Signed-off-by: Alex Deucher
[bwh: Backported to 3.2: drop the DCE6 case]
Signed-off-by: Ben Hutchings
---
drivers/gpu/drm/radeon/atombios_crtc.c | 163 +---
1 file changed, 129 insertions(+), 34 deletions(-)
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -1446,14 +1446,98 @@ static void radeon_legacy_atom_fixup(str
}
}
+/**
+ * radeon_get_pll_use_mask - look up a mask of which pplls are in use
+ *
+ * @crtc: drm crtc
+ *
+ * Returns the mask of which PPLLs (Pixel PLLs) are in use.
+ */
+static u32 radeon_get_pll_use_mask(struct drm_crtc *crtc)
+{
+ struct drm_device *dev = crtc->dev;
+ struct drm_crtc *test_crtc;
+ struct radeon_crtc *radeon_test_crtc;
+ u32 pll_in_use = 0;
+
+ list_for_each_entry(test_crtc, >mode_config.crtc_list, head) {
+ if (crtc == test_crtc)
+ continue;
+
+ radeon_test_crtc = to_radeon_crtc(test_crtc);
+ if (radeon_test_crtc->pll_id != ATOM_PPLL_INVALID)
+ pll_in_use |= (1 << radeon_test_crtc->pll_id);
+ }
+ return pll_in_use;
+}
+
+/**
+ * radeon_get_shared_dp_ppll - return the PPLL used by another crtc for DP
+ *
+ * @crtc: drm crtc
+ *
+ * Returns the PPLL (Pixel PLL) used by another crtc/encoder which is
+ * also in DP mode. For DP, a single PPLL can be used for all DP
+ * crtcs/encoders.
+ */
+static int radeon_get_shared_dp_ppll(struct drm_crtc *crtc)
+{
+ struct drm_device *dev = crtc->dev;
+ struct drm_encoder *test_encoder;
+ struct radeon_crtc *radeon_test_crtc;
+
+ list_for_each_entry(test_encoder, >mode_config.encoder_list, head)
{
+ if (test_encoder->crtc && (test_encoder->crtc != crtc)) {
+ if
(ENCODER_MODE_IS_DP(atombios_get_encoder_mode(test_encoder))) {
+ /* for DP use the same PLL for all */
+ radeon_test_crtc =
to_radeon_crtc(test_encoder->crtc);
+ if (radeon_test_crtc->pll_id !=
ATOM_PPLL_INVALID)
+ return radeon_test_crtc->pll_id;
+ }
+ }
+ }
+ return ATOM_PPLL_INVALID;
+}
+
+/**
+ * radeon_atom_pick_pll - Allocate a PPLL for use by the crtc.
+ *
+ * @crtc: drm crtc
+ *
+ * Returns the PPLL (Pixel PLL) to be used by the crtc. For DP monitors
+ * a single PPLL can be used for all DP crtcs/encoders. For non-DP
+ * monitors a dedicated PPLL must be used. If a particular board has
+ * an external DP PLL, return ATOM_PPLL_INVALID to skip PLL programming
+ * as there is no need to program the PLL itself. If we are not able to
+ * allocate a PLL, return ATOM_PPLL_INVALID to skip PLL programming to
+ * avoid messing up an existing monitor.
+ *
+ * Asic specific PLL information
+ *
+ * DCE 6.1
+ * - PPLL2 is only available to UNIPHYA (both DP and non-DP)
+ * - PPLL0, PPLL1 are available for UNIPHYB/C/D/E/F (both DP and non-DP)
+ *
+ * DCE 6.0
+ * - PPLL0 is available to all UNIPHY (DP only)
+ * - PPLL1, PPLL2 are available for all UNIPHY (both DP and non-DP) and DAC
+ *
+ * DCE 5.0
+ * - DCPLL is available to all UNIPHY (DP only)
+ * - PPLL1, PPLL2 are available for all UNIPHY (both DP and non-DP) and DAC
+ *
+ * DCE 3.0/4.0/4.1
+ * - PPLL1, PPLL2 are available for all UNIPHY (both DP and non-DP) and DAC
+ *
+ */
static int radeon_atom_pick_pll(struct drm_crtc *crtc)
{
struct radeon_crtc *radeon_crtc = to_radeon_crtc(crtc);
struct drm_device *dev = crtc->dev;
struct radeon_device *rdev = dev->dev_private;
struct drm_encoder *test_encoder;
- struct drm_crtc *test_crtc;
- uint32_t pll_in_use = 0;
+ u32 pll_in_use;
+ int pll;
if (ASIC_IS_DCE4(rdev)) {
list_for_each_entry(test_encoder,
>mode_config.encoder_list, head) {
@@ -1461,7 +1545,7 @@ static int radeon_atom_pick_pll(struct d
/* in DP mode, the DP ref clock can come from
PPLL, DCPLL, or ext clock,
* depending on the asic:
* DCE4: PPLL or ext clock
-* DCE5: DCPLL or ext clock
+* DCE5:
[ 135/135] vfs: make O_PATH file descriptors usable for fstat()
3.2-stable review patch. If anyone has any objections, please let me know.
--
From: Linus Torvalds
commit 55815f70147dcfa3ead5738fd56d3574e2e3c1c2 upstream.
We already use them for openat() and friends, but fstat() also wants to
be able to use O_PATH file descriptors. This should make it more
directly comparable to the O_SEARCH of Solaris.
Note that you could already do the same thing with "fstatat()" and an
empty path, but just doing "fstat()" directly is simpler and faster, so
there is no reason not to just allow it directly.
See also commit 332a2e1244bd, which did the same thing for fchdir, for
the same reasons.
Reported-by: олÑга кÑÑжановÑкаÑ
Cc: Al Viro
Signed-off-by: Linus Torvalds
Signed-off-by: Ben Hutchings
---
fs/stat.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/stat.c b/fs/stat.c
index b6ff118..4078022 100644
--- a/fs/stat.c
+++ b/fs/stat.c
@@ -58,7 +58,7 @@ EXPORT_SYMBOL(vfs_getattr);
int vfs_fstat(unsigned int fd, struct kstat *stat)
{
int fput_needed;
- struct file *f = fget_light(fd, _needed);
+ struct file *f = fget_raw_light(fd, _needed);
int error = -EBADF;
if (f) {
--
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/
[ 122/135] USB: ftdi_sio: do not claim CDC ACM function
3.2-stable review patch. If anyone has any objections, please let me know.
--
From: Bjørn Mork
commit f08dea734844aa42ec57c229b0b73b3d7d21f810 upstream.
The Microchip vid:pid 04d8:000a is used for their CDC ACM
demo firmware application. This is a device with a single
function conforming to the CDC ACM specification and with
the intention of demonstrating CDC ACM class firmware and
driver interaction. The demo is used on a number of
development boards, and may also be used unmodified by
vendors using Microchip hardware.
Some vendors have re-used this vid:pid for other types of
firmware, emulating FTDI chips. Attempting to continue to
support such devices without breaking class based
applications that by matching on interface
class/subclass/proto being ff/ff/00. I have no information
about the actual device or interface descriptors, but this
will at least make the proper CDC ACM devices work again.
Anyone having details of the offending device's descriptors
should update this entry with the details.
Reported-by: Florian Wöhrl
Reported-by: Xiaofan Chen
Cc: Alan Cox
Cc: Bruno Thomsen
Signed-off-by: Bjørn Mork
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Ben Hutchings
---
drivers/usb/serial/ftdi_sio.c |4 +++-
drivers/usb/serial/ftdi_sio_ids.h |5 -
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
index e2fa788..f906b3a 100644
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -805,7 +805,9 @@ static struct usb_device_id id_table_combined [] = {
.driver_info = (kernel_ulong_t)_jtag_quirk },
{ USB_DEVICE(ADI_VID, ADI_GNICEPLUS_PID),
.driver_info = (kernel_ulong_t)_jtag_quirk },
- { USB_DEVICE(MICROCHIP_VID, MICROCHIP_USB_BOARD_PID) },
+ { USB_DEVICE_AND_INTERFACE_INFO(MICROCHIP_VID, MICROCHIP_USB_BOARD_PID,
+ USB_CLASS_VENDOR_SPEC,
+ USB_SUBCLASS_VENDOR_SPEC, 0x00) },
{ USB_DEVICE(JETI_VID, JETI_SPC1201_PID) },
{ USB_DEVICE(MARVELL_VID, MARVELL_SHEEVAPLUG_PID),
.driver_info = (kernel_ulong_t)_jtag_quirk },
diff --git a/drivers/usb/serial/ftdi_sio_ids.h
b/drivers/usb/serial/ftdi_sio_ids.h
index 9bcaf9c..41fe582 100644
--- a/drivers/usb/serial/ftdi_sio_ids.h
+++ b/drivers/usb/serial/ftdi_sio_ids.h
@@ -542,7 +542,10 @@
/*
* Microchip Technology, Inc.
*
- * MICROCHIP_VID (0x04D8) and MICROCHIP_USB_BOARD_PID (0x000A) are also used
by:
+ * MICROCHIP_VID (0x04D8) and MICROCHIP_USB_BOARD_PID (0x000A) are
+ * used by single function CDC ACM class based firmware demo
+ * applications. The VID/PID has also been used in firmware
+ * emulating FTDI serial chips by:
* Hornby Elite - Digital Command Control Console
* http://www.hornby.com/hornby-dcc/controllers/
*/
--
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/
[ 125/135] hwmon: (twl4030-madc-hwmon) Initialize uninitialized structure elements
3.2-stable review patch. If anyone has any objections, please let me know.
--
From: Guenter Roeck
commit 73d7c119255615a26070f9d6cdb722a166a29015 upstream.
twl4030_madc_conversion uses do_avg and type structure elements of
twl4030_madc_request. Initialize structure to avoid random operation.
Fix for: Coverity CID 200794 Uninitialized scalar variable.
Cc: Keerthy
Signed-off-by: Guenter Roeck
Acked-by: Jean Delvare
Acked-by: Keerthy
Signed-off-by: Ben Hutchings
---
drivers/hwmon/twl4030-madc-hwmon.c |9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/hwmon/twl4030-madc-hwmon.c
b/drivers/hwmon/twl4030-madc-hwmon.c
index 0018c7d..1a174f0 100644
--- a/drivers/hwmon/twl4030-madc-hwmon.c
+++ b/drivers/hwmon/twl4030-madc-hwmon.c
@@ -44,12 +44,13 @@ static ssize_t madc_read(struct device *dev,
struct device_attribute *devattr, char *buf)
{
struct sensor_device_attribute *attr = to_sensor_dev_attr(devattr);
- struct twl4030_madc_request req;
+ struct twl4030_madc_request req = {
+ .channels = 1 << attr->index,
+ .method = TWL4030_MADC_SW2,
+ .type = TWL4030_MADC_WAIT,
+ };
long val;
- req.channels = (1 << attr->index);
- req.method = TWL4030_MADC_SW2;
- req.func_cb = NULL;
val = twl4030_madc_conversion();
if (val < 0)
return val;
--
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/
[ 127/135] vmwgfx: add dumb ioctl support
3.2-stable review patch. If anyone has any objections, please let me know.
Is this useful for 3.2 or does it depend on any other later changes?
(All I know is that it builds cleanly.)
--
From: Dave Airlie
commit 5e1782d224c79b26ab7d5c31e3f87657000714fb upstream.
Testing and works with the -modesetting driver,
Reviewed-by: Jakob Bornecrantz
Signed-off-by: Dave Airlie
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c |5 ++
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 10
drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 73 ++
3 files changed, 88 insertions(+)
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -1089,6 +1089,11 @@ static struct drm_driver driver = {
.master_drop = vmw_master_drop,
.open = vmw_driver_open,
.postclose = vmw_postclose,
+
+ .dumb_create = vmw_dumb_create,
+ .dumb_map_offset = vmw_dumb_map_offset,
+ .dumb_destroy = vmw_dumb_destroy,
+
.fops = {
.owner = THIS_MODULE,
.open = drm_open,
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
@@ -641,6 +641,16 @@ int vmw_kms_readback(struct vmw_private
int vmw_kms_update_layout_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_priv);
+int vmw_dumb_create(struct drm_file *file_priv,
+ struct drm_device *dev,
+ struct drm_mode_create_dumb *args);
+
+int vmw_dumb_map_offset(struct drm_file *file_priv,
+ struct drm_device *dev, uint32_t handle,
+ uint64_t *offset);
+int vmw_dumb_destroy(struct drm_file *file_priv,
+struct drm_device *dev,
+uint32_t handle);
/**
* Overlay control - vmwgfx_overlay.c
*/
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
@@ -1950,3 +1950,76 @@ err_ref:
vmw_resource_unreference();
return ret;
}
+
+
+int vmw_dumb_create(struct drm_file *file_priv,
+ struct drm_device *dev,
+ struct drm_mode_create_dumb *args)
+{
+ struct vmw_private *dev_priv = vmw_priv(dev);
+ struct vmw_master *vmaster = vmw_master(file_priv->master);
+ struct vmw_user_dma_buffer *vmw_user_bo;
+ struct ttm_buffer_object *tmp;
+ int ret;
+
+ args->pitch = args->width * ((args->bpp + 7) / 8);
+ args->size = args->pitch * args->height;
+
+ vmw_user_bo = kzalloc(sizeof(*vmw_user_bo), GFP_KERNEL);
+ if (vmw_user_bo == NULL)
+ return -ENOMEM;
+
+ ret = ttm_read_lock(>lock, true);
+ if (ret != 0) {
+ kfree(vmw_user_bo);
+ return ret;
+ }
+
+ ret = vmw_dmabuf_init(dev_priv, _user_bo->dma, args->size,
+ _vram_sys_placement, true,
+ _user_dmabuf_destroy);
+ if (ret != 0)
+ goto out_no_dmabuf;
+
+ tmp = ttm_bo_reference(_user_bo->dma.base);
+ ret = ttm_base_object_init(vmw_fpriv(file_priv)->tfile,
+ _user_bo->base,
+ false,
+ ttm_buffer_type,
+ _user_dmabuf_release, NULL);
+ if (unlikely(ret != 0))
+ goto out_no_base_object;
+
+ args->handle = vmw_user_bo->base.hash.key;
+
+out_no_base_object:
+ ttm_bo_unref();
+out_no_dmabuf:
+ ttm_read_unlock(>lock);
+ return ret;
+}
+
+int vmw_dumb_map_offset(struct drm_file *file_priv,
+ struct drm_device *dev, uint32_t handle,
+ uint64_t *offset)
+{
+ struct ttm_object_file *tfile = vmw_fpriv(file_priv)->tfile;
+ struct vmw_dma_buffer *out_buf;
+ int ret;
+
+ ret = vmw_user_dmabuf_lookup(tfile, handle, _buf);
+ if (ret != 0)
+ return -EINVAL;
+
+ *offset = out_buf->base.addr_space_offset;
+ vmw_dmabuf_unreference(_buf);
+ return 0;
+}
+
+int vmw_dumb_destroy(struct drm_file *file_priv,
+struct drm_device *dev,
+uint32_t handle)
+{
+ return ttm_ref_object_base_unref(vmw_fpriv(file_priv)->tfile,
+handle, TTM_REF_USAGE);
+}
--
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/
[ 007/135] Input: i8042 - add Gigabyte T1005 series netbooks to noloop table
3.2-stable review patch. If anyone has any objections, please let me know.
--
From: Dmitry Torokhov
commit 7b125b94ca16b7e618c6241cb02c4c8060cea5e3 upstream.
They all define their chassis type as "Other" and therefore are not
categorized as "laptops" by the driver, which tries to perform AUX IRQ
delivery test which fails and causes touchpad not working.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=42620
Signed-off-by: Dmitry Torokhov
Signed-off-by: Ben Hutchings
---
drivers/input/serio/i8042-x86ia64io.h | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/input/serio/i8042-x86ia64io.h
b/drivers/input/serio/i8042-x86ia64io.h
index 5ec774d..6918773 100644
--- a/drivers/input/serio/i8042-x86ia64io.h
+++ b/drivers/input/serio/i8042-x86ia64io.h
@@ -177,6 +177,20 @@ static const struct dmi_system_id __initconst
i8042_dmi_noloop_table[] = {
},
},
{
+ /* Gigabyte T1005 - defines wrong chassis type ("Other") */
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "GIGABYTE"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "T1005"),
+ },
+ },
+ {
+ /* Gigabyte T1005M/P - defines wrong chassis type ("Other") */
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "GIGABYTE"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "T1005M/P"),
+ },
+ },
+ {
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"),
DMI_MATCH(DMI_PRODUCT_NAME, "HP Pavilion dv9700"),
--
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/
[ 126/135] ALSA: ice1724: Use linear scale for AK4396 volume control.
3.2-stable review patch. If anyone has any objections, please let me know.
--
From: Matteo Frigo
commit 3737e2be505d872bf2b3c1cd4151b2d2b413d7b5 upstream.
The AK4396 DAC has a linear-scale attentuator, but
sound/pci/ice1712/prodigy_hifi.c used a log scale instead, which is
not quite right. This patch restores the correct scale, borrowing
from the ak4396 code in sound/pci/oxygen/oxygen.c.
Signed-off-by: Matteo Frigo
Signed-off-by: Takashi Iwai
Signed-off-by: Ben Hutchings
---
sound/pci/ice1712/prodigy_hifi.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/sound/pci/ice1712/prodigy_hifi.c b/sound/pci/ice1712/prodigy_hifi.c
index 764cc93..075d5aa 100644
--- a/sound/pci/ice1712/prodigy_hifi.c
+++ b/sound/pci/ice1712/prodigy_hifi.c
@@ -297,6 +297,7 @@ static int ak4396_dac_vol_put(struct snd_kcontrol
*kcontrol, struct snd_ctl_elem
}
static const DECLARE_TLV_DB_SCALE(db_scale_wm_dac, -12700, 100, 1);
+static const DECLARE_TLV_DB_LINEAR(ak4396_db_scale, TLV_DB_GAIN_MUTE, 0);
static struct snd_kcontrol_new prodigy_hd2_controls[] __devinitdata = {
{
@@ -307,7 +308,7 @@ static struct snd_kcontrol_new prodigy_hd2_controls[]
__devinitdata = {
.info = ak4396_dac_vol_info,
.get = ak4396_dac_vol_get,
.put = ak4396_dac_vol_put,
- .tlv = { .p = db_scale_wm_dac },
+ .tlv = { .p = ak4396_db_scale },
},
};
--
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/
[ 124/135] EHCI: Update qTD next pointer in QH overlay region during unlink
3.2-stable review patch. If anyone has any objections, please let me know.
--
From: Pavankumar Kondeti
commit 3d037774b42ed677f699b1dce7d548d55f4e4c2b upstream.
There is a possibility of QH overlay region having reference to a stale
qTD pointer during unlink.
Consider an endpoint having two pending qTD before unlink process begins.
The endpoint's QH queue looks like this.
qTD1 --> qTD2 --> Dummy
To unlink qTD2, QH is removed from asynchronous list and Asynchronous
Advance Doorbell is programmed. The qTD1's next qTD pointer is set to
qTD2'2 next qTD pointer and qTD2 is retired upon controller's doorbell
interrupt. If QH's current qTD pointer points to qTD1, transfer overlay
region still have reference to qTD2. But qtD2 is just unlinked and freed.
This may cause EHCI system error. Fix this by updating qTD next pointer
in QH overlay region with the qTD next pointer of the current qTD.
Signed-off-by: Pavankumar Kondeti
Acked-by: Alan Stern
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Ben Hutchings
---
drivers/usb/host/ehci-q.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/ehci-q.c b/drivers/usb/host/ehci-q.c
index 9bc39ca..4b66374 100644
--- a/drivers/usb/host/ehci-q.c
+++ b/drivers/usb/host/ehci-q.c
@@ -128,9 +128,17 @@ qh_refresh (struct ehci_hcd *ehci, struct ehci_qh *qh)
else {
qtd = list_entry (qh->qtd_list.next,
struct ehci_qtd, qtd_list);
- /* first qtd may already be partially processed */
- if (cpu_to_hc32(ehci, qtd->qtd_dma) == qh->hw->hw_current)
+ /*
+* first qtd may already be partially processed.
+* If we come here during unlink, the QH overlay region
+* might have reference to the just unlinked qtd. The
+* qtd is updated in qh_completions(). Update the QH
+* overlay here.
+*/
+ if (cpu_to_hc32(ehci, qtd->qtd_dma) == qh->hw->hw_current) {
+ qh->hw->hw_qtd_next = qtd->hw_next;
qtd = NULL;
+ }
}
if (qtd)
--
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/
[ 128/135] ahci: Add alternate identifier for the 88SE9172
3.2-stable review patch. If anyone has any objections, please let me know.
--
From: Alan Cox
commit 17c60c6b763cb5b83b0185e7d38d01d18e55a05a upstream.
This can also appear as 0x9192. Reported in bugzilla and confirmed with the
board documentation for these boards.
Resolves-bug: https://bugzilla.kernel.org/show_bug.cgi?id=42970
Signed-off-by: Alan Cox
Signed-off-by: Jeff Garzik
Signed-off-by: Ben Hutchings
---
drivers/ata/ahci.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index c3f52eb..51548dd 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -396,6 +396,8 @@ static const struct pci_device_id ahci_pci_tbl[] = {
.driver_data = board_ahci_yes_fbs }, /* 88se9125 */
{ PCI_DEVICE(0x1b4b, 0x917a),
.driver_data = board_ahci_yes_fbs }, /* 88se9172 */
+ { PCI_DEVICE(0x1b4b, 0x9192),
+ .driver_data = board_ahci_yes_fbs }, /* 88se9172 on
some Gigabyte */
{ PCI_DEVICE(0x1b4b, 0x91a3),
.driver_data = board_ahci_yes_fbs },
--
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] drivers: phy: add generic PHY framework
> > The PHY framework provides a set of API's for the PHY drivers to > create/remove a PHY and the PHY users to obtain a reference to the PHY > using or without using phandle. If the PHY users has to obtain a > reference to > the PHY without using phandle, the platform specfic intialization code > (say > from board file) should have already called phy_bind with the binding > information. The binding information consists of phy's device name, phy > user device name and an index. The index is used when the same phy user > binds to mulitple phys. > What's an example of "the same phy user binds to multiple phys"? I only remembered that Felipe said there are two phy users for one single phy at omap5 that is both usb3 and sata uses the same phy. -- 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/
[ 116/135] kobject: fix oops with "input0: bad kobj_uevent_env content in show_uevent()"
3.2-stable review patch. If anyone has any objections, please let me know.
--
From: Bjørn Mork
commit 60e233a56609fd963c59e99bd75c663d63fa91b6 upstream.
Fengguang Wu writes:
> After the __devinit* removal series, I can still get kernel panic in
> show_uevent(). So there are more sources of bug..
>
> Debug patch:
>
> @@ -343,8 +343,11 @@ static ssize_t show_uevent(struct device
> goto out;
>
> /* copy keys to file */
> - for (i = 0; i < env->envp_idx; i++)
> + dev_err(dev, "uevent %d env[%d]: %s/.../%s\n", env->buflen,
> env->envp_idx, top_kobj->name, dev->kobj.name);
> + for (i = 0; i < env->envp_idx; i++) {
> + printk(KERN_ERR "uevent %d env[%d]: %s\n", (int)count, i,
> env->envp[i]);
> count += sprintf([count], "%s\n", env->envp[i]);
> + }
>
> Oops message, the env[] is again not properly initilized:
>
> [ 44.068623] input input0: uevent 61 env[805306368]: input0/.../input0
> [ 44.069552] uevent 0 env[0]: (null)
This is a completely different CONFIG_HOTPLUG problem, only
demonstrating another reason why CONFIG_HOTPLUG should go away. I had a
hard time trying to disable it anyway ;-)
The problem this time is lots of code assuming that a call to
add_uevent_var() will guarantee that env->buflen > 0. This is not true
if CONFIG_HOTPLUG is unset. So things like this end up overwriting
env->envp_idx because the array index is -1:
if (add_uevent_var(env, "MODALIAS="))
return -ENOMEM;
len = input_print_modalias(>buf[env->buflen - 1],
sizeof(env->buf) - env->buflen,
dev, 0);
Don't know what the best action is, given that there seem to be a *lot*
of this around the kernel. This patch "fixes" the problem for me, but I
don't know if it can be considered an appropriate fix.
[ It is the correct fix for now, for 3.7 forcing CONFIG_HOTPLUG to
always be on is the longterm fix, but it's too late for 3.6 and older
kernels to resolve this that way - gregkh ]
Reported-by: Fengguang Wu
Signed-off-by: Bjørn Mork
Tested-by: Fengguang Wu
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Ben Hutchings
---
include/linux/kobject.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/kobject.h b/include/linux/kobject.h
index fc615a9..1e57449 100644
--- a/include/linux/kobject.h
+++ b/include/linux/kobject.h
@@ -224,7 +224,7 @@ static inline int kobject_uevent_env(struct kobject *kobj,
static inline __printf(2, 3)
int add_uevent_var(struct kobj_uevent_env *env, const char *format, ...)
-{ return 0; }
+{ return -ENOMEM; }
static inline int kobject_action_type(const char *buf, size_t count,
enum kobject_action *type)
--
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/
[ 123/135] staging: r8712u: fix bug in r8712_recv_indicatepkt()
3.2-stable review patch. If anyone has any objections, please let me know. -- From: Eric Dumazet commit abf02cfc179bb4bd30d05f582d61b3b8f429b813 upstream. 64bit arches have a buggy r8712u driver, let's fix it. skb->tail must be set properly or network stack behavior is undefined. Addresses https://bugzilla.redhat.com/show_bug.cgi?id=847525 Addresses https://bugzilla.kernel.org/show_bug.cgi?id=45071 Signed-off-by: Eric Dumazet Cc: Dave Jones Acked-by: Larry Finger Signed-off-by: Greg Kroah-Hartman Signed-off-by: Ben Hutchings --- drivers/staging/rtl8712/recv_linux.c |7 +-- 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/drivers/staging/rtl8712/recv_linux.c b/drivers/staging/rtl8712/recv_linux.c index 0e26d5f..495ee12 100644 --- a/drivers/staging/rtl8712/recv_linux.c +++ b/drivers/staging/rtl8712/recv_linux.c @@ -117,13 +117,8 @@ void r8712_recv_indicatepkt(struct _adapter *padapter, if (skb == NULL) goto _recv_indicatepkt_drop; skb->data = precv_frame->u.hdr.rx_data; -#ifdef NET_SKBUFF_DATA_USES_OFFSET - skb->tail = (sk_buff_data_t)(precv_frame->u.hdr.rx_tail - -precv_frame->u.hdr.rx_head); -#else - skb->tail = (sk_buff_data_t)precv_frame->u.hdr.rx_tail; -#endif skb->len = precv_frame->u.hdr.len; + skb_set_tail_pointer(skb, skb->len); if ((pattrib->tcpchk_valid == 1) && (pattrib->tcp_chkrpt == 1)) skb->ip_summed = CHECKSUM_UNNECESSARY; else -- 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/
[ 003/135] ARM: OMAP2+: Fix dmtimer set source clock failure
3.2-stable review patch. If anyone has any objections, please let me know.
--
From: Jon Hunter
commit 54f32a35f4d3a653a18a2c8c239f19ae060bd803 upstream.
Calling the dmtimer function omap_dm_timer_set_source() fails if following a
call to pm_runtime_put() to disable the timer. For example the following
sequence would fail to set the parent clock ...
omap_dm_timer_stop(gptimer);
omap_dm_timer_set_source(gptimer, OMAP_TIMER_SRC_32_KHZ);
The following error message would be seen ...
omap_dm_timer_set_source: failed to set timer_32k_ck as parent
The problem is that, by design, pm_runtime_put() simply decrements the usage
count and returns before the timer has actually been disabled. Therefore,
setting the parent clock failed because the timer was still active when the
trying to set the parent clock. Setting a parent clock will fail if the clock
you are setting the parent of has a non-zero usage count. To ensure that this
does not fail use pm_runtime_put_sync() when disabling the timer.
Note that this will not be seen on OMAP1 devices, because these devices do
not use the clock framework for dmtimers.
Signed-off-by: Jon Hunter
Acked-by: Kevin Hilman
Signed-off-by: Tony Lindgren
Signed-off-by: Ben Hutchings
---
arch/arm/plat-omap/dmtimer.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index 626ad8c..7b6689a 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -258,7 +258,7 @@ EXPORT_SYMBOL_GPL(omap_dm_timer_enable);
void omap_dm_timer_disable(struct omap_dm_timer *timer)
{
- pm_runtime_put(>pdev->dev);
+ pm_runtime_put_sync(>pdev->dev);
}
EXPORT_SYMBOL_GPL(omap_dm_timer_disable);
--
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/
[ 010/135] [SCSI] Fix Device not ready issue on mpt2sas
3.2-stable review patch. If anyone has any objections, please let me know.
--
From: James Bottomley
commit 14216561e164671ce147458653b1fea06a4ada1e upstream.
This is a particularly nasty SCSI ATA Translation Layer (SATL) problem.
SAT-2 says (section 8.12.2)
if the device is in the stopped state as the result of
processing a START STOP UNIT command (see 9.11), then the SATL
shall terminate the TEST UNIT READY command with CHECK CONDITION
status with the sense key set to NOT READY and the additional
sense code of LOGICAL UNIT NOT READY, INITIALIZING COMMAND
REQUIRED;
mpt2sas internal SATL seems to implement this. The result is very confusing
standby behaviour (using hdparm -y). If you suspend a drive and then send
another command, usually it wakes up. However, if the next command is a TEST
UNIT READY, the SATL sees that the drive is suspended and proceeds to follow
the SATL rules for this, returning NOT READY to all subsequent commands. This
means that the ordering of TEST UNIT READY is crucial: if you send TUR and
then a command, you get a NOT READY to both back. If you send a command and
then a TUR, you get GOOD status because the preceeding command woke the drive.
This bit us badly because
commit 85ef06d1d252f6a2e73b678591ab71caad4667bb
Author: Tejun Heo
Date: Fri Jul 1 16:17:47 2011 +0200
block: flush MEDIA_CHANGE from drivers on close(2)
Changed our ordering on TEST UNIT READY commands meaning that SATA drives
connected to an mpt2sas now suspend and refuse to wake (because the mpt2sas
SATL sees the suspend *before* the drives get awoken by the next ATA command)
resulting in lots of failed commands.
The standard is completely nuts forcing this inconsistent behaviour, but we
have to work around it.
The fix for this is twofold:
1. Set the allow_restart flag so we wake the drive when we see it has been
suspended
2. Return all TEST UNIT READY status directly to the mid layer without any
further error handling which prevents us causing error handling which
may offline the device just because of a media check TUR.
Reported-by: Matthias Prager
Signed-off-by: James Bottomley
Signed-off-by: Ben Hutchings
---
drivers/scsi/scsi_error.c | 10 ++
drivers/scsi/scsi_scan.c | 10 ++
2 files changed, 20 insertions(+)
diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c
index 4a6381c..de2337f 100644
--- a/drivers/scsi/scsi_error.c
+++ b/drivers/scsi/scsi_error.c
@@ -42,6 +42,8 @@
#include
+static void scsi_eh_done(struct scsi_cmnd *scmd);
+
#define SENSE_TIMEOUT (10*HZ)
/*
@@ -241,6 +243,14 @@ static int scsi_check_sense(struct scsi_cmnd *scmd)
if (! scsi_command_normalize_sense(scmd, ))
return FAILED; /* no valid sense data */
+ if (scmd->cmnd[0] == TEST_UNIT_READY && scmd->scsi_done != scsi_eh_done)
+ /*
+* nasty: for mid-layer issued TURs, we need to return the
+* actual sense data without any recovery attempt. For eh
+* issued ones, we need to try to recover and interpret
+*/
+ return SUCCESS;
+
if (scsi_sense_is_deferred())
return NEEDS_RETRY;
diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c
index 56a9379..d947ffc 100644
--- a/drivers/scsi/scsi_scan.c
+++ b/drivers/scsi/scsi_scan.c
@@ -764,6 +764,16 @@ static int scsi_add_lun(struct scsi_device *sdev, unsigned
char *inq_result,
sdev->model = (char *) (sdev->inquiry + 16);
sdev->rev = (char *) (sdev->inquiry + 32);
+ if (strncmp(sdev->vendor, "ATA ", 8) == 0) {
+ /*
+* sata emulation layer device. This is a hack to work around
+* the SATL power management specifications which state that
+* when the SATL detects the device has gone into standby
+* mode, it shall respond with NOT READY.
+*/
+ sdev->allow_restart = 1;
+ }
+
if (*bflags & BLIST_ISROM) {
sdev->type = TYPE_ROM;
sdev->removable = 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/
[ 012/135] drm/i915: Fix assert_pch_hdmi_disabled to mention HDMI (not DP)
3.2-stable review patch. If anyone has any objections, please let me know.
--
From: Adam Jackson
commit 23c99e775d14f01ba45a5affd2fb51af4328359c upstream.
Signed-off-by: Adam Jackson
Signed-off-by: Daniel Vetter
Signed-off-by: Ben Hutchings
---
drivers/gpu/drm/i915/intel_display.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index d775f95..3e21f3c 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1096,7 +1096,7 @@ static void assert_pch_hdmi_disabled(struct
drm_i915_private *dev_priv,
{
u32 val = I915_READ(reg);
WARN(hdmi_pipe_enabled(dev_priv, val, pipe),
-"PCH DP (0x%08x) enabled on transcoder %c, should be disabled\n",
+"PCH HDMI (0x%08x) enabled on transcoder %c, should be disabled\n",
reg, pipe_name(pipe));
}
--
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/
[ 118/135] SUNRPC: Fix a UDP transport regression
3.2-stable review patch. If anyone has any objections, please let me know.
--
From: Trond Myklebust
commit f39c1bfb5a03e2d255451bff05be0d7255298fa4 upstream.
Commit 43cedbf0e8dfb9c5610eb7985d5f21263e313802 (SUNRPC: Ensure that
we grab the XPRT_LOCK before calling xprt_alloc_slot) is causing
hangs in the case of NFS over UDP mounts.
Since neither the UDP or the RDMA transport mechanism use dynamic slot
allocation, we can skip grabbing the socket lock for those transports.
Add a new rpc_xprt_op to allow switching between the TCP and UDP/RDMA
case.
Note that the NFSv4.1 back channel assigns the slot directly
through rpc_run_bc_task, so we can ignore that case.
Reported-by: Dick Streefland
Signed-off-by: Trond Myklebust
Signed-off-by: Ben Hutchings
---
include/linux/sunrpc/xprt.h |3 +++
net/sunrpc/xprt.c | 34 --
net/sunrpc/xprtrdma/transport.c |1 +
net/sunrpc/xprtsock.c |3 +++
4 files changed, 27 insertions(+), 14 deletions(-)
diff --git a/include/linux/sunrpc/xprt.h b/include/linux/sunrpc/xprt.h
index cff40aa..bf8c49f 100644
--- a/include/linux/sunrpc/xprt.h
+++ b/include/linux/sunrpc/xprt.h
@@ -114,6 +114,7 @@ struct rpc_xprt_ops {
void(*set_buffer_size)(struct rpc_xprt *xprt, size_t
sndsize, size_t rcvsize);
int (*reserve_xprt)(struct rpc_xprt *xprt, struct rpc_task
*task);
void(*release_xprt)(struct rpc_xprt *xprt, struct rpc_task
*task);
+ void(*alloc_slot)(struct rpc_xprt *xprt, struct rpc_task
*task);
void(*rpcbind)(struct rpc_task *task);
void(*set_port)(struct rpc_xprt *xprt, unsigned short port);
void(*connect)(struct rpc_task *task);
@@ -281,6 +282,8 @@ voidxprt_connect(struct rpc_task
*task);
void xprt_reserve(struct rpc_task *task);
intxprt_reserve_xprt(struct rpc_xprt *xprt, struct
rpc_task *task);
intxprt_reserve_xprt_cong(struct rpc_xprt *xprt, struct
rpc_task *task);
+void xprt_alloc_slot(struct rpc_xprt *xprt, struct rpc_task
*task);
+void xprt_lock_and_alloc_slot(struct rpc_xprt *xprt, struct
rpc_task *task);
intxprt_prepare_transmit(struct rpc_task *task);
void xprt_transmit(struct rpc_task *task);
void xprt_end_transmit(struct rpc_task *task);
diff --git a/net/sunrpc/xprt.c b/net/sunrpc/xprt.c
index a5a402a..5d7f61d 100644
--- a/net/sunrpc/xprt.c
+++ b/net/sunrpc/xprt.c
@@ -969,11 +969,11 @@ static bool xprt_dynamic_free_slot(struct rpc_xprt *xprt,
struct rpc_rqst *req)
return false;
}
-static void xprt_alloc_slot(struct rpc_task *task)
+void xprt_alloc_slot(struct rpc_xprt *xprt, struct rpc_task *task)
{
- struct rpc_xprt *xprt = task->tk_xprt;
struct rpc_rqst *req;
+ spin_lock(>reserve_lock);
if (!list_empty(>free)) {
req = list_entry(xprt->free.next, struct rpc_rqst, rq_list);
list_del(>rq_list);
@@ -994,12 +994,29 @@ static void xprt_alloc_slot(struct rpc_task *task)
default:
task->tk_status = -EAGAIN;
}
+ spin_unlock(>reserve_lock);
return;
out_init_req:
task->tk_status = 0;
task->tk_rqstp = req;
xprt_request_init(task, xprt);
+ spin_unlock(>reserve_lock);
+}
+EXPORT_SYMBOL_GPL(xprt_alloc_slot);
+
+void xprt_lock_and_alloc_slot(struct rpc_xprt *xprt, struct rpc_task *task)
+{
+ /* Note: grabbing the xprt_lock_write() ensures that we throttle
+* new slot allocation if the transport is congested (i.e. when
+* reconnecting a stream transport or when out of socket write
+* buffer space).
+*/
+ if (xprt_lock_write(xprt, task)) {
+ xprt_alloc_slot(xprt, task);
+ xprt_release_write(xprt, task);
+ }
}
+EXPORT_SYMBOL_GPL(xprt_lock_and_alloc_slot);
static void xprt_free_slot(struct rpc_xprt *xprt, struct rpc_rqst *req)
{
@@ -1083,20 +1100,9 @@ void xprt_reserve(struct rpc_task *task)
if (task->tk_rqstp != NULL)
return;
- /* Note: grabbing the xprt_lock_write() here is not strictly needed,
-* but ensures that we throttle new slot allocation if the transport
-* is congested (e.g. if reconnecting or if we're out of socket
-* write buffer space).
-*/
task->tk_timeout = 0;
task->tk_status = -EAGAIN;
- if (!xprt_lock_write(xprt, task))
- return;
-
- spin_lock(>reserve_lock);
- xprt_alloc_slot(task);
- spin_unlock(>reserve_lock);
- xprt_release_write(xprt, task);
+ xprt->ops->alloc_slot(xprt, task);
}
static inline __be32 xprt_alloc_xid(struct rpc_xprt *xprt)
diff --git a/net/sunrpc/xprtrdma/transport.c
[ 004/135] ARM: Orion: Set eth packet size csum offload limit
3.2-stable review patch. If anyone has any objections, please let me know.
--
From: "Arnaud Patard (Rtp)"
commit 58569aee5a1a5dcc25c34a0a2ed9a377874e6b05 upstream.
The mv643xx ethernet controller limits the packet size for the TX
checksum offloading. This patch sets this limits for Kirkwood and
Dove which have smaller limits that the default.
As a side note, this patch is an updated version of a patch sent some years
ago: http://lists.infradead.org/pipermail/linux-arm-kernel/2010-June/017320.html
which seems to have been lost.
Signed-off-by: Arnaud Patard
Signed-off-by: Jason Cooper
[bwh: Backported to 3.2: adjust for the extra two parameters of
orion_ge0{0,1}_init()]
Signed-off-by: Ben Hutchings
---
--- a/arch/arm/mach-dove/common.c
+++ b/arch/arm/mach-dove/common.c
@@ -92,7 +92,7 @@ void __init dove_ge00_init(struct mv643x
{
orion_ge00_init(eth_data, _mbus_dram_info,
DOVE_GE00_PHYS_BASE, IRQ_DOVE_GE00_SUM,
- 0, get_tclk());
+ 0, get_tclk(), 1600);
}
/*
--- a/arch/arm/mach-kirkwood/common.c
+++ b/arch/arm/mach-kirkwood/common.c
@@ -88,7 +88,7 @@ void __init kirkwood_ge00_init(struct mv
orion_ge00_init(eth_data, _mbus_dram_info,
GE00_PHYS_BASE, IRQ_KIRKWOOD_GE00_SUM,
- IRQ_KIRKWOOD_GE00_ERR, kirkwood_tclk);
+ IRQ_KIRKWOOD_GE00_ERR, kirkwood_tclk, 1600);
}
@@ -102,7 +102,7 @@ void __init kirkwood_ge01_init(struct mv
orion_ge01_init(eth_data, _mbus_dram_info,
GE01_PHYS_BASE, IRQ_KIRKWOOD_GE01_SUM,
- IRQ_KIRKWOOD_GE01_ERR, kirkwood_tclk);
+ IRQ_KIRKWOOD_GE01_ERR, kirkwood_tclk, 1600);
}
--- a/arch/arm/mach-mv78xx0/common.c
+++ b/arch/arm/mach-mv78xx0/common.c
@@ -202,7 +202,8 @@ void __init mv78xx0_ge00_init(struct mv6
{
orion_ge00_init(eth_data, _mbus_dram_info,
GE00_PHYS_BASE, IRQ_MV78XX0_GE00_SUM,
- IRQ_MV78XX0_GE_ERR, get_tclk());
+ IRQ_MV78XX0_GE_ERR, get_tclk(),
+ MV643XX_TX_CSUM_DEFAULT_LIMIT);
}
@@ -213,7 +214,8 @@ void __init mv78xx0_ge01_init(struct mv6
{
orion_ge01_init(eth_data, _mbus_dram_info,
GE01_PHYS_BASE, IRQ_MV78XX0_GE01_SUM,
- NO_IRQ, get_tclk());
+ NO_IRQ, get_tclk(),
+ MV643XX_TX_CSUM_DEFAULT_LIMIT);
}
--- a/arch/arm/mach-orion5x/common.c
+++ b/arch/arm/mach-orion5x/common.c
@@ -95,7 +95,8 @@ void __init orion5x_eth_init(struct mv64
{
orion_ge00_init(eth_data, _mbus_dram_info,
ORION5X_ETH_PHYS_BASE, IRQ_ORION5X_ETH_SUM,
- IRQ_ORION5X_ETH_ERR, orion5x_tclk);
+ IRQ_ORION5X_ETH_ERR, orion5x_tclk,
+ MV643XX_TX_CSUM_DEFAULT_LIMIT);
}
--- a/arch/arm/plat-orion/common.c
+++ b/arch/arm/plat-orion/common.c
@@ -263,10 +263,12 @@ void __init orion_ge00_init(struct mv643
unsigned long mapbase,
unsigned long irq,
unsigned long irq_err,
- int tclk)
+ int tclk,
+ unsigned int tx_csum_limit)
{
fill_resources(_ge00_shared, orion_ge00_shared_resources,
mapbase + 0x2000, SZ_16K - 1, irq_err);
+ orion_ge00_shared_data.tx_csum_limit = tx_csum_limit;
ge_complete(_ge00_shared_data, mbus_dram_info, tclk,
orion_ge00_resources, irq, _ge00_shared,
eth_data, _ge00);
@@ -317,10 +319,12 @@ void __init orion_ge01_init(struct mv643
unsigned long mapbase,
unsigned long irq,
unsigned long irq_err,
- int tclk)
+ int tclk,
+ unsigned int tx_csum_limit)
{
fill_resources(_ge01_shared, orion_ge01_shared_resources,
mapbase + 0x2000, SZ_16K - 1, irq_err);
+ orion_ge01_shared_data.tx_csum_limit = tx_csum_limit;
ge_complete(_ge01_shared_data, mbus_dram_info, tclk,
orion_ge01_resources, irq, _ge01_shared,
eth_data, _ge01);
--- a/arch/arm/plat-orion/include/plat/common.h
+++ b/arch/arm/plat-orion/include/plat/common.h
@@ -41,14 +41,16 @@ void __init orion_ge00_init(struct mv643
unsigned long mapbase,
unsigned long irq,
unsigned long irq_err,
- int tclk);
+ int tclk,
+ unsigned int tx_csum_limit);
void __init orion_ge01_init(struct
[ 111/135] tty: serial: imx: dont reinit clock in imx_setup_ufcr()
3.2-stable review patch. If anyone has any objections, please let me know.
--
From: Dirk Behme
commit 7be0670f7b9198382938a03ff3db7f47ef6b4780 upstream.
Remove the clock configuration from imx_setup_ufcr(). This
isn't needed here and will cause garbage output if done.
To be be sure that we only touch the bits we want (TXTL and RXTL)
we have to mask out all other bits of the UFCR register. Add
one non-existing bit macro for this, too (bit 6, DCEDTE on i.MX6).
Signed-off-by: Dirk Behme
CC: Shawn Guo
CC: Sascha Hauer
CC: Troy Kisky
CC: Xinyu Chen
Acked-by: Shawn Guo
Signed-off-by: Greg Kroah-Hartman
[bwh: Backported to 3.2: deleted code in imx_setup_ufcr() refers to
sport->clk not sport->clk_per]
Signed-off-by: Ben Hutchings
---
drivers/tty/serial/imx.c | 18 --
1 file changed, 4 insertions(+), 14 deletions(-)
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -130,6 +130,7 @@
#define UCR4_OREN (1<<1) /* Receiver overrun interrupt enable */
#define UCR4_DREN (1<<0) /* Recv data ready interrupt enable */
#define UFCR_RXTL_SHF 0 /* Receiver trigger level shift */
+#define UFCR_DCEDTE(1<<6) /* DCE/DTE mode select */
#define UFCR_RFDIV (7<<7) /* Reference freq divider mask */
#define UFCR_RFDIV_REG(x) (((x) < 7 ? 6 - (x) : 6) << 7)
#define UFCR_TXTL_SHF 10 /* Transmitter trigger level shift */
@@ -635,22 +636,11 @@ static void imx_break_ctl(struct uart_po
static int imx_setup_ufcr(struct imx_port *sport, unsigned int mode)
{
unsigned int val;
- unsigned int ufcr_rfdiv;
-
- /* set receiver / transmitter trigger level.
-* RFDIV is set such way to satisfy requested uartclk value
-*/
- val = TXTL << 10 | RXTL;
- ufcr_rfdiv = (clk_get_rate(sport->clk) + sport->port.uartclk / 2)
- / sport->port.uartclk;
-
- if(!ufcr_rfdiv)
- ufcr_rfdiv = 1;
-
- val |= UFCR_RFDIV_REG(ufcr_rfdiv);
+ /* set receiver / transmitter trigger level */
+ val = readl(sport->port.membase + UFCR) & (UFCR_RFDIV | UFCR_DCEDTE);
+ val |= TXTL << UFCR_TXTL_SHF | RXTL;
writel(val, sport->port.membase + UFCR);
-
return 0;
}
--
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/
[ 113/135] USB: ftdi-sio: add support for more Physik Instrumente devices
3.2-stable review patch. If anyone has any objections, please let me know.
--
From: Ãric Piel
commit dafc4f7be1a556ca3868d343c00127728b397068 upstream.
Commit b69cc672052540 added support for the E-861. After acquiring a C-867, I
realised that every Physik Instrumente's device has a different PID. They are
listed in the Windows device driver's .inf file. So here are all PIDs for the
current (and probably future) USB devices from Physik Instrumente.
Compiled, but only actually tested on the E-861 and C-867.
Signed-off-by: Ãric Piel
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Ben Hutchings
---
drivers/usb/serial/ftdi_sio.c | 17 +
drivers/usb/serial/ftdi_sio_ids.h | 21 -
2 files changed, 37 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
index 5620db6..1197d47 100644
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -810,7 +810,24 @@ static struct usb_device_id id_table_combined [] = {
.driver_info = (kernel_ulong_t)_jtag_quirk },
{ USB_DEVICE(LARSENBRUSGAARD_VID, LB_ALTITRACK_PID) },
{ USB_DEVICE(GN_OTOMETRICS_VID, AURICAL_USB_PID) },
+ { USB_DEVICE(FTDI_VID, PI_C865_PID) },
+ { USB_DEVICE(FTDI_VID, PI_C857_PID) },
+ { USB_DEVICE(PI_VID, PI_C866_PID) },
+ { USB_DEVICE(PI_VID, PI_C663_PID) },
+ { USB_DEVICE(PI_VID, PI_C725_PID) },
+ { USB_DEVICE(PI_VID, PI_E517_PID) },
+ { USB_DEVICE(PI_VID, PI_C863_PID) },
{ USB_DEVICE(PI_VID, PI_E861_PID) },
+ { USB_DEVICE(PI_VID, PI_C867_PID) },
+ { USB_DEVICE(PI_VID, PI_E609_PID) },
+ { USB_DEVICE(PI_VID, PI_E709_PID) },
+ { USB_DEVICE(PI_VID, PI_100F_PID) },
+ { USB_DEVICE(PI_VID, PI_1011_PID) },
+ { USB_DEVICE(PI_VID, PI_1012_PID) },
+ { USB_DEVICE(PI_VID, PI_1013_PID) },
+ { USB_DEVICE(PI_VID, PI_1014_PID) },
+ { USB_DEVICE(PI_VID, PI_1015_PID) },
+ { USB_DEVICE(PI_VID, PI_1016_PID) },
{ USB_DEVICE(KONDO_VID, KONDO_USB_SERIAL_PID) },
{ USB_DEVICE(BAYER_VID, BAYER_CONTOUR_CABLE_PID) },
{ USB_DEVICE(FTDI_VID, MARVELL_OPENRD_PID),
diff --git a/drivers/usb/serial/ftdi_sio_ids.h
b/drivers/usb/serial/ftdi_sio_ids.h
index 5dd96ca..080d158 100644
--- a/drivers/usb/serial/ftdi_sio_ids.h
+++ b/drivers/usb/serial/ftdi_sio_ids.h
@@ -791,8 +791,27 @@
* Physik Instrumente
* http://www.physikinstrumente.com/en/products/
*/
+/* These two devices use the VID of FTDI */
+#define PI_C865_PID0xe0a0 /* PI C-865 Piezomotor Controller */
+#define PI_C857_PID0xe0a1 /* PI Encoder Trigger Box */
+
#define PI_VID 0x1a72 /* Vendor ID */
-#define PI_E861_PID 0x1008 /* E-861 piezo controller USB connection */
+#define PI_C866_PID0x1000 /* PI C-866 Piezomotor Controller */
+#define PI_C663_PID0x1001 /* PI C-663 Mercury-Step */
+#define PI_C725_PID0x1002 /* PI C-725 Piezomotor Controller */
+#define PI_E517_PID0x1005 /* PI E-517 Digital Piezo Controller Operation
Module */
+#define PI_C863_PID0x1007 /* PI C-863 */
+#define PI_E861_PID0x1008 /* PI E-861 Piezomotor Controller */
+#define PI_C867_PID0x1009 /* PI C-867 Piezomotor Controller */
+#define PI_E609_PID0x100D /* PI E-609 Digital Piezo Controller */
+#define PI_E709_PID0x100E /* PI E-709 Digital Piezo Controller */
+#define PI_100F_PID0x100F /* PI Digital Piezo Controller */
+#define PI_1011_PID0x1011 /* PI Digital Piezo Controller */
+#define PI_1012_PID0x1012 /* PI Motion Controller */
+#define PI_1013_PID0x1013 /* PI Motion Controller */
+#define PI_1014_PID0x1014 /* PI Device */
+#define PI_1015_PID0x1015 /* PI Device */
+#define PI_1016_PID0x1016 /* PI Digital Servo Module */
/*
* Kondo Kagaku Co.Ltd.
--
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/
[ 108/135] usb: host: xhci: Fix Compliance Mode on SN65LVPE502CP Hardware
3.2-stable review patch. If anyone has any objections, please let me know.
--
From: "Alexis R. Cortes"
commit 71c731a296f1b08a3724bd1b514b64f1bda87a23 upstream.
This patch is intended to work around a known issue on the
SN65LVPE502CP USB3.0 re-driver that can delay the negotiation
between a device and the host past the usual handshake timeout.
If that happens on the first insertion, the host controller
port will enter in Compliance Mode and NO port status event will
be generated (as per xHCI Spec) making impossible to detect this
event by software. The port will remain in compliance mode until
a warm reset is applied to it.
As a result of this, the port will seem "dead" to the user and no
device connections or disconnections will be detected.
For solving this, the patch creates a timer which polls every 2
seconds the link state of each host controller's port (this
by reading the PORTSC register) and recovers the port by issuing a
Warm reset every time Compliance mode is detected.
If a xHC USB3.0 port has previously entered to U0, the compliance
mode issue will NOT occur only until system resumes from
sleep/hibernate, therefore, the compliance mode timer is stopped
when all xHC USB 3.0 ports have entered U0. The timer is initialized
again after each system resume.
Since the issue is being caused by a piece of hardware, the timer
will be enabled ONLY on those systems that have the SN65LVPE502CP
installed (this patch uses DMI strings for detecting those systems)
therefore making this patch to act as a quirk (XHCI_COMP_MODE_QUIRK
has been added to the xhci stack).
This patch applies for these systems:
Vendor: Hewlett-Packard. System Models: Z420, Z620 and Z820.
This patch should be backported to kernels as old as 3.2, as that was
the first kernel to support warm reset. The kernels will need to
contain both commit 10d674a82e553cb8a1f41027bb3c3e309b3f6804 "USB: When
hot reset for USB3 fails, try warm reset" and commit
8bea2bd37df08aaa599aa361a9f8b836ba98e554 "usb: Add support for root hub
port status CAS". The first patch add warm reset support, and the
second patch modifies the USB core to issue a warm reset when the port
is in compliance mode.
Signed-off-by: Alexis R. Cortes
Signed-off-by: Sarah Sharp
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings
---
drivers/usb/host/xhci-hub.c | 42 +++
drivers/usb/host/xhci.c | 121 +++
drivers/usb/host/xhci.h |6 +++
3 files changed, 169 insertions(+)
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -469,11 +469,48 @@ static void xhci_hub_report_link_state(u
* when this bit is set.
*/
pls |= USB_PORT_STAT_CONNECTION;
+ } else {
+ /*
+* If CAS bit isn't set but the Port is already at
+* Compliance Mode, fake a connection so the USB core
+* notices the Compliance state and resets the port.
+* This resolves an issue generated by the SN65LVPE502CP
+* in which sometimes the port enters compliance mode
+* caused by a delay on the host-device negotiation.
+*/
+ if (pls == USB_SS_PORT_LS_COMP_MOD)
+ pls |= USB_PORT_STAT_CONNECTION;
}
+
/* update status field */
*status |= pls;
}
+/*
+ * Function for Compliance Mode Quirk.
+ *
+ * This Function verifies if all xhc USB3 ports have entered U0, if so,
+ * the compliance mode timer is deleted. A port won't enter
+ * compliance mode if it has previously entered U0.
+ */
+void xhci_del_comp_mod_timer(struct xhci_hcd *xhci, u32 status, u16 wIndex)
+{
+ u32 all_ports_seen_u0 = ((1 << xhci->num_usb3_ports)-1);
+ bool port_in_u0 = ((status & PORT_PLS_MASK) == XDEV_U0);
+
+ if (!(xhci->quirks & XHCI_COMP_MODE_QUIRK))
+ return;
+
+ if ((xhci->port_status_u0 != all_ports_seen_u0) && port_in_u0) {
+ xhci->port_status_u0 |= 1 << wIndex;
+ if (xhci->port_status_u0 == all_ports_seen_u0) {
+ del_timer_sync(>comp_mode_recovery_timer);
+ xhci_dbg(xhci, "All USB3 ports have entered U0
already!\n");
+ xhci_dbg(xhci, "Compliance Mode Recovery Timer
Deleted.\n");
+ }
+ }
+}
+
int xhci_hub_control(struct usb_hcd *hcd, u16 typeReq, u16 wValue,
u16 wIndex, char *buf, u16 wLength)
{
@@ -618,6 +655,11 @@ int xhci_hub_control(struct usb_hcd *hcd
/* Update Port Link State for super speed ports*/
if (hcd->speed == HCD_USB3) {
xhci_hub_report_link_state(, temp);
+ /*
+* Verify if all USB3 Ports Have entered U0 already.
+* Delete Compliance Mode Timer if so.
+*/
[ 107/135] xhci: Make handover code more robust
3.2-stable review patch. If anyone has any objections, please let me know.
--
From: Matthew Garrett
commit e955a1cd086de4d165ae0f4c7be7289d84b63bdc upstream.
My test platform (Intel DX79SI) boots reliably under BIOS, but frequently
crashes when booting via UEFI. I finally tracked this down to the xhci
handoff code. It seems that reads from the device occasionally just return
0xff, resulting in xhci_find_next_cap_offset generating a value that's
larger than the resource region. We then oops when attempting to read the
value. Sanity checking that value lets us avoid the crash.
I've no idea what's causing the underlying problem, and xhci still doesn't
actually *work* even with this, but the machine at least boots which will
probably make further debugging easier.
This should be backported to kernels as old as 2.6.31, that contain the
commit 66d4eadd8d067269ea8fead1a50fe87c2979a80d "USB: xhci: BIOS handoff
and HW initialization."
Signed-off-by: Matthew Garrett
Signed-off-by: Sarah Sharp
Signed-off-by: Ben Hutchings
---
drivers/usb/host/pci-quirks.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
index 20b9f45..966d148 100644
--- a/drivers/usb/host/pci-quirks.c
+++ b/drivers/usb/host/pci-quirks.c
@@ -841,12 +841,12 @@ static void __devinit quirk_usb_handoff_xhci(struct
pci_dev *pdev)
void __iomem *op_reg_base;
u32 val;
int timeout;
+ int len = pci_resource_len(pdev, 0);
if (!mmio_resource_enabled(pdev, 0))
return;
- base = ioremap_nocache(pci_resource_start(pdev, 0),
- pci_resource_len(pdev, 0));
+ base = ioremap_nocache(pci_resource_start(pdev, 0), len);
if (base == NULL)
return;
@@ -856,9 +856,17 @@ static void __devinit quirk_usb_handoff_xhci(struct
pci_dev *pdev)
*/
ext_cap_offset = xhci_find_next_cap_offset(base,
XHCI_HCC_PARAMS_OFFSET);
do {
+ if ((ext_cap_offset + sizeof(val)) > len) {
+ /* We're reading garbage from the controller */
+ dev_warn(>dev,
+"xHCI controller failing to respond");
+ return;
+ }
+
if (!ext_cap_offset)
/* We've reached the end of the extended capabilities */
goto hc_init;
+
val = readl(base + ext_cap_offset);
if (XHCI_EXT_CAPS_ID(val) == XHCI_EXT_CAPS_LEGACY)
break;
--
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/
[ 112/135] ibmveth: Fix alignment of rx queue bug
3.2-stable review patch. If anyone has any objections, please let me know.
--
From: Santiago Leon
commit d90c92fee89ccd75ef2646f3bde0b4c0450666c3 upstream.
This patch fixes a bug found by Nish Aravamudan
(https://lkml.org/lkml/2012/5/15/220) where the driver is not following
the spec (it is not aligning the rx buffer on a 16-byte boundary) and the
hypervisor aborts the registration, making the device unusable.
The fix follows BenH's recommendation (https://lkml.org/lkml/2012/7/20/461)
to replace the kmalloc+map for a single call to dma_alloc_coherent()
because that function always aligns to a 16-byte boundary.
The stable trees will run into this bug whenever the rx buffer kmalloc call
returns something not aligned on a 16-byte boundary.
Signed-off-by: Santiago Leon
Signed-off-by: David S. Miller
Signed-off-by: Ben Hutchings
---
drivers/net/ethernet/ibm/ibmveth.c | 26 +-
1 file changed, 9 insertions(+), 17 deletions(-)
diff --git a/drivers/net/ethernet/ibm/ibmveth.c
b/drivers/net/ethernet/ibm/ibmveth.c
index 9010cea..b68d28a 100644
--- a/drivers/net/ethernet/ibm/ibmveth.c
+++ b/drivers/net/ethernet/ibm/ibmveth.c
@@ -472,14 +472,9 @@ static void ibmveth_cleanup(struct ibmveth_adapter
*adapter)
}
if (adapter->rx_queue.queue_addr != NULL) {
- if (!dma_mapping_error(dev, adapter->rx_queue.queue_dma)) {
- dma_unmap_single(dev,
- adapter->rx_queue.queue_dma,
- adapter->rx_queue.queue_len,
- DMA_BIDIRECTIONAL);
- adapter->rx_queue.queue_dma = DMA_ERROR_CODE;
- }
- kfree(adapter->rx_queue.queue_addr);
+ dma_free_coherent(dev, adapter->rx_queue.queue_len,
+ adapter->rx_queue.queue_addr,
+ adapter->rx_queue.queue_dma);
adapter->rx_queue.queue_addr = NULL;
}
@@ -556,10 +551,13 @@ static int ibmveth_open(struct net_device *netdev)
goto err_out;
}
+ dev = >vdev->dev;
+
adapter->rx_queue.queue_len = sizeof(struct ibmveth_rx_q_entry) *
rxq_entries;
- adapter->rx_queue.queue_addr = kmalloc(adapter->rx_queue.queue_len,
- GFP_KERNEL);
+ adapter->rx_queue.queue_addr =
+ dma_alloc_coherent(dev, adapter->rx_queue.queue_len,
+ >rx_queue.queue_dma, GFP_KERNEL);
if (!adapter->rx_queue.queue_addr) {
netdev_err(netdev, "unable to allocate rx queue pages\n");
@@ -567,19 +565,13 @@ static int ibmveth_open(struct net_device *netdev)
goto err_out;
}
- dev = >vdev->dev;
-
adapter->buffer_list_dma = dma_map_single(dev,
adapter->buffer_list_addr, 4096, DMA_BIDIRECTIONAL);
adapter->filter_list_dma = dma_map_single(dev,
adapter->filter_list_addr, 4096, DMA_BIDIRECTIONAL);
- adapter->rx_queue.queue_dma = dma_map_single(dev,
- adapter->rx_queue.queue_addr,
- adapter->rx_queue.queue_len, DMA_BIDIRECTIONAL);
if ((dma_mapping_error(dev, adapter->buffer_list_dma)) ||
- (dma_mapping_error(dev, adapter->filter_list_dma)) ||
- (dma_mapping_error(dev, adapter->rx_queue.queue_dma))) {
+ (dma_mapping_error(dev, adapter->filter_list_dma))) {
netdev_err(netdev, "unable to map filter or buffer list "
"pages\n");
rc = -ENOMEM;
--
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/
[ 009/135] [SCSI] megaraid_sas: Move poll_aen_lock initializer
3.2-stable review patch. If anyone has any objections, please let me know. -- From: Kashyap Desai commit bd8d6dd43a77bfd2b8fef5b094b9d6095e169dee upstream. The following patch moves the poll_aen_lock initializer from megasas_probe_one() to megasas_init(). This prevents a crash when a user loads the driver and tries to issue a poll() system call on the ioctl interface with no adapters present. Signed-off-by: Kashyap Desai Signed-off-by: Adam Radford Signed-off-by: James Bottomley Signed-off-by: Ben Hutchings --- drivers/scsi/megaraid/megaraid_sas_base.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c b/drivers/scsi/megaraid/megaraid_sas_base.c index dc27598..ed38454 100644 --- a/drivers/scsi/megaraid/megaraid_sas_base.c +++ b/drivers/scsi/megaraid/megaraid_sas_base.c @@ -4066,7 +4066,6 @@ megasas_probe_one(struct pci_dev *pdev, const struct pci_device_id *id) spin_lock_init(>cmd_pool_lock); spin_lock_init(>hba_lock); spin_lock_init(>completion_lock); - spin_lock_init(_aen_lock); mutex_init(>aen_mutex); mutex_init(>reset_mutex); @@ -5392,6 +5391,8 @@ static int __init megasas_init(void) printk(KERN_INFO "megasas: %s %s\n", MEGASAS_VERSION, MEGASAS_EXT_VERSION); + spin_lock_init(_aen_lock); + support_poll_for_event = 2; support_device_change = 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/
[ 015/135] ARM: imx6: spin the cpu until hardware takes it down
3.2-stable review patch. If anyone has any objections, please let me know.
--
From: Shawn Guo
commit c944b0b9354ea06ffb0c8a7178949f1185f9f499 upstream.
Though commit 602bf40 (ARM: imx6: exit coherency when shutting down
a cpu) improves the stability of imx6q cpu hotplug a lot, there are
still hangs seen with a more stressful hotplug testing.
It's expected that once imx_enable_cpu(cpu, false) is called, the cpu
will be taken down by hardware immediately, and the code after that
will not get any chance to execute. However, this is not always the
case from the testing. The cpu could possibly be alive for a few
cycles before hardware actually takes it down. So rather than letting
cpu execute some code that could cause a hang in these cycles, let's
make the cpu spin there and wait for hardware to take it down.
Signed-off-by: Shawn Guo
Signed-off-by: Ben Hutchings
---
arch/arm/mach-imx/hotplug.c | 23 +++
1 file changed, 3 insertions(+), 20 deletions(-)
--- a/arch/arm/mach-imx/hotplug.c
+++ b/arch/arm/mach-imx/hotplug.c
@@ -42,22 +42,6 @@ static inline void cpu_enter_lowpower(vo
: "cc");
}
-static inline void cpu_leave_lowpower(void)
-{
- unsigned int v;
-
- asm volatile(
- "mrcp15, 0, %0, c1, c0, 0\n"
- " orr %0, %0, %1\n"
- " mcr p15, 0, %0, c1, c0, 0\n"
- " mrc p15, 0, %0, c1, c0, 1\n"
- " orr %0, %0, %2\n"
- " mcr p15, 0, %0, c1, c0, 1\n"
- : "=" (v)
- : "Ir" (CR_C), "Ir" (0x40)
- : "cc");
-}
-
/*
* platform-specific code to shutdown a CPU
*
@@ -67,11 +51,10 @@ void platform_cpu_die(unsigned int cpu)
{
cpu_enter_lowpower();
imx_enable_cpu(cpu, false);
- cpu_do_idle();
- cpu_leave_lowpower();
- /* We should never return from idle */
- panic("cpu %d unexpectedly exit from shutdown\n", cpu);
+ /* spin here until hardware takes it down */
+ while (1)
+ ;
}
int platform_cpu_disable(unsigned int cpu)
--
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/
[ 008/135] [SCSI] mpt2sas: Fix for Driver oops, when loading driver with max_queue_depth command line option to a very small value
3.2-stable review patch. If anyone has any objections, please let me know.
--
From: "sreekanth.re...@lsi.com"
commit 338b131a3269881c7431234855c93c219b0979b6 upstream.
If the specified max_queue_depth setting is less than the
expected number of internal commands, then driver will calculate
the queue depth size to a negitive number. This negitive number
is actually a very large number because variable is unsigned
16bit integer. So, the driver will ask for a very large amount of
memory for message frames and resulting into oops as memory
allocation routines will not able to handle such a large request.
So, in order to limit this kind of oops, The driver need to set
the max_queue_depth to a scsi mid layer's can_queue value. Then
the overall message frames required for IO is minimum of either
(max_queue_depth plus internal commands) or the IOC global
credits.
Signed-off-by: Sreekanth Reddy
Signed-off-by: James Bottomley
Signed-off-by: Ben Hutchings
---
drivers/scsi/mpt2sas/mpt2sas_base.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/scsi/mpt2sas/mpt2sas_base.c
b/drivers/scsi/mpt2sas/mpt2sas_base.c
index 9d46fcb..b25757d 100644
--- a/drivers/scsi/mpt2sas/mpt2sas_base.c
+++ b/drivers/scsi/mpt2sas/mpt2sas_base.c
@@ -2424,10 +2424,13 @@ _base_allocate_memory_pools(struct MPT2SAS_ADAPTER
*ioc, int sleep_flag)
}
/* command line tunables for max controller queue depth */
- if (max_queue_depth != -1)
- max_request_credit = (max_queue_depth < facts->RequestCredit)
- ? max_queue_depth : facts->RequestCredit;
- else
+ if (max_queue_depth != -1 && max_queue_depth != 0) {
+ max_request_credit = min_t(u16, max_queue_depth +
+ ioc->hi_priority_depth + ioc->internal_depth,
+ facts->RequestCredit);
+ if (max_request_credit > MAX_HBA_QUEUE_DEPTH)
+ max_request_credit = MAX_HBA_QUEUE_DEPTH;
+ } else
max_request_credit = min_t(u16, facts->RequestCredit,
MAX_HBA_QUEUE_DEPTH);
@@ -2502,7 +2505,7 @@ _base_allocate_memory_pools(struct MPT2SAS_ADAPTER *ioc,
int sleep_flag)
/* set the scsi host can_queue depth
* with some internal commands that could be outstanding
*/
- ioc->shost->can_queue = ioc->scsiio_depth - (2);
+ ioc->shost->can_queue = ioc->scsiio_depth;
dinitprintk(ioc, printk(MPT2SAS_INFO_FMT "scsi host: "
"can_queue depth (%d)\n", ioc->name, ioc->shost->can_queue));
--
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/
[ 078/135] time: Improve sanity checking of timekeeping inputs
3.2-stable review patch. If anyone has any objections, please let me know.
--
From: John Stultz
This is a -stable backport of 4e8b14526ca7fb046a81c94002c1c43b6fdf0e9b
Unexpected behavior could occur if the time is set to a value large
enough to overflow a 64bit ktime_t (which is something larger then the
year 2262).
Also unexpected behavior could occur if large negative offsets are
injected via adjtimex.
So this patch improves the sanity check timekeeping inputs by
improving the timespec_valid() check, and then makes better use of
timespec_valid() to make sure we don't set the time to an invalid
negative value or one that overflows ktime_t.
Note: This does not protect from setting the time close to overflowing
ktime_t and then letting natural accumulation cause the overflow.
Reported-by: CAI Qian
Reported-by: Sasha Levin
Signed-off-by: John Stultz
Cc: Peter Zijlstra
Cc: Prarit Bhargava
Cc: Zhouping Liu
Cc: Ingo Molnar
Link:
http://lkml.kernel.org/r/1344454580-17031-1-git-send-email-john.stu...@linaro.org
Signed-off-by: Thomas Gleixner
Cc: Linux Kernel
Signed-off-by: John Stultz
---
include/linux/ktime.h |7 ---
include/linux/time.h | 22 --
kernel/time/timekeeping.c | 26 --
3 files changed, 44 insertions(+), 11 deletions(-)
--- a/include/linux/ktime.h
+++ b/include/linux/ktime.h
@@ -58,13 +58,6 @@ union ktime {
typedef union ktime ktime_t; /* Kill this */
-#define KTIME_MAX ((s64)~((u64)1 << 63))
-#if (BITS_PER_LONG == 64)
-# define KTIME_SEC_MAX (KTIME_MAX / NSEC_PER_SEC)
-#else
-# define KTIME_SEC_MAX LONG_MAX
-#endif
-
/*
* ktime_t definitions when using the 64-bit scalar representation:
*/
--- a/include/linux/time.h
+++ b/include/linux/time.h
@@ -107,11 +107,29 @@ static inline struct timespec timespec_s
return ts_delta;
}
+#define KTIME_MAX ((s64)~((u64)1 << 63))
+#if (BITS_PER_LONG == 64)
+# define KTIME_SEC_MAX (KTIME_MAX / NSEC_PER_SEC)
+#else
+# define KTIME_SEC_MAX LONG_MAX
+#endif
+
/*
* Returns true if the timespec is norm, false if denorm:
*/
-#define timespec_valid(ts) \
- (((ts)->tv_sec >= 0) && (((unsigned long) (ts)->tv_nsec) <
NSEC_PER_SEC))
+static inline bool timespec_valid(const struct timespec *ts)
+{
+ /* Dates before 1970 are bogus */
+ if (ts->tv_sec < 0)
+ return false;
+ /* Can't have more nanoseconds then a second */
+ if ((unsigned long)ts->tv_nsec >= NSEC_PER_SEC)
+ return false;
+ /* Disallow values that could overflow ktime_t */
+ if ((unsigned long long)ts->tv_sec >= KTIME_SEC_MAX)
+ return false;
+ return true;
+}
extern void read_persistent_clock(struct timespec *ts);
extern void read_boot_clock(struct timespec *ts);
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -382,7 +382,7 @@ int do_settimeofday(const struct timespe
struct timespec ts_delta;
unsigned long flags;
- if ((unsigned long)tv->tv_nsec >= NSEC_PER_SEC)
+ if (!timespec_valid(tv))
return -EINVAL;
write_seqlock_irqsave(_lock, flags);
@@ -417,6 +417,8 @@ EXPORT_SYMBOL(do_settimeofday);
int timekeeping_inject_offset(struct timespec *ts)
{
unsigned long flags;
+ struct timespec tmp;
+ int ret = 0;
if ((unsigned long)ts->tv_nsec >= NSEC_PER_SEC)
return -EINVAL;
@@ -425,9 +427,16 @@ int timekeeping_inject_offset(struct tim
timekeeping_forward_now();
+ tmp = timespec_add(xtime, *ts);
+ if (!timespec_valid()) {
+ ret = -EINVAL;
+ goto error;
+ }
+
xtime = timespec_add(xtime, *ts);
wall_to_monotonic = timespec_sub(wall_to_monotonic, *ts);
+error: /* even if we error out, we forwarded the time, so call update */
timekeeping_update(true);
write_sequnlock_irqrestore(_lock, flags);
@@ -435,7 +444,7 @@ int timekeeping_inject_offset(struct tim
/* signal hrtimers about time change */
clock_was_set();
- return 0;
+ return ret;
}
EXPORT_SYMBOL(timekeeping_inject_offset);
@@ -582,7 +591,20 @@ void __init timekeeping_init(void)
struct timespec now, boot;
read_persistent_clock();
+ if (!timespec_valid()) {
+ pr_warn("WARNING: Persistent clock returned invalid value!\n"
+ " Check your CMOS/BIOS settings.\n");
+ now.tv_sec = 0;
+ now.tv_nsec = 0;
+ }
+
read_boot_clock();
+ if (!timespec_valid()) {
+ pr_warn("WARNING: Boot clock returned invalid value!\n"
+ " Check your CMOS/BIOS settings.\n");
+ boot.tv_sec = 0;
+ boot.tv_nsec = 0;
+ }
[ 088/135] ARM: 7496/1: hw_breakpoint: dont rely on dfsr to show watchpoint access type
3.2-stable review patch. If anyone has any objections, please let me know.
--
From: Will Deacon
commit bf8801145c01ab600f8df66e8c879ac642fa5846 upstream.
>From ARM debug architecture v7.1 onwards, a watchpoint exception causes
the DFAR to be updated with the faulting data address. However, DFSR.WnR
takes an UNKNOWN value and therefore cannot be used in general to
determine the access type that triggered the watchpoint.
This patch forbids watchpoints without an overflow handler from
specifying a specific access type (load/store). Those with overflow
handlers must be able to handle false positives potentially triggered by
a watchpoint of a different access type on the same address. For
SIGTRAP-based handlers (i.e. ptrace), this should have no impact.
Signed-off-by: Will Deacon
Signed-off-by: Russell King
Signed-off-by: Ben Hutchings
---
arch/arm/kernel/hw_breakpoint.c | 55 ---
1 file changed, 40 insertions(+), 15 deletions(-)
diff --git a/arch/arm/kernel/hw_breakpoint.c b/arch/arm/kernel/hw_breakpoint.c
index ba386bd..18d39ea 100644
--- a/arch/arm/kernel/hw_breakpoint.c
+++ b/arch/arm/kernel/hw_breakpoint.c
@@ -159,6 +159,12 @@ static int debug_arch_supported(void)
arch >= ARM_DEBUG_ARCH_V7_1;
}
+/* Can we determine the watchpoint access type from the fsr? */
+static int debug_exception_updates_fsr(void)
+{
+ return 0;
+}
+
/* Determine number of WRP registers available. */
static int get_num_wrp_resources(void)
{
@@ -619,18 +625,35 @@ int arch_validate_hwbkpt_settings(struct perf_event *bp)
info->address &= ~alignment_mask;
info->ctrl.len <<= offset;
- /*
-* Currently we rely on an overflow handler to take
-* care of single-stepping the breakpoint when it fires.
-* In the case of userspace breakpoints on a core with V7 debug,
-* we can use the mismatch feature as a poor-man's hardware
-* single-step, but this only works for per-task breakpoints.
-*/
- if (!bp->overflow_handler && (arch_check_bp_in_kernelspace(bp) ||
- !core_has_mismatch_brps() || !bp->hw.bp_target)) {
- pr_warning("overflow handler required but none found\n");
- ret = -EINVAL;
+ if (!bp->overflow_handler) {
+ /*
+* Mismatch breakpoints are required for single-stepping
+* breakpoints.
+*/
+ if (!core_has_mismatch_brps())
+ return -EINVAL;
+
+ /* We don't allow mismatch breakpoints in kernel space. */
+ if (arch_check_bp_in_kernelspace(bp))
+ return -EPERM;
+
+ /*
+* Per-cpu breakpoints are not supported by our stepping
+* mechanism.
+*/
+ if (!bp->hw.bp_target)
+ return -EINVAL;
+
+ /*
+* We only support specific access types if the fsr
+* reports them.
+*/
+ if (!debug_exception_updates_fsr() &&
+ (info->ctrl.type == ARM_BREAKPOINT_LOAD ||
+info->ctrl.type == ARM_BREAKPOINT_STORE))
+ return -EINVAL;
}
+
out:
return ret;
}
@@ -706,10 +729,12 @@ static void watchpoint_handler(unsigned long addr,
unsigned int fsr,
goto unlock;
/* Check that the access type matches. */
- access = (fsr & ARM_FSR_ACCESS_MASK) ? HW_BREAKPOINT_W :
-HW_BREAKPOINT_R;
- if (!(access & hw_breakpoint_type(wp)))
- goto unlock;
+ if (debug_exception_updates_fsr()) {
+ access = (fsr & ARM_FSR_ACCESS_MASK) ?
+ HW_BREAKPOINT_W : HW_BREAKPOINT_R;
+ if (!(access & hw_breakpoint_type(wp)))
+ goto unlock;
+ }
/* We have a winner. */
info->trigger = addr;
--
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/
[ 101/135] rt2x00: Fix word size of rt2500usb MAC_CSR19 register.
3.2-stable review patch. If anyone has any objections, please let me know. -- From: Gertjan van Wingerde commit 6ced58a5dbb94dbfbea1b33ca3c56d1e929cd548 upstream. The register is 16 bits wide, not 32. Signed-off-by: Gertjan van Wingerde Acked-by: Ivo Van Doorn Signed-off-by: John W. Linville Signed-off-by: Ben Hutchings --- drivers/net/wireless/rt2x00/rt2500usb.c |2 +- drivers/net/wireless/rt2x00/rt2500usb.h | 16 2 files changed, 9 insertions(+), 9 deletions(-) diff --git a/drivers/net/wireless/rt2x00/rt2500usb.c b/drivers/net/wireless/rt2x00/rt2500usb.c index 3aae36b..b3a1d73 100644 --- a/drivers/net/wireless/rt2x00/rt2500usb.c +++ b/drivers/net/wireless/rt2x00/rt2500usb.c @@ -283,7 +283,7 @@ static int rt2500usb_rfkill_poll(struct rt2x00_dev *rt2x00dev) u16 reg; rt2500usb_register_read(rt2x00dev, MAC_CSR19, ); - return rt2x00_get_field32(reg, MAC_CSR19_BIT7); + return rt2x00_get_field16(reg, MAC_CSR19_BIT7); } #ifdef CONFIG_RT2X00_LIB_LEDS diff --git a/drivers/net/wireless/rt2x00/rt2500usb.h b/drivers/net/wireless/rt2x00/rt2500usb.h index b493306..192531d 100644 --- a/drivers/net/wireless/rt2x00/rt2500usb.h +++ b/drivers/net/wireless/rt2x00/rt2500usb.h @@ -189,14 +189,14 @@ * MAC_CSR19: GPIO control register. */ #define MAC_CSR19 0x0426 -#define MAC_CSR19_BIT0 FIELD32(0x0001) -#define MAC_CSR19_BIT1 FIELD32(0x0002) -#define MAC_CSR19_BIT2 FIELD32(0x0004) -#define MAC_CSR19_BIT3 FIELD32(0x0008) -#define MAC_CSR19_BIT4 FIELD32(0x0010) -#define MAC_CSR19_BIT5 FIELD32(0x0020) -#define MAC_CSR19_BIT6 FIELD32(0x0040) -#define MAC_CSR19_BIT7 FIELD32(0x0080) +#define MAC_CSR19_BIT0 FIELD16(0x0001) +#define MAC_CSR19_BIT1 FIELD16(0x0002) +#define MAC_CSR19_BIT2 FIELD16(0x0004) +#define MAC_CSR19_BIT3 FIELD16(0x0008) +#define MAC_CSR19_BIT4 FIELD16(0x0010) +#define MAC_CSR19_BIT5 FIELD16(0x0020) +#define MAC_CSR19_BIT6 FIELD16(0x0040) +#define MAC_CSR19_BIT7 FIELD16(0x0080) /* * MAC_CSR20: LED control register. -- 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/
[ 105/135] xhci: Switch PPT ports to EHCI on shutdown.
3.2-stable review patch. If anyone has any objections, please let me know.
--
From: Sarah Sharp
commit e95829f474f0db3a4d940cae1423783edd966027 upstream.
The Intel desktop boards DH77EB and DH77DF have a hardware issue that
can be worked around by BIOS. If the USB ports are switched to xHCI on
shutdown, the xHCI host will send a spurious interrupt, which will wake
the system. Some BIOS will work around this, but not all.
The bug can be avoided if the USB ports are switched back to EHCI on
shutdown. The Intel Windows driver switches the ports back to EHCI, so
change the Linux xHCI driver to do the same.
Unfortunately, we can't tell the two effected boards apart from other
working motherboards, because the vendors will change the DMI strings
for the DH77EB and DH77DF boards to their own custom names. One example
is Compulab's mini-desktop, the Intense-PC. Instead, key off the
Panther Point xHCI host PCI vendor and device ID, and switch the ports
over for all PPT xHCI hosts.
The only impact this will have on non-effected boards is to add a couple
hundred milliseconds delay on boot when the BIOS has to switch the ports
over from EHCI to xHCI.
This patch should be backported to kernels as old as 3.0, that contain
the commit 69e848c2090aebba5698a1620604c7dccb448684 "Intel xhci: Support
EHCI/xHCI port switching."
Signed-off-by: Sarah Sharp
Reported-by: Denis Turischev
Tested-by: Denis Turischev
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings
---
drivers/usb/host/pci-quirks.c |7 +++
drivers/usb/host/pci-quirks.h |1 +
drivers/usb/host/xhci-pci.c |9 +
drivers/usb/host/xhci.c |3 +++
drivers/usb/host/xhci.h |1 +
5 files changed, 21 insertions(+)
--- a/drivers/usb/host/pci-quirks.c
+++ b/drivers/usb/host/pci-quirks.c
@@ -819,6 +819,13 @@ void usb_enable_xhci_ports(struct pci_de
}
EXPORT_SYMBOL_GPL(usb_enable_xhci_ports);
+void usb_disable_xhci_ports(struct pci_dev *xhci_pdev)
+{
+ pci_write_config_dword(xhci_pdev, USB_INTEL_USB3_PSSEN, 0x0);
+ pci_write_config_dword(xhci_pdev, USB_INTEL_XUSB2PR, 0x0);
+}
+EXPORT_SYMBOL_GPL(usb_disable_xhci_ports);
+
/**
* PCI Quirks for xHCI.
*
--- a/drivers/usb/host/pci-quirks.h
+++ b/drivers/usb/host/pci-quirks.h
@@ -10,6 +10,7 @@ void usb_amd_quirk_pll_disable(void);
void usb_amd_quirk_pll_enable(void);
bool usb_is_intel_switchable_xhci(struct pci_dev *pdev);
void usb_enable_xhci_ports(struct pci_dev *xhci_pdev);
+void usb_disable_xhci_ports(struct pci_dev *xhci_pdev);
#else
static inline void usb_amd_quirk_pll_disable(void) {}
static inline void usb_amd_quirk_pll_enable(void) {}
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -90,6 +90,15 @@ static void xhci_pci_quirks(struct devic
xhci->quirks |= XHCI_EP_LIMIT_QUIRK;
xhci->limit_active_eps = 64;
xhci->quirks |= XHCI_SW_BW_CHECKING;
+ /*
+* PPT desktop boards DH77EB and DH77DF will power back on after
+* a few seconds of being shutdown. The fix for this is to
+* switch the ports from xHCI to EHCI on shutdown. We can't use
+* DMI information to find those particular boards (since each
+* vendor will change the board name), so we have to key off all
+* PPT chipsets.
+*/
+ xhci->quirks |= XHCI_SPURIOUS_REBOOT;
}
if (pdev->vendor == PCI_VENDOR_ID_ETRON &&
pdev->device == PCI_DEVICE_ID_ASROCK_P67) {
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -648,6 +648,9 @@ void xhci_shutdown(struct usb_hcd *hcd)
{
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
+ if (xhci->quirks && XHCI_SPURIOUS_REBOOT)
+ usb_disable_xhci_ports(to_pci_dev(hcd->self.controller));
+
spin_lock_irq(>lock);
xhci_halt(xhci);
spin_unlock_irq(>lock);
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -1471,6 +1471,7 @@ struct xhci_hcd {
#defineXHCI_SW_BW_CHECKING (1 << 8)
#define XHCI_AMD_0x96_HOST (1 << 9)
#define XHCI_TRUST_TX_LENGTH (1 << 10)
+#define XHCI_SPURIOUS_REBOOT (1 << 13)
unsigned intnum_active_eps;
unsigned intlimit_active_eps;
/* There are two roothubs to keep track of bus suspend info for */
--
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/
[ 081/135] drm/i915: Wait for all pending operations to the fb before disabling the pipe
3.2-stable review patch. If anyone has any objections, please let me know.
--
From: Chris Wilson
During modeset we have to disable the pipe to reconfigure its timings
and maybe its size. Userspace may have queued up command buffers that
depend upon the pipe running in a certain configuration and so the
commands may become confused across the modeset. At the moment, we use a
less than satisfactory kick-scanline-waits should the GPU hang during
the modeset. It should be more reliable to wait for the pending
operations to complete first, even though we still have a window for
userspace to submit a broken command buffer during the modeset.
Signed-off-by: Chris Wilson
Signed-off-by: Daniel Vetter
(cherry picked from commit 0f91128d88bbb8b0a8e7bb93df2c40680871d45a)
Signed-off-by: Timo Aaltonen
---
drivers/gpu/drm/i915/intel_display.c | 27 ---
1 file changed, 4 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index cc75c4b..ae74df7 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2852,16 +2852,14 @@ static void intel_clear_scanline_wait(struct drm_device
*dev)
static void intel_crtc_wait_for_pending_flips(struct drm_crtc *crtc)
{
- struct drm_i915_gem_object *obj;
- struct drm_i915_private *dev_priv;
+ struct drm_device *dev = crtc->dev;
if (crtc->fb == NULL)
return;
- obj = to_intel_framebuffer(crtc->fb)->obj;
- dev_priv = crtc->dev->dev_private;
- wait_event(dev_priv->pending_flip_queue,
- atomic_read(>pending_flip) == 0);
+ mutex_lock(>struct_mutex);
+ intel_finish_fb(crtc->fb);
+ mutex_unlock(>struct_mutex);
}
static bool intel_crtc_driving_pch(struct drm_crtc *crtc)
@@ -3322,23 +3320,6 @@ static void intel_crtc_disable(struct drm_crtc *crtc)
struct drm_crtc_helper_funcs *crtc_funcs = crtc->helper_private;
struct drm_device *dev = crtc->dev;
- /* Flush any pending WAITs before we disable the pipe. Note that
-* we need to drop the struct_mutex in order to acquire it again
-* during the lowlevel dpms routines around a couple of the
-* operations. It does not look trivial nor desirable to move
-* that locking higher. So instead we leave a window for the
-* submission of further commands on the fb before we can actually
-* disable it. This race with userspace exists anyway, and we can
-* only rely on the pipe being disabled by userspace after it
-* receives the hotplug notification and has flushed any pending
-* batches.
-*/
- if (crtc->fb) {
- mutex_lock(>struct_mutex);
- intel_finish_fb(crtc->fb);
- mutex_unlock(>struct_mutex);
- }
-
crtc_funcs->dpms(crtc, DRM_MODE_DPMS_OFF);
if (crtc->fb) {
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-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/
[ 017/135] xen/setup: Fix one-off error when adding for-balloon PFNs to the P2M.
3.2-stable review patch. If anyone has any objections, please let me know.
--
From: Konrad Rzeszutek Wilk
commit c96aae1f7f393387d160211f60398d58463a7e65 upstream.
When we are finished with return PFNs to the hypervisor, then
populate it back, and also mark the E820 MMIO and E820 gaps
as IDENTITY_FRAMEs, we then call P2M to set areas that can
be used for ballooning. We were off by one, and ended up
over-writting a P2M entry that most likely was an IDENTITY_FRAME.
For example:
1-1 mapping on 4->40200
1-1 mapping on bc558->bc5ac
1-1 mapping on bc5b4->bc8c5
1-1 mapping on bc8c6->bcb7c
1-1 mapping on bcd00->10
Released 614 pages of unused memory
Set 277889 page(s) to 1-1 mapping
Populating 40200-40466 pfn range: 614 pages added
=> here we set from 40466 up to bc559 P2M tree to be
INVALID_P2M_ENTRY. We should have done it up to bc558.
The end result is that if anybody is trying to construct
a PTE for PFN bc558 they end up with ~PAGE_PRESENT.
Reported-by-and-Tested-by: Andre Przywara
Signed-off-by: Konrad Rzeszutek Wilk
Signed-off-by: Ben Hutchings
---
arch/x86/xen/setup.c |9 -
1 file changed, 8 insertions(+), 1 deletion(-)
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -78,9 +78,16 @@ static void __init xen_add_extra_mem(u64
memblock_x86_reserve_range(start, start + size, "XEN EXTRA");
xen_max_p2m_pfn = PFN_DOWN(start + size);
+ for (pfn = PFN_DOWN(start); pfn < xen_max_p2m_pfn; pfn++) {
+ unsigned long mfn = pfn_to_mfn(pfn);
+
+ if (WARN(mfn == pfn, "Trying to over-write 1-1 mapping (pfn:
%lx)\n", pfn))
+ continue;
+ WARN(mfn != INVALID_P2M_ENTRY, "Trying to remove %lx which has
%lx mfn!\n",
+ pfn, mfn);
- for (pfn = PFN_DOWN(start); pfn <= xen_max_p2m_pfn; pfn++)
__set_phys_to_machine(pfn, INVALID_P2M_ENTRY);
+ }
}
static unsigned long __init xen_release_chunk(unsigned long start,
--
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/
[ 014/135] OMAPFB: fix framebuffer console colors
3.2-stable review patch. If anyone has any objections, please let me know.
--
From: Grazvydas Ignotas
commit c1c52848cef52e157468b8879fc3cae23b6f3a99 upstream.
omapfb does not currently set pseudo palette correctly for color depths
above 16bpp, making red text invisible, command like
echo -e '\e[0;31mRED' > /dev/tty1
will display nothing on framebuffer console in 24bpp mode.
This is because temporary variable is declared incorrectly, fix it.
Signed-off-by: Grazvydas Ignotas
Signed-off-by: Tomi Valkeinen
Signed-off-by: Florian Tobias Schandinat
Signed-off-by: Ben Hutchings
---
drivers/video/omap2/omapfb/omapfb-main.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/omap2/omapfb/omapfb-main.c
b/drivers/video/omap2/omapfb/omapfb-main.c
index 08ec1a7..fc671d3 100644
--- a/drivers/video/omap2/omapfb/omapfb-main.c
+++ b/drivers/video/omap2/omapfb/omapfb-main.c
@@ -1192,7 +1192,7 @@ static int _setcolreg(struct fb_info *fbi, u_int regno,
u_int red, u_int green,
break;
if (regno < 16) {
- u16 pal;
+ u32 pal;
pal = ((red >> (16 - var->red.length)) <<
var->red.offset) |
((green >> (16 - var->green.length)) <<
--
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/
[ 016/135] ARM: dts: imx51-babbage: fix esdhc cd/wp properties
3.2-stable review patch. If anyone has any objections, please let me know.
--
From: Shawn Guo
commit a46d2619d7180bda12bad2bf15bbd0731dfc2dcf upstream.
The binding doc and dts use properties "fsl,{cd,wp}-internal" while
esdhc driver uses "fsl,{cd,wp}-controller". Fix binding doc and dts
to get them match driver code.
Reported-by: Chris Ball
Signed-off-by: Shawn Guo
Acked-by: Chris Ball
Signed-off-by: Ben Hutchings
---
Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.txt |8
arch/arm/boot/dts/imx51-babbage.dts |4 ++--
2 files changed, 6 insertions(+), 6 deletions(-)
--- a/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.txt
+++ b/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.txt
@@ -10,8 +10,8 @@ Required properties:
Optional properties:
- fsl,card-wired : Indicate the card is wired to host permanently
-- fsl,cd-internal : Indicate to use controller internal card detection
-- fsl,wp-internal : Indicate to use controller internal write protection
+- fsl,cd-controller : Indicate to use controller internal card detection
+- fsl,wp-controller : Indicate to use controller internal write protection
- cd-gpios : Specify GPIOs for card detection
- wp-gpios : Specify GPIOs for write protection
@@ -21,8 +21,8 @@ esdhc@70004000 {
compatible = "fsl,imx51-esdhc";
reg = <0x70004000 0x4000>;
interrupts = <1>;
- fsl,cd-internal;
- fsl,wp-internal;
+ fsl,cd-controller;
+ fsl,wp-controller;
};
esdhc@70008000 {
--- a/arch/arm/boot/dts/imx51-babbage.dts
+++ b/arch/arm/boot/dts/imx51-babbage.dts
@@ -29,8 +29,8 @@
aips@7000 { /* aips-1 */
spba@7000 {
esdhc@70004000 { /* ESDHC1 */
- fsl,cd-internal;
- fsl,wp-internal;
+ fsl,cd-controller;
+ fsl,wp-controller;
status = "okay";
};
--
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/
[ 102/135] rt2x00: Fix rfkill polling prior to interface start.
3.2-stable review patch. If anyone has any objections, please let me know.
--
From: Gertjan van Wingerde
commit a396e10019eaf3809b0219c966865aaafec12630 upstream.
We need to program the rfkill switch GPIO pin direction to input at
device initialization time, not only when the interface is brought up.
Doing this only when the interface is brought up could lead to rfkill
detecting the switch is turned on erroneously and inability to create
the interface and bringing it up.
Reported-and-tested-by: Andreas Messer
Signed-off-by: Gertjan van Wingerde
Acked-by: Ivo Van Doorn
Signed-off-by: John W. Linville
Signed-off-by: Ben Hutchings
---
drivers/net/wireless/rt2x00/rt2400pci.c |9 +
drivers/net/wireless/rt2x00/rt2400pci.h |1 +
drivers/net/wireless/rt2x00/rt2500pci.c |9 +
drivers/net/wireless/rt2x00/rt2500usb.c |9 +
drivers/net/wireless/rt2x00/rt2500usb.h |1 +
drivers/net/wireless/rt2x00/rt2800pci.c |9 +
drivers/net/wireless/rt2x00/rt2800usb.c |9 +
drivers/net/wireless/rt2x00/rt61pci.c |9 +
drivers/net/wireless/rt2x00/rt61pci.h |1 +
drivers/net/wireless/rt2x00/rt73usb.c |9 +
drivers/net/wireless/rt2x00/rt73usb.h |3 +++
11 files changed, 69 insertions(+)
diff --git a/drivers/net/wireless/rt2x00/rt2400pci.c
b/drivers/net/wireless/rt2x00/rt2400pci.c
index 8b9dbd7..64328af 100644
--- a/drivers/net/wireless/rt2x00/rt2400pci.c
+++ b/drivers/net/wireless/rt2x00/rt2400pci.c
@@ -1611,6 +1611,7 @@ static int rt2400pci_probe_hw_mode(struct rt2x00_dev
*rt2x00dev)
static int rt2400pci_probe_hw(struct rt2x00_dev *rt2x00dev)
{
int retval;
+ u32 reg;
/*
* Allocate eeprom data.
@@ -1624,6 +1625,14 @@ static int rt2400pci_probe_hw(struct rt2x00_dev
*rt2x00dev)
return retval;
/*
+* Enable rfkill polling by setting GPIO direction of the
+* rfkill switch GPIO pin correctly.
+*/
+ rt2x00pci_register_read(rt2x00dev, GPIOCSR, );
+ rt2x00_set_field32(, GPIOCSR_BIT8, 1);
+ rt2x00pci_register_write(rt2x00dev, GPIOCSR, reg);
+
+ /*
* Initialize hw specifications.
*/
retval = rt2400pci_probe_hw_mode(rt2x00dev);
diff --git a/drivers/net/wireless/rt2x00/rt2400pci.h
b/drivers/net/wireless/rt2x00/rt2400pci.h
index d3a4a68..7564ae9 100644
--- a/drivers/net/wireless/rt2x00/rt2400pci.h
+++ b/drivers/net/wireless/rt2x00/rt2400pci.h
@@ -670,6 +670,7 @@
#define GPIOCSR_BIT5 FIELD32(0x0020)
#define GPIOCSR_BIT6 FIELD32(0x0040)
#define GPIOCSR_BIT7 FIELD32(0x0080)
+#define GPIOCSR_BIT8 FIELD32(0x0100)
/*
* BBPPCSR: BBP Pin control register.
diff --git a/drivers/net/wireless/rt2x00/rt2500pci.c
b/drivers/net/wireless/rt2x00/rt2500pci.c
index d2cf8a4..3de0406 100644
--- a/drivers/net/wireless/rt2x00/rt2500pci.c
+++ b/drivers/net/wireless/rt2x00/rt2500pci.c
@@ -1929,6 +1929,7 @@ static int rt2500pci_probe_hw_mode(struct rt2x00_dev
*rt2x00dev)
static int rt2500pci_probe_hw(struct rt2x00_dev *rt2x00dev)
{
int retval;
+ u32 reg;
/*
* Allocate eeprom data.
@@ -1942,6 +1943,14 @@ static int rt2500pci_probe_hw(struct rt2x00_dev
*rt2x00dev)
return retval;
/*
+* Enable rfkill polling by setting GPIO direction of the
+* rfkill switch GPIO pin correctly.
+*/
+ rt2x00pci_register_read(rt2x00dev, GPIOCSR, );
+ rt2x00_set_field32(, GPIOCSR_DIR0, 1);
+ rt2x00pci_register_write(rt2x00dev, GPIOCSR, reg);
+
+ /*
* Initialize hw specifications.
*/
retval = rt2500pci_probe_hw_mode(rt2x00dev);
diff --git a/drivers/net/wireless/rt2x00/rt2500usb.c
b/drivers/net/wireless/rt2x00/rt2500usb.c
index b3a1d73..89fee31 100644
--- a/drivers/net/wireless/rt2x00/rt2500usb.c
+++ b/drivers/net/wireless/rt2x00/rt2500usb.c
@@ -1768,6 +1768,7 @@ static int rt2500usb_probe_hw_mode(struct rt2x00_dev
*rt2x00dev)
static int rt2500usb_probe_hw(struct rt2x00_dev *rt2x00dev)
{
int retval;
+ u16 reg;
/*
* Allocate eeprom data.
@@ -1781,6 +1782,14 @@ static int rt2500usb_probe_hw(struct rt2x00_dev
*rt2x00dev)
return retval;
/*
+* Enable rfkill polling by setting GPIO direction of the
+* rfkill switch GPIO pin correctly.
+*/
+ rt2500usb_register_read(rt2x00dev, MAC_CSR19, );
+ rt2x00_set_field16(, MAC_CSR19_BIT8, 0);
+ rt2500usb_register_write(rt2x00dev, MAC_CSR19, reg);
+
+ /*
* Initialize hw specifications.
*/
retval = rt2500usb_probe_hw_mode(rt2x00dev);
diff --git a/drivers/net/wireless/rt2x00/rt2500usb.h
b/drivers/net/wireless/rt2x00/rt2500usb.h
index 192531d..196bd51 100644
--- a/drivers/net/wireless/rt2x00/rt2500usb.h
+++
[ 100/135] rt2x00: Identify ASUS USB-N53 device.
3.2-stable review patch. If anyone has any objections, please let me know.
--
From: Gertjan van Wingerde
commit 177ef8360fabdc49ff08d2598c06e7f7a36b53e3 upstream.
This is an RT3572 based device.
Signed-off-by: Maximilian Engelhardt
Signed-off-by: Gertjan van Wingerde
Acked-by: Ivo Van Doorn
Signed-off-by: John W. Linville
Signed-off-by: Ben Hutchings
---
drivers/net/wireless/rt2x00/rt2800usb.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/rt2x00/rt2800usb.c
b/drivers/net/wireless/rt2x00/rt2800usb.c
index 6cf3365..6681bfc 100644
--- a/drivers/net/wireless/rt2x00/rt2800usb.c
+++ b/drivers/net/wireless/rt2x00/rt2800usb.c
@@ -1157,6 +1157,8 @@ static struct usb_device_id rt2800usb_device_table[] = {
{ USB_DEVICE(0x1690, 0x0744) },
{ USB_DEVICE(0x1690, 0x0761) },
{ USB_DEVICE(0x1690, 0x0764) },
+ /* ASUS */
+ { USB_DEVICE(0x0b05, 0x179d) },
/* Cisco */
{ USB_DEVICE(0x167b, 0x4001) },
/* EnGenius */
@@ -1222,7 +1224,6 @@ static struct usb_device_id rt2800usb_device_table[] = {
{ USB_DEVICE(0x0b05, 0x1760) },
{ USB_DEVICE(0x0b05, 0x1761) },
{ USB_DEVICE(0x0b05, 0x1790) },
- { USB_DEVICE(0x0b05, 0x179d) },
/* AzureWave */
{ USB_DEVICE(0x13d3, 0x3262) },
{ USB_DEVICE(0x13d3, 0x3284) },
--
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/
[ 080/135] time: Move ktime_t overflow checking into timespec_valid_strict
3.2-stable review patch. If anyone has any objections, please let me know.
--
From: John Stultz
This is a -stable backport of cee58483cf56e0ba355fdd97ff5e8925329aa936
Andreas Bombe reported that the added ktime_t overflow checking added to
timespec_valid in commit 4e8b14526ca7 ("time: Improve sanity checking of
timekeeping inputs") was causing problems with X.org because it caused
timeouts larger then KTIME_T to be invalid.
Previously, these large timeouts would be clamped to KTIME_MAX and would
never expire, which is valid.
This patch splits the ktime_t overflow checking into a new
timespec_valid_strict function, and converts the timekeeping codes
internal checking to use this more strict function.
Reported-and-tested-by: Andreas Bombe
Cc: Zhouping Liu
Cc: Ingo Molnar
Cc: Prarit Bhargava
Cc: Thomas Gleixner
Signed-off-by: John Stultz
Signed-off-by: Linus Torvalds
Cc: Linux Kernel
Signed-off-by: John Stultz
---
include/linux/time.h |7 +++
kernel/time/timekeeping.c | 10 +-
2 files changed, 12 insertions(+), 5 deletions(-)
--- a/include/linux/time.h
+++ b/include/linux/time.h
@@ -125,6 +125,13 @@ static inline bool timespec_valid(const
/* Can't have more nanoseconds then a second */
if ((unsigned long)ts->tv_nsec >= NSEC_PER_SEC)
return false;
+ return true;
+}
+
+static inline bool timespec_valid_strict(const struct timespec *ts)
+{
+ if (!timespec_valid(ts))
+ return false;
/* Disallow values that could overflow ktime_t */
if ((unsigned long long)ts->tv_sec >= KTIME_SEC_MAX)
return false;
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -382,7 +382,7 @@ int do_settimeofday(const struct timespe
struct timespec ts_delta;
unsigned long flags;
- if (!timespec_valid(tv))
+ if (!timespec_valid_strict(tv))
return -EINVAL;
write_seqlock_irqsave(_lock, flags);
@@ -428,7 +428,7 @@ int timekeeping_inject_offset(struct tim
timekeeping_forward_now();
tmp = timespec_add(xtime, *ts);
- if (!timespec_valid()) {
+ if (!timespec_valid_strict()) {
ret = -EINVAL;
goto error;
}
@@ -591,7 +591,7 @@ void __init timekeeping_init(void)
struct timespec now, boot;
read_persistent_clock();
- if (!timespec_valid()) {
+ if (!timespec_valid_strict()) {
pr_warn("WARNING: Persistent clock returned invalid value!\n"
" Check your CMOS/BIOS settings.\n");
now.tv_sec = 0;
@@ -599,7 +599,7 @@ void __init timekeeping_init(void)
}
read_boot_clock();
- if (!timespec_valid()) {
+ if (!timespec_valid_strict()) {
pr_warn("WARNING: Boot clock returned invalid value!\n"
" Check your CMOS/BIOS settings.\n");
boot.tv_sec = 0;
@@ -649,7 +649,7 @@ static void update_sleep_time(struct tim
*/
static void __timekeeping_inject_sleeptime(struct timespec *delta)
{
- if (!timespec_valid(delta)) {
+ if (!timespec_valid_strict(delta)) {
printk(KERN_WARNING "__timekeeping_inject_sleeptime: Invalid "
"sleep delta value!\n");
return;
--
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/
[ 103/135] rt2800usb: Added rx packet length validity check
3.2-stable review patch. If anyone has any objections, please let me know.
--
From: Sergei Poselenov
commit efd5d6b03bd9c9e0df646c56fb5f4f3e25e5c1ac upstream.
On our system (ARM Cortex-M3 SOC running linux-2.6.33)
frequent crashes were observed in the rt2800usb module
because of the invalid length of the received packet (3392,
46920...). This patch adds the sanity check on the packet
legth. Also, changed WARNING to ERROR in rt2x00lib_rxdone()
so that the bad packet condition would be noticed.
The fix was tested on the latest compat-wireless-3.5.1-1-snpc.
Signed-off-by: Sergei Poselenov
Acked-by: Ivo van Doorn
Signed-off-by: John W. Linville
Signed-off-by: Ben Hutchings
---
drivers/net/wireless/rt2x00/rt2800usb.c | 10 +-
drivers/net/wireless/rt2x00/rt2x00dev.c |2 +-
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/rt2x00/rt2800usb.c
b/drivers/net/wireless/rt2x00/rt2800usb.c
index 52a32b5..6b4226b 100644
--- a/drivers/net/wireless/rt2x00/rt2800usb.c
+++ b/drivers/net/wireless/rt2x00/rt2800usb.c
@@ -667,8 +667,16 @@ static void rt2800usb_fill_rxdone(struct queue_entry
*entry,
skb_pull(entry->skb, RXINFO_DESC_SIZE);
/*
-* FIXME: we need to check for rx_pkt_len validity
+* Check for rx_pkt_len validity. Return if invalid, leaving
+* rxdesc->size zeroed out by the upper level.
*/
+ if (unlikely(rx_pkt_len == 0 ||
+ rx_pkt_len > entry->queue->data_size)) {
+ ERROR(entry->queue->rt2x00dev,
+ "Bad frame size %d, forcing to 0\n", rx_pkt_len);
+ return;
+ }
+
rxd = (__le32 *)(entry->skb->data + rx_pkt_len);
/*
diff --git a/drivers/net/wireless/rt2x00/rt2x00dev.c
b/drivers/net/wireless/rt2x00/rt2x00dev.c
index a6b88bd..3f07e36 100644
--- a/drivers/net/wireless/rt2x00/rt2x00dev.c
+++ b/drivers/net/wireless/rt2x00/rt2x00dev.c
@@ -629,7 +629,7 @@ void rt2x00lib_rxdone(struct queue_entry *entry, gfp_t gfp)
*/
if (unlikely(rxdesc.size == 0 ||
rxdesc.size > entry->queue->data_size)) {
- WARNING(rt2x00dev, "Wrong frame size %d max %d.\n",
+ ERROR(rt2x00dev, "Wrong frame size %d max %d.\n",
rxdesc.size, entry->queue->data_size);
dev_kfree_skb(entry->skb);
goto renew_skb;
--
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/
[ 104/135] staging: zcache: fix cleancache race condition with shrinker
3.2-stable review patch. If anyone has any objections, please let me know.
--
From: Seth Jennings
commit 6d7d9798ad5c97ee4e911dd070dc12dc5ae55bd0 upstream.
This patch fixes a race condition that results in memory
corruption when using cleancache.
The race exists between the zcache shrinker handler,
shrink_zcache_memory() and cleancache_get_page().
In most cases, the shrinker will both evict a zbpg
from its buddy list and flush it from tmem before a
cleancache_get_page() occurs on that page. A subsequent
cleancache_get_page() will fail in the tmem layer.
In the rare case that two occur together and the
cleancache_get_page() path gets through the tmem
layer before the shrinker path can flush tmem,
zbud_decompress() does a check to see if the zbpg is a
"zombie", i.e. not on a buddy list, which means the shrinker
is in the process of reclaiming it. If the zbpg is a zombie,
zbud_decompress() returns -EINVAL.
However, this return code is being ignored by the caller,
zcache_pampd_get_data_and_free(), which results in the
caller of cleancache_get_page() thinking that the page has
been properly retrieved when it has not.
This patch modifies zcache_pampd_get_data_and_free() to
convey the failure up the stack so that the caller of
cleancache_get_page() knows the page retrieval failed.
This needs to be applied to stable trees as well.
zcache-main.c was named zcache.c before v3.1, so
I'm not sure how you want to handle trees earlier
than that.
Signed-off-by: Seth Jennings
Reviewed-by: Konrad Rzeszutek Wilk
Reviewed-by: Minchan Kim
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Ben Hutchings
---
drivers/staging/zcache/zcache-main.c |7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/zcache/zcache-main.c
b/drivers/staging/zcache/zcache-main.c
index c214977..52b43b7 100644
--- a/drivers/staging/zcache/zcache-main.c
+++ b/drivers/staging/zcache/zcache-main.c
@@ -1251,13 +1251,12 @@ static int zcache_pampd_get_data_and_free(char *data,
size_t *bufsize, bool raw,
void *pampd, struct tmem_pool *pool,
struct tmem_oid *oid, uint32_t index)
{
- int ret = 0;
-
BUG_ON(!is_ephemeral(pool));
- zbud_decompress((struct page *)(data), pampd);
+ if (zbud_decompress((struct page *)(data), pampd) < 0)
+ return -EINVAL;
zbud_free_and_delist((struct zbud_hdr *)pampd);
atomic_dec(_curr_eph_pampd_count);
- return ret;
+ return 0;
}
/*
--
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/
[ 077/135] fixing dmi match for hp t5745 and hp st5747 thin client
3.2-stable review patch. If anyone has any objections, please let me know.
--
From: Marc Gariepy
commit 62004978df3898649e152751eb6ac264a323ec36 upstream.
Match the correct information which is DMI_PRODUCT_NAME instead of
DMI_BOARD_NAME
See dmidecode information on launchpad for both thin client:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/911920
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/911916
Signed-off-by: Marc Gariepy
Reviewed-by: Adam Jackson
Signed-Off-by: Daniel Vetter
Signed-off-by: Ben Hutchings
---
drivers/gpu/drm/i915/intel_lvds.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lvds.c
b/drivers/gpu/drm/i915/intel_lvds.c
index 30e2c82..9c71183 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -750,7 +750,7 @@ static const struct dmi_system_id intel_no_lvds[] = {
.ident = "Hewlett-Packard t5745",
.matches = {
DMI_MATCH(DMI_BOARD_VENDOR, "Hewlett-Packard"),
- DMI_MATCH(DMI_BOARD_NAME, "hp t5745"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "hp t5745"),
},
},
{
@@ -758,7 +758,7 @@ static const struct dmi_system_id intel_no_lvds[] = {
.ident = "Hewlett-Packard st5747",
.matches = {
DMI_MATCH(DMI_BOARD_VENDOR, "Hewlett-Packard"),
- DMI_MATCH(DMI_BOARD_NAME, "hp st5747"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "hp st5747"),
},
},
{
--
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/
[ 076/135] workqueue: UNBOUND -> REBIND morphing in rebind_workers() should be atomic
3.2-stable review patch. If anyone has any objections, please let me know.
--
From: Lai Jiangshan
commit 96e65306b81351b656835c15931d1d237b252f27 upstream.
The compiler may compile the following code into TWO write/modify
instructions.
worker->flags &= ~WORKER_UNBOUND;
worker->flags |= WORKER_REBIND;
so the other CPU may temporarily see worker->flags which doesn't have
either WORKER_UNBOUND or WORKER_REBIND set and perform local wakeup
prematurely.
Fix it by using single explicit assignment via ACCESS_ONCE().
Because idle workers have another WORKER_NOT_RUNNING flag, this bug
doesn't exist for them; however, update it to use the same pattern for
consistency.
tj: Applied the change to idle workers too and updated comments and
patch description a bit.
stable: Idle worker rebinding doesn't apply for -stable and
WORKER_UNBOUND used to be WORKER_ROGUE. Updated accordingly.
Signed-off-by: Lai Jiangshan
Signed-off-by: Tejun Heo
---
kernel/workqueue.c |9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index 9a3128d..d7eb05a 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -3441,14 +3441,17 @@ static int __cpuinit trustee_thread(void *__gcwq)
for_each_busy_worker(worker, i, pos, gcwq) {
struct work_struct *rebind_work = >rebind_work;
+ unsigned long worker_flags = worker->flags;
/*
* Rebind_work may race with future cpu hotplug
* operations. Use a separate flag to mark that
-* rebinding is scheduled.
+* rebinding is scheduled. The morphing should
+* be atomic.
*/
- worker->flags |= WORKER_REBIND;
- worker->flags &= ~WORKER_ROGUE;
+ worker_flags |= WORKER_REBIND;
+ worker_flags &= ~WORKER_ROGUE;
+ ACCESS_ONCE(worker->flags) = worker_flags;
/* queue rebind_work, wq doesn't matter, use the default one */
if (test_and_set_bit(WORK_STRUCT_PENDING_BIT,
--
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/
[ 075/135] bnx2x: fix 57840_MF pci id
3.2-stable review patch. If anyone has any objections, please let me know. -- From: Yuval Mintz [ Upstream commit 5c879d2094946081af934739850c7260e8b25d3c ] Commit c3def943c7117d42caaed3478731ea7c3c87190e have added support for new pci ids of the 57840 board, while failing to change the obsolete value in 'pci_ids.h'. This patch does so, allowing the probe of such devices. Signed-off-by: Yuval Mintz Signed-off-by: Eilon Greenstein Signed-off-by: David S. Miller Signed-off-by: Ben Hutchings --- include/linux/pci_ids.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h index 2aaee0c..67cc215 100644 --- a/include/linux/pci_ids.h +++ b/include/linux/pci_ids.h @@ -2124,7 +2124,7 @@ #define PCI_DEVICE_ID_TIGON3_5704S 0x16a8 #define PCI_DEVICE_ID_NX2_57800_VF 0x16a9 #define PCI_DEVICE_ID_NX2_5706S0x16aa -#define PCI_DEVICE_ID_NX2_57840_MF 0x16ab +#define PCI_DEVICE_ID_NX2_57840_MF 0x16a4 #define PCI_DEVICE_ID_NX2_5708S0x16ac #define PCI_DEVICE_ID_NX2_57840_VF 0x16ad #define PCI_DEVICE_ID_NX2_57810_MF 0x16ae -- 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/
[ 005/135] iwlwifi: fix flow handler debug code
3.2-stable review patch. If anyone has any objections, please let me know.
--
From: Johannes Berg
commit 94543a8d4fb302817014981489f15cb3b92ec3c2 upstream.
iwl_dbgfs_fh_reg_read() can cause crashes and/or
BUG_ON in slub because the ifdefs are wrong, the
code in iwl_dump_fh() should use DEBUGFS, not
DEBUG to protect the buffer writing code.
Also, while at it, clean up the arguments to the
function, some code and make it generally safer.
Reported-by: Benjamin Herrenschmidt
Signed-off-by: Johannes Berg
Signed-off-by: John W. Linville
[bwh: Backported to 3.2: adjust filenames and context]
Signed-off-by: Ben Hutchings
---
--- a/drivers/net/wireless/iwlwifi/iwl-trans-pcie-int.h
+++ b/drivers/net/wireless/iwlwifi/iwl-trans-pcie-int.h
@@ -303,7 +303,7 @@ int iwl_queue_space(const struct iwl_que
**/
int iwl_dump_nic_event_log(struct iwl_trans *trans, bool full_log,
char **buf, bool display);
-int iwl_dump_fh(struct iwl_trans *trans, char **buf, bool display);
+int iwl_dump_fh(struct iwl_trans *trans, char **buf);
void iwl_dump_csr(struct iwl_trans *trans);
/*
--- a/drivers/net/wireless/iwlwifi/iwl-trans-pcie-rx.c
+++ b/drivers/net/wireless/iwlwifi/iwl-trans-pcie-rx.c
@@ -678,7 +678,7 @@ static void iwl_irq_handle_error(struct
iwl_dump_nic_error_log(trans);
iwl_dump_csr(trans);
- iwl_dump_fh(trans, NULL, false);
+ iwl_dump_fh(trans, NULL);
iwl_dump_nic_event_log(trans, false, NULL, false);
#ifdef CONFIG_IWLWIFI_DEBUG
if (iwl_get_debug_level(trans->shrd) & IWL_DL_FW_ERRORS)
--- a/drivers/net/wireless/iwlwifi/iwl-trans-pcie.c
+++ b/drivers/net/wireless/iwlwifi/iwl-trans-pcie.c
@@ -1541,13 +1541,9 @@ static const char *get_fh_string(int cmd
}
}
-int iwl_dump_fh(struct iwl_trans *trans, char **buf, bool display)
+int iwl_dump_fh(struct iwl_trans *trans, char **buf)
{
int i;
-#ifdef CONFIG_IWLWIFI_DEBUG
- int pos = 0;
- size_t bufsz = 0;
-#endif
static const u32 fh_tbl[] = {
FH_RSCSR_CHNL0_STTS_WPTR_REG,
FH_RSCSR_CHNL0_RBDCB_BASE_REG,
@@ -1559,29 +1555,35 @@ int iwl_dump_fh(struct iwl_trans *trans,
FH_TSSR_TX_STATUS_REG,
FH_TSSR_TX_ERROR_REG
};
-#ifdef CONFIG_IWLWIFI_DEBUG
- if (display) {
- bufsz = ARRAY_SIZE(fh_tbl) * 48 + 40;
+
+#ifdef CONFIG_IWLWIFI_DEBUGFS
+ if (buf) {
+ int pos = 0;
+ size_t bufsz = ARRAY_SIZE(fh_tbl) * 48 + 40;
+
*buf = kmalloc(bufsz, GFP_KERNEL);
if (!*buf)
return -ENOMEM;
+
pos += scnprintf(*buf + pos, bufsz - pos,
"FH register values:\n");
- for (i = 0; i < ARRAY_SIZE(fh_tbl); i++) {
+
+ for (i = 0; i < ARRAY_SIZE(fh_tbl); i++)
pos += scnprintf(*buf + pos, bufsz - pos,
" %34s: 0X%08x\n",
get_fh_string(fh_tbl[i]),
iwl_read_direct32(bus(trans), fh_tbl[i]));
- }
+
return pos;
}
#endif
+
IWL_ERR(trans, "FH register values:\n");
- for (i = 0; i < ARRAY_SIZE(fh_tbl); i++) {
+ for (i = 0; i < ARRAY_SIZE(fh_tbl); i++)
IWL_ERR(trans, " %34s: 0X%08x\n",
get_fh_string(fh_tbl[i]),
iwl_read_direct32(bus(trans), fh_tbl[i]));
- }
+
return 0;
}
@@ -1929,11 +1931,11 @@ static ssize_t iwl_dbgfs_fh_reg_read(str
size_t count, loff_t *ppos)
{
struct iwl_trans *trans = file->private_data;
- char *buf;
+ char *buf = NULL;
int pos = 0;
ssize_t ret = -EFAULT;
- ret = pos = iwl_dump_fh(trans, , true);
+ ret = pos = iwl_dump_fh(trans, );
if (buf) {
ret = simple_read_from_buffer(user_buf,
count, ppos, buf, pos);
--
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/
[ 018/135] ARM: imx: select CPU_FREQ_TABLE when needed
3.2-stable review patch. If anyone has any objections, please let me know. -- From: Arnd Bergmann commit f637c4c9405e21f44cf0045eaf77eddd3a79ca5a upstream. The i.MX cpufreq implementation uses the CPU_FREQ_TABLE helpers, so it needs to select that code to be built. This problem has apparently existed since the i.MX cpufreq code was first merged in v2.6.37. Building IMX without CPU_FREQ_TABLE results in: arch/arm/plat-mxc/built-in.o: In function `mxc_cpufreq_exit': arch/arm/plat-mxc/cpufreq.c:173: undefined reference to `cpufreq_frequency_table_put_attr' arch/arm/plat-mxc/built-in.o: In function `mxc_set_target': arch/arm/plat-mxc/cpufreq.c:84: undefined reference to `cpufreq_frequency_table_target' arch/arm/plat-mxc/built-in.o: In function `mxc_verify_speed': arch/arm/plat-mxc/cpufreq.c:65: undefined reference to `cpufreq_frequency_table_verify' arch/arm/plat-mxc/built-in.o: In function `mxc_cpufreq_init': arch/arm/plat-mxc/cpufreq.c:154: undefined reference to `cpufreq_frequency_table_cpuinfo' arch/arm/plat-mxc/cpufreq.c:162: undefined reference to `cpufreq_frequency_table_get_attr' Signed-off-by: Arnd Bergmann Acked-by: Shawn Guo Cc: Sascha Hauer Cc: Yong Shen Signed-off-by: Ben Hutchings --- arch/arm/Kconfig |1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index e91c7cd..84b5a0c 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -2150,6 +2150,7 @@ source "drivers/cpufreq/Kconfig" config CPU_FREQ_IMX tristate "CPUfreq driver for i.MX CPUs" depends on ARCH_MXC && CPU_FREQ + select CPU_FREQ_TABLE help This enables the CPUfreq driver for i.MX CPUs. -- 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/
[ 011/135] hwmon: (asus_atk0110) Add quirk for Asus M5A78L
3.2-stable review patch. If anyone has any objections, please let me know.
--
From: Luca Tettamanti
commit 43ca6cb28c871f2fbad10117b0648e5ae3b0f638 upstream.
The old interface is bugged and reads the wrong sensor when retrieving
the reading for the chassis fan (it reads the CPU sensor); the new
interface works fine.
Reported-by: Göran Uddeborg
Tested-by: Göran Uddeborg
Signed-off-by: Luca Tettamanti
Signed-off-by: Guenter Roeck
Signed-off-by: Ben Hutchings
---
drivers/hwmon/asus_atk0110.c |6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/hwmon/asus_atk0110.c b/drivers/hwmon/asus_atk0110.c
index 351d1f4..4ee5789 100644
--- a/drivers/hwmon/asus_atk0110.c
+++ b/drivers/hwmon/asus_atk0110.c
@@ -34,6 +34,12 @@ static const struct dmi_system_id __initconst
atk_force_new_if[] = {
.matches = {
DMI_MATCH(DMI_BOARD_NAME, "SABERTOOTH X58")
}
+ }, {
+ /* Old interface reads the same sensor for fan0 and fan1 */
+ .ident = "Asus M5A78L",
+ .matches = {
+ DMI_MATCH(DMI_BOARD_NAME, "M5A78L")
+ }
},
{ }
};
--
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/
[ 019/135] drm: remove some potentially dangerous DRM_ERRORs
3.2-stable review patch. If anyone has any objections, please let me know.
--
From: Jesse Barnes
commit acb4b992d8a13728044f430b47b9199aa45993e9 upstream.
Each of these error messages can be caused by a broken or malicious
userspace wanting to spam the dmesg with useless info. They're really
not worthy of DRM_DEBUG statements either; those are generally only
useful during bringup of new hardware or versions, and ought to be
removed before going upstream anyway.
Signed-off-by: Jesse Barnes
Reviewed-by: Alex Deucher
Signed-off-by: Dave Airlie
[bwh: Backported to 3.2: s/r\./r->/ in drm_mode_addfb()]
Signed-off-by: Ben Hutchings
---
drivers/gpu/drm/drm_crtc.c | 19 ---
1 file changed, 4 insertions(+), 15 deletions(-)
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1625,10 +1625,8 @@ int drm_mode_cursor_ioctl(struct drm_dev
if (!drm_core_check_feature(dev, DRIVER_MODESET))
return -EINVAL;
- if (!req->flags) {
- DRM_ERROR("no operation set\n");
+ if (!req->flags)
return -EINVAL;
- }
mutex_lock(>mode_config.mutex);
obj = drm_mode_object_find(dev, req->crtc_id, DRM_MODE_OBJECT_CRTC);
@@ -1641,7 +1639,6 @@ int drm_mode_cursor_ioctl(struct drm_dev
if (req->flags & DRM_MODE_CURSOR_BO) {
if (!crtc->funcs->cursor_set) {
- DRM_ERROR("crtc does not support cursor\n");
ret = -ENXIO;
goto out;
}
@@ -1654,7 +1651,6 @@ int drm_mode_cursor_ioctl(struct drm_dev
if (crtc->funcs->cursor_move) {
ret = crtc->funcs->cursor_move(crtc, req->x, req->y);
} else {
- DRM_ERROR("crtc does not support cursor\n");
ret = -EFAULT;
goto out;
}
@@ -1692,14 +1688,11 @@ int drm_mode_addfb(struct drm_device *de
if (!drm_core_check_feature(dev, DRIVER_MODESET))
return -EINVAL;
- if ((config->min_width > r->width) || (r->width > config->max_width)) {
- DRM_ERROR("mode new framebuffer width not within limits\n");
+ if ((config->min_width > r->width) || (r->width > config->max_width))
return -EINVAL;
- }
- if ((config->min_height > r->height) || (r->height >
config->max_height)) {
- DRM_ERROR("mode new framebuffer height not within limits\n");
+
+ if ((config->min_height > r->height) || (r->height >
config->max_height))
return -EINVAL;
- }
mutex_lock(>mode_config.mutex);
@@ -1756,7 +1749,6 @@ int drm_mode_rmfb(struct drm_device *dev
obj = drm_mode_object_find(dev, *id, DRM_MODE_OBJECT_FB);
/* TODO check that we really get a framebuffer back. */
if (!obj) {
- DRM_ERROR("mode invalid framebuffer id\n");
ret = -EINVAL;
goto out;
}
@@ -1767,7 +1759,6 @@ int drm_mode_rmfb(struct drm_device *dev
found = 1;
if (!found) {
- DRM_ERROR("tried to remove a fb that we didn't own\n");
ret = -EINVAL;
goto out;
}
@@ -1814,7 +1805,6 @@ int drm_mode_getfb(struct drm_device *de
mutex_lock(>mode_config.mutex);
obj = drm_mode_object_find(dev, r->fb_id, DRM_MODE_OBJECT_FB);
if (!obj) {
- DRM_ERROR("invalid framebuffer id\n");
ret = -EINVAL;
goto out;
}
@@ -1850,7 +1840,6 @@ int drm_mode_dirtyfb_ioctl(struct drm_de
mutex_lock(>mode_config.mutex);
obj = drm_mode_object_find(dev, r->fb_id, DRM_MODE_OBJECT_FB);
if (!obj) {
- DRM_ERROR("invalid framebuffer id\n");
ret = -EINVAL;
goto out_err1;
}
--
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/
[ 013/135] drm/i915: fix wrong order of parameters in port checking functions
3.2-stable review patch. If anyone has any objections, please let me know.
--
From: "Xu, Anhua"
commit b70ad586162609141f0aa9eb34790f31a8954f89 upstream.
Wrong order of parameters passed-in when calling hdmi/adpa
/lvds_pipe_enabled(), 2nd and 3rd parameters are reversed.
This bug was indroduced by
commit 1519b9956eb4b4180fa3f47c73341463cdcfaa37
Author: Keith Packard
Date: Sat Aug 6 10:35:34 2011 -0700
drm/i915: Fix PCH port pipe select in CPT disable paths
The reachable tag for this commit is v3.1-rc1-3-g1519b99
Signed-off-by: Anhua Xu
Reviewed-by: Chris Wilson
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44876
Tested-by: Daniel Schroeder
Signed-off-by: Daniel Vetter
Signed-off-by: Ben Hutchings
---
drivers/gpu/drm/i915/intel_display.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1072,7 +1072,7 @@ static void assert_pch_hdmi_disabled(str
enum pipe pipe, int reg)
{
u32 val = I915_READ(reg);
- WARN(hdmi_pipe_enabled(dev_priv, val, pipe),
+ WARN(hdmi_pipe_enabled(dev_priv, pipe, val),
"PCH HDMI (0x%08x) enabled on transcoder %c, should be disabled\n",
reg, pipe_name(pipe));
}
@@ -1089,13 +1089,13 @@ static void assert_pch_ports_disabled(st
reg = PCH_ADPA;
val = I915_READ(reg);
- WARN(adpa_pipe_enabled(dev_priv, val, pipe),
+ WARN(adpa_pipe_enabled(dev_priv, pipe, val),
"PCH VGA enabled on transcoder %c, should be disabled\n",
pipe_name(pipe));
reg = PCH_LVDS;
val = I915_READ(reg);
- WARN(lvds_pipe_enabled(dev_priv, val, pipe),
+ WARN(lvds_pipe_enabled(dev_priv, pipe, val),
"PCH LVDS enabled on transcoder %c, should be disabled\n",
pipe_name(pipe));
@@ -1437,7 +1437,7 @@ static void disable_pch_hdmi(struct drm_
enum pipe pipe, int reg)
{
u32 val = I915_READ(reg);
- if (hdmi_pipe_enabled(dev_priv, val, pipe)) {
+ if (hdmi_pipe_enabled(dev_priv, pipe, val)) {
DRM_DEBUG_KMS("Disabling pch HDMI %x on pipe %d\n",
reg, pipe);
I915_WRITE(reg, val & ~PORT_ENABLE);
@@ -1459,12 +1459,12 @@ static void intel_disable_pch_ports(stru
reg = PCH_ADPA;
val = I915_READ(reg);
- if (adpa_pipe_enabled(dev_priv, val, pipe))
+ if (adpa_pipe_enabled(dev_priv, pipe, val))
I915_WRITE(reg, val & ~ADPA_DAC_ENABLE);
reg = PCH_LVDS;
val = I915_READ(reg);
- if (lvds_pipe_enabled(dev_priv, val, pipe)) {
+ if (lvds_pipe_enabled(dev_priv, pipe, val)) {
DRM_DEBUG_KMS("disable lvds on pipe %d val 0x%08x\n", pipe,
val);
I915_WRITE(reg, val & ~LVDS_PORT_EN);
POSTING_READ(reg);
--
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/
[ 073/135] l2tp: avoid to use synchronize_rcu in tunnel free function
3.2-stable review patch. If anyone has any objections, please let me know.
--
From: "x...@mail.ru"
[ Upstream commit 99469c32f79a32d8481f87be0d3c66dad286f4ec ]
Avoid to use synchronize_rcu in l2tp_tunnel_free because context may be
atomic.
Signed-off-by: Dmitry Kozlov
Signed-off-by: David S. Miller
Signed-off-by: Ben Hutchings
---
net/l2tp/l2tp_core.c | 3 +--
net/l2tp/l2tp_core.h | 1 +
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/l2tp/l2tp_core.c b/net/l2tp/l2tp_core.c
index 89ff8c6..7501b22 100644
--- a/net/l2tp/l2tp_core.c
+++ b/net/l2tp/l2tp_core.c
@@ -1253,11 +1253,10 @@ static void l2tp_tunnel_free(struct l2tp_tunnel *tunnel)
/* Remove from tunnel list */
spin_lock_bh(>l2tp_tunnel_list_lock);
list_del_rcu(>list);
+ kfree_rcu(tunnel, rcu);
spin_unlock_bh(>l2tp_tunnel_list_lock);
- synchronize_rcu();
atomic_dec(_tunnel_count);
- kfree(tunnel);
}
/* Create a socket for the tunnel, if one isn't set up by
diff --git a/net/l2tp/l2tp_core.h b/net/l2tp/l2tp_core.h
index a16a48e..4393794 100644
--- a/net/l2tp/l2tp_core.h
+++ b/net/l2tp/l2tp_core.h
@@ -157,6 +157,7 @@ struct l2tp_tunnel_cfg {
struct l2tp_tunnel {
int magic; /* Should be L2TP_TUNNEL_MAGIC
*/
+ struct rcu_head rcu;
rwlock_thlist_lock; /* protect session_hlist */
struct hlist_head session_hlist[L2TP_HASH_SIZE];
/* hashed list of sessions,
--
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/
[ 074/135] net: ipv4: ipmr_expire_timer causes crash when removing net namespace
3.2-stable review patch. If anyone has any objections, please let me know.
--
From: Francesco Ruggeri
[ Upstream commit acbb219d5f53821b2d0080d047800410c0420ea1 ]
When tearing down a net namespace, ipv4 mr_table structures are freed
without first deactivating their timers. This can result in a crash in
run_timer_softirq.
This patch mimics the corresponding behaviour in ipv6.
Locking and synchronization seem to be adequate.
We are about to kfree mrt, so existing code should already make sure that
no other references to mrt are pending or can be created by incoming traffic.
The functions invoked here do not cause new references to mrt or other
race conditions to be created.
Invoking del_timer_sync guarantees that ipmr_expire_timer is inactive.
Both ipmr_expire_process (whose completion we may have to wait in
del_timer_sync) and mroute_clean_tables internally use mfc_unres_lock
or other synchronizations when needed, and they both only modify mrt.
Tested in Linux 3.4.8.
Signed-off-by: Francesco Ruggeri
Signed-off-by: David S. Miller
Signed-off-by: Ben Hutchings
---
net/ipv4/ipmr.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/ipmr.c b/net/ipv4/ipmr.c
index d2aae27..0064394 100644
--- a/net/ipv4/ipmr.c
+++ b/net/ipv4/ipmr.c
@@ -125,6 +125,8 @@ static DEFINE_SPINLOCK(mfc_unres_lock);
static struct kmem_cache *mrt_cachep __read_mostly;
static struct mr_table *ipmr_new_table(struct net *net, u32 id);
+static void ipmr_free_table(struct mr_table *mrt);
+
static int ip_mr_forward(struct net *net, struct mr_table *mrt,
struct sk_buff *skb, struct mfc_cache *cache,
int local);
@@ -132,6 +134,7 @@ static int ipmr_cache_report(struct mr_table *mrt,
struct sk_buff *pkt, vifi_t vifi, int assert);
static int __ipmr_fill_mroute(struct mr_table *mrt, struct sk_buff *skb,
struct mfc_cache *c, struct rtmsg *rtm);
+static void mroute_clean_tables(struct mr_table *mrt);
static void ipmr_expire_process(unsigned long arg);
#ifdef CONFIG_IP_MROUTE_MULTIPLE_TABLES
@@ -272,7 +275,7 @@ static void __net_exit ipmr_rules_exit(struct net *net)
list_for_each_entry_safe(mrt, next, >ipv4.mr_tables, list) {
list_del(>list);
- kfree(mrt);
+ ipmr_free_table(mrt);
}
fib_rules_unregister(net->ipv4.mr_rules_ops);
}
@@ -300,7 +303,7 @@ static int __net_init ipmr_rules_init(struct net *net)
static void __net_exit ipmr_rules_exit(struct net *net)
{
- kfree(net->ipv4.mrt);
+ ipmr_free_table(net->ipv4.mrt);
}
#endif
@@ -337,6 +340,13 @@ static struct mr_table *ipmr_new_table(struct net *net,
u32 id)
return mrt;
}
+static void ipmr_free_table(struct mr_table *mrt)
+{
+ del_timer_sync(>ipmr_expire_timer);
+ mroute_clean_tables(mrt);
+ kfree(mrt);
+}
+
/* Service routines creating virtual interfaces: DVMRP tunnels and PIMREG */
static void ipmr_del_tunnel(struct net_device *dev, struct vifctl *v)
--
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: ux500: 8500: use hsit_a_2 group for HSI
On Fri, Sep 14, 2012 at 12:54:35PM +0200, Linus Walleij wrote: > From: Patrice Chotard > > Due to specific constraint, pin HSIT_ACWAKE0_a is > not driven by HSI block but as a GPIO. > > Cc: a...@kernel.org > Signed-off-by: Patrice Chotard > Signed-off-by: Linus Walleij > --- > ARM SoC maintainers - I'll take this fixup through the pinctrl > tree if you don't mind. Sure, you should know best yourself if you're likely to have conflicts with other updates in this merge window anyway. Acked-by: Olof Johansson -Olof -- 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] cgroup: fix invalid rcu dereference
On 2012/9/15 1:01, Tejun Heo wrote: > On Fri, Sep 14, 2012 at 09:27:38AM -0400, Aristeu Rozanski wrote: >> On Fri, Sep 14, 2012 at 11:40:12AM +0200, Jiri Slaby wrote: >>> Commit "device_cgroup: convert device_cgroup internally to policy + >>> exceptions" removed rcu locks which are needed in task_devcgroup >>> called in this chain: devcgroup_inode_mknod OR >>> __devcgroup_inode_permission -> __devcgroup_inode_permission -> >>> task_devcgroup -> task_subsys_state -> task_subsys_state_check. >> >> ugh, missed that >> > ... >> thanks Jiri >> Acked-by: Aristeu Rozanski > > How should this be routed? > through akpm's -mm tree. -- 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/
[ 095/135] staging: comedi: das08: Correct AI encoding for das08jr-16-ao
3.2-stable review patch. If anyone has any objections, please let me know. -- From: Ian Abbott commit e6391a182865efc896cb2a8d79e07b7ac2f45b48 upstream. The element of `das08_boards[]` for the 'das08jr-16-ao' board has the `ai_encoding` member set to `das08_encode12`. It should be set to `das08_encode16` same as the 'das08jr/16' board. After all, this board has 16-bit AI resolution. The description of the A/D LSB register at offset 0 seems incorrect in the user manual "cio-das08jr-16-ao.pdf" as it implies that the AI resolution is only 12 bits. The diagrams of the A/D LSB and MSB registers show 15 data bits and a sign bit, which matches what the software expects for the `das08_encode16` AI encoding method. Signed-off-by: Ian Abbott Signed-off-by: Greg Kroah-Hartman [bwh: Backported to 3.2: adjust indentation] Signed-off-by: Ben Hutchings --- drivers/staging/comedi/drivers/das08.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/staging/comedi/drivers/das08.c +++ b/drivers/staging/comedi/drivers/das08.c @@ -385,7 +385,7 @@ static const struct das08_board_struct d .ai = das08_ai_rinsn, .ai_nbits = 16, .ai_pg = das08_pg_none, -.ai_encoding = das08_encode12, +.ai_encoding = das08_encode16, .ao = das08jr_ao_winsn, .ao_nbits = 16, .di = das08jr_di_rbits, -- 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/
