Re: [PATCH 0/4] dw_dmac: introduce generic DMA binding for DT
On Fri, Feb 15, 2013 at 07:21:48PM +0100, Arnd Bergmann wrote: > Hi Vinod, > > As Andy pointed out today, we don't have a good solution for the > dw_dmac DT binding in linux-next yet. I have posted my series > once before and then got distracted after getting feedback from > Viresh, Andy and Russell. I have now updated my earlier patch > based on the feedback and rebased on your tree without any > of the arm-soc patches mixed in. > > Unfortunately the patches have never been tested on real hardware > so I don't think it's a good idea to use them in v3.9 on the > spear platform. However, your dma-slave tree still contains Viresh's > earlier patches, causing a few problems: > > * With those patches, the spear3xx platform currently does not build. > (this one would be easy to fix though) > * There is a conflict between those patches and my spear multiplatform > series, which I have not yet queued up for 3.9 because of this, > since that would have meant that Stephen Rothwell would have to > discard either the arm-soc tree or the dma-slave tree from linux-next. > * I really don't want the broken binding to appear in 3.9. > > I believe the best way out at this point is this series, which first > first reverts the patch f9965aa2 "ARM: SPEAr13xx: Pass DW DMAC > platform data from DT" from your tree and then adds my update. > > This will give us the right DT binding for dw-dmac but no in-tree > users, which means that nothing should break if I get it slightly > wrong. Please apply the first two patches from these set, and > optionally the two patches that based on this convert the pl011 > uart and pl022 spi controller drivers. Arnd, Since there is still churn, would it make sense if I just revert the SPEAr13xx patch (your first patch) and send a pull request to Linus. Since there are no users and not much testing has been done, I think we can push these to 3.10 via arm-soc/slave-dma tree. Gives more testing and usage will go along as well. Since merge window is open, I would like my pull to go soonish and not churn the tree much. -- ~Vinod > > I can then decide with Olof whether or not to take the spear multiplatform > changes that no longer conflict with the dma slave tree as a "late" > branch into 3.9 or wait until 3.10, but that is something you don't > need to worry about then. Also the conversion of spear to use > the new binding (patch 5 of my original series) can go through the > arm-soc tree for 3.10 after the ST folks have tested that it works. > > Arnd > > Arnd Bergmann (4): > Revert "ARM: SPEAr13xx: Pass DW DMAC platform data from DT" > dmaengine: dw_dmac: move to generic DMA binding > spi: pl022: use generic DMA slave configuration if possible > serial: pl011: use generic DMA slave configuration if possible > > .../devicetree/bindings/arm/primecell.txt | 19 ++- > Documentation/devicetree/bindings/dma/snps-dma.txt | 70 ++- > Documentation/devicetree/bindings/serial/pl011.txt | 17 +++ > .../devicetree/bindings/spi/spi_pl022.txt | 36 ++ > arch/arm/boot/dts/spear1340.dtsi | 19 --- > arch/arm/boot/dts/spear13xx.dtsi | 38 -- > arch/arm/mach-spear13xx/include/mach/spear.h | 2 + > arch/arm/mach-spear13xx/spear1310.c| 5 +- > arch/arm/mach-spear13xx/spear1340.c| 33 +++-- > arch/arm/mach-spear13xx/spear13xx.c| 55 - > drivers/dma/dw_dmac.c | 137 > ++--- > drivers/dma/dw_dmac_regs.h | 8 +- > drivers/spi/spi-pl022.c| 43 ++- > drivers/tty/serial/amba-pl011.c| 62 ++ > include/linux/dw_dmac.h| 5 - > 15 files changed, 333 insertions(+), 216 deletions(-) > create mode 100644 Documentation/devicetree/bindings/serial/pl011.txt > > -- > 1.8.1.2 > -- 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 07/11] mfd: menelaus: use devm_request_irq() and devm_kzalloc()
On Wednesday, February 20, 2013 4:31 PM, Dmitry Torokhov wrote:
>
> Hi Jongoo,
>
> On Wed, Feb 20, 2013 at 03:12:38PM +0900, Jingoo Han wrote:
> > Use devm_request_irq() and devm_kzalloc() to make cleanup paths
> > more simple.
> >
>
> ...
>
> > @@ -1269,9 +1266,7 @@ static int __exit menelaus_remove(struct i2c_client
> > *client)
> > {
> > struct menelaus_chip*menelaus = i2c_get_clientdata(client);
> >
> > - free_irq(client->irq, menelaus);
> > flush_work(&menelaus->work);
> > - kfree(menelaus);
> > the_menelaus = NULL;
> > return 0;
>
> This conversion is certainly wrong - you really want to disable IRQ and
> then wait for the scheduled work to finish before freeing memory. Here
> you flush work but nothing stops IRQ from firing and scheduling that
> work again.
Yes, you're right.
I will use devm_free_irq() before flush_work().
>
> Please, be *extra* careful with devm_request_irq() conversions.
>
> Thanks.
>
> --
> Dmitry
--
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 08/11] mfd: ezx-pcap: use devm_request_irq() and devm_kzalloc()
On Wednesday, February 20, 2013 4:34 PM, Dmitry Torokhov wrote: > > On Wed, Feb 20, 2013 at 03:13:06PM +0900, Jingoo Han wrote: > > Use devm_request_irq() and devm_kzalloc() to make cleanup paths > > more simple. > > > > Signed-off-by: Jingoo Han > > --- > > drivers/mfd/ezx-pcap.c | 16 +--- > > 1 files changed, 5 insertions(+), 11 deletions(-) > > > > diff --git a/drivers/mfd/ezx-pcap.c b/drivers/mfd/ezx-pcap.c > > index b7a61f0..8dea3a9 100644 > > --- a/drivers/mfd/ezx-pcap.c > > +++ b/drivers/mfd/ezx-pcap.c > > @@ -403,7 +403,6 @@ static int ezx_pcap_remove(struct spi_device *spi) > > /* cleanup ADC */ > > adc_irq = pcap_to_irq(pcap, (pdata->config & PCAP_SECOND_PORT) ? > > PCAP_IRQ_ADCDONE2 : PCAP_IRQ_ADCDONE); > > - free_irq(adc_irq, pcap); > > mutex_lock(&pcap->adc_mutex); > > for (i = 0; i < PCAP_ADC_MAXQ; i++) > > kfree(pcap->adc_queue[i]); > > @@ -415,8 +414,6 @@ static int ezx_pcap_remove(struct spi_device *spi) > > > > destroy_workqueue(pcap->workqueue); > > > > - kfree(pcap); > > - > > I am pretty sure this conversion is wrong as well. Pretty much > work/workqueue and devm_request_irq() do not mix. Yes, you're right. I will use devm_free_irq(). > > Thanks. > > -- > Dmitry -- 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 10/11] mfd: tps65010: use devm_request_irq() and devm_kzalloc()
On Wednesday, February 20, 2013 4:35 PM, Dmitry Torokhov wrote: > -Original Message- > From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com] > Sent: Wednesday, February 20, 2013 4:35 PM > To: Jingoo Han > Cc: 'Samuel Ortiz'; linux-kernel@vger.kernel.org > Subject: Re: [PATCH 10/11] mfd: tps65010: use devm_request_irq() and > devm_kzalloc() > > On Wed, Feb 20, 2013 at 03:14:05PM +0900, Jingoo Han wrote: > > Use devm_request_irq() and devm_kzalloc() to make cleanup paths > > more simple. > > > > Signed-off-by: Jingoo Han > > --- > > drivers/mfd/tps65010.c | 15 +-- > > 1 files changed, 5 insertions(+), 10 deletions(-) > > > > diff --git a/drivers/mfd/tps65010.c b/drivers/mfd/tps65010.c > > index da2691f..a5438cc 100644 > > --- a/drivers/mfd/tps65010.c > > +++ b/drivers/mfd/tps65010.c > > @@ -525,11 +525,8 @@ static int __exit tps65010_remove(struct i2c_client > > *client) > > dev_dbg(&client->dev, "board %s %s err %d\n", > > "teardown", client->name, status); > > } > > - if (client->irq > 0) > > - free_irq(client->irq, tps); > > cancel_delayed_work_sync(&tps->work); > > debugfs_remove(tps->file); > > - kfree(tps); > > the_tps = NULL; > > return 0; > > Nope, again work and IRQ have to be handled in certain order. Yes, you're right. I will use devm_free_irq() > > Thanks. > > -- > Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 05/11] mfd: twl6040: use devm_gpio_request_one() and devm_request_threaded_irq()
On Wednesday, February 20, 2013 4:37 PM, Dmitry Torokhov wrote:
>
> Hi Jingoo,
>
> On Wed, Feb 20, 2013 at 03:11:38PM +0900, Jingoo Han wrote:
> > Use devm_gpio_request_one() and devm_request_threaded_irq() to make
> > cleanup paths and more simple.
> >
> > Signed-off-by: Jingoo Han
> > ---
> > drivers/mfd/twl6040.c | 26 +++---
> > 1 files changed, 7 insertions(+), 19 deletions(-)
> >
> > diff --git a/drivers/mfd/twl6040.c b/drivers/mfd/twl6040.c
> > index f361bf3..2d38512 100644
> > --- a/drivers/mfd/twl6040.c
> > +++ b/drivers/mfd/twl6040.c
> > @@ -586,8 +586,8 @@ static int twl6040_probe(struct i2c_client *client,
> > twl6040->audpwron = -EINVAL;
> >
> > if (gpio_is_valid(twl6040->audpwron)) {
> > - ret = gpio_request_one(twl6040->audpwron, GPIOF_OUT_INIT_LOW,
> > - "audpwron");
> > + ret = devm_gpio_request_one(twl6040->dev, twl6040->audpwron,
> > + GPIOF_OUT_INIT_LOW, "audpwron");
> > if (ret)
> > goto gpio_err;
> > }
> > @@ -596,14 +596,14 @@ static int twl6040_probe(struct i2c_client *client,
> > IRQF_ONESHOT, 0, &twl6040_irq_chip,
> > &twl6040->irq_data);
> > if (ret < 0)
> > - goto irq_init_err;
> > + goto gpio_err;
> >
> > twl6040->irq_ready = regmap_irq_get_virq(twl6040->irq_data,
> >TWL6040_IRQ_READY);
> > twl6040->irq_th = regmap_irq_get_virq(twl6040->irq_data,
> >TWL6040_IRQ_TH);
> >
> > - ret = request_threaded_irq(twl6040->irq_ready, NULL,
> > + ret = devm_request_threaded_irq(twl6040->dev, twl6040->irq_ready, NULL,
> >twl6040_readyint_handler, IRQF_ONESHOT,
> >"twl6040_irq_ready", twl6040);
> > if (ret) {
> > @@ -611,12 +611,12 @@ static int twl6040_probe(struct i2c_client *client,
> > goto readyirq_err;
> > }
> >
> > - ret = request_threaded_irq(twl6040->irq_th, NULL,
> > + ret = devm_request_threaded_irq(twl6040->dev, twl6040->irq_th, NULL,
> >twl6040_thint_handler, IRQF_ONESHOT,
> >"twl6040_irq_th", twl6040);
> > if (ret) {
> > dev_err(twl6040->dev, "Thermal IRQ request failed: %d\n", ret);
> > - goto thirq_err;
> > + goto readyirq_err;
> > }
> >
> > /* dual-access registers controlled by I2C only */
> > @@ -676,19 +676,12 @@ static int twl6040_probe(struct i2c_client *client,
> > ret = mfd_add_devices(&client->dev, -1, twl6040->cells, children,
> > NULL, 0, NULL);
> > if (ret)
> > - goto mfd_err;
> > + goto readyirq_err;
> >
> > return 0;
> >
> > -mfd_err:
> > - free_irq(twl6040->irq_th, twl6040);
> > -thirq_err:
> > - free_irq(twl6040->irq_ready, twl6040);
> > readyirq_err:
> > regmap_del_irq_chip(twl6040->irq, twl6040->irq_data);
> > -irq_init_err:
> > - if (gpio_is_valid(twl6040->audpwron))
> > - gpio_free(twl6040->audpwron);
> > gpio_err:
> > regulator_bulk_disable(TWL6040_NUM_SUPPLIES, twl6040->supplies);
> > power_err:
> > @@ -706,11 +699,6 @@ static int twl6040_remove(struct i2c_client *client)
> > if (twl6040->power_count)
> > twl6040_power(twl6040, 0);
> >
> > - if (gpio_is_valid(twl6040->audpwron))
> > - gpio_free(twl6040->audpwron);
> > -
> > - free_irq(twl6040->irq_ready, twl6040);
> > - free_irq(twl6040->irq_th, twl6040);
> > regmap_del_irq_chip(twl6040->irq, twl6040->irq_data);
> >
> > mfd_remove_devices(&client->dev);
>
> Are you sure it is OK to have sub-devices removed and regmap destroyed
> with IRQs still active?
Yes, you're right.
I will use devm_free_irq().
>
> Thanks.
>
> --
> Dmitry
--
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 10/35] mfd: ab8500-core: Rework MFD sub-device initialisation structures
On Tue, 19 Feb 2013, Arnd Bergmann wrote:
> On Friday 15 February 2013, Lee Jones wrote:
> > + {
> > + .name = "ab8500-charger",
> > + .of_compatible = "stericsson,ab8500-charger",
> > + .num_resources = ARRAY_SIZE(ab8500_charger_resources),
> > + .resources = ab8500_charger_resources,
> > +#ifndef CONFIG_OF
> > + .platform_data = &ab8500_bm_data,
> > + .pdata_size = sizeof(ab8500_bm_data),
> > +#endif
> > + },
>
> Is this #ifdef correct? I would have expected "#ifdef CONFIG_ATAGS"
> here.
No, it's not correct. See: 23a04f9f40f2b32ee593b768483105b1c776814d
I will fixup when the branched is rebased post-merge.
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 07/11] mfd: menelaus: use devm_request_irq() and devm_kzalloc()
On Wed, Feb 20, 2013 at 05:05:10PM +0900, Jingoo Han wrote:
> On Wednesday, February 20, 2013 4:31 PM, Dmitry Torokhov wrote:
> >
> > Hi Jongoo,
> >
> > On Wed, Feb 20, 2013 at 03:12:38PM +0900, Jingoo Han wrote:
> > > Use devm_request_irq() and devm_kzalloc() to make cleanup paths
> > > more simple.
> > >
> >
> > ...
> >
> > > @@ -1269,9 +1266,7 @@ static int __exit menelaus_remove(struct i2c_client
> > > *client)
> > > {
> > > struct menelaus_chip*menelaus = i2c_get_clientdata(client);
> > >
> > > - free_irq(client->irq, menelaus);
> > > flush_work(&menelaus->work);
> > > - kfree(menelaus);
> > > the_menelaus = NULL;
> > > return 0;
> >
> > This conversion is certainly wrong - you really want to disable IRQ and
> > then wait for the scheduled work to finish before freeing memory. Here
> > you flush work but nothing stops IRQ from firing and scheduling that
> > work again.
>
> Yes, you're right.
> I will use devm_free_irq() before flush_work().
Why change it at all if you have to call it manually in both error
unwinding and menelaus_remove() cases?
BTW, that __exit markup on menelaus_remove() is surprising... I am
pretty sure it can be unbound via sysfs and so there will be a nasty
oops.
--
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch v5 10/15] sched: packing transitory tasks in wake/exec power balancing
On 02/20/2013 03:40 PM, Mike Galbraith wrote: > On Wed, 2013-02-20 at 13:55 +0800, Alex Shi wrote: > >> Joonsoo Kim suggests not packing exec task, since the old task utils is >> possibly unuseable. > > (I'm stumbling around in rtmutex PI land, all dazed and confused, so > forgive me if my peripheral following of this thread is off target;) > > Hm, possibly. Future behavior is always undefined, trying to predict > always a gamble... so it looks to me like not packing on exec places a > bet against the user, who chose to wager that powersaving will happen > and it won't cost him too much, if you don't always try to pack despite > any risks. The user placed a bet on powersaving, not burst performance. > > Same for the fork, if you spread to accommodate a potential burst, you > bin the power wager, so maybe it's not in his best interest.. fork/exec > is common, if it's happening frequently, you'll bin the potential power > win frequently, reducing effectiveness, and silently trading power for > performance when the user asked to trade performance for a lower > electric bill. > > Dunno, just a thought, but I'd say for powersaving policy, you have to > go just for broke and hope it works out. You can't know it won't, but > you'll toss potential winnings every time you don't roll the dice. Sounds reasonable too. I have no idea of the of the decision now. And guess many guys dislike to use a knob to let user do the choice. What's your opinions, Peter? > > -Mike > -- Thanks Alex -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] timekeeping: avoid adjust kernel time once hwclock kept in UTC time
On Tue, Dec 18, 2012 at 10:37:08PM -0800, John Stultz wrote:
> On 12/18/2012 09:15 PM, Dong Zhu wrote:
> >On Thu, Dec 06, 2012 at 10:03:34PM +0800, Dong Zhu wrote:
> >> From c126376cf1837b0956e0268056db61870fbbc1d4 Mon Sep 17 00:00:00 2001
> >>From: Dong Zhu
> >>Date: Thu, 6 Dec 2012 21:45:00 +0800
> >>Subject: [PATCH] timekeeping: avoid adjust kernel time once hwclock kept in
> >> UTC time
> >>
> >>If the Hardware Clock kept in local time,kernel will adjust the time
> >>to be UTC time.But if Hardware Clock kept in UTC time,system will make
> >>a dummy settimeofday call first (sys_tz.tz_minuteswest = 0) to make sure
> >>the time is not shifted,so at this point I think maybe it is not necessary
> >>to set the kernel time once the sys_tz.tz_minuteswest is zero.
> >>
> >>Signed-off-by: Dong Zhu
> >>---
> >> kernel/time.c | 8 +---
> >> 1 file changed, 5 insertions(+), 3 deletions(-)
> >>
> >>diff --git a/kernel/time.c b/kernel/time.c
> >>index d226c6a..0b592ce 100644
> >>--- a/kernel/time.c
> >>+++ b/kernel/time.c
> >>@@ -134,9 +134,11 @@ static inline void warp_clock(void)
> >> {
> >>struct timespec adjust;
> >>- adjust = current_kernel_time();
> >>- adjust.tv_sec += sys_tz.tz_minuteswest * 60;
> >>- do_settimeofday(&adjust);
> >>+ if (sys_tz.tz_minuteswest) {
> >>+ adjust = current_kernel_time();
> >>+ adjust.tv_sec += sys_tz.tz_minuteswest * 60;
> >>+ do_settimeofday(&adjust);
> >>+ }
> >> }
> >> /*
> >>--
> >>1.7.11.7
> >>
> >Hi,
> >
> >Any comments ?
> Sorry for the slow response, been a little busy. Honestly the
> warp_clock() code path is always been a bit odd to me, so I've not
> really been able to get my head around the implications of this
> change.
>
> Really, I'm not sure if I'll get to this before the new year.
> Its on my list, but don't be afraid to ping me early Jan if I
> haven't queued it for 3.9 by then.
>
Hi,
Distance my submit over a long time,whether my patch can be applied ?
--
Best Regards,
Dong Zhu
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 06/35] mfd: ab8500-core: Sysfs chip id modification
On Tue, 19 Feb 2013, Arnd Bergmann wrote:
> On Friday 15 February 2013, Lee Jones wrote:
> > struct ab8500 *ab8500;
> > + int chip_id = -EINVAL;
> >
> > ab8500 = dev_get_drvdata(dev);
> > - return sprintf(buf, "%#x\n", ab8500 ? ab8500->chip_id : -EINVAL);
> > + if(ab8500) {
> > + chip_id = ab8500->chip_id;
> > + if((is_ab8505(ab8500) || is_ab9540(ab8500)) &&
> > ab8500->version != 0xFF)
> > + chip_id = (ab8500->version << 8) | chip_id;
> > + }
> > + return sprintf(buf, "%#x\n", chip_id);
> > }
>
> What's the use of printing "ffea" for unknown versions here?
You mean instead of -EINVAL? No idea, Marcus?
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v12 rebased 2/8] start vm after resetting it
On Thu, Feb 07, 2013 at 11:50:28PM -0200, Marcelo Tosatti wrote:
> On Wed, Jan 23, 2013 at 03:19:23PM +0800, Hu Tao wrote:
> > From: Wen Congyang
> >
> > The guest should run after resetting it, but it does not run if its
> > old state is RUN_STATE_INTERNAL_ERROR or RUN_STATE_PAUSED.
> >
> > We don't set runstate to RUN_STATE_PAUSED when resetting the guest,
> > so the runstate will be changed from RUN_STATE_INTERNAL_ERROR or
> > RUN_STATE_PAUSED to RUN_STATE_RUNNING(not RUN_STATE_PAUSED).
>
> It appears the last hunk will automatically reset state from
> RUN_STATE_INTERNAL_ERROR to RUN_STATE_RUNNING ?
Yes.
>
> I suppose the transition table allows, from RUN_STATE_INTERNAL_ERROR:
>
> system_reset
> cont
>
> To resume the machine?
True.
I think the purpose of this patch is to always reset and _run_ the guest
by `system_reset', avoiding an additional `cont' following `system_reset'.
>
> >
> > Signed-off-by: Wen Congyang
> > ---
> > include/block/block.h | 2 ++
> > qmp.c | 2 +-
> > vl.c | 7 ---
> > 3 files changed, 7 insertions(+), 4 deletions(-)
> >
> > diff --git a/include/block/block.h b/include/block/block.h
> > index ffd1936..5e82ccb 100644
> > --- a/include/block/block.h
> > +++ b/include/block/block.h
> > @@ -366,6 +366,8 @@ void bdrv_disable_copy_on_read(BlockDriverState *bs);
> > void bdrv_set_in_use(BlockDriverState *bs, int in_use);
> > int bdrv_in_use(BlockDriverState *bs);
> >
> > +void iostatus_bdrv_it(void *opaque, BlockDriverState *bs);
> > +
> > #ifdef CONFIG_LINUX_AIO
> > int raw_get_aio_fd(BlockDriverState *bs);
> > #else
> > diff --git a/qmp.c b/qmp.c
> > index 55b056b..5f1bed1 100644
> > --- a/qmp.c
> > +++ b/qmp.c
> > @@ -130,7 +130,7 @@ SpiceInfo *qmp_query_spice(Error **errp)
> > };
> > #endif
> >
> > -static void iostatus_bdrv_it(void *opaque, BlockDriverState *bs)
> > +void iostatus_bdrv_it(void *opaque, BlockDriverState *bs)
> > {
> > bdrv_iostatus_reset(bs);
> > }
> > diff --git a/vl.c b/vl.c
> > index b0bcf1e..1d2edaa 100644
> > --- a/vl.c
> > +++ b/vl.c
> > @@ -534,7 +534,7 @@ static const RunStateTransition
> > runstate_transitions_def[] = {
> > { RUN_STATE_INMIGRATE, RUN_STATE_RUNNING },
> > { RUN_STATE_INMIGRATE, RUN_STATE_PAUSED },
> >
> > -{ RUN_STATE_INTERNAL_ERROR, RUN_STATE_PAUSED },
> > +{ RUN_STATE_INTERNAL_ERROR, RUN_STATE_RUNNING },
> > { RUN_STATE_INTERNAL_ERROR, RUN_STATE_FINISH_MIGRATE },
> >
> > { RUN_STATE_IO_ERROR, RUN_STATE_RUNNING },
> > @@ -569,7 +569,7 @@ static const RunStateTransition
> > runstate_transitions_def[] = {
> >
> > { RUN_STATE_SAVE_VM, RUN_STATE_RUNNING },
> >
> > -{ RUN_STATE_SHUTDOWN, RUN_STATE_PAUSED },
> > +{ RUN_STATE_SHUTDOWN, RUN_STATE_RUNNING },
> > { RUN_STATE_SHUTDOWN, RUN_STATE_FINISH_MIGRATE },
> >
> > { RUN_STATE_DEBUG, RUN_STATE_SUSPENDED },
> > @@ -1951,7 +1951,8 @@ static bool main_loop_should_exit(void)
> > resume_all_vcpus();
> > if (runstate_check(RUN_STATE_INTERNAL_ERROR) ||
> > runstate_check(RUN_STATE_SHUTDOWN)) {
> > -runstate_set(RUN_STATE_PAUSED);
> > +bdrv_iterate(iostatus_bdrv_it, NULL);
> > +vm_start();
> > }
> > }
> > if (qemu_wakeup_requested()) {
> > --
> > 1.8.0.1.240.ge8a1f5a
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe kvm" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Regards,
Hu Tao
--
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 07/11] mfd: menelaus: use devm_request_irq() and devm_kzalloc()
On Wednesday, February 20, 2013 5:10 PM, Dmitry Torokhov wrote:
>
> On Wed, Feb 20, 2013 at 05:05:10PM +0900, Jingoo Han wrote:
> > On Wednesday, February 20, 2013 4:31 PM, Dmitry Torokhov wrote:
> > >
> > > Hi Jongoo,
> > >
> > > On Wed, Feb 20, 2013 at 03:12:38PM +0900, Jingoo Han wrote:
> > > > Use devm_request_irq() and devm_kzalloc() to make cleanup paths
> > > > more simple.
> > > >
> > >
> > > ...
> > >
> > > > @@ -1269,9 +1266,7 @@ static int __exit menelaus_remove(struct
> > > > i2c_client *client)
> > > > {
> > > > struct menelaus_chip*menelaus = i2c_get_clientdata(client);
> > > >
> > > > - free_irq(client->irq, menelaus);
> > > > flush_work(&menelaus->work);
> > > > - kfree(menelaus);
> > > > the_menelaus = NULL;
> > > > return 0;
> > >
> > > This conversion is certainly wrong - you really want to disable IRQ and
> > > then wait for the scheduled work to finish before freeing memory. Here
> > > you flush work but nothing stops IRQ from firing and scheduling that
> > > work again.
> >
> > Yes, you're right.
> > I will use devm_free_irq() before flush_work().
>
> Why change it at all if you have to call it manually in both error
> unwinding and menelaus_remove() cases?
>
> BTW, that __exit markup on menelaus_remove() is surprising... I am
> pretty sure it can be unbound via sysfs and so there will be a nasty
> oops.
I see, I will not modify this menelaus mfd driver.
Thank you.
>
> --
> Dmitry
--
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/
[GIT PULL] fuse updates for 3.9
Hi Linus, Please pull git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse.git for-linus The biggest part of this pull request is a patch series from Maxim Patlasov to optimize scatter-gather direct IO. There's also the addition of a "readdirplus" API, poll events and various fixes and cleanups. There's a one line change outside of fuse to mm/filemap.c which makes the argument of iov_iter_single_seg_count() const, required by Maxim's patches. Thanks, Miklos Anand V. Avati (1): fuse: implement NFS-like readdirplus support Anatol Pomozov (1): Do not use RCU for current process credentials Enke Chen (1): fuse: send poll events Eric Wong (2): fuse: avoid out-of-scope stack access fuse: allow control of adaptive readdirplus use Feng Shuo (1): FUSE: Adapt readdirplus to application usage patterns Maxim Patlasov (12): fuse: general infrastructure for pages[] of variable size fuse: categorize fuse_get_req() fuse: rework fuse_retrieve() fuse: rework fuse_readpages() fuse: rework fuse_perform_write() fuse: rework fuse_do_ioctl() fuse: add per-page descriptor to fuse_req fuse: use req->page_descs[] for argpages cases mm: minor cleanup of iov_iter_single_seg_count() fuse: pass iov[] to fuse_get_user_pages() fuse: optimize fuse_get_user_pages() fuse: optimize __fuse_direct_io() Miklos Szeredi (4): fuse: cleanup fuse_direct_io() fuse: bump version for READDIRPLUS fuse: don't WARN when nlink is zero Synchronize fuse header with one used in library --- fs/fuse/cuse.c| 10 +- fs/fuse/dev.c | 128 -- fs/fuse/dir.c | 259 ++--- fs/fuse/file.c| 238 ++--- fs/fuse/fuse_i.h | 74 ++--- fs/fuse/inode.c | 16 ++- include/linux/fs.h|2 +- include/uapi/linux/fuse.h | 60 ++- mm/filemap.c |2 +- 9 files changed, 609 insertions(+), 180 deletions(-) -- 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 V2] sched/core: remove obsolete nr_uninterruptible()
From: Sha Zhengju
Signed-off-by: Sha Zhengju
---
kernel/sched/core.c | 22 ++
1 file changed, 2 insertions(+), 20 deletions(-)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 03d7784..b7b03cd 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -1969,11 +1969,10 @@ context_switch(struct rq *rq, struct task_struct *prev,
}
/*
- * nr_running, nr_uninterruptible and nr_context_switches:
+ * nr_running and nr_context_switches:
*
* externally visible scheduler statistics: current number of runnable
- * threads, current number of uninterruptible-sleeping threads, total
- * number of context switches performed since bootup.
+ * threads, total number of context switches performed since bootup.
*/
unsigned long nr_running(void)
{
@@ -1985,23 +1984,6 @@ unsigned long nr_running(void)
return sum;
}
-unsigned long nr_uninterruptible(void)
-{
- unsigned long i, sum = 0;
-
- for_each_possible_cpu(i)
- sum += cpu_rq(i)->nr_uninterruptible;
-
- /*
-* Since we read the counters lockless, it might be slightly
-* inaccurate. Do not allow it to go below zero though:
-*/
- if (unlikely((long)sum < 0))
- sum = 0;
-
- return sum;
-}
-
unsigned long long nr_context_switches(void)
{
int i;
--
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: general protection fault in do_msgrcv [3.8]
19.02.2013 22:04, Dave Jones пишет:
general protection fault: [#1] PREEMPT SMP DEBUG_PAGEALLOC
Modules linked in: can af_rxrpc binfmt_misc scsi_transport_iscsi ax25 ipt_ULOG
decnet nfc appletalk x25 rds ipx p8023 psnap p8022 llc irda crc_ccitt atm lockd
sunrpc ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_conntrack nf_conntrack
ip6table_filter ip6_tables btusb bluetooth snd_hda_codec_realtek snd_hda_intel
snd_hda_codec snd_pcm edac_core snd_page_alloc snd_timer microcode rfkill
usb_debug serio_raw pcspkr snd soundcore vhost_net r8169 mii tun macvtap
macvlan kvm_amd kvm
CPU 2
Pid: 887, comm: trinity-child2 Not tainted 3.8.0+ #57 Gigabyte Technology Co.,
Ltd. GA-MA78GM-S2H/GA-MA78GM-S2H
RIP: 0010:[] [] do_msgrcv+0x22a/0x670
RSP: 0018:88011892be88 EFLAGS: 00010297
RAX: RBX: 0001 RCX: 4000
RDX: 7adea6f6 RSI: 6b6b6b6b6b6b6b6b RDI: 8801189ffb60
RBP: 88011892bf68 R08: 0001 R09:
R10: R11: R12:
R13: 8801189ffc10 R14: 8801189ffb60 R15: 6b6b6b6b6b6b6b6b
FS: 7f681e955740() GS:88012f20() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: 7f681e846064 CR3: 00012553d000 CR4: 07e0
DR0: DR1: DR2:
DR3: DR6: 0ff0 DR7: 0400
Process trinity-child2 (pid: 887, threadinfo 88011892a000, task
88010bc82490)
Stack:
88011892beb8 88010bc82490 88010bc82490 88010bc82490
8801186d8000 812ad5f0 01aba000 81c688c0
7adea6f6 001f 400046a9467e 6b6b6b6b6b6b6b6b
Call Trace:
[] ? load_msg+0x180/0x180
[] ? trace_hardirqs_on_caller+0x115/0x1a0
[] ? trace_hardirqs_on_thunk+0x3a/0x3f
[] sys_msgrcv+0x15/0x20
[] system_call_fastpath+0x16/0x1b
Code: 84 14 01 00 00 8b 8d 74 ff ff ff 85 c9 0f 84 52 02 00 00 48 8b 95 60 ff ff ff
48 39 55 80 0f 84 4d 02 00 00 4c 89 bd 78 ff ff ff <4d> 8b 3f 48 ff 45 80 4d 39
ef 75 9a 66 90 48 81 bd 78 ff ff ff
RIP [] do_msgrcv+0x22a/0x670
RSP
---[ end trace d3cc044a84b1d828 ]---
oopsing instruction is..
0: 4d 8b 3fmov(%r15),%r15
Looks like a use-after-free.
Disassembly of ipc/msg.o shows this happens here..
msg = ERR_PTR(-EAGAIN);
tmp = msq->q_messages.next;
1537: 4d 8b be b0 00 00 00mov0xb0(%r14),%r15
while (tmp != &msq->q_messages) {
153e: 4d 8d ae b0 00 00 00lea0xb0(%r14),%r13
1545: 4d 39 efcmp%r13,%r15
1548: 0f 84 5f 03 00 00 je 18ad
154e: 48 c7 45 80 00 00 00movq $0x0,-0x80(%rbp)
1555: 00
1556: 48 c7 85 78 ff ff ffmovq $0xfff5,-0x88(%rbp)
155d: f5 ff ff ff
1561: eb 0d jmp1570
1563: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)
}
} else
break;
msg_counter++;
}
tmp = tmp->next;
1568: 4d 8b 3fmov(%r15),%r15
if (ipcperms(ns, &msq->q_perm, S_IRUGO))
goto out_unlock;
msg = ERR_PTR(-EAGAIN);
tmp = msq->q_messages.next;
while (tmp != &msq->q_messages) {
Looks like Stanislav recently changed this code, so problem was likely
introduced
in those changes.
Hello.
Is it easy to reproduce? Do you use KVM?
There is a NULL selinux handler bug fix by Stephen Smalley here:
https://lkml.org/lkml/2013/2/6/663
But anyway, this bug fix affects only the case, when MSG_COPY flag is set.
And this is not your case, I suppose?
Dave
--
Best regards,
Stanislav Kinsbursky
--
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: ux500: read the correct soc_id number
Fix db8500_read_soc_id() to read all five soc_id number locations instead of repeating the second one two times. Signed-off-by: Fabio Baltieri --- arch/arm/mach-ux500/cpu-db8500.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/mach-ux500/cpu-db8500.c b/arch/arm/mach-ux500/cpu-db8500.c index 5b286e0..4b5602b 100644 --- a/arch/arm/mach-ux500/cpu-db8500.c +++ b/arch/arm/mach-ux500/cpu-db8500.c @@ -199,7 +199,7 @@ static const char *db8500_read_soc_id(void) /* Throw these device-specific numbers into the entropy pool */ add_device_randomness(uid, 0x14); return kasprintf(GFP_KERNEL, "%08x%08x%08x%08x%08x", -readl((u32 *)uid+1), +readl((u32 *)uid+0), readl((u32 *)uid+1), readl((u32 *)uid+2), readl((u32 *)uid+3), readl((u32 *)uid+4)); } -- 1.7.12.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] base: core: WARN() about bogus permissions on device attributes
Whenever a struct device_attribute is registered
with mismatched permissions - read permission without
a show routine or write permission without store
routine - we will issue a big warning so we catch
those early enough.
Signed-off-by: Felipe Balbi
---
drivers/base/core.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/base/core.c b/drivers/base/core.c
index a235085..14e6a92 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -563,8 +563,15 @@ int device_create_file(struct device *dev,
const struct device_attribute *attr)
{
int error = 0;
- if (dev)
+
+ if (dev) {
+ WARN(((attr->attr.mode & S_IWUGO) && !attr->store),
+ "Write permission without 'store'\n");
+ WARN(((attr->attr.mode & S_IRUGO) && !attr->show),
+ "Read permission without 'show'\n");
error = sysfs_create_file(&dev->kobj, &attr->attr);
+ }
+
return error;
}
--
1.8.1.rc1.5.g7e0651a
--
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] sched/core: remove obsolete nr_uninterruptible()
On Wed, Feb 20, 2013 at 3:37 PM, Sha Zhengju wrote:
> From: Sha Zhengju
>
> Signed-off-by: Sha Zhengju
> ---
> kernel/sched/core.c | 17 -
> 1 file changed, 17 deletions(-)
You missed include/linux/sched.h :)
>
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index c0b07c3..792f6fc 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -1957,23 +1957,6 @@ unsigned long nr_running(void)
> return sum;
> }
>
> -unsigned long nr_uninterruptible(void)
> -{
> - unsigned long i, sum = 0;
> -
> - for_each_possible_cpu(i)
> - sum += cpu_rq(i)->nr_uninterruptible;
> -
> - /*
> -* Since we read the counters lockless, it might be slightly
> -* inaccurate. Do not allow it to go below zero though:
> -*/
> - if (unlikely((long)sum < 0))
> - sum = 0;
> -
> - return sum;
> -}
> -
> unsigned long long nr_context_switches(void)
> {
> int i;
> --
> 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/
--
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 0/3] leds: move LED triggers and add new LED trigger for camera
This patch-set consists of major changes below. (a) Move trigger drivers into new subdirectory, 'drivers/leds/trigger/' (b) Add LED trigger for camera functions: 'flash' and 'torch' (c) Support camera LED trigger feature in existing drivers: LM355x and LM3642 Milo(Woogyom) Kim (3): leds: move LED trigger drivers into new subdirectory leds: add LED Trigger for camera function leds: lm355x, lm3642: support Camera LED triggers for flash/torch drivers/leds/Kconfig | 101 +--- drivers/leds/Makefile | 10 +- drivers/leds/leds-lm355x.c|2 + drivers/leds/leds-lm3642.c|2 + drivers/leds/ledtrig-backlight.c | 166 --- drivers/leds/ledtrig-cpu.c| 142 drivers/leds/ledtrig-default-on.c | 45 - drivers/leds/ledtrig-gpio.c | 253 - drivers/leds/ledtrig-heartbeat.c | 161 -- drivers/leds/ledtrig-ide-disk.c | 47 -- drivers/leds/ledtrig-oneshot.c| 204 --- drivers/leds/ledtrig-timer.c | 131 --- drivers/leds/ledtrig-transient.c | 237 --- drivers/leds/trigger/Kconfig | 111 + drivers/leds/trigger/Makefile | 10 ++ drivers/leds/trigger/ledtrig-backlight.c | 166 +++ drivers/leds/trigger/ledtrig-camera.c | 57 +++ drivers/leds/trigger/ledtrig-cpu.c| 142 drivers/leds/trigger/ledtrig-default-on.c | 45 + drivers/leds/trigger/ledtrig-gpio.c | 253 + drivers/leds/trigger/ledtrig-heartbeat.c | 161 ++ drivers/leds/trigger/ledtrig-ide-disk.c | 47 ++ drivers/leds/trigger/ledtrig-oneshot.c| 204 +++ drivers/leds/trigger/ledtrig-timer.c | 130 +++ drivers/leds/trigger/ledtrig-transient.c | 237 +++ include/linux/leds.h |8 + 26 files changed, 1577 insertions(+), 1495 deletions(-) delete mode 100644 drivers/leds/ledtrig-backlight.c delete mode 100644 drivers/leds/ledtrig-cpu.c delete mode 100644 drivers/leds/ledtrig-default-on.c delete mode 100644 drivers/leds/ledtrig-gpio.c delete mode 100644 drivers/leds/ledtrig-heartbeat.c delete mode 100644 drivers/leds/ledtrig-ide-disk.c delete mode 100644 drivers/leds/ledtrig-oneshot.c delete mode 100644 drivers/leds/ledtrig-timer.c delete mode 100644 drivers/leds/ledtrig-transient.c create mode 100644 drivers/leds/trigger/Kconfig create mode 100644 drivers/leds/trigger/Makefile create mode 100644 drivers/leds/trigger/ledtrig-backlight.c create mode 100644 drivers/leds/trigger/ledtrig-camera.c create mode 100644 drivers/leds/trigger/ledtrig-cpu.c create mode 100644 drivers/leds/trigger/ledtrig-default-on.c create mode 100644 drivers/leds/trigger/ledtrig-gpio.c create mode 100644 drivers/leds/trigger/ledtrig-heartbeat.c create mode 100644 drivers/leds/trigger/ledtrig-ide-disk.c create mode 100644 drivers/leds/trigger/ledtrig-oneshot.c create mode 100644 drivers/leds/trigger/ledtrig-timer.c create mode 100644 drivers/leds/trigger/ledtrig-transient.c -- 1.7.9.5 Best Regards, Milo -- 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/3] leds: lm355x, lm3642: support Camera LED triggers for flash/torch
LM355x and LM3642 support flash and torch functionality.
(Camera driver) (LED trigger for camera) (LED driver)
Turn on the flash ...> ledtrig_flash_ctrl(true) ...> LM355x or LM3642
brightness ctrl
Flash/torch LEDs are controlled by other driver using LED camera trigger
APIs, ledtrig_flash_ctrl()/ledtrig_torch_ctrl().
Then, actual device control is activated by each LED driver such like
LM355x or LM3642.
Signed-off-by: Milo(Woogyom) Kim
---
drivers/leds/leds-lm355x.c |2 ++
drivers/leds/leds-lm3642.c |2 ++
2 files changed, 4 insertions(+)
diff --git a/drivers/leds/leds-lm355x.c b/drivers/leds/leds-lm355x.c
index 4117235..d81a8e7 100644
--- a/drivers/leds/leds-lm355x.c
+++ b/drivers/leds/leds-lm355x.c
@@ -477,6 +477,7 @@ static int lm355x_probe(struct i2c_client *client,
chip->cdev_flash.name = "flash";
chip->cdev_flash.max_brightness = 16;
chip->cdev_flash.brightness_set = lm355x_strobe_brightness_set;
+ chip->cdev_flash.default_trigger = "flash";
err = led_classdev_register((struct device *)
&client->dev, &chip->cdev_flash);
if (err < 0)
@@ -486,6 +487,7 @@ static int lm355x_probe(struct i2c_client *client,
chip->cdev_torch.name = "torch";
chip->cdev_torch.max_brightness = 8;
chip->cdev_torch.brightness_set = lm355x_torch_brightness_set;
+ chip->cdev_torch.default_trigger = "torch";
err = led_classdev_register((struct device *)
&client->dev, &chip->cdev_torch);
if (err < 0)
diff --git a/drivers/leds/leds-lm3642.c b/drivers/leds/leds-lm3642.c
index 9f428d9..f361bbe 100644
--- a/drivers/leds/leds-lm3642.c
+++ b/drivers/leds/leds-lm3642.c
@@ -363,6 +363,7 @@ static int lm3642_probe(struct i2c_client *client,
chip->cdev_flash.name = "flash";
chip->cdev_flash.max_brightness = 16;
chip->cdev_flash.brightness_set = lm3642_strobe_brightness_set;
+ chip->cdev_flash.default_trigger = "flash";
err = led_classdev_register((struct device *)
&client->dev, &chip->cdev_flash);
if (err < 0) {
@@ -380,6 +381,7 @@ static int lm3642_probe(struct i2c_client *client,
chip->cdev_torch.name = "torch";
chip->cdev_torch.max_brightness = 8;
chip->cdev_torch.brightness_set = lm3642_torch_brightness_set;
+ chip->cdev_torch.default_trigger = "torch";
err = led_classdev_register((struct device *)
&client->dev, &chip->cdev_torch);
if (err < 0) {
--
1.7.9.5
Best Regards,
Milo
--
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 07/11] mfd: menelaus: use devm_request_irq() and devm_kzalloc()
On Wed, Feb 20, 2013 at 05:17:30PM +0900, Jingoo Han wrote:
> On Wednesday, February 20, 2013 5:10 PM, Dmitry Torokhov wrote:
> >
> > On Wed, Feb 20, 2013 at 05:05:10PM +0900, Jingoo Han wrote:
> > > On Wednesday, February 20, 2013 4:31 PM, Dmitry Torokhov wrote:
> > > >
> > > > Hi Jongoo,
> > > >
> > > > On Wed, Feb 20, 2013 at 03:12:38PM +0900, Jingoo Han wrote:
> > > > > Use devm_request_irq() and devm_kzalloc() to make cleanup paths
> > > > > more simple.
> > > > >
> > > >
> > > > ...
> > > >
> > > > > @@ -1269,9 +1266,7 @@ static int __exit menelaus_remove(struct
> > > > > i2c_client *client)
> > > > > {
> > > > > struct menelaus_chip*menelaus = i2c_get_clientdata(client);
> > > > >
> > > > > - free_irq(client->irq, menelaus);
> > > > > flush_work(&menelaus->work);
> > > > > - kfree(menelaus);
> > > > > the_menelaus = NULL;
> > > > > return 0;
> > > >
> > > > This conversion is certainly wrong - you really want to disable IRQ and
> > > > then wait for the scheduled work to finish before freeing memory. Here
> > > > you flush work but nothing stops IRQ from firing and scheduling that
> > > > work again.
> > >
> > > Yes, you're right.
> > > I will use devm_free_irq() before flush_work().
> >
> > Why change it at all if you have to call it manually in both error
> > unwinding and menelaus_remove() cases?
> >
> > BTW, that __exit markup on menelaus_remove() is surprising... I am
> > pretty sure it can be unbound via sysfs and so there will be a nasty
> > oops.
>
> I see, I will not modify this menelaus mfd driver.
> Thank you.
Same goes for the other drivers that can't safely use devm_request_irq()
please.
Thanks.
--
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] leds: add LED Trigger for camera function
Some LED devices support flash/torch functionality through the LED subsystem.
This patch enables direct LED trigger controls by the driver.
Flash on/off and torch on/off can be done simply by other driver space.
Two trigger APIs are added, ledtrig_flash_ctrl() and ledtrig_torch_ctrl().
Signed-off-by: Milo(Woogyom) Kim
---
drivers/leds/trigger/Kconfig |8 +
drivers/leds/trigger/Makefile |1 +
drivers/leds/trigger/ledtrig-camera.c | 57 +
include/linux/leds.h |8 +
4 files changed, 74 insertions(+)
create mode 100644 drivers/leds/trigger/ledtrig-camera.c
diff --git a/drivers/leds/trigger/Kconfig b/drivers/leds/trigger/Kconfig
index eaa286d..49794b4 100644
--- a/drivers/leds/trigger/Kconfig
+++ b/drivers/leds/trigger/Kconfig
@@ -100,4 +100,12 @@ config LEDS_TRIGGER_TRANSIENT
GPIO/PWM based hardware.
If unsure, say Y.
+config LEDS_TRIGGER_CAMERA
+ tristate "LED Camera Flash/Torch Trigger"
+ depends on LEDS_TRIGGERS
+ help
+ This allows LEDs to be controlled as a camera flash/torch device.
+ This enables direct flash/torch on/off by the driver, kernel space.
+ If unsure, say Y.
+
endif # LEDS_TRIGGERS
diff --git a/drivers/leds/trigger/Makefile b/drivers/leds/trigger/Makefile
index 554e46e..1abf48d 100644
--- a/drivers/leds/trigger/Makefile
+++ b/drivers/leds/trigger/Makefile
@@ -7,3 +7,4 @@ obj-$(CONFIG_LEDS_TRIGGER_GPIO) += ledtrig-gpio.o
obj-$(CONFIG_LEDS_TRIGGER_CPU) += ledtrig-cpu.o
obj-$(CONFIG_LEDS_TRIGGER_DEFAULT_ON) += ledtrig-default-on.o
obj-$(CONFIG_LEDS_TRIGGER_TRANSIENT) += ledtrig-transient.o
+obj-$(CONFIG_LEDS_TRIGGER_CAMERA) += ledtrig-camera.o
diff --git a/drivers/leds/trigger/ledtrig-camera.c
b/drivers/leds/trigger/ledtrig-camera.c
new file mode 100644
index 000..9bd73a8
--- /dev/null
+++ b/drivers/leds/trigger/ledtrig-camera.c
@@ -0,0 +1,57 @@
+/*
+ * Camera Flash and Torch On/Off Trigger
+ *
+ * based on ledtrig-ide-disk.c
+ *
+ * Copyright 2013 Texas Instruments
+ *
+ * Author: Milo(Woogyom) Kim
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#include
+#include
+#include
+#include
+
+DEFINE_LED_TRIGGER(ledtrig_flash);
+DEFINE_LED_TRIGGER(ledtrig_torch);
+
+void ledtrig_flash_ctrl(bool on)
+{
+ enum led_brightness brt = on ? LED_FULL : LED_OFF;
+
+ led_trigger_event(ledtrig_flash, brt);
+}
+EXPORT_SYMBOL_GPL(ledtrig_flash_ctrl);
+
+void ledtrig_torch_ctrl(bool on)
+{
+ enum led_brightness brt = on ? LED_FULL : LED_OFF;
+
+ led_trigger_event(ledtrig_torch, brt);
+}
+EXPORT_SYMBOL_GPL(ledtrig_torch_ctrl);
+
+static int __init ledtrig_camera_init(void)
+{
+ led_trigger_register_simple("flash", &ledtrig_flash);
+ led_trigger_register_simple("torch", &ledtrig_torch);
+ return 0;
+}
+module_init(ledtrig_camera_init);
+
+static void __exit ledtrig_camera_exit(void)
+{
+ led_trigger_unregister_simple(ledtrig_torch);
+ led_trigger_unregister_simple(ledtrig_flash);
+}
+module_exit(ledtrig_camera_exit);
+
+MODULE_DESCRIPTION("LED Trigger for Camera Flash/Torch Control");
+MODULE_AUTHOR("Milo Kim");
+MODULE_LICENSE("GPL");
diff --git a/include/linux/leds.h b/include/linux/leds.h
index 0d9b5ee..197ca9e 100644
--- a/include/linux/leds.h
+++ b/include/linux/leds.h
@@ -215,6 +215,14 @@ extern void ledtrig_ide_activity(void);
#define ledtrig_ide_activity() do {} while(0)
#endif
+#if defined(CONFIG_LEDS_TRIGGER_CAMERA) ||
defined(CONFIG_LEDS_TRIGGER_CAMERA_MODULE)
+extern void ledtrig_flash_ctrl(bool on);
+extern void ledtrig_torch_ctrl(bool on);
+#else
+#define ledtrig_flash_ctrl(x) do {} while(0)
+#define ledtrig_torch_ctrl(x) do {} while(0)
+#endif
+
/*
* Generic LED platform data for describing LED names and default triggers.
*/
--
1.7.9.5
Best Regards,
Milo
--
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 17/16] virtio-scsi: use virtqueue_add_sgs for command buffers
Using the new virtqueue_add_sgs function lets us simplify the queueing
path. In particular, all data protected by the tgt_lock is just gone
(multiqueue will find a new use for the lock).
Signed-off-by: Paolo Bonzini
Signed-off-by: Wanlong Gao
---
drivers/scsi/virtio_scsi.c | 93 --
1 file changed, 33 insertions(+), 60 deletions(-)
diff --git a/drivers/scsi/virtio_scsi.c b/drivers/scsi/virtio_scsi.c
index 3449a1f..b002d7b 100644
--- a/drivers/scsi/virtio_scsi.c
+++ b/drivers/scsi/virtio_scsi.c
@@ -59,11 +59,8 @@ struct virtio_scsi_vq {
/* Per-target queue state */
struct virtio_scsi_target_state {
- /* Protects sg. Lock hierarchy is tgt_lock -> vq_lock. */
+ /* Never held at the same time as vq_lock. */
spinlock_t tgt_lock;
-
- /* For sglist construction when adding commands to the virtqueue. */
- struct scatterlist sg[];
};
/* Driver instance state */
@@ -351,75 +348,57 @@ static void virtscsi_event_done(struct virtqueue *vq)
spin_unlock_irqrestore(&vscsi->event_vq.vq_lock, flags);
};
-static void virtscsi_map_sgl(struct scatterlist *sg, unsigned int *p_idx,
-struct scsi_data_buffer *sdb)
-{
- struct sg_table *table = &sdb->table;
- struct scatterlist *sg_elem;
- unsigned int idx = *p_idx;
- int i;
-
- for_each_sg(table->sgl, sg_elem, table->nents, i)
- sg[idx++] = *sg_elem;
-
- *p_idx = idx;
-}
-
/**
- * virtscsi_map_cmd - map a scsi_cmd to a virtqueue scatterlist
- * @vscsi : virtio_scsi state
+ * virtscsi_add_cmd - add a virtio_scsi_cmd to a virtqueue
+ * @vq : the struct virtqueue we're talking about
* @cmd: command structure
- * @out_num: number of read-only elements
- * @in_num : number of write-only elements
* @req_size : size of the request buffer
* @resp_size : size of the response buffer
- *
- * Called with tgt_lock held.
+ * @gfp: flags to use for memory allocations
*/
-static void virtscsi_map_cmd(struct virtio_scsi_target_state *tgt,
-struct virtio_scsi_cmd *cmd,
-unsigned *out_num, unsigned *in_num,
-size_t req_size, size_t resp_size)
+static int virtscsi_add_cmd(struct virtqueue *vq,
+ struct virtio_scsi_cmd *cmd,
+ size_t req_size, size_t resp_size, gfp_t gfp)
{
struct scsi_cmnd *sc = cmd->sc;
- struct scatterlist *sg = tgt->sg;
- unsigned int idx = 0;
+ struct scatterlist *sgs[4], req, resp;
+ struct sg_table *out, *in;
+ unsigned out_num = 0, in_num = 0;
+
+ out = in = NULL;
- /* Request header. */
- sg_set_buf(&sg[idx++], &cmd->req, req_size);
+ if (sc && sc->sc_data_direction != DMA_NONE) {
+ if (sc->sc_data_direction != DMA_FROM_DEVICE)
+ out = &scsi_out(sc)->table;
+ if (sc->sc_data_direction != DMA_TO_DEVICE)
+ in = &scsi_in(sc)->table;
+ }
- /* Data-out buffer. */
- if (sc && sc->sc_data_direction != DMA_FROM_DEVICE)
- virtscsi_map_sgl(sg, &idx, scsi_out(sc));
+ sg_init_one(&req, &cmd->req, req_size);
+ sgs[out_num++] = &req;
- *out_num = idx;
+ if (out)
+ sgs[out_num++] = out->sgl;
- /* Response header. */
- sg_set_buf(&sg[idx++], &cmd->resp, resp_size);
+ sg_init_one(&resp, &cmd->resp, resp_size);
+ sgs[out_num + in_num++] = &resp;
- /* Data-in buffer */
- if (sc && sc->sc_data_direction != DMA_TO_DEVICE)
- virtscsi_map_sgl(sg, &idx, scsi_in(sc));
+ if (in)
+ sgs[out_num + in_num++] = in->sgl;
- *in_num = idx - *out_num;
+ return virtqueue_add_sgs(vq, sgs, out_num, in_num, cmd, gfp);
}
-static int virtscsi_kick_cmd(struct virtio_scsi_target_state *tgt,
-struct virtio_scsi_vq *vq,
+static int virtscsi_kick_cmd(struct virtio_scsi_vq *vq,
struct virtio_scsi_cmd *cmd,
size_t req_size, size_t resp_size, gfp_t gfp)
{
- unsigned int out_num, in_num;
unsigned long flags;
int err;
bool needs_kick = false;
- spin_lock_irqsave(&tgt->tgt_lock, flags);
- virtscsi_map_cmd(tgt, cmd, &out_num, &in_num, req_size, resp_size);
-
- spin_lock(&vq->vq_lock);
- err = virtqueue_add_buf(vq->vq, tgt->sg, out_num, in_num, cmd, gfp);
- spin_unlock(&tgt->tgt_lock);
+ spin_lock_irqsave(&vq->vq_lock, flags);
+ err = virtscsi_add_cmd(vq->vq, cmd, req_size, resp_size, gfp);
if (!err)
needs_kick = virtqueue_kick_prepare(vq->vq);
@@ -433,7 +412,6 @@ static int virtscsi_kick_cmd(struct
virtio_scsi_target_state *tgt,
static int virtscsi_queuecommand(struct Scsi_Ho
Re: prctl(PR_SET_MM)
On Tue, Feb 19, 2013 at 05:25:31PM +1100, Amnon Shiloh wrote: > > To reconstruct Linux process(es), one must be able to restore all their > memory contents, states and registers to their original and consistent > values. I personally don't mind if this come become y by default, because it will work for us. Still I guess if you need to reconstruct Linux process(es) plain prctl extension is not enough, you still need a functionality which is enclosed in config-checkpoint-restore (say /proc/pid/map_files, kcmp), no? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch v5 10/15] sched: packing transitory tasks in wake/exec power balancing
On Wed, 2013-02-20 at 16:11 +0800, Alex Shi wrote: > On 02/20/2013 03:40 PM, Mike Galbraith wrote: > > On Wed, 2013-02-20 at 13:55 +0800, Alex Shi wrote: > > > >> Joonsoo Kim suggests not packing exec task, since the old task utils is > >> possibly unuseable. > > > > (I'm stumbling around in rtmutex PI land, all dazed and confused, so > > forgive me if my peripheral following of this thread is off target;) > > > > Hm, possibly. Future behavior is always undefined, trying to predict > > always a gamble... so it looks to me like not packing on exec places a > > bet against the user, who chose to wager that powersaving will happen > > and it won't cost him too much, if you don't always try to pack despite > > any risks. The user placed a bet on powersaving, not burst performance. > > > > Same for the fork, if you spread to accommodate a potential burst, you > > bin the power wager, so maybe it's not in his best interest.. fork/exec > > is common, if it's happening frequently, you'll bin the potential power > > win frequently, reducing effectiveness, and silently trading power for > > performance when the user asked to trade performance for a lower > > electric bill. > > > > Dunno, just a thought, but I'd say for powersaving policy, you have to > > go just for broke and hope it works out. You can't know it won't, but > > you'll toss potential winnings every time you don't roll the dice. > > > Sounds reasonable too. > > I have no idea of the of the decision now. > And guess many guys dislike to use a knob to let user do the choice. Nobody likes seeing yet more knobs much, automagical is preferred. Trouble with automagical heuristics usage is that any heuristic will inevitably get it wrong sometimes, so giving the user control over usage is IMHO a good thing.. and once we give the user the choice, we must honor it, else what was the point? Anyway, fwiw, I liked what I saw test driving the patch set.. > What's your opinions, Peter? ..but maintainer opinions carry more weight than mine, even to me ;-) -Mike -- 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] hp-wmi: fix handling of platform device
The driver will not quite work if someone unbinds the platform device
from the platform driver via sysfs (moreover it will bomb is the driver
built into the kernel as hp_wmi_bios_remove is marked as __exit and will
not be present in the kernel).
To fix it let's use platform_driver_probe() instead of
platform_driver_register(), which disables binding/unbinding via sysfs.
This also allows us to mark hp_wmi_bios_setup as __init and discard it
once module is initialized.
Signed-off-by: Dmitry Torokhov
---
Compiled only, no hardware to run.
drivers/platform/x86/hp-wmi.c | 69 +++
1 file changed, 30 insertions(+), 39 deletions(-)
diff --git a/drivers/platform/x86/hp-wmi.c b/drivers/platform/x86/hp-wmi.c
index 1dde7ac..de78024 100644
--- a/drivers/platform/x86/hp-wmi.c
+++ b/drivers/platform/x86/hp-wmi.c
@@ -72,10 +72,6 @@ enum hp_wmi_event_ids {
HPWMI_LOCK_SWITCH = 7,
};
-static int hp_wmi_bios_setup(struct platform_device *device);
-static int __exit hp_wmi_bios_remove(struct platform_device *device);
-static int hp_wmi_resume_handler(struct device *device);
-
struct bios_args {
u32 signature;
u32 command;
@@ -157,21 +153,6 @@ struct rfkill2_device {
static int rfkill2_count;
static struct rfkill2_device rfkill2[HPWMI_MAX_RFKILL2_DEVICES];
-static const struct dev_pm_ops hp_wmi_pm_ops = {
- .resume = hp_wmi_resume_handler,
- .restore = hp_wmi_resume_handler,
-};
-
-static struct platform_driver hp_wmi_driver = {
- .driver = {
- .name = "hp-wmi",
- .owner = THIS_MODULE,
- .pm = &hp_wmi_pm_ops,
- },
- .probe = hp_wmi_bios_setup,
- .remove = hp_wmi_bios_remove,
-};
-
/*
* hp_wmi_perform_query
*
@@ -778,7 +759,7 @@ fail:
return err;
}
-static int hp_wmi_bios_setup(struct platform_device *device)
+static int __init hp_wmi_bios_setup(struct platform_device *device)
{
int err;
@@ -874,12 +855,29 @@ static int hp_wmi_resume_handler(struct device *device)
return 0;
}
+static const struct dev_pm_ops hp_wmi_pm_ops = {
+ .resume = hp_wmi_resume_handler,
+ .restore = hp_wmi_resume_handler,
+};
+
+static struct platform_driver hp_wmi_driver = {
+ .driver = {
+ .name = "hp-wmi",
+ .owner = THIS_MODULE,
+ .pm = &hp_wmi_pm_ops,
+ },
+ .remove = __exit_p(hp_wmi_bios_remove),
+};
+
static int __init hp_wmi_init(void)
{
int err;
int event_capable = wmi_has_guid(HPWMI_EVENT_GUID);
int bios_capable = wmi_has_guid(HPWMI_BIOS_GUID);
+ if (!bios_capable && !event_capable)
+ return -ENODEV;
+
if (event_capable) {
err = hp_wmi_input_setup();
if (err)
@@ -887,34 +885,29 @@ static int __init hp_wmi_init(void)
}
if (bios_capable) {
- err = platform_driver_register(&hp_wmi_driver);
- if (err)
- goto err_driver_reg;
- hp_wmi_platform_dev = platform_device_alloc("hp-wmi", -1);
- if (!hp_wmi_platform_dev) {
- err = -ENOMEM;
- goto err_device_alloc;
+ hp_wmi_platform_dev =
+ platform_device_register_simple("hp-wmi", -1, NULL, 0);
+ if (IS_ERR(hp_wmi_platform_dev)) {
+ err = PTR_ERR(hp_wmi_platform_dev);
+ goto err_destroy_input;
}
- err = platform_device_add(hp_wmi_platform_dev);
+
+ err = platform_driver_probe(&hp_wmi_driver, hp_wmi_bios_setup);
if (err)
- goto err_device_add;
+ goto err_unregister_device;
}
- if (!bios_capable && !event_capable)
- return -ENODEV;
-
return 0;
-err_device_add:
- platform_device_put(hp_wmi_platform_dev);
-err_device_alloc:
- platform_driver_unregister(&hp_wmi_driver);
-err_driver_reg:
+err_unregister_device:
+ platform_device_unregister(hp_wmi_platform_dev);
+err_destroy_input:
if (event_capable)
hp_wmi_input_destroy();
return err;
}
+module_init(hp_wmi_init);
static void __exit hp_wmi_exit(void)
{
@@ -926,6 +919,4 @@ static void __exit hp_wmi_exit(void)
platform_driver_unregister(&hp_wmi_driver);
}
}
-
-module_init(hp_wmi_init);
module_exit(hp_wmi_exit);
--
1.7.11.7
--
Dmitry
--
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] Fix rq->lock vs logbuf_lock unlock race
On Mon, 2013-02-18 at 12:53 +, Bu, Yitian wrote:
> This patch is for kernel V3.7.9
>
> From 8796f4a2175a323aaa49ea8dd0fe68678dd5dccd Mon Sep 17 00:00:00 2001
> From: ybu
> Date: Mon, 18 Feb 2013 19:52:01 +0800
> Subject: [PATCH] Fix rq->lock vs logbuf_lock unlock race
>
> fix up the fallout from commit 07354eb1a74d1 ("locking printk:
> Annotate logbuf_lock as raw")
> Release console_sem after unlocking the logbuf_lock avoids some lock
> inversion troubles between logbuf_lock and rq->lock.
Please clarify how and where.. you're not actually supposed to use
printk() while holding rq->lock.
--
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] sched: Skip looking at skip if next or last is set
On Mon, 2013-02-18 at 18:31 +0530, Srikar Dronamraju wrote:
> pick_next_entity() prefers next, then last. However code checks if the
> left entity can be skipped even if next / last is set.
>
> Check if left entity should be skipped only if next/last is not set.
You fail to explain why its a problem and continue to make a horrid mess
of the code..
> Signed-off-by: Srikar Dronamraju
> ---
> kernel/sched/fair.c | 31 +++
> 1 files changed, 15 insertions(+), 16 deletions(-)
>
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index fdee793..cc97b12 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -1900,27 +1900,26 @@ static struct sched_entity *pick_next_entity(struct
> cfs_rq *cfs_rq)
> struct sched_entity *left = se;
>
> /*
> - * Avoid running the skip buddy, if running something else can
> - * be done without getting too unfair.
> + * Someone really wants next to run. If it's not unfair, run it.
>*/
> - if (cfs_rq->skip == se) {
> - struct sched_entity *second = __pick_next_entity(se);
> + if (cfs_rq->next && wakeup_preempt_entity(cfs_rq->next, left) < 1) {
> + se = cfs_rq->next;
> + } else if (cfs_rq->last && wakeup_preempt_entity(cfs_rq->last, left) <
> 1) {
> + /*
> + * Prefer last buddy, try to return the CPU to a preempted
> + * task.
> + */
> + se = cfs_rq->last;
> + } else if (cfs_rq->skip == left) {
> + /*
> + * Avoid running the skip buddy, if running something else
> + * can be done without getting too unfair.
> + */
> + struct sched_entity *second = __pick_next_entity(left);
> if (second && wakeup_preempt_entity(second, left) < 1)
> se = second;
> }
>
> - /*
> - * Prefer last buddy, try to return the CPU to a preempted task.
> - */
> - if (cfs_rq->last && wakeup_preempt_entity(cfs_rq->last, left) < 1)
> - se = cfs_rq->last;
> -
> - /*
> - * Someone really wants this to run. If it's not unfair, run it.
> - */
> - if (cfs_rq->next && wakeup_preempt_entity(cfs_rq->next, left) < 1)
> - se = cfs_rq->next;
> -
> clear_buddies(cfs_rq, se);
>
> return se;
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] rwsem: Implement writer lock-stealing
> > Alex, could you go through my patch and see if there is anything you > find objectionable ? (if not about the details, at least about the > general approach of enabling writer lock stealing on the fast path) > I did a quick review on the patchset and tested the patches 1~3, and 1~3 plus 4th, my patch plus 4th. The patch looks much complicated, and also goes writing slow path to steal locking. My patch looks quite straight and simple. This 1~3 patch has very very similar performance effect with mine. The highlight patch is the 4th, seems it can provide about ~2% aim7 performance gain(base on both of mine or patches 1~3) on my 4S NHM EX machine. -- Thanks Alex -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] I2C: i2c-pxa - remove incorrect __exit annotations
The remove() methods should not be marked __exit unless we are using
platform_driver_probe() which disables unbinding device from driver
via sysfs.
Signed-off-by: Dmitry Torokhov
---
Compiled only, no hardware.
drivers/i2c/busses/i2c-pxa.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-pxa.c b/drivers/i2c/busses/i2c-pxa.c
index 1034d93..4a79e76 100644
--- a/drivers/i2c/busses/i2c-pxa.c
+++ b/drivers/i2c/busses/i2c-pxa.c
@@ -1215,7 +1215,7 @@ emalloc:
return ret;
}
-static int __exit i2c_pxa_remove(struct platform_device *dev)
+static int i2c_pxa_remove(struct platform_device *dev)
{
struct pxa_i2c *i2c = platform_get_drvdata(dev);
@@ -1269,7 +1269,7 @@ static const struct dev_pm_ops i2c_pxa_dev_pm_ops = {
static struct platform_driver i2c_pxa_driver = {
.probe = i2c_pxa_probe,
- .remove = __exit_p(i2c_pxa_remove),
+ .remove = i2c_pxa_remove,
.driver = {
.name = "pxa2xx-i2c",
.owner = THIS_MODULE,
--
1.7.11.7
--
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 06/35] mfd: ab8500-core: Sysfs chip id modification
On 20 February 2013 09:13, Lee Jones wrote:
> On Tue, 19 Feb 2013, Arnd Bergmann wrote:
>
>> On Friday 15 February 2013, Lee Jones wrote:
>> > struct ab8500 *ab8500;
>> > + int chip_id = -EINVAL;
>> >
>> > ab8500 = dev_get_drvdata(dev);
>> > - return sprintf(buf, "%#x\n", ab8500 ? ab8500->chip_id : -EINVAL);
>> > + if(ab8500) {
>> > + chip_id = ab8500->chip_id;
>> > + if((is_ab8505(ab8500) || is_ab9540(ab8500)) &&
>> > ab8500->version != 0xFF)
>> > + chip_id = (ab8500->version << 8) | chip_id;
>> > + }
>> > + return sprintf(buf, "%#x\n", chip_id);
>> > }
>>
>> What's the use of printing "ffea" for unknown versions here?
>
> You mean instead of -EINVAL? No idea, Marcus?
>
Looks like I'm guilty of just making the minimal changes. Arnd is
right though, getting ffea(-EINVAL) back is pretty useless.
I'll have to check user land to see what is using this. Maybe not
printing and returning 0 should be the correct behaviour
when an unknown version is found.
--
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] usb: musb: drop dangling CONFIG_USB_MUSB_DEBUG
CONFIG_USB_MUSB_DEBUG option was removed in
5c8a86e usb: musb: drop unneeded musb_debug trickery
to cleanup the code from driver specific debug facilities. This patch
drops the last references to the musb debug config option,
unconditionally enabling all debug code paths, thus letting that code
being dropped at compile time if not needed.
Signed-off-by: Fabio Baltieri
---
Hello Felipe,
this looks like a leftover from the debug code cleanup. Some code in
cppi_dma was constantly compiled out, and that included some dead
_dbg_level() references. All debug printks are already declared as
pr_debug or dev_dbg so it should be ok to keep the code compiled in.
Compiled tested only.
Fabio
drivers/usb/musb/cppi_dma.c | 17 +++--
1 file changed, 3 insertions(+), 14 deletions(-)
diff --git a/drivers/usb/musb/cppi_dma.c b/drivers/usb/musb/cppi_dma.c
index f522000..9db211e 100644
--- a/drivers/usb/musb/cppi_dma.c
+++ b/drivers/usb/musb/cppi_dma.c
@@ -435,7 +435,6 @@ cppi_rndis_update(struct cppi_channel *c, int is_rx,
}
}
-#ifdef CONFIG_USB_MUSB_DEBUG
static void cppi_dump_rxbd(const char *tag, struct cppi_descriptor *bd)
{
pr_debug("RXBD/%s %08x: "
@@ -444,21 +443,16 @@ static void cppi_dump_rxbd(const char *tag, struct
cppi_descriptor *bd)
bd->hw_next, bd->hw_bufp, bd->hw_off_len,
bd->hw_options);
}
-#endif
static void cppi_dump_rxq(int level, const char *tag, struct cppi_channel *rx)
{
-#ifdef CONFIG_USB_MUSB_DEBUG
struct cppi_descriptor *bd;
- if (!_dbg_level(level))
- return;
cppi_dump_rx(level, rx, tag);
if (rx->last_processed)
cppi_dump_rxbd("last", rx->last_processed);
for (bd = rx->head; bd; bd = bd->next)
cppi_dump_rxbd("active", bd);
-#endif
}
@@ -784,6 +778,7 @@ cppi_next_rx_segment(struct musb *musb, struct cppi_channel
*rx, int onepacket)
void __iomem*tibase = musb->ctrl_base;
int is_rndis = 0;
struct cppi_rx_stateram __iomem *rx_ram = rx->state_ram;
+ struct cppi_descriptor *d;
if (onepacket) {
/* almost every USB driver, host or peripheral side */
@@ -897,14 +892,8 @@ cppi_next_rx_segment(struct musb *musb, struct
cppi_channel *rx, int onepacket)
bd->hw_options |= CPPI_SOP_SET;
tail->hw_options |= CPPI_EOP_SET;
-#ifdef CONFIG_USB_MUSB_DEBUG
- if (_dbg_level(5)) {
- struct cppi_descriptor *d;
-
- for (d = rx->head; d; d = d->next)
- cppi_dump_rxbd("S", d);
- }
-#endif
+ for (d = rx->head; d; d = d->next)
+ cppi_dump_rxbd("S", d);
/* in case the preceding transfer left some state... */
tail = rx->last_processed;
--
1.7.12.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch v5 10/15] sched: packing transitory tasks in wake/exec power balancing
On 02/20/2013 04:43 PM, Mike Galbraith wrote: >> > >> > Sounds reasonable too. >> > >> > I have no idea of the of the decision now. >> > And guess many guys dislike to use a knob to let user do the choice. > Nobody likes seeing yet more knobs much, automagical is preferred. > Trouble with automagical heuristics usage is that any heuristic will > inevitably get it wrong sometimes, so giving the user control over usage > is IMHO a good thing.. and once we give the user the choice, we must > honor it, else what was the point? > > Anyway, fwiw, I liked what I saw test driving the patch set.. > >> > What's your opinions, Peter? > ..but maintainer opinions carry more weight than mine, even to me ;-) :) Yes, maintainers usually heard enough arguments and can balance them... -- Thanks Alex -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] MFD: remove incorrect __exit annotations
Even if bus is not hot-pluggable, the devices can be unbound from the
driver via sysfs, so we should not be using __exit annotations on
remove() methods.
Signed-off-by: Dmitry Torokhov
---
Not tested - no hardware.
drivers/mfd/menelaus.c | 4 ++--
drivers/mfd/tps65010.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/mfd/menelaus.c b/drivers/mfd/menelaus.c
index 998ce8c..fda3211 100644
--- a/drivers/mfd/menelaus.c
+++ b/drivers/mfd/menelaus.c
@@ -1265,7 +1265,7 @@ fail1:
return err;
}
-static int __exit menelaus_remove(struct i2c_client *client)
+static int menelaus_remove(struct i2c_client *client)
{
struct menelaus_chip*menelaus = i2c_get_clientdata(client);
@@ -1287,7 +1287,7 @@ static struct i2c_driver menelaus_i2c_driver = {
.name = DRIVER_NAME,
},
.probe = menelaus_probe,
- .remove = __exit_p(menelaus_remove),
+ .remove = menelaus_remove,
.id_table = menelaus_id,
};
diff --git a/drivers/mfd/tps65010.c b/drivers/mfd/tps65010.c
index da2691f..9030233 100644
--- a/drivers/mfd/tps65010.c
+++ b/drivers/mfd/tps65010.c
@@ -514,7 +514,7 @@ static int tps65010_gpio_get(struct gpio_chip *chip,
unsigned offset)
static struct tps65010 *the_tps;
-static int __exit tps65010_remove(struct i2c_client *client)
+static int tps65010_remove(struct i2c_client *client)
{
struct tps65010 *tps = i2c_get_clientdata(client);
struct tps65010_board *board = client->dev.platform_data;
@@ -687,7 +687,7 @@ static struct i2c_driver tps65010_driver = {
.name = "tps65010",
},
.probe = tps65010_probe,
- .remove = __exit_p(tps65010_remove),
+ .remove = tps65010_remove,
.id_table = tps65010_id,
};
--
1.7.11.7
--
Dmitry
--
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: [GIT PULL] x86/platform changes for v3.9
* Linus Torvalds wrote: > On Tue, Feb 19, 2013 at 7:41 AM, Ingo Molnar wrote: > > > > Please pull the latest x86-platform-for-linus git tree from: > > Hmm. > > My main desktop just had a reboot failure - it just got stuck > at the end, not powering down, and not rebooting like it > should have. > > This is *not* necessarily the pull that caused it, but > 8f55cea410db rebooted cleanly, and 1a13c0b181f2 did not. That > implies that it's one of your pull requests. The pulls I did > in between are: > > - scheduler (with the dyntick and cputime accounting) > > - smp-hotplug-for-linus: stop_machine preparatory patches from Thomas.. > > - timers-core-for-linus. Hmm.. > > - x86-apic-for-linus: certainly possibly causing problems at shutdown.. > > - x86-asm-for-linus: sounds unlikely, but who knows.. > > - x86-boot-for-linus: shouldn't affect shutdown, but.. > > - x86-build-for-linus: _really_ shouldn't affect shutdown.. > > - x86-cleanups-for-linus: unlikely > > - x86-hyperv-for-linus: no, not a hyperv user ;) > > - x86-platform-for-linus: rebooting is a platform thing, but none of > this seems relevant > > - x86-uv-for-linus: not likely relevant. > > I'm not going to bisect it right now, hoping that somebody > goes "Hmm, maybe it's xyzzy". And maybe it was just a one-time > event, but I don't recall having had that whole "reboot fails" > case on this machine before. Any ideas? Hm, no quick ideas. None of those trees had any similar problems during development, so there's no "drat, it must be _that_ tree again" memory. Timers and APIC would be my leading suspect - but scheduler and hotplug changes might be the culprits as well. Yesterday, while preparing the trees I wanted to mention this x86/apic commit: 336224ba5e4f x86, apic: Mask IO-APIC and PIC unconditionally on LAPIC resume ... as a change that needs monitored because it changes the suspend and shutdown sequence but then skipped mentioning it because it seemed relatively old and proven. But there are other potentially dangerous commits as well - I suspect we won't be able to avoid a bisection :-/ Thanks, Ingo -- 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] freezer: configure user space process frozen along with kernel threads
On Wed, Feb 20, 2013 at 10:15:25AM +0800, Li Fei wrote:
>
> +#ifdef CONFIG_FREEZER
> +
> +static ssize_t freeze_late_read(struct file *file, char __user *buf,
> + size_t count, loff_t *ppos)
> +{
> + struct task_struct *task = get_proc_task(file->f_path.dentry->d_inode);
> + char buffer[PROC_NUMBUF];
> + int freeze_late;
> + size_t len;
> + if (!task)
> + return -ESRCH;
> + freeze_late = (task->flags & PF_FREEZER_LATE) ? 1 : 0;
> + len = snprintf(buffer, sizeof(buffer), "%d\n", freeze_late);
> + return simple_read_from_buffer(buf, count, ppos, buffer, len);
> +}
Don't you need put_task_struct() once you grabbed it?
--
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] sched/core: remove obsolete nr_uninterruptible()
On Wed, Feb 20, 2013 at 4:31 PM, Xiaotian Feng wrote:
> On Wed, Feb 20, 2013 at 3:37 PM, Sha Zhengju wrote:
>> From: Sha Zhengju
>>
>> Signed-off-by: Sha Zhengju
>> ---
>> kernel/sched/core.c | 17 -
>> 1 file changed, 17 deletions(-)
>
> You missed include/linux/sched.h :)
O... yeah, another lost... thank you for correcting me! :)
>
>>
>> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
>> index c0b07c3..792f6fc 100644
>> --- a/kernel/sched/core.c
>> +++ b/kernel/sched/core.c
>> @@ -1957,23 +1957,6 @@ unsigned long nr_running(void)
>> return sum;
>> }
>>
>> -unsigned long nr_uninterruptible(void)
>> -{
>> - unsigned long i, sum = 0;
>> -
>> - for_each_possible_cpu(i)
>> - sum += cpu_rq(i)->nr_uninterruptible;
>> -
>> - /*
>> -* Since we read the counters lockless, it might be slightly
>> -* inaccurate. Do not allow it to go below zero though:
>> -*/
>> - if (unlikely((long)sum < 0))
>> - sum = 0;
>> -
>> - return sum;
>> -}
>> -
>> unsigned long long nr_context_switches(void)
>> {
>> int i;
>> --
>> 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/
--
Thanks,
Sha
--
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/3] leds: move LED trigger drivers into new subdirectory
Hello Kim,
On Wed, Feb 20, 2013 at 08:36:01AM +, Kim, Milo wrote:
> For better driver management, new subdirectory, 'trigger' is created.
> All LED trigger drivers are moved into this directory.
>
> Internal header, 'leds.h' is included in each LED trigger drivers.
> Fix the location of header file, "leds.h" -> "../leds.h" in driver files.
> One exception is here, 'ledtrig-timer.c'.
> There is no need to include 'leds.h'. so '#include "leds.h"' line was removed.
>
> Signed-off-by: Milo(Woogyom) Kim
> ---
> drivers/leds/Kconfig | 101 +---
> drivers/leds/Makefile | 10 +-
> drivers/leds/ledtrig-backlight.c | 166 ---
> drivers/leds/ledtrig-cpu.c| 142
> drivers/leds/ledtrig-default-on.c | 45 -
> drivers/leds/ledtrig-gpio.c | 253
> -
> drivers/leds/ledtrig-heartbeat.c | 161 --
> drivers/leds/ledtrig-ide-disk.c | 47 --
> drivers/leds/ledtrig-oneshot.c| 204 ---
> drivers/leds/ledtrig-timer.c | 131 ---
> drivers/leds/ledtrig-transient.c | 237 ---
> drivers/leds/trigger/Kconfig | 103
> drivers/leds/trigger/Makefile |9 +
> drivers/leds/trigger/ledtrig-backlight.c | 166 +++
> drivers/leds/trigger/ledtrig-cpu.c| 142
> drivers/leds/trigger/ledtrig-default-on.c | 45 +
> drivers/leds/trigger/ledtrig-gpio.c | 253
> +
> drivers/leds/trigger/ledtrig-heartbeat.c | 161 ++
> drivers/leds/trigger/ledtrig-ide-disk.c | 47 ++
> drivers/leds/trigger/ledtrig-oneshot.c| 204 +++
> drivers/leds/trigger/ledtrig-timer.c | 130 +++
> drivers/leds/trigger/ledtrig-transient.c | 237 +++
> 22 files changed, 1499 insertions(+), 1495 deletions(-)
> delete mode 100644 drivers/leds/ledtrig-backlight.c
> delete mode 100644 drivers/leds/ledtrig-cpu.c
> delete mode 100644 drivers/leds/ledtrig-default-on.c
> delete mode 100644 drivers/leds/ledtrig-gpio.c
> delete mode 100644 drivers/leds/ledtrig-heartbeat.c
> delete mode 100644 drivers/leds/ledtrig-ide-disk.c
> delete mode 100644 drivers/leds/ledtrig-oneshot.c
> delete mode 100644 drivers/leds/ledtrig-timer.c
> delete mode 100644 drivers/leds/ledtrig-transient.c
> create mode 100644 drivers/leds/trigger/Kconfig
> create mode 100644 drivers/leds/trigger/Makefile
> create mode 100644 drivers/leds/trigger/ledtrig-backlight.c
> create mode 100644 drivers/leds/trigger/ledtrig-cpu.c
> create mode 100644 drivers/leds/trigger/ledtrig-default-on.c
> create mode 100644 drivers/leds/trigger/ledtrig-gpio.c
> create mode 100644 drivers/leds/trigger/ledtrig-heartbeat.c
> create mode 100644 drivers/leds/trigger/ledtrig-ide-disk.c
> create mode 100644 drivers/leds/trigger/ledtrig-oneshot.c
> create mode 100644 drivers/leds/trigger/ledtrig-timer.c
> create mode 100644 drivers/leds/trigger/ledtrig-transient.c
For this kind of patches you should really use the "-M" flag of "git
format-patch" to activate rename detection. The patch becomes much more
readable. For example, the diffstat for this one using -M is:
drivers/leds/Kconfig| 101 +--
drivers/leds/Makefile | 10 +--
drivers/leds/trigger/Kconfig| 103
drivers/leds/trigger/Makefile | 9 +++
drivers/leds/{ => trigger}/ledtrig-backlight.c | 2 +-
drivers/leds/{ => trigger}/ledtrig-cpu.c| 2 +-
drivers/leds/{ => trigger}/ledtrig-default-on.c | 2 +-
drivers/leds/{ => trigger}/ledtrig-gpio.c | 2 +-
drivers/leds/{ => trigger}/ledtrig-heartbeat.c | 2 +-
drivers/leds/{ => trigger}/ledtrig-ide-disk.c | 0
drivers/leds/{ => trigger}/ledtrig-oneshot.c| 2 +-
drivers/leds/{ => trigger}/ledtrig-timer.c | 1 -
drivers/leds/{ => trigger}/ledtrig-transient.c | 2 +-
13 files changed, 121 insertions(+), 117 deletions(-)
create mode 100644 drivers/leds/trigger/Kconfig
create mode 100644 drivers/leds/trigger/Makefile
rename drivers/leds/{ => trigger}/ledtrig-backlight.c (99%)
rename drivers/leds/{ => trigger}/ledtrig-cpu.c (99%)
rename drivers/leds/{ => trigger}/ledtrig-default-on.c (98%)
rename drivers/leds/{ => trigger}/ledtrig-gpio.c (99%)
rename drivers/leds/{ => trigger}/ledtrig-heartbeat.c (99%)
rename drivers/leds/{ => trigger}/ledtrig-ide-disk.c (100%)
rename drivers/leds/{ => trigger}/ledtrig-oneshot.c (99%)
rename drivers/leds/{ => trigger}/ledtrig-timer.c (99%)
rename drivers/leds/{ => trigger}/ledtrig-transient.c (99%)
Fabio
--
Fabio Baltieri
--
To unsubscribe from this list: send the line "unsubscribe
Re: [PATCH LINUX v4] xen: event channel arrays are xen_ulong_t and not unsigned long
On Wed, 2013-02-20 at 03:09 +, Konrad Rzeszutek Wilk wrote:
> On Tue, Feb 19, 2013 at 09:07:27PM -0500, Konrad Rzeszutek Wilk wrote:
> > On Tue, Feb 19, 2013 at 05:29:11PM +, Ian Campbell wrote:
> > > On ARM we want these to be the same size on 32- and 64-bit.
> > >
> > > This is an ABI change on ARM. X86 does not change.
> >
> > Hehe. You didn't test this, did you :-)
> >
> > It hangs bootup on X86.
>
> Ah wait. The version that hangs was the first posted - I hadn't
> tested this one yet. I will wait until later on Wednesday to do that.
I don't know what I tested yesterday but it surely wasn't this patch
because it hangs for me too this morning :-/
Sorry about this, will investigate...
Ian.
>
>
> > >
> > > Signed-off-by: Ian Campbell
> > > Cc: Jan Beulich
> > > Cc: Keir (Xen.org)
> > > Cc: Tim Deegan
> > > Cc: Stefano Stabellini
> > > Cc: linux-arm-ker...@lists.infradead.org
> > > Cc: xen-de...@lists.xen.org
> > > Cc: Konrad Rzeszutek Wilk
> > > ---
> > > Changes since V3
> > > s/read_evtchn_pending_sel/xchg_xen_ulong/ in a comment.
> > > Changes since V2
> > > Add comments about the correct bitops to use, and on the
> > > ordering/barrier
> > > requirements on xchg_xen_ulong.
> > > Changes since V1
> > > use find_first_set not __ffs
> > > fix some more unsigned long -> xen_ulong_t
> > > use more generic xchg_xen_ulong instead of ...read_evtchn...
> > > ---
> > > arch/arm/include/asm/xen/events.h | 22 +++
> > > arch/x86/include/asm/xen/events.h |3 +
> > > drivers/xen/events.c | 113
> > > +
> > > include/xen/interface/xen.h |8 +-
> > > 4 files changed, 94 insertions(+), 52 deletions(-)
> > >
> > > diff --git a/arch/arm/include/asm/xen/events.h
> > > b/arch/arm/include/asm/xen/events.h
> > > index 94b4e90..5c27696 100644
> > > --- a/arch/arm/include/asm/xen/events.h
> > > +++ b/arch/arm/include/asm/xen/events.h
> > > @@ -15,4 +15,26 @@ static inline int xen_irqs_disabled(struct pt_regs
> > > *regs)
> > > return raw_irqs_disabled_flags(regs->ARM_cpsr);
> > > }
> > >
> > > +/*
> > > + * We cannot use xchg because it does not support 8-byte
> > > + * values. However it is safe to use {ldr,dtd}exd directly because all
> > > + * platforms which Xen can run on support those instructions.
> > > + */
> > > +static inline xen_ulong_t xchg_xen_ulong(xen_ulong_t *ptr, xen_ulong_t
> > > val)
> > > +{
> > > + xen_ulong_t oldval;
> > > + unsigned int tmp;
> > > +
> > > + wmb();
> > > + asm volatile("@ xchg_xen_ulong\n"
> > > + "1: ldrexd %0, %H0, [%3]\n"
> > > + " strexd %1, %2, %H2, [%3]\n"
> > > + " teq %1, #0\n"
> > > + " bne 1b"
> > > + : "=&r" (oldval), "=&r" (tmp)
> > > + : "r" (val), "r" (ptr)
> > > + : "memory", "cc");
> > > + return oldval;
> > > +}
> > > +
> > > #endif /* _ASM_ARM_XEN_EVENTS_H */
> > > diff --git a/arch/x86/include/asm/xen/events.h
> > > b/arch/x86/include/asm/xen/events.h
> > > index cc146d5..ca842f2 100644
> > > --- a/arch/x86/include/asm/xen/events.h
> > > +++ b/arch/x86/include/asm/xen/events.h
> > > @@ -16,4 +16,7 @@ static inline int xen_irqs_disabled(struct pt_regs
> > > *regs)
> > > return raw_irqs_disabled_flags(regs->flags);
> > > }
> > >
> > > +/* No need for a barrier -- XCHG is a barrier on x86. */
> > > +#define xchg_xen_ulong(ptr, val) xchg((ptr), (val))
> > > +
> > > #endif /* _ASM_X86_XEN_EVENTS_H */
> > > diff --git a/drivers/xen/events.c b/drivers/xen/events.c
> > > index 0be4df3..b8d84f5 100644
> > > --- a/drivers/xen/events.c
> > > +++ b/drivers/xen/events.c
> > > @@ -80,6 +80,12 @@ enum xen_irq_type {
> > > };
> > >
> > > /*
> > > + * Make a bitmask (i.e. unsigned long *) of a xen_ulong_t
> > > + * array. Primarily to avoid long lines (hence the terse name).
> > > + */
> > > +#define BM(x) (unsigned long *)(x)
> > > +
> > > +/*
> > > * Packed IRQ information:
> > > * type - enum xen_irq_type
> > > * event channel - irq->event channel mapping
> > > @@ -120,7 +126,14 @@ static unsigned long *pirq_eoi_map;
> > > #endif
> > > static bool (*pirq_needs_eoi)(unsigned irq);
> > >
> > > -static DEFINE_PER_CPU(unsigned long [NR_EVENT_CHANNELS/BITS_PER_LONG],
> > > +/*
> > > + * Note sizeof(xen_ulong_t) can be more than sizeof(unsigned long). Be
> > > + * careful to only use bitops which allow for this (e.g test_bit and
> > > + * friends but not __ffs).
> > > + */
> > > +#define BITS_PER_EVTCHN_WORD (sizeof(xen_ulong_t)*8)
> > > +
> > > +static DEFINE_PER_CPU(xen_ulong_t
> > > [NR_EVENT_CHANNELS/BITS_PER_EVTCHN_WORD],
> > > cpu_evtchn_mask);
> > >
> > > /* Xen will never allocate port zero for any purpose. */
> > > @@ -294,9 +307,9 @@ static bool pirq_needs_eoi_flag(unsigned irq)
> > > return info->u.pirq.flags & PIRQ_NEEDS_EOI;
> > > }
> > >
> > > -static inline unsigned long active_evtchns(unsigned int cpu,
> > >
Re: [GIT PULL] x86/platform changes for v3.9
> * Linus Torvalds wrote: > > > My main desktop just had a reboot failure - it just got > > stuck at the end, not powering down, and not rebooting like > > it should have. if it matters: I have test machines of various x86 vintage, most of which test booted these trees before sending, and none had reboot failures: so I'd suspect the hang is either system/driver specific, or somehow .config dependent. I'd be surprised if it was a generic hang. Thanks, Ingo -- 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] sched/core: remove obsolete nr_uninterruptible()
From: Sha Zhengju
Signed-off-by: Sha Zhengju
---
include/linux/sched.h |1 -
kernel/sched/core.c | 22 ++
2 files changed, 2 insertions(+), 21 deletions(-)
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 33cc421..f9ca237d 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -98,7 +98,6 @@ extern int nr_threads;
DECLARE_PER_CPU(unsigned long, process_counts);
extern int nr_processes(void);
extern unsigned long nr_running(void);
-extern unsigned long nr_uninterruptible(void);
extern unsigned long nr_iowait(void);
extern unsigned long nr_iowait_cpu(int cpu);
extern unsigned long this_cpu_load(void);
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 03d7784..b7b03cd 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -1969,11 +1969,10 @@ context_switch(struct rq *rq, struct task_struct *prev,
}
/*
- * nr_running, nr_uninterruptible and nr_context_switches:
+ * nr_running and nr_context_switches:
*
* externally visible scheduler statistics: current number of runnable
- * threads, current number of uninterruptible-sleeping threads, total
- * number of context switches performed since bootup.
+ * threads, total number of context switches performed since bootup.
*/
unsigned long nr_running(void)
{
@@ -1985,23 +1984,6 @@ unsigned long nr_running(void)
return sum;
}
-unsigned long nr_uninterruptible(void)
-{
- unsigned long i, sum = 0;
-
- for_each_possible_cpu(i)
- sum += cpu_rq(i)->nr_uninterruptible;
-
- /*
-* Since we read the counters lockless, it might be slightly
-* inaccurate. Do not allow it to go below zero though:
-*/
- if (unlikely((long)sum < 0))
- sum = 0;
-
- return sum;
-}
-
unsigned long long nr_context_switches(void)
{
int i;
--
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: [GIT PULL] perf fix for v3.9
* Linus Torvalds wrote: > On Tue, Feb 19, 2013 at 6:16 AM, Ingo Molnar wrote: > > > > Please pull the latest perf-urgent-for-linus git tree from: > > > >git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git > > perf-urgent-for-linus > > > >HEAD: e97cbe3edf7d88aad4c21dd3de124d9f9d039881 perf/hwbp: Fix cleanup in > > case of kzalloc() failure > > > > Leftover fix from the v3.8 cycle. > > This was already in the other (big) perf pull, as commit > 02e176af92f3 Oops, sorry - Arnaldo picked up the fix too and I never noticed the overlap. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 02/16] virtio_ring: virtqueue_add_sgs, to add multiple sgs.
On 02/19/2013 03:56 PM, Rusty Russell wrote:
> virtio_scsi can really use this, to avoid the current hack of copying
> the whole sg array. Some other things get slightly neater, too.
>
> Signed-off-by: Rusty Russell
This simpler API makes more sense to me.
Reviewed-by: Asias He
> ---
> drivers/virtio/virtio_ring.c | 144
> ++
> include/linux/virtio.h |7 ++
> 2 files changed, 109 insertions(+), 42 deletions(-)
>
> diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
> index 245177c..27e31d3 100644
> --- a/drivers/virtio/virtio_ring.c
> +++ b/drivers/virtio/virtio_ring.c
> @@ -100,14 +100,16 @@ struct vring_virtqueue
>
> /* Set up an indirect table of descriptors and add it to the queue. */
> static int vring_add_indirect(struct vring_virtqueue *vq,
> - struct scatterlist sg[],
> - unsigned int out,
> - unsigned int in,
> + struct scatterlist *sgs[],
> + unsigned int total_sg,
> + unsigned int out_sgs,
> + unsigned int in_sgs,
> gfp_t gfp)
> {
> struct vring_desc *desc;
> unsigned head;
> - int i;
> + struct scatterlist *sg;
> + int i, n;
>
> /*
>* We require lowmem mappings for the descriptors because
> @@ -116,25 +118,31 @@ static int vring_add_indirect(struct vring_virtqueue
> *vq,
>*/
> gfp &= ~(__GFP_HIGHMEM | __GFP_HIGH);
>
> - desc = kmalloc((out + in) * sizeof(struct vring_desc), gfp);
> + desc = kmalloc(total_sg * sizeof(struct vring_desc), gfp);
> if (!desc)
> return -ENOMEM;
>
> - /* Transfer entries from the sg list into the indirect page */
> - for (i = 0; i < out; i++) {
> - desc[i].flags = VRING_DESC_F_NEXT;
> - desc[i].addr = sg_phys(sg);
> - desc[i].len = sg->length;
> - desc[i].next = i+1;
> - sg++;
> + /* Transfer entries from the sg lists into the indirect page */
> + i = 0;
> + for (n = 0; n < out_sgs; n++) {
> + for (sg = sgs[n]; sg; sg = sg_next(sg)) {
> + desc[i].flags = VRING_DESC_F_NEXT;
> + desc[i].addr = sg_phys(sg);
> + desc[i].len = sg->length;
> + desc[i].next = i+1;
> + i++;
> + }
> }
> - for (; i < (out + in); i++) {
> - desc[i].flags = VRING_DESC_F_NEXT|VRING_DESC_F_WRITE;
> - desc[i].addr = sg_phys(sg);
> - desc[i].len = sg->length;
> - desc[i].next = i+1;
> - sg++;
> + for (; n < (out_sgs + in_sgs); n++) {
> + for (sg = sgs[n]; sg; sg = sg_next(sg)) {
> + desc[i].flags = VRING_DESC_F_NEXT|VRING_DESC_F_WRITE;
> + desc[i].addr = sg_phys(sg);
> + desc[i].len = sg->length;
> + desc[i].next = i+1;
> + i++;
> + }
> }
> + BUG_ON(i != total_sg);
>
> /* Last one doesn't continue. */
> desc[i-1].flags &= ~VRING_DESC_F_NEXT;
> @@ -176,8 +184,48 @@ int virtqueue_add_buf(struct virtqueue *_vq,
> void *data,
> gfp_t gfp)
> {
> + struct scatterlist *sgs[2];
> + unsigned int i;
> +
> + sgs[0] = sg;
> + sgs[1] = sg + out;
> +
> + /* Workaround until callers pass well-formed sgs. */
> + for (i = 0; i < out + in; i++)
> + sg_unmark_end(sg + i);
> +
> + sg_mark_end(sg + out + in - 1);
> + if (out && in)
> + sg_mark_end(sg + out - 1);
> +
> + return virtqueue_add_sgs(_vq, sgs, out ? 1 : 0, in ? 1 : 0, data, gfp);
> +}
> +EXPORT_SYMBOL_GPL(virtqueue_add_buf);
> +
> +/**
> + * virtqueue_add_sgs - expose buffers to other end
> + * @vq: the struct virtqueue we're talking about.
> + * @sgs: array of terminated scatterlists.
> + * @out_num: the number of scatterlists readable by other side
> + * @in_num: the number of scatterlists which are writable (after readable
> ones)
> + * @data: the token identifying the buffer.
> + * @gfp: how to do memory allocations (if necessary).
> + *
> + * Caller must ensure we don't call this with other virtqueue operations
> + * at the same time (except where noted).
> + *
> + * Returns zero or a negative error (ie. ENOSPC, ENOMEM).
> + */
> +int virtqueue_add_sgs(struct virtqueue *_vq,
> + struct scatterlist *sgs[],
> + unsigned int out_sgs,
> + unsigned int in_sgs,
> + void *data,
> + gfp_t gfp)
> +{
> struct vring_virtqueue *vq = to_vvq(_vq);
> - unsigned int i, avail, uninitialized_var(prev);
> + struct scatterlist *sg;
> + unsigned int i, n, avail, uninitialize
Re: [PATCH 04/16] virtio-blk: use virtqueue_start_buf on bio path
On 02/19/2013 03:56 PM, Rusty Russell wrote:
> (This is a respin of Paolo Bonzini's patch, but it calls
> virtqueue_add_sgs() instead of his multi-part API).
>
> Move the creation of the request header and response footer to
> __virtblk_add_req. vbr->sg only contains the data scatterlist,
> the header/footer are added separately using virtqueue_add_sgs().
>
> With this change, virtio-blk (with use_bio) is not relying anymore on
> the virtio functions ignoring the end markers in a scatterlist.
> The next patch will do the same for the other path.
>
> Signed-off-by: Paolo Bonzini
> Signed-off-by: Rusty Russell
(This subject needs to be changed to reflect using of virtqueue_add_sgs)
> ---
> drivers/block/virtio_blk.c | 58
> ++--
> 1 file changed, 29 insertions(+), 29 deletions(-)
>
> diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
> index fd8a689..e27bc6c 100644
> --- a/drivers/block/virtio_blk.c
> +++ b/drivers/block/virtio_blk.c
> @@ -62,6 +62,7 @@ struct virtblk_req
> struct virtio_blk *vblk;
> int flags;
> u8 status;
> + int nents;
> struct scatterlist sg[];
> };
>
> @@ -100,24 +101,36 @@ static inline struct virtblk_req
> *virtblk_alloc_req(struct virtio_blk *vblk,
> return vbr;
> }
>
> -static inline int __virtblk_add_req(struct virtqueue *vq,
> - struct virtblk_req *vbr,
> - unsigned long out,
> - unsigned long in)
> +static int __virtblk_add_req(struct virtqueue *vq,
> + struct virtblk_req *vbr)
> {
> - return virtqueue_add_buf(vq, vbr->sg, out, in, vbr, GFP_ATOMIC);
> + struct scatterlist hdr, tailer, *sgs[3];
'status' might be better than 'tailer'. We are using status in other
places.
> + unsigned int num_out = 0, num_in = 0;
> +
> + sg_init_one(&hdr, &vbr->out_hdr, sizeof(vbr->out_hdr));
> + sgs[num_out++] = &hdr;
> +
> + if (vbr->nents) {
> + if (vbr->out_hdr.type & VIRTIO_BLK_T_OUT)
> + sgs[num_out++] = vbr->sg;
> + else
> + sgs[num_out + num_in++] = vbr->sg;
> + }
> +
> + sg_init_one(&tailer, &vbr->status, sizeof(vbr->status));
> + sgs[num_out + num_in++] = &tailer;
> +
> + return virtqueue_add_sgs(vq, sgs, num_out, num_in, vbr, GFP_ATOMIC);
> }
>
> -static void virtblk_add_req(struct virtblk_req *vbr,
> - unsigned int out, unsigned int in)
> +static void virtblk_add_req(struct virtblk_req *vbr)
> {
> struct virtio_blk *vblk = vbr->vblk;
> DEFINE_WAIT(wait);
> int ret;
>
> spin_lock_irq(vblk->disk->queue->queue_lock);
> - while (unlikely((ret = __virtblk_add_req(vblk->vq, vbr,
> - out, in)) < 0)) {
> + while (unlikely((ret = __virtblk_add_req(vblk->vq, vbr)) < 0)) {
> prepare_to_wait_exclusive(&vblk->queue_wait, &wait,
> TASK_UNINTERRUPTIBLE);
>
> @@ -134,22 +147,18 @@ static void virtblk_add_req(struct virtblk_req *vbr,
>
> static void virtblk_bio_send_flush(struct virtblk_req *vbr)
> {
> - unsigned int out = 0, in = 0;
> -
> vbr->flags |= VBLK_IS_FLUSH;
> vbr->out_hdr.type = VIRTIO_BLK_T_FLUSH;
> vbr->out_hdr.sector = 0;
> vbr->out_hdr.ioprio = 0;
> - sg_set_buf(&vbr->sg[out++], &vbr->out_hdr, sizeof(vbr->out_hdr));
> - sg_set_buf(&vbr->sg[out + in++], &vbr->status, sizeof(vbr->status));
> + vbr->nents = 0;
>
> - virtblk_add_req(vbr, out, in);
> + virtblk_add_req(vbr);
> }
>
> static void virtblk_bio_send_data(struct virtblk_req *vbr)
> {
> struct virtio_blk *vblk = vbr->vblk;
> - unsigned int num, out = 0, in = 0;
> struct bio *bio = vbr->bio;
>
> vbr->flags &= ~VBLK_IS_FLUSH;
> @@ -157,24 +166,15 @@ static void virtblk_bio_send_data(struct virtblk_req
> *vbr)
> vbr->out_hdr.sector = bio->bi_sector;
> vbr->out_hdr.ioprio = bio_prio(bio);
>
> - sg_set_buf(&vbr->sg[out++], &vbr->out_hdr, sizeof(vbr->out_hdr));
> -
> - num = blk_bio_map_sg(vblk->disk->queue, bio, vbr->sg + out);
> -
> - sg_set_buf(&vbr->sg[num + out + in++], &vbr->status,
> -sizeof(vbr->status));
> -
> - if (num) {
> - if (bio->bi_rw & REQ_WRITE) {
> + vbr->nents = blk_bio_map_sg(vblk->disk->queue, bio, vbr->sg);
> + if (vbr->nents) {
> + if (bio->bi_rw & REQ_WRITE)
> vbr->out_hdr.type |= VIRTIO_BLK_T_OUT;
> - out += num;
> - } else {
> + else
> vbr->out_hdr.type |= VIRTIO_BLK_T_IN;
> - in += num;
> - }
> }
>
> - virtblk_add_req(vbr, out, in);
> + virtblk_add_req(vbr);
> }
>
> static void virtblk_bio_send_data_work(struct work_struct *work)
>
Reviewed
[PATCH v2 -tip] sched/rt: Fix locality of threaded interrupt handlers
When a interrupt affinity mask targets multiple CPUs, the
RT scheduler selects a runqueue for RT task corresponding
to a threaded interrupt handler without consideration of
where the interrupt is actually gets delivered. It leads
to a suboptimal condition when a hardware interrupt handler
executes on one CPU while the threaded interrupt handler
executes on another CPU.
This fix alters the behaviour of threaded handler wake-ups
by getting priority to a CPU where the hardware interrupt
handler is executing. As result, most of the time both
halves of interrupt handling are kept local.
Signed-off-by: Alexander Gordeev
---
include/linux/sched.h |2 ++
kernel/irq/handle.c |2 +-
kernel/sched/core.c |5 +
kernel/sched/rt.c | 27 +++
4 files changed, 27 insertions(+), 9 deletions(-)
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 206bb08..1d59efa 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1061,6 +1061,7 @@ struct sched_domain;
#define WF_SYNC0x01/* waker goes to sleep after
wakup */
#define WF_FORK0x02/* child wakeup after fork */
#define WF_MIGRATED0x04/* internal use, task got migrated */
+#define WF_LOCAL 0x08/* try to wake up locally */
#define ENQUEUE_WAKEUP 1
#define ENQUEUE_HEAD 2
@@ -2207,6 +2208,7 @@ extern void xtime_update(unsigned long ticks);
extern int wake_up_state(struct task_struct *tsk, unsigned int state);
extern int wake_up_process(struct task_struct *tsk);
+extern int wake_up_local(struct task_struct *tsk);
extern void wake_up_new_task(struct task_struct *tsk);
#ifdef CONFIG_SMP
extern void kick_process(struct task_struct *tsk);
diff --git a/kernel/irq/handle.c b/kernel/irq/handle.c
index 131ca17..fe97d0c 100644
--- a/kernel/irq/handle.c
+++ b/kernel/irq/handle.c
@@ -126,7 +126,7 @@ static void irq_wake_thread(struct irq_desc *desc, struct
irqaction *action)
*/
atomic_inc(&desc->threads_active);
- wake_up_process(action->thread);
+ wake_up_local(action->thread);
}
irqreturn_t
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 257002c..38413f6 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -1527,6 +1527,11 @@ int wake_up_process(struct task_struct *p)
}
EXPORT_SYMBOL(wake_up_process);
+int wake_up_local(struct task_struct *p)
+{
+ return try_to_wake_up(p, TASK_ALL, WF_LOCAL);
+}
+
int wake_up_state(struct task_struct *p, unsigned int state)
{
return try_to_wake_up(p, state, 0);
diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c
index 418feb0..de16e16 100644
--- a/kernel/sched/rt.c
+++ b/kernel/sched/rt.c
@@ -1234,7 +1234,7 @@ static void yield_task_rt(struct rq *rq)
}
#ifdef CONFIG_SMP
-static int find_lowest_rq(struct task_struct *task);
+static int find_lowest_rq(struct task_struct *task, bool prefer_this_cpu);
static int
select_task_rq_rt(struct task_struct *p, int sd_flag, int flags)
@@ -1242,6 +1242,7 @@ select_task_rq_rt(struct task_struct *p, int sd_flag, int
flags)
struct task_struct *curr;
struct rq *rq;
int cpu;
+ bool prefer_this_cpu = flags & WF_LOCAL;
cpu = task_cpu(p);
@@ -1258,6 +1259,11 @@ select_task_rq_rt(struct task_struct *p, int sd_flag,
int flags)
curr = ACCESS_ONCE(rq->curr); /* unlocked access */
/*
+* If this RT task is a threaded interrupt handler, then
+* it is being awaken from the hardware interrupt handler.
+* In this case try to keep hardware and threaded interrupt
+* handlers as close as possible and wake it up on this CPU.
+*
* If the current task on @p's runqueue is an RT task, then
* try to see if we can wake this RT task up on another
* runqueue. Otherwise simply start this RT task
@@ -1279,11 +1285,12 @@ select_task_rq_rt(struct task_struct *p, int sd_flag,
int flags)
* This test is optimistic, if we get it wrong the load-balancer
* will have to sort it out.
*/
- if (curr && unlikely(rt_task(curr)) &&
- (curr->nr_cpus_allowed < 2 ||
-curr->prio <= p->prio) &&
- (p->nr_cpus_allowed > 1)) {
- int target = find_lowest_rq(p);
+ if (prefer_this_cpu ||
+ (curr && unlikely(rt_task(curr)) &&
+(curr->nr_cpus_allowed < 2 ||
+ curr->prio <= p->prio) &&
+(p->nr_cpus_allowed > 1))) {
+ int target = find_lowest_rq(p, prefer_this_cpu);
if (target != -1)
cpu = target;
@@ -1473,7 +1480,7 @@ next_idx:
static DEFINE_PER_CPU(cpumask_var_t, local_cpu_mask);
-static int find_lowest_rq(struct task_struct *task)
+static int find_lowest_rq(struct task_struct *task, bool prefer_this_cpu)
{
struct sched_domain *sd;
struct cpumask *lowest_mask = __ge
Re: [PATCH 05/16] virtio-blk: use virtqueue_add_sgs on req path
On 02/19/2013 03:56 PM, Rusty Russell wrote:
> From: Paolo Bonzini
>
> (This is a respin of Paolo Bonzini's patch, but it calls
> virtqueue_add_sgs() instead of his multi-part API).
>
> This is similar to the previous patch, but a bit more radical
> because the bio and req paths now share the buffer construction
> code. Because the req path doesn't use vbr->sg, however, we
> need to add a couple of arguments to __virtblk_add_req.
>
> We also need to teach __virtblk_add_req how to build SCSI command
> requests.
>
> Signed-off-by: Paolo Bonzini
> Signed-off-by: Rusty Russell
Reviewed-by: Asias He
> ---
> drivers/block/virtio_blk.c | 69
> +---
> 1 file changed, 33 insertions(+), 36 deletions(-)
>
> diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
> index e27bc6c..523a70f 100644
> --- a/drivers/block/virtio_blk.c
> +++ b/drivers/block/virtio_blk.c
> @@ -102,19 +102,40 @@ static inline struct virtblk_req
> *virtblk_alloc_req(struct virtio_blk *vblk,
> }
>
> static int __virtblk_add_req(struct virtqueue *vq,
> - struct virtblk_req *vbr)
> + struct virtblk_req *vbr,
> + struct scatterlist *data_sg,
> + unsigned data_nents)
> {
> - struct scatterlist hdr, tailer, *sgs[3];
> + struct scatterlist hdr, tailer, cmd, sense, inhdr, *sgs[6];
> unsigned int num_out = 0, num_in = 0;
> + int type = vbr->out_hdr.type & ~VIRTIO_BLK_T_OUT;
>
> sg_init_one(&hdr, &vbr->out_hdr, sizeof(vbr->out_hdr));
> sgs[num_out++] = &hdr;
>
> - if (vbr->nents) {
> + /*
> + * If this is a packet command we need a couple of additional headers.
> + * Behind the normal outhdr we put a segment with the scsi command
> + * block, and before the normal inhdr we put the sense data and the
> + * inhdr with additional status information.
> + */
> + if (type == VIRTIO_BLK_T_SCSI_CMD) {
> + sg_init_one(&cmd, vbr->req->cmd, vbr->req->cmd_len);
> + sgs[num_out++] = &cmd;
> + }
> +
> + if (data_nents) {
> if (vbr->out_hdr.type & VIRTIO_BLK_T_OUT)
> - sgs[num_out++] = vbr->sg;
> + sgs[num_out++] = data_sg;
> else
> - sgs[num_out + num_in++] = vbr->sg;
> + sgs[num_out + num_in++] = data_sg;
> + }
> +
> + if (type == VIRTIO_BLK_T_SCSI_CMD) {
> + sg_init_one(&sense, vbr->req->sense, SCSI_SENSE_BUFFERSIZE);
> + sgs[num_out + num_in++] = &sense;
> + sg_init_one(&inhdr, &vbr->in_hdr, sizeof(vbr->in_hdr));
> + sgs[num_out + num_in++] = &inhdr;
> }
>
> sg_init_one(&tailer, &vbr->status, sizeof(vbr->status));
> @@ -130,7 +151,8 @@ static void virtblk_add_req(struct virtblk_req *vbr)
> int ret;
>
> spin_lock_irq(vblk->disk->queue->queue_lock);
> - while (unlikely((ret = __virtblk_add_req(vblk->vq, vbr)) < 0)) {
> + while (unlikely((ret = __virtblk_add_req(vblk->vq, vbr, vbr->sg,
> + vbr->nents)) < 0)) {
> prepare_to_wait_exclusive(&vblk->queue_wait, &wait,
> TASK_UNINTERRUPTIBLE);
>
> @@ -283,7 +305,7 @@ static void virtblk_done(struct virtqueue *vq)
> static bool do_req(struct request_queue *q, struct virtio_blk *vblk,
> struct request *req)
> {
> - unsigned long num, out = 0, in = 0;
> + unsigned int num;
> struct virtblk_req *vbr;
>
> vbr = virtblk_alloc_req(vblk, GFP_ATOMIC);
> @@ -320,40 +342,15 @@ static bool do_req(struct request_queue *q, struct
> virtio_blk *vblk,
> }
> }
>
> - sg_set_buf(&vblk->sg[out++], &vbr->out_hdr, sizeof(vbr->out_hdr));
> -
> - /*
> - * If this is a packet command we need a couple of additional headers.
> - * Behind the normal outhdr we put a segment with the scsi command
> - * block, and before the normal inhdr we put the sense data and the
> - * inhdr with additional status information before the normal inhdr.
> - */
> - if (vbr->req->cmd_type == REQ_TYPE_BLOCK_PC)
> - sg_set_buf(&vblk->sg[out++], vbr->req->cmd, vbr->req->cmd_len);
> -
> - num = blk_rq_map_sg(q, vbr->req, vblk->sg + out);
> -
> - if (vbr->req->cmd_type == REQ_TYPE_BLOCK_PC) {
> - sg_set_buf(&vblk->sg[num + out + in++], vbr->req->sense,
> SCSI_SENSE_BUFFERSIZE);
> - sg_set_buf(&vblk->sg[num + out + in++], &vbr->in_hdr,
> -sizeof(vbr->in_hdr));
> - }
> -
> - sg_set_buf(&vblk->sg[num + out + in++], &vbr->status,
> -sizeof(vbr->status));
> -
> + num = blk_rq_map_sg(q, vbr->req, vblk->sg);
> if (num) {
> - if (rq_data_dir(vbr->req) == WRITE) {
> + if (rq_data_dir(vbr->req
Re: [PATCH 06/16] virtio_blk: remove nents member.
On 02/19/2013 03:56 PM, Rusty Russell wrote:
> It's simply a flag as to whether we have data now, so make it an
> explicit function parameter rather than a member of struct
> virtblk_req.
>
> Signed-off-by: Rusty Russell
Reviewed-by: Asias He
> ---
> drivers/block/virtio_blk.c | 22 +++---
> 1 file changed, 11 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
> index 523a70f..6369cb9 100644
> --- a/drivers/block/virtio_blk.c
> +++ b/drivers/block/virtio_blk.c
> @@ -62,7 +62,6 @@ struct virtblk_req
> struct virtio_blk *vblk;
> int flags;
> u8 status;
> - int nents;
> struct scatterlist sg[];
> };
>
> @@ -104,7 +103,7 @@ static inline struct virtblk_req
> *virtblk_alloc_req(struct virtio_blk *vblk,
> static int __virtblk_add_req(struct virtqueue *vq,
>struct virtblk_req *vbr,
>struct scatterlist *data_sg,
> - unsigned data_nents)
> + bool have_data)
> {
> struct scatterlist hdr, tailer, cmd, sense, inhdr, *sgs[6];
> unsigned int num_out = 0, num_in = 0;
> @@ -124,7 +123,7 @@ static int __virtblk_add_req(struct virtqueue *vq,
> sgs[num_out++] = &cmd;
> }
>
> - if (data_nents) {
> + if (have_data) {
> if (vbr->out_hdr.type & VIRTIO_BLK_T_OUT)
> sgs[num_out++] = data_sg;
> else
> @@ -144,7 +143,7 @@ static int __virtblk_add_req(struct virtqueue *vq,
> return virtqueue_add_sgs(vq, sgs, num_out, num_in, vbr, GFP_ATOMIC);
> }
>
> -static void virtblk_add_req(struct virtblk_req *vbr)
> +static void virtblk_add_req(struct virtblk_req *vbr, bool have_data)
> {
> struct virtio_blk *vblk = vbr->vblk;
> DEFINE_WAIT(wait);
> @@ -152,7 +151,7 @@ static void virtblk_add_req(struct virtblk_req *vbr)
>
> spin_lock_irq(vblk->disk->queue->queue_lock);
> while (unlikely((ret = __virtblk_add_req(vblk->vq, vbr, vbr->sg,
> - vbr->nents)) < 0)) {
> + have_data)) < 0)) {
> prepare_to_wait_exclusive(&vblk->queue_wait, &wait,
> TASK_UNINTERRUPTIBLE);
>
> @@ -173,30 +172,31 @@ static void virtblk_bio_send_flush(struct virtblk_req
> *vbr)
> vbr->out_hdr.type = VIRTIO_BLK_T_FLUSH;
> vbr->out_hdr.sector = 0;
> vbr->out_hdr.ioprio = 0;
> - vbr->nents = 0;
>
> - virtblk_add_req(vbr);
> + virtblk_add_req(vbr, false);
> }
>
> static void virtblk_bio_send_data(struct virtblk_req *vbr)
> {
> struct virtio_blk *vblk = vbr->vblk;
> struct bio *bio = vbr->bio;
> + bool have_data;
>
> vbr->flags &= ~VBLK_IS_FLUSH;
> vbr->out_hdr.type = 0;
> vbr->out_hdr.sector = bio->bi_sector;
> vbr->out_hdr.ioprio = bio_prio(bio);
>
> - vbr->nents = blk_bio_map_sg(vblk->disk->queue, bio, vbr->sg);
> - if (vbr->nents) {
> + if (blk_bio_map_sg(vblk->disk->queue, bio, vbr->sg)) {
> + have_data = true;
> if (bio->bi_rw & REQ_WRITE)
> vbr->out_hdr.type |= VIRTIO_BLK_T_OUT;
> else
> vbr->out_hdr.type |= VIRTIO_BLK_T_IN;
> - }
> + } else
> + have_data = false;
>
> - virtblk_add_req(vbr);
> + virtblk_add_req(vbr, have_data);
> }
>
> static void virtblk_bio_send_data_work(struct work_struct *work)
>
--
Asias
--
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/5] HID: LG: Add support for Logitech Momo Force (Red) Wheel
On Tue, 19 Feb 2013, Simon Wood wrote: > This patch provides a modified report descriptor to split accelerator > and brake, and adds the 'NO_GET' flag to prevent it hanging on > connection. Applied, thanks Simon. -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Xen-devel] [PATCH] xen: netback: remove redundant xenvif_put
On Tue, 2013-02-19 at 18:06 +, David Miller wrote: > From: Ian Campbell > Date: Tue, 19 Feb 2013 08:58:44 + > > > On Tue, 2013-02-19 at 08:03 +, Jan Beulich wrote: > >> >>> On 19.02.13 at 06:53, David Miller wrote: > >> > From: Andrew Jones > >> > Date: Mon, 18 Feb 2013 21:29:20 +0100 > >> > > >> >> netbk_fatal_tx_err() calls xenvif_carrier_off(), which does > >> >> a xenvif_put(). As callers of netbk_fatal_tx_err should only > >> >> have one reference to the vif at this time, then the xenvif_put > >> >> in netbk_fatal_tx_err is one too many. > >> >> > >> >> Signed-off-by: Andrew Jones > >> > > >> > Applied. > >> > >> But this is wrong from all we can tell, > > > > Yes, please can this be reverted. > > Done and I've annotated the revert commit message with as much > information as possible. Thanks, 629821d9b looks good to me. May be worth considering the patch in <1361281636.1051.100.ca...@zakaz.uk.xensource.com> if we get many more of these queries... Ian. -- 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: Debugging system freezes on filesystem writes
On 05.12.2012 17:32, Jan Kara wrote: On Tue 27-11-12 18:14:42, Marcus Sundman wrote: On 22.11.2012 01:30, Jan Kara wrote: On Fri 16-11-12 03:11:22, Marcus Sundman wrote: On 13.11.2012 15:51, Jan Kara wrote: On Fri 09-11-12 15:12:43, Marcus Sundman wrote: On 09.11.2012 01:41, Marcus Sundman wrote: On 07.11.2012 18:17, Jan Kara wrote: On Fri 02-11-12 04:19:24, Marcus Sundman wrote: Also, and this might be important, according to iotop there is almost no disk writing going on during the freeze. (Occasionally there are a few MB/s, but mostly it's 0-200 kB/s.) Well, at least when an iotop running on nice -20 hasn't frozen completely, which it does during the more severe freezes. OK, it seems as if your machine has some problems with memory allocations. Can you capture /proc/vmstat before the freeze and after the freeze and send them for comparison. Maybe it will show us what is the system doing. t=01:06 http://sundman.iki.fi/vmstat.pre-freeze.txt t=01:08 http://sundman.iki.fi/vmstat.during-freeze.txt t=01:12 http://sundman.iki.fi/vmstat.post-freeze.txt Here are some more vmstats: http://sundman.iki.fi/vmstats.tar.gz They are from running this: while true; do cat /proc/vmstat > "vmstat.$(date +%FT%X).txt"; sleep 10; done There were lots and lots of freezes for almost 20 mins from 14:37:45 onwards, pretty much constantly, but at 14:56:50 the freezes suddenly stopped and everything went back to how it should be. I was looking into the data but they didn't show anything problematic. The machine seems to be writing a lot but there's always some free memory, even direct reclaim isn't ever entered. Hum, actually you wrote iotop isn't showing much IO going on but vmstats show there is about 1 GB written during the freeze. It is not a huge amount given the time span but it certainly gives a few MB/s of write load. I didn't watch iotop during this particular freeze. I'll try to keep an eye on iotop in the future. Is there some particular options I should run iotop with, or is a "nice -n -20 iotop -od3" fine? I'm not really familiar with iotop :). Usually I use iostat... OK, which options for iostat should I use then? :) I'm back from vacation. Sorry for the delay. You can use iostat -x 1 Just when you got back I started my pre-vacation work stress and am now ending my post-vacation work-stress.. :) That iostat -x 1 shows %util as 100 and w_await at 2,000 - 70,000.. like so: avg-cpu: %user %nice %system %iowait %steal %idle 9.050.001.51 66.330.00 23.12 Device: rrqm/s wrqm/s r/s w/srkB/swkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util sda 0.00 0.000.001.00 0.00 184.00 368.00 137.08 62199.000.00 62199.00 1000.00 100.00 There's surprisingly high number of allocations going on but that may be due to the IO activity. So let's try something else: Can you switch to console and when the hang happens press Alt-Sysrq-w (or you can just do "echo w >/proc/sysrq-trigger" if the machine is live enough to do that). Then send me the output from dmesg. Thanks! Sure! Here are two: http://sundman.iki.fi/dmesg-1.txt http://sundman.iki.fi/dmesg-2.txt Thanks for those and sorry for the delay (I was busy with other stuff). I had a look into those traces and I have to say I'm not much wiser. In the first dump there is just kswapd waiting for IO. In the second dump there are more processes waiting for IO (mostly for reads - nautilus, thunderbird, opera, ...) but nothing really surprising. So I'm lost what could cause the hangs you observe. Yes, mostly it's difficult to trigger the sysrq thingy, because by the time I manage to switch to the console or running that echo to proc in a terminal the worst is already over. I see. Maybe you could have something like while true; do echo w >/proc/sysrq-trigger; sleep 10; done running in the background? Sure, but I suspect it'll take until the worst is over before it manages to load and execute that "echo w". Recalling you wrote even simple programs like top hang, maybe it is some CPU scheduling issue? Can you boot with noautogroup kernel option? Sure. I've been running with noautogroup for almost a week now, but no big change one way or the other. (E.g., it's still impossible to listen to music, because the songs will start skipping/looping several times during each song even if there isn't any big "hang" happening. And uncompressing a 100 MB archive (with nice '19' and ionice 'idle') is still, after a while, followed by a couple of minutes of superhigh I/O wait causing everything to become really slow.) Hum, I'm starting to wander what's so special about your system that you see these hangs while noone else seems to be hitting them. Your kernel is a standard one from Ubuntu so tons of people run it. Your HW doesn't seem to be too special either. BTW the fact that you ionice 'tar' doesn't change anything because all the writes ar
Re: Linux ACPI DSDT table editing tools
On Wed, Feb 20, 2013 at 07:36:32AM +, Pallala, Ramakrishna wrote: > I am looking for tools(Linux or w*s) for editing ACPI tables. > Can you advise me some good tools. Also I would like to know how BIOS > engineers populate the ACPI tables? Which tools they use? Dunno about the BIOS engineers but I use tools from acpica (acpica.org). There is ASL (dis)assembler and other useful tools in that. In addition there is tools/power/acpi/acpidump.c in the kernel source tree which is extremely useful. -- 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 V2 1/9] mfd: 88pm860x: drop devm_kfree of devm_kzalloc'd data
devm_kfree() allocates memory that is released when a driver detaches.
Thus, there is no reason to explicitly call devm_kfree() in probe or remove
functions.
Signed-off-by: Jingoo Han
---
No changes since v1:
drivers/mfd/88pm860x-core.c | 12 +++-
1 files changed, 3 insertions(+), 9 deletions(-)
diff --git a/drivers/mfd/88pm860x-core.c b/drivers/mfd/88pm860x-core.c
index 893fc1b..31ca555 100644
--- a/drivers/mfd/88pm860x-core.c
+++ b/drivers/mfd/88pm860x-core.c
@@ -1144,17 +1144,15 @@ static int pm860x_probe(struct i2c_client *client,
return -ENOMEM;
ret = pm860x_dt_init(node, &client->dev, pdata);
if (ret)
- goto err;
+ return ret;
} else if (!pdata) {
pr_info("No platform data in %s!\n", __func__);
return -EINVAL;
}
chip = kzalloc(sizeof(struct pm860x_chip), GFP_KERNEL);
- if (chip == NULL) {
- ret = -ENOMEM;
- goto err;
- }
+ if (chip == NULL)
+ return -ENOMEM;
chip->id = verify_addr(client);
chip->regmap = regmap_init_i2c(client, &pm860x_regmap_config);
@@ -1194,10 +1192,6 @@ static int pm860x_probe(struct i2c_client *client,
pm860x_device_init(chip, pdata);
return 0;
-err:
- if (node)
- devm_kfree(&client->dev, pdata);
- return ret;
}
static int pm860x_remove(struct i2c_client *client)
--
1.7.2.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 V2 2/9] mfd: lm3533: use devm_gpio_request_one()
Use devm_gpio_request_one() to make cleanup paths more simple.
Signed-off-by: Jingoo Han
---
No changes since v1:
drivers/mfd/lm3533-core.c |8 ++--
1 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/mfd/lm3533-core.c b/drivers/mfd/lm3533-core.c
index ceebf2c..4b7e6da 100644
--- a/drivers/mfd/lm3533-core.c
+++ b/drivers/mfd/lm3533-core.c
@@ -496,8 +496,8 @@ static int lm3533_device_init(struct lm3533 *lm3533)
dev_set_drvdata(lm3533->dev, lm3533);
if (gpio_is_valid(lm3533->gpio_hwen)) {
- ret = gpio_request_one(lm3533->gpio_hwen, GPIOF_OUT_INIT_LOW,
- "lm3533-hwen");
+ ret = devm_gpio_request_one(lm3533->dev, lm3533->gpio_hwen,
+ GPIOF_OUT_INIT_LOW, "lm3533-hwen");
if (ret < 0) {
dev_err(lm3533->dev,
"failed to request HWEN GPIO %d\n",
@@ -528,8 +528,6 @@ err_unregister:
mfd_remove_devices(lm3533->dev);
err_disable:
lm3533_disable(lm3533);
- if (gpio_is_valid(lm3533->gpio_hwen))
- gpio_free(lm3533->gpio_hwen);
return ret;
}
@@ -542,8 +540,6 @@ static void lm3533_device_exit(struct lm3533 *lm3533)
mfd_remove_devices(lm3533->dev);
lm3533_disable(lm3533);
- if (gpio_is_valid(lm3533->gpio_hwen))
- gpio_free(lm3533->gpio_hwen);
}
static bool lm3533_readable_register(struct device *dev, unsigned int reg)
--
1.7.2.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 V2 3/9] mfd: intel_msic: use devm_gpio_request_one()
Use devm_gpio_request_one() to make cleanup paths more simple.
Signed-off-by: Jingoo Han
---
No changes since v1:
drivers/mfd/intel_msic.c | 10 ++
1 files changed, 2 insertions(+), 8 deletions(-)
diff --git a/drivers/mfd/intel_msic.c b/drivers/mfd/intel_msic.c
index 1804331..5be3b5e 100644
--- a/drivers/mfd/intel_msic.c
+++ b/drivers/mfd/intel_msic.c
@@ -323,7 +323,8 @@ static int intel_msic_init_devices(struct intel_msic *msic)
if (pdata->ocd) {
unsigned gpio = pdata->ocd->gpio;
- ret = gpio_request_one(gpio, GPIOF_IN, "ocd_gpio");
+ ret = devm_gpio_request_one(&pdev->dev, gpio,
+ GPIOF_IN, "ocd_gpio");
if (ret) {
dev_err(&pdev->dev, "failed to register OCD GPIO\n");
return ret;
@@ -332,7 +333,6 @@ static int intel_msic_init_devices(struct intel_msic *msic)
ret = gpio_to_irq(gpio);
if (ret < 0) {
dev_err(&pdev->dev, "no IRQ number for OCD GPIO\n");
- gpio_free(gpio);
return ret;
}
@@ -359,8 +359,6 @@ static int intel_msic_init_devices(struct intel_msic *msic)
fail:
mfd_remove_devices(&pdev->dev);
- if (pdata->ocd)
- gpio_free(pdata->ocd->gpio);
return ret;
}
@@ -368,12 +366,8 @@ fail:
static void intel_msic_remove_devices(struct intel_msic *msic)
{
struct platform_device *pdev = msic->pdev;
- struct intel_msic_platform_data *pdata = pdev->dev.platform_data;
mfd_remove_devices(&pdev->dev);
-
- if (pdata->ocd)
- gpio_free(pdata->ocd->gpio);
}
static int intel_msic_probe(struct platform_device *pdev)
--
1.7.2.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 1/3] leds: move LED trigger drivers into new subdirectory
> For this kind of patches you should really use the "-M" flag of "git > format-patch" to activate rename detection. The patch becomes much > more > readable. For example, the diffstat for this one using -M is: Thanks for useful tip! Regards, Milo -- 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 V2 4/9] mfd: omap-usb-host: use devm_gpio_request_one()
Use devm_gpio_request_one() to make cleanup paths more simple.
Signed-off-by: Jingoo Han
---
No changes since v1:
drivers/mfd/omap-usb-host.c | 23 ++-
1 files changed, 2 insertions(+), 21 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 6b5edf6..2104d66 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -437,11 +437,11 @@ static void omap_usbhs_init(struct device *dev)
if (pdata->phy_reset) {
if (gpio_is_valid(pdata->reset_gpio_port[0]))
- gpio_request_one(pdata->reset_gpio_port[0],
+ devm_gpio_request_one(dev, pdata->reset_gpio_port[0],
GPIOF_OUT_INIT_LOW, "USB1 PHY reset");
if (gpio_is_valid(pdata->reset_gpio_port[1]))
- gpio_request_one(pdata->reset_gpio_port[1],
+ devm_gpio_request_one(dev, pdata->reset_gpio_port[1],
GPIOF_OUT_INIT_LOW, "USB2 PHY reset");
/* Hold the PHY in RESET for enough time till DIR is high */
@@ -492,21 +492,6 @@ static void omap_usbhs_init(struct device *dev)
}
}
-static void omap_usbhs_deinit(struct device *dev)
-{
- struct usbhs_hcd_omap *omap = dev_get_drvdata(dev);
- struct usbhs_omap_platform_data *pdata = omap->pdata;
-
- if (pdata->phy_reset) {
- if (gpio_is_valid(pdata->reset_gpio_port[0]))
- gpio_free(pdata->reset_gpio_port[0]);
-
- if (gpio_is_valid(pdata->reset_gpio_port[1]))
- gpio_free(pdata->reset_gpio_port[1]);
- }
-}
-
-
/**
* usbhs_omap_probe - initialize TI-based HCDs
*
@@ -709,8 +694,6 @@ static int usbhs_omap_probe(struct platform_device *pdev)
return 0;
err_alloc:
- omap_usbhs_deinit(&pdev->dev);
-
for (i = 0; i < omap->nports; i++) {
if (!IS_ERR(omap->utmi_clk[i]))
clk_put(omap->utmi_clk[i]);
@@ -755,8 +738,6 @@ static int usbhs_omap_remove(struct platform_device *pdev)
struct usbhs_hcd_omap *omap = platform_get_drvdata(pdev);
int i;
- omap_usbhs_deinit(&pdev->dev);
-
for (i = 0; i < omap->nports; i++) {
if (!IS_ERR(omap->utmi_clk[i]))
clk_put(omap->utmi_clk[i]);
--
1.7.2.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 V2 5/9] mfd: aat2870: use use devm_*() functions
Use devm_*() functions to make cleanup paths more simple.
Signed-off-by: Jingoo Han
---
No changes since v1:
drivers/mfd/aat2870-core.c | 20 ++--
1 files changed, 6 insertions(+), 14 deletions(-)
diff --git a/drivers/mfd/aat2870-core.c b/drivers/mfd/aat2870-core.c
index f1beb49..dfdb0a2 100644
--- a/drivers/mfd/aat2870-core.c
+++ b/drivers/mfd/aat2870-core.c
@@ -367,12 +367,12 @@ static int aat2870_i2c_probe(struct i2c_client *client,
int i, j;
int ret = 0;
- aat2870 = kzalloc(sizeof(struct aat2870_data), GFP_KERNEL);
+ aat2870 = devm_kzalloc(&client->dev, sizeof(struct aat2870_data),
+ GFP_KERNEL);
if (!aat2870) {
dev_err(&client->dev,
"Failed to allocate memory for aat2870\n");
- ret = -ENOMEM;
- goto out;
+ return -ENOMEM;
}
aat2870->dev = &client->dev;
@@ -400,12 +400,12 @@ static int aat2870_i2c_probe(struct i2c_client *client,
aat2870->init(aat2870);
if (aat2870->en_pin >= 0) {
- ret = gpio_request_one(aat2870->en_pin, GPIOF_OUT_INIT_HIGH,
- "aat2870-en");
+ ret = devm_gpio_request_one(&client->dev, aat2870->en_pin,
+ GPIOF_OUT_INIT_HIGH, "aat2870-en");
if (ret < 0) {
dev_err(&client->dev,
"Failed to request GPIO %d\n", aat2870->en_pin);
- goto out_kfree;
+ return ret;
}
}
@@ -436,11 +436,6 @@ static int aat2870_i2c_probe(struct i2c_client *client,
out_disable:
aat2870_disable(aat2870);
- if (aat2870->en_pin >= 0)
- gpio_free(aat2870->en_pin);
-out_kfree:
- kfree(aat2870);
-out:
return ret;
}
@@ -452,11 +447,8 @@ static int aat2870_i2c_remove(struct i2c_client *client)
mfd_remove_devices(aat2870->dev);
aat2870_disable(aat2870);
- if (aat2870->en_pin >= 0)
- gpio_free(aat2870->en_pin);
if (aat2870->uninit)
aat2870->uninit(aat2870);
- kfree(aat2870);
return 0;
}
--
1.7.2.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 V2 6/9] mfd: twl6040: use devm_*() functions
Use devm_*() functions to make cleanup paths more simple.
Signed-off-by: Jingoo Han
---
Changes since v1:
- Use devm_free_irq()
- Use devm_regulator_bulk_get()
drivers/mfd/twl6040.c | 31 +++
1 files changed, 11 insertions(+), 20 deletions(-)
diff --git a/drivers/mfd/twl6040.c b/drivers/mfd/twl6040.c
index f361bf3..492ee2c 100644
--- a/drivers/mfd/twl6040.c
+++ b/drivers/mfd/twl6040.c
@@ -554,7 +554,7 @@ static int twl6040_probe(struct i2c_client *client,
twl6040->supplies[0].supply = "vio";
twl6040->supplies[1].supply = "v2v1";
- ret = regulator_bulk_get(&client->dev, TWL6040_NUM_SUPPLIES,
+ ret = devm_regulator_bulk_get(&client->dev, TWL6040_NUM_SUPPLIES,
twl6040->supplies);
if (ret != 0) {
dev_err(&client->dev, "Failed to get supplies: %d\n", ret);
@@ -564,7 +564,7 @@ static int twl6040_probe(struct i2c_client *client,
ret = regulator_bulk_enable(TWL6040_NUM_SUPPLIES, twl6040->supplies);
if (ret != 0) {
dev_err(&client->dev, "Failed to enable supplies: %d\n", ret);
- goto power_err;
+ goto regulator_get_err;
}
twl6040->dev = &client->dev;
@@ -586,8 +586,8 @@ static int twl6040_probe(struct i2c_client *client,
twl6040->audpwron = -EINVAL;
if (gpio_is_valid(twl6040->audpwron)) {
- ret = gpio_request_one(twl6040->audpwron, GPIOF_OUT_INIT_LOW,
- "audpwron");
+ ret = devm_gpio_request_one(&client->dev, twl6040->audpwron,
+ GPIOF_OUT_INIT_LOW, "audpwron");
if (ret)
goto gpio_err;
}
@@ -596,14 +596,14 @@ static int twl6040_probe(struct i2c_client *client,
IRQF_ONESHOT, 0, &twl6040_irq_chip,
&twl6040->irq_data);
if (ret < 0)
- goto irq_init_err;
+ goto gpio_err;
twl6040->irq_ready = regmap_irq_get_virq(twl6040->irq_data,
TWL6040_IRQ_READY);
twl6040->irq_th = regmap_irq_get_virq(twl6040->irq_data,
TWL6040_IRQ_TH);
- ret = request_threaded_irq(twl6040->irq_ready, NULL,
+ ret = devm_request_threaded_irq(twl6040->dev, twl6040->irq_ready, NULL,
twl6040_readyint_handler, IRQF_ONESHOT,
"twl6040_irq_ready", twl6040);
if (ret) {
@@ -611,7 +611,7 @@ static int twl6040_probe(struct i2c_client *client,
goto readyirq_err;
}
- ret = request_threaded_irq(twl6040->irq_th, NULL,
+ ret = devm_request_threaded_irq(twl6040->dev, twl6040->irq_th, NULL,
twl6040_thint_handler, IRQF_ONESHOT,
"twl6040_irq_th", twl6040);
if (ret) {
@@ -681,18 +681,13 @@ static int twl6040_probe(struct i2c_client *client,
return 0;
mfd_err:
- free_irq(twl6040->irq_th, twl6040);
+ devm_free_irq(&client->dev, twl6040->irq_th, twl6040);
thirq_err:
- free_irq(twl6040->irq_ready, twl6040);
+ devm_free_irq(&client->dev, twl6040->irq_ready, twl6040);
readyirq_err:
regmap_del_irq_chip(twl6040->irq, twl6040->irq_data);
-irq_init_err:
- if (gpio_is_valid(twl6040->audpwron))
- gpio_free(twl6040->audpwron);
gpio_err:
regulator_bulk_disable(TWL6040_NUM_SUPPLIES, twl6040->supplies);
-power_err:
- regulator_bulk_free(TWL6040_NUM_SUPPLIES, twl6040->supplies);
regulator_get_err:
i2c_set_clientdata(client, NULL);
err:
@@ -706,18 +701,14 @@ static int twl6040_remove(struct i2c_client *client)
if (twl6040->power_count)
twl6040_power(twl6040, 0);
- if (gpio_is_valid(twl6040->audpwron))
- gpio_free(twl6040->audpwron);
-
- free_irq(twl6040->irq_ready, twl6040);
- free_irq(twl6040->irq_th, twl6040);
+ devm_free_irq(&client->dev, twl6040->irq_ready, twl6040);
+ devm_free_irq(&client->dev, twl6040->irq_th, twl6040);
regmap_del_irq_chip(twl6040->irq, twl6040->irq_data);
mfd_remove_devices(&client->dev);
i2c_set_clientdata(client, NULL);
regulator_bulk_disable(TWL6040_NUM_SUPPLIES, twl6040->supplies);
- regulator_bulk_free(TWL6040_NUM_SUPPLIES, twl6040->supplies);
return 0;
}
--
1.7.2.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 V2 7/9] mfd: ezx-pcap: use devm_*() functions
Use devm_*() functions to make cleanup paths more simple.
Signed-off-by: Jingoo Han
---
Changes since v1:
- Use devm_free_irq()
drivers/mfd/ezx-pcap.c | 17 +++--
1 files changed, 7 insertions(+), 10 deletions(-)
diff --git a/drivers/mfd/ezx-pcap.c b/drivers/mfd/ezx-pcap.c
index b7a61f0..f83cc3d 100644
--- a/drivers/mfd/ezx-pcap.c
+++ b/drivers/mfd/ezx-pcap.c
@@ -403,7 +403,7 @@ static int ezx_pcap_remove(struct spi_device *spi)
/* cleanup ADC */
adc_irq = pcap_to_irq(pcap, (pdata->config & PCAP_SECOND_PORT) ?
PCAP_IRQ_ADCDONE2 : PCAP_IRQ_ADCDONE);
- free_irq(adc_irq, pcap);
+ devm_free_irq(&spi->dev, adc_irq, pcap);
mutex_lock(&pcap->adc_mutex);
for (i = 0; i < PCAP_ADC_MAXQ; i++)
kfree(pcap->adc_queue[i]);
@@ -415,8 +415,6 @@ static int ezx_pcap_remove(struct spi_device *spi)
destroy_workqueue(pcap->workqueue);
- kfree(pcap);
-
return 0;
}
@@ -431,7 +429,7 @@ static int ezx_pcap_probe(struct spi_device *spi)
if (!pdata)
goto ret;
- pcap = kzalloc(sizeof(*pcap), GFP_KERNEL);
+ pcap = devm_kzalloc(&spi->dev, sizeof(*pcap), GFP_KERNEL);
if (!pcap) {
ret = -ENOMEM;
goto ret;
@@ -448,7 +446,7 @@ static int ezx_pcap_probe(struct spi_device *spi)
spi->mode = SPI_MODE_0 | (pdata->config & PCAP_CS_AH ? SPI_CS_HIGH : 0);
ret = spi_setup(spi);
if (ret)
- goto free_pcap;
+ goto ret;
pcap->spi = spi;
@@ -458,7 +456,7 @@ static int ezx_pcap_probe(struct spi_device *spi)
if (!pcap->workqueue) {
ret = -ENOMEM;
dev_err(&spi->dev, "can't create pcap thread\n");
- goto free_pcap;
+ goto ret;
}
/* redirect interrupts to AP, except adcdone2 */
@@ -491,7 +489,8 @@ static int ezx_pcap_probe(struct spi_device *spi)
adc_irq = pcap_to_irq(pcap, (pdata->config & PCAP_SECOND_PORT) ?
PCAP_IRQ_ADCDONE2 : PCAP_IRQ_ADCDONE);
- ret = request_irq(adc_irq, pcap_adc_irq, 0, "ADC", pcap);
+ ret = devm_request_irq(&spi->dev, adc_irq, pcap_adc_irq, 0, "ADC",
+ pcap);
if (ret)
goto free_irqchip;
@@ -511,14 +510,12 @@ static int ezx_pcap_probe(struct spi_device *spi)
remove_subdevs:
device_for_each_child(&spi->dev, NULL, pcap_remove_subdev);
/* free_adc: */
- free_irq(adc_irq, pcap);
+ devm_free_irq(&spi->dev, adc_irq, pcap);
free_irqchip:
for (i = pcap->irq_base; i < (pcap->irq_base + PCAP_NIRQS); i++)
irq_set_chip_and_handler(i, NULL, NULL);
/* destroy_workqueue: */
destroy_workqueue(pcap->workqueue);
-free_pcap:
- kfree(pcap);
ret:
return ret;
}
--
1.7.2.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch v5 06/15] sched: log the cpu utilization at rq
On Mon, 2013-02-18 at 13:07 +0800, Alex Shi wrote:
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index fcdb21f..b9a34ab 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -1495,8 +1495,12 @@ static void update_cfs_rq_blocked_load(struct cfs_rq
> *cfs_rq, int force_update)
>
> static inline void update_rq_runnable_avg(struct rq *rq, int runnable)
> {
> + u32 period;
> __update_entity_runnable_avg(rq->clock_task, &rq->avg, runnable);
> __update_tg_runnable_avg(&rq->avg, &rq->cfs);
> +
> + period = rq->avg.runnable_avg_period ? rq->avg.runnable_avg_period : 1;
> + rq->util = rq->avg.runnable_avg_sum * 100 / period;
> }
>
> /* Add the load generated by se into cfs_rq's child load-average */
> diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
> index 7a19792..ac1e107 100644
> --- a/kernel/sched/sched.h
> +++ b/kernel/sched/sched.h
> @@ -350,6 +350,9 @@ extern struct root_domain def_root_domain;
>
> #endif /* CONFIG_SMP */
>
> +/* the percentage full cpu utilization */
> +#define FULL_UTIL100
There's generally a better value than 100 when using computers.. seeing
how 100 is 64+32+4.
> +
> /*
> * This is the main, per-CPU runqueue data structure.
> *
> @@ -481,6 +484,7 @@ struct rq {
> #endif
>
> struct sched_avg avg;
> + unsigned int util;
> };
>
> static inline int cpu_of(struct rq *rq)
You don't actually compute the rq utilization, you only compute the
utilization as per the fair class, so if there's significant RT activity
it'll think the cpu is under-utilized, whihc I think will result in the
wrong thing.
--
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 V2 8/9] mfd: da903x: use devm_*() functions
Use devm_*() functions to make cleanup paths more simple.
Signed-off-by: Jingoo Han
---
No changes since v1:
drivers/mfd/da903x.c | 19 ++-
1 files changed, 6 insertions(+), 13 deletions(-)
diff --git a/drivers/mfd/da903x.c b/drivers/mfd/da903x.c
index 05176cd..f1a316e 100644
--- a/drivers/mfd/da903x.c
+++ b/drivers/mfd/da903x.c
@@ -499,7 +499,8 @@ static int da903x_probe(struct i2c_client *client,
unsigned int tmp;
int ret;
- chip = kzalloc(sizeof(struct da903x_chip), GFP_KERNEL);
+ chip = devm_kzalloc(&client->dev, sizeof(struct da903x_chip),
+ GFP_KERNEL);
if (chip == NULL)
return -ENOMEM;
@@ -515,33 +516,27 @@ static int da903x_probe(struct i2c_client *client,
ret = chip->ops->init_chip(chip);
if (ret)
- goto out_free_chip;
+ return ret;
/* mask and clear all IRQs */
chip->events_mask = 0x;
chip->ops->mask_events(chip, chip->events_mask);
chip->ops->read_events(chip, &tmp);
- ret = request_irq(client->irq, da903x_irq_handler,
+ ret = devm_request_irq(&client->dev, client->irq, da903x_irq_handler,
IRQF_TRIGGER_FALLING,
"da903x", chip);
if (ret) {
dev_err(&client->dev, "failed to request irq %d\n",
client->irq);
- goto out_free_chip;
+ return ret;
}
ret = da903x_add_subdevs(chip, pdata);
if (ret)
- goto out_free_irq;
+ return ret;
return 0;
-
-out_free_irq:
- free_irq(client->irq, chip);
-out_free_chip:
- kfree(chip);
- return ret;
}
static int da903x_remove(struct i2c_client *client)
@@ -549,8 +544,6 @@ static int da903x_remove(struct i2c_client *client)
struct da903x_chip *chip = i2c_get_clientdata(client);
da903x_remove_subdevs(chip);
- free_irq(client->irq, chip);
- kfree(chip);
return 0;
}
--
1.7.2.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 V2 9/9] mfd: tc3589x: use devm_*() functions
Use devm_*() functions to make cleanup paths more simple.
Signed-off-by: Jingoo Han
---
No changes since v1:
drivers/mfd/tc3589x.c | 21 ++---
1 files changed, 6 insertions(+), 15 deletions(-)
diff --git a/drivers/mfd/tc3589x.c b/drivers/mfd/tc3589x.c
index ecc092c..4cb92bb 100644
--- a/drivers/mfd/tc3589x.c
+++ b/drivers/mfd/tc3589x.c
@@ -350,7 +350,8 @@ static int tc3589x_probe(struct i2c_client *i2c,
| I2C_FUNC_SMBUS_I2C_BLOCK))
return -EIO;
- tc3589x = kzalloc(sizeof(struct tc3589x), GFP_KERNEL);
+ tc3589x = devm_kzalloc(&i2c->dev, sizeof(struct tc3589x),
+ GFP_KERNEL);
if (!tc3589x)
return -ENOMEM;
@@ -366,33 +367,27 @@ static int tc3589x_probe(struct i2c_client *i2c,
ret = tc3589x_chip_init(tc3589x);
if (ret)
- goto out_free;
+ return ret;
ret = tc3589x_irq_init(tc3589x, np);
if (ret)
- goto out_free;
+ return ret;
ret = request_threaded_irq(tc3589x->i2c->irq, NULL, tc3589x_irq,
IRQF_TRIGGER_FALLING | IRQF_ONESHOT,
"tc3589x", tc3589x);
if (ret) {
dev_err(tc3589x->dev, "failed to request IRQ: %d\n", ret);
- goto out_free;
+ return ret;
}
ret = tc3589x_device_init(tc3589x);
if (ret) {
dev_err(tc3589x->dev, "failed to add child devices\n");
- goto out_freeirq;
+ return ret;
}
return 0;
-
-out_freeirq:
- free_irq(tc3589x->i2c->irq, tc3589x);
-out_free:
- kfree(tc3589x);
- return ret;
}
static int tc3589x_remove(struct i2c_client *client)
@@ -401,10 +396,6 @@ static int tc3589x_remove(struct i2c_client *client)
mfd_remove_devices(tc3589x->dev);
- free_irq(tc3589x->i2c->irq, tc3589x);
-
- kfree(tc3589x);
-
return 0;
}
--
1.7.2.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 3/3 RESEND] mmc: sdhci: check voltage range only on regulators aware of voltage value
2013/2/14 Ulf Hansson :
> On 14 February 2013 09:05, Marek Szyprowski wrote:
>>
>> On 2/13/2013 12:35 PM, Mark Brown wrote:
>>>
>>> On Wed, Feb 13, 2013 at 08:45:56AM +0100, Guennadi Liakhovetski wrote:
>>> > On Wed, 13 Feb 2013, Marek Szyprowski wrote:
>>>
>>> > > BTW, mmc_regulator_get_ocrmask() won't work with continuous range
>>> > > regulators.
>>>
>>> > This seems like a problem, that has to be fixed...
>>>
>>> Indeed, what's the issue?
>>
>>
>> There are probably 2 issues:
>>
>> 1. mmc_regulator_get_ocrmask() works only with regulators which support
>> regulator_count_voltages() and regulator_list_voltage(). Recently support
>> for
>> continuous regulators have been merged. Such regulators doesn't provide
>> regulator_list_voltage() method, but are able to change/set voltage to the
>> given value. I agree that they are not very common, so right now we can
>> probably ignore them until the first board, which uses them arrives.
>>
>> 2. The second issue might be related to the testing of precise voltage
>> values
>> in the ocr mask, not the whole allowed ranges. Such issues in sdhci.c driver
>> has been recently fixed by commit cec2e216f72c6b5ccdadb60aadbe99821d744503
>> ("mmc: sdhci: Use regulator min/max voltage range according to spec"), but I
>> don't know MMC core code to judge if ocr mask is used for exact voltage
>> checking or only for checking the voltage ranges. However someone with good
>> mmc subsystem knowledge should check it.
>>
>
> Not 100% sure what your problem relates too here, but I am aware of an
> issue for how the mmc protocol layer are handling ocr_masks. Let me
> try to describe it here:
>
> 1. During "card init" mmc_power_up will be called for telling the host
> driver to provide power to the card. The level of voltage will be set
> to "ocr_avail" which means the highest supported voltage by the host.
> 2. At the protocol layer the card init sequence tries to negotiate to
> lowest possible ocr value from what the card and the host together
> supports. Once done, the ocr mask value will be cached into the host
> struct.
> 3. The host will informed about the new ocr mask from the protocol
> layer with mmc_select_voltage and it somewhere here the problems
> starts. No host are actually changing the voltage level at this state
> (MMC_POWER_ON) which is correct since it would likely mean violation
> of the spec. At the same time the protocol layer still believes the
> host has switched to operate at the new voltage level.
According to the spec, only during the initialization procedure, the
host is not allowed to change the operating voltage range.
In fact, mmc_select_voltage is called before init start in
mmc_attach_sd/mmc_attach_mmc/mmc_attach_sdio.
So voltage level should can be changed during MMC_POWER_ON.
sdhci.c did this way and worked well. But I noticed some other hosts
didn't change voltage for MMC_POWER_ON.
I think it should be changed.
> 4. So the host and the protocol layer are out of sync with regards to
> the ocr mask, which is why the cached ocr_mask in the host struct is
> reset when doing mmc_power_off. Otherwise the suspend/resume sequence
> would have been broken.
>
But there indeed exist issues that the host->ocr doesn't restore after
resume back and operation voltage use the highest voltage.
Just submitted below patch to fix this. Please help to review.
"[PATCH] mmc: core: restore ocr and operation voltage in resume"
Thanks
Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch v5 04/15] sched: add sched balance policies in kernel
* Alex Shi wrote: > Current scheduler behavior is just consider for larger > performance of system. So it try to spread tasks on more cpu > sockets and cpu cores > > To adding the consideration of power awareness, the patchset > adds 2 kinds of scheduler policy: powersaving and balance. > They will use runnable load util in scheduler balancing. The > current scheduling is taken as performance policy. > > performance: the current scheduling behaviour, try to spread tasks > on more CPU sockets or cores. performance oriented. > powersaving: will pack tasks into few sched group until all LCPU in the > group is full, power oriented. > balance: will pack tasks into few sched group until group_capacity > numbers CPU is full, balance between performance and > powersaving. Hm, so in a previous review I suggested keeping two main policies: power-saving and performance, plus a third, default policy, which automatically switches between these two if/when the kernel has information about whether a system is on battery or on AC - and picking 'performance' when it has no information. Such an automatic policy would obviously be useful to users - and that is what makes such a feature really interesting and a step forward. I think Peter expressed similar views: we don't want many knobs and states, we want two major goals plus an (optional but default enabled) automatism. Is your 'balance' policy implementing that suggestion? If not, why not? Thanks, Ingo -- 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: prctl(PR_SET_MM)
Hi Cyrill, Cyrill Gorcunov wrote: > On Tue, Feb 19, 2013 at 05:25:31PM +1100, Amnon Shiloh wrote: > > > > To reconstruct Linux process(es), one must be able to restore all their > > memory contents, states and registers to their original and consistent > > values. > > I personally don't mind if this come become y by default, because it will > work for us. I don't mind either, to say the least, to have CONFIG_CHECKPOINT_RESTORE have a "default y" in "init/Kconfig" - that would solve my problem and make me happy, as well as your group and others, but we are told here that Linus has a policy vetoing such changes and I don't believe either of us can make him change his mind. As such, we must look at other options, such as having the code in "kernel/sys.c" out in the open, not enclosed by any #ifdef's altogether - surely you would like that! > Still I guess if you need to reconstruct Linux process(es) > plain prctl extension is not enough, you still need a functionality which > is enclosed in config-checkpoint-restore (say /proc/pid/map_files, kcmp), > no? My process-migration package only reconstructs Linux processes partially: as it's a bit different than any classical checkpoint-restore, the critical code in "kernel/sys.c" is all I need at the moment (from within CONFIG_CHECKPOINT_RESTORE). I do appreciate that anyone attempting to perform complete, classical, checkpoint-restore operations, needs more than that. Best Regards, Amnon. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch v5 07/15] sched: add new sg/sd_lb_stats fields for incoming fork/exec/wake balancing
On Mon, 2013-02-18 at 13:07 +0800, Alex Shi wrote:
> @@ -4214,6 +4214,11 @@ struct sd_lb_stats {
> unsigned int busiest_group_weight;
>
> int group_imb; /* Is there imbalance in this sd */
> +
> + /* Varibles of power awaring scheduling */
> + unsigned int sd_utils; /* sum utilizations of this domain */
> + unsigned long sd_capacity; /* capacity of this domain */
> + struct sched_group *group_leader; /* Group which relieves
> group_min */
> };
>
> /*
> @@ -4229,6 +4234,7 @@ struct sg_lb_stats {
> unsigned long group_weight;
> int group_imb; /* Is there an imbalance in the group ? */
> int group_has_capacity; /* Is there extra capacity in the
> group? */
> + unsigned int group_utils; /* sum utilizations of group
> */
> };
So I have two problems with the _utils name, firstly its a single value
and therefore we shouldn't give it a name in plural, secondly, whenever
I read utils I read utilities, not utilizations.
As a non native speaker I'm not entirely sure, but utilizations sounds
iffy to me, is there even a plural of utilization?
--
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] Fix rq->lock vs logbuf_lock unlock race
> -Original Message-
> From: Peter Zijlstra [mailto:a.p.zijls...@chello.nl]
> Sent: Wednesday, February 20, 2013 4:45 PM
> To: Bu, Yitian
> Cc: t...@linutronix.de; linux-kernel@vger.kernel.org; mi...@kernel.org
> Subject: Re: [PATCH] Fix rq->lock vs logbuf_lock unlock race
>
> On Mon, 2013-02-18 at 12:53 +, Bu, Yitian wrote:
> > This patch is for kernel V3.7.9
> >
> > From 8796f4a2175a323aaa49ea8dd0fe68678dd5dccd Mon Sep 17 00:00:00
> 2001
> > From: ybu
> > Date: Mon, 18 Feb 2013 19:52:01 +0800
> > Subject: [PATCH] Fix rq->lock vs logbuf_lock unlock race
> >
> > fix up the fallout from commit 07354eb1a74d1 ("locking printk:
> > Annotate logbuf_lock as raw")
> > Release console_sem after unlocking the logbuf_lock avoids some lock
> > inversion troubles between logbuf_lock and rq->lock.
>
> Please clarify how and where.. you're not actually supposed to use
> printk() while holding rq->lock.
>
1. the patch 0b5e1c5255e, which is written by you, release console_sem
after logbuf_lock. But the patch 07354eb1a revert one of your change, it
reintroduced a lock inversion problem which was fixed in 0b5e1c5255.
The purpose of my patch is the same as your patch 0b5e1c5255e.
2. from printk comment: "This is printk(). It can be called from any context.
We want it to work. ". I suppose to use printk in any context.
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
Re: [PATCH 17/16] virtio-scsi: use virtqueue_add_sgs for command buffers
On 02/20/2013 04:37 PM, Wanlong Gao wrote:
> Using the new virtqueue_add_sgs function lets us simplify the queueing
> path. In particular, all data protected by the tgt_lock is just gone
> (multiqueue will find a new use for the lock).
>
> Signed-off-by: Paolo Bonzini
> Signed-off-by: Wanlong Gao
> ---
> drivers/scsi/virtio_scsi.c | 93
> --
> 1 file changed, 33 insertions(+), 60 deletions(-)
>
> diff --git a/drivers/scsi/virtio_scsi.c b/drivers/scsi/virtio_scsi.c
> index 3449a1f..b002d7b 100644
> --- a/drivers/scsi/virtio_scsi.c
> +++ b/drivers/scsi/virtio_scsi.c
> @@ -59,11 +59,8 @@ struct virtio_scsi_vq {
>
> /* Per-target queue state */
> struct virtio_scsi_target_state {
> - /* Protects sg. Lock hierarchy is tgt_lock -> vq_lock. */
> + /* Never held at the same time as vq_lock. */
> spinlock_t tgt_lock;
> -
> - /* For sglist construction when adding commands to the virtqueue. */
> - struct scatterlist sg[];
> };
>
> /* Driver instance state */
> @@ -351,75 +348,57 @@ static void virtscsi_event_done(struct virtqueue *vq)
> spin_unlock_irqrestore(&vscsi->event_vq.vq_lock, flags);
> };
>
> -static void virtscsi_map_sgl(struct scatterlist *sg, unsigned int *p_idx,
> - struct scsi_data_buffer *sdb)
> -{
> - struct sg_table *table = &sdb->table;
> - struct scatterlist *sg_elem;
> - unsigned int idx = *p_idx;
> - int i;
> -
> - for_each_sg(table->sgl, sg_elem, table->nents, i)
> - sg[idx++] = *sg_elem;
> -
> - *p_idx = idx;
> -}
> -
> /**
> - * virtscsi_map_cmd - map a scsi_cmd to a virtqueue scatterlist
> - * @vscsi: virtio_scsi state
> + * virtscsi_add_cmd - add a virtio_scsi_cmd to a virtqueue
> + * @vq : the struct virtqueue we're talking about
> * @cmd : command structure
> - * @out_num : number of read-only elements
> - * @in_num : number of write-only elements
> * @req_size : size of the request buffer
> * @resp_size: size of the response buffer
> - *
> - * Called with tgt_lock held.
> + * @gfp : flags to use for memory allocations
> */
> -static void virtscsi_map_cmd(struct virtio_scsi_target_state *tgt,
> - struct virtio_scsi_cmd *cmd,
> - unsigned *out_num, unsigned *in_num,
> - size_t req_size, size_t resp_size)
> +static int virtscsi_add_cmd(struct virtqueue *vq,
> + struct virtio_scsi_cmd *cmd,
> + size_t req_size, size_t resp_size, gfp_t gfp)
> {
> struct scsi_cmnd *sc = cmd->sc;
> - struct scatterlist *sg = tgt->sg;
> - unsigned int idx = 0;
> + struct scatterlist *sgs[4], req, resp;
> + struct sg_table *out, *in;
> + unsigned out_num = 0, in_num = 0;
> +
> + out = in = NULL;
>
> - /* Request header. */
> - sg_set_buf(&sg[idx++], &cmd->req, req_size);
> + if (sc && sc->sc_data_direction != DMA_NONE) {
> + if (sc->sc_data_direction != DMA_FROM_DEVICE)
> + out = &scsi_out(sc)->table;
> + if (sc->sc_data_direction != DMA_TO_DEVICE)
> + in = &scsi_in(sc)->table;
> + }
>
> - /* Data-out buffer. */
> - if (sc && sc->sc_data_direction != DMA_FROM_DEVICE)
> - virtscsi_map_sgl(sg, &idx, scsi_out(sc));
> + sg_init_one(&req, &cmd->req, req_size);
> + sgs[out_num++] = &req;
>
> - *out_num = idx;
> + if (out)
> + sgs[out_num++] = out->sgl;
>
> - /* Response header. */
> - sg_set_buf(&sg[idx++], &cmd->resp, resp_size);
> + sg_init_one(&resp, &cmd->resp, resp_size);
> + sgs[out_num + in_num++] = &resp;
>
> - /* Data-in buffer */
Why do you want to drop all the comments?
> - if (sc && sc->sc_data_direction != DMA_TO_DEVICE)
> - virtscsi_map_sgl(sg, &idx, scsi_in(sc));
> + if (in)
> + sgs[out_num + in_num++] = in->sgl;
>
> - *in_num = idx - *out_num;
> + return virtqueue_add_sgs(vq, sgs, out_num, in_num, cmd, gfp);
> }
>
> -static int virtscsi_kick_cmd(struct virtio_scsi_target_state *tgt,
> - struct virtio_scsi_vq *vq,
> +static int virtscsi_kick_cmd(struct virtio_scsi_vq *vq,
>struct virtio_scsi_cmd *cmd,
>size_t req_size, size_t resp_size, gfp_t gfp)
> {
> - unsigned int out_num, in_num;
> unsigned long flags;
> int err;
> bool needs_kick = false;
>
> - spin_lock_irqsave(&tgt->tgt_lock, flags);
> - virtscsi_map_cmd(tgt, cmd, &out_num, &in_num, req_size, resp_size);
> -
> - spin_lock(&vq->vq_lock);
> - err = virtqueue_add_buf(vq->vq, tgt->sg, out_num, in_num, cmd, gfp);
> - spin_unlock(&tgt->tgt_lock);
> + spin_lock_irqsave(&vq->vq_lock, flags);
> + err = virtscsi_add_cmd(vq->vq, cmd, req_size, resp_size, gfp);
>
RE: [PATCH 6/6 v8] iommu/fsl: Freescale PAMU driver and IOMMU API implementation.
> -Original Message-
> From: Craciun Diana Madalina-STFD002
> Sent: Tuesday, February 19, 2013 9:30 PM
> To: Sethi Varun-B16395
> Cc: io...@lists.linux-foundation.org; linuxppc-...@lists.ozlabs.org;
> linux-kernel@vger.kernel.org; Wood Scott-B07421; j...@8bytes.org; Yoder
> Stuart-B08248
> Subject: Re: [PATCH 6/6 v8] iommu/fsl: Freescale PAMU driver and IOMMU
> API implementation.
>
> On 02/18/2013 02:52 PM, Varun Sethi wrote:
> > +/**
> > + * pamu_get_ppaace() - Return the primary PACCE
> > + * @liodn: liodn PAACT index for desired PAACE
> > + *
> > + * Returns the ppace pointer upon success else return
> > + * null.
> > + */
> > +static struct paace *pamu_get_ppaace(int liodn) {
> > + if (!ppaact || liodn > PAACE_NUMBER_ENTRIES) {
>
> Shouldn't be "liodn >= PAACE_NUMBER_ENTRIES" ?
Yes, will fix this.
-Varun
--
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 17/16] virtio-scsi: use virtqueue_add_sgs for command buffers
On 02/20/2013 05:38 PM, Asias He wrote:
> On 02/20/2013 04:37 PM, Wanlong Gao wrote:
>> Using the new virtqueue_add_sgs function lets us simplify the queueing
>> path. In particular, all data protected by the tgt_lock is just gone
>> (multiqueue will find a new use for the lock).
>>
>> Signed-off-by: Paolo Bonzini
>> Signed-off-by: Wanlong Gao
>> ---
>> drivers/scsi/virtio_scsi.c | 93
>> --
>> 1 file changed, 33 insertions(+), 60 deletions(-)
>>
>> diff --git a/drivers/scsi/virtio_scsi.c b/drivers/scsi/virtio_scsi.c
>> index 3449a1f..b002d7b 100644
>> --- a/drivers/scsi/virtio_scsi.c
>> +++ b/drivers/scsi/virtio_scsi.c
>> @@ -59,11 +59,8 @@ struct virtio_scsi_vq {
>>
>> /* Per-target queue state */
>> struct virtio_scsi_target_state {
>> -/* Protects sg. Lock hierarchy is tgt_lock -> vq_lock. */
>> +/* Never held at the same time as vq_lock. */
>> spinlock_t tgt_lock;
>> -
>> -/* For sglist construction when adding commands to the virtqueue. */
>> -struct scatterlist sg[];
>> };
>>
>> /* Driver instance state */
>> @@ -351,75 +348,57 @@ static void virtscsi_event_done(struct virtqueue *vq)
>> spin_unlock_irqrestore(&vscsi->event_vq.vq_lock, flags);
>> };
>>
>> -static void virtscsi_map_sgl(struct scatterlist *sg, unsigned int *p_idx,
>> - struct scsi_data_buffer *sdb)
>> -{
>> -struct sg_table *table = &sdb->table;
>> -struct scatterlist *sg_elem;
>> -unsigned int idx = *p_idx;
>> -int i;
>> -
>> -for_each_sg(table->sgl, sg_elem, table->nents, i)
>> -sg[idx++] = *sg_elem;
>> -
>> -*p_idx = idx;
>> -}
>> -
>> /**
>> - * virtscsi_map_cmd - map a scsi_cmd to a virtqueue scatterlist
>> - * @vscsi : virtio_scsi state
>> + * virtscsi_add_cmd - add a virtio_scsi_cmd to a virtqueue
>> + * @vq : the struct virtqueue we're talking about
>> * @cmd : command structure
>> - * @out_num : number of read-only elements
>> - * @in_num : number of write-only elements
>> * @req_size: size of the request buffer
>> * @resp_size : size of the response buffer
>> - *
>> - * Called with tgt_lock held.
>> + * @gfp : flags to use for memory allocations
>> */
>> -static void virtscsi_map_cmd(struct virtio_scsi_target_state *tgt,
>> - struct virtio_scsi_cmd *cmd,
>> - unsigned *out_num, unsigned *in_num,
>> - size_t req_size, size_t resp_size)
>> +static int virtscsi_add_cmd(struct virtqueue *vq,
>> +struct virtio_scsi_cmd *cmd,
>> +size_t req_size, size_t resp_size, gfp_t gfp)
>> {
>> struct scsi_cmnd *sc = cmd->sc;
>> -struct scatterlist *sg = tgt->sg;
>> -unsigned int idx = 0;
>> +struct scatterlist *sgs[4], req, resp;
>> +struct sg_table *out, *in;
>> +unsigned out_num = 0, in_num = 0;
>> +
>> +out = in = NULL;
>>
>> -/* Request header. */
>> -sg_set_buf(&sg[idx++], &cmd->req, req_size);
>> +if (sc && sc->sc_data_direction != DMA_NONE) {
>> +if (sc->sc_data_direction != DMA_FROM_DEVICE)
>> +out = &scsi_out(sc)->table;
>> +if (sc->sc_data_direction != DMA_TO_DEVICE)
>> +in = &scsi_in(sc)->table;
>> +}
>>
>> -/* Data-out buffer. */
>> -if (sc && sc->sc_data_direction != DMA_FROM_DEVICE)
>> -virtscsi_map_sgl(sg, &idx, scsi_out(sc));
>> +sg_init_one(&req, &cmd->req, req_size);
>> +sgs[out_num++] = &req;
>>
>> -*out_num = idx;
>> +if (out)
>> +sgs[out_num++] = out->sgl;
>>
>> -/* Response header. */
>> -sg_set_buf(&sg[idx++], &cmd->resp, resp_size);
>> +sg_init_one(&resp, &cmd->resp, resp_size);
>> +sgs[out_num + in_num++] = &resp;
>>
>> -/* Data-in buffer */
>
> Why do you want to drop all the comments?
Oops, just rewrote the new function and deleted the old function
without adding the original comments again, will add, thank you.
Regards,
Wanlong Gao
>
>> -if (sc && sc->sc_data_direction != DMA_TO_DEVICE)
>> -virtscsi_map_sgl(sg, &idx, scsi_in(sc));
>> +if (in)
>> +sgs[out_num + in_num++] = in->sgl;
>>
>> -*in_num = idx - *out_num;
>> +return virtqueue_add_sgs(vq, sgs, out_num, in_num, cmd, gfp);
>> }
>>
>> -static int virtscsi_kick_cmd(struct virtio_scsi_target_state *tgt,
>> - struct virtio_scsi_vq *vq,
>> +static int virtscsi_kick_cmd(struct virtio_scsi_vq *vq,
>> struct virtio_scsi_cmd *cmd,
>> size_t req_size, size_t resp_size, gfp_t gfp)
>> {
>> -unsigned int out_num, in_num;
>> unsigned long flags;
>> int err;
>> bool needs_kick = false;
>>
>> -spin_lock_irqsave(&tgt->tgt_lock, flags);
>> -virtscsi_map_cmd(tgt, cmd, &out_num, &in_num, req_size, resp_size);
>> -
>> -
Re: [patch v5 09/15] sched: add power aware scheduling in fork/exec/wake
On Mon, 2013-02-18 at 13:07 +0800, Alex Shi wrote:
> +/*
> + * Try to collect the task running number and capacity of the group.
> + */
> +static void get_sg_power_stats(struct sched_group *group,
> + struct sched_domain *sd, struct sg_lb_stats *sgs)
> +{
> + int i;
> +
> + for_each_cpu(i, sched_group_cpus(group)) {
> + struct rq *rq = cpu_rq(i);
> +
> + sgs->group_utils += rq->nr_running;
> + }
> +
> + sgs->group_capacity = DIV_ROUND_CLOSEST(group->sgp->power,
> + SCHED_POWER_SCALE);
> + if (!sgs->group_capacity)
> + sgs->group_capacity = fix_small_capacity(sd, group);
> + sgs->group_weight = group->group_weight;
> +}
So you're trying to compute the group utilization, but what does that
have to do with nr_running? In an earlier patch you introduced the
per-cpu utilization, so why not avg that to compute the group
utilization?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch v5 11/15] sched: add power/performance balance allow flag
On Mon, 2013-02-18 at 13:07 +0800, Alex Shi wrote:
> @@ -4053,6 +4053,8 @@ struct lb_env {
> unsigned intloop;
> unsigned intloop_break;
> unsigned intloop_max;
> + int power_lb; /* if power balance needed
> */
> + int perf_lb; /* if performance balance
> needed */
> };
>
> /*
> @@ -5195,6 +5197,8 @@ static int load_balance(int this_cpu, struct rq
> *this_rq,
> .idle = idle,
> .loop_break = sched_nr_migrate_break,
> .cpus = cpus,
> + .power_lb = 0,
> + .perf_lb= 1,
> };
>
> cpumask_copy(cpus, cpu_active_mask);
This construct allows for the possibility of power_lb=1,perf_lb=1, does
that make sense? Why not have a single balance_policy enumeration?
--
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 17/16 V2] virtio-scsi: use virtqueue_add_sgs for command buffers
Using the new virtqueue_add_sgs function lets us simplify the queueing
path. In particular, all data protected by the tgt_lock is just gone
(multiqueue will find a new use for the lock).
Signed-off-by: Paolo Bonzini
Signed-off-by: Wanlong Gao
---
V1->V2:
add the lost comments (Asias)
drivers/scsi/virtio_scsi.c | 91 +-
1 file changed, 34 insertions(+), 57 deletions(-)
diff --git a/drivers/scsi/virtio_scsi.c b/drivers/scsi/virtio_scsi.c
index 3449a1f..bae0c95 100644
--- a/drivers/scsi/virtio_scsi.c
+++ b/drivers/scsi/virtio_scsi.c
@@ -59,11 +59,8 @@ struct virtio_scsi_vq {
/* Per-target queue state */
struct virtio_scsi_target_state {
- /* Protects sg. Lock hierarchy is tgt_lock -> vq_lock. */
+ /* Never held at the same time as vq_lock. */
spinlock_t tgt_lock;
-
- /* For sglist construction when adding commands to the virtqueue. */
- struct scatterlist sg[];
};
/* Driver instance state */
@@ -351,75 +348,61 @@ static void virtscsi_event_done(struct virtqueue *vq)
spin_unlock_irqrestore(&vscsi->event_vq.vq_lock, flags);
};
-static void virtscsi_map_sgl(struct scatterlist *sg, unsigned int *p_idx,
-struct scsi_data_buffer *sdb)
-{
- struct sg_table *table = &sdb->table;
- struct scatterlist *sg_elem;
- unsigned int idx = *p_idx;
- int i;
-
- for_each_sg(table->sgl, sg_elem, table->nents, i)
- sg[idx++] = *sg_elem;
-
- *p_idx = idx;
-}
-
/**
- * virtscsi_map_cmd - map a scsi_cmd to a virtqueue scatterlist
- * @vscsi : virtio_scsi state
+ * virtscsi_add_cmd - add a virtio_scsi_cmd to a virtqueue
+ * @vq : the struct virtqueue we're talking about
* @cmd: command structure
- * @out_num: number of read-only elements
- * @in_num : number of write-only elements
* @req_size : size of the request buffer
* @resp_size : size of the response buffer
- *
- * Called with tgt_lock held.
+ * @gfp: flags to use for memory allocations
*/
-static void virtscsi_map_cmd(struct virtio_scsi_target_state *tgt,
-struct virtio_scsi_cmd *cmd,
-unsigned *out_num, unsigned *in_num,
-size_t req_size, size_t resp_size)
+static int virtscsi_add_cmd(struct virtqueue *vq,
+ struct virtio_scsi_cmd *cmd,
+ size_t req_size, size_t resp_size, gfp_t gfp)
{
struct scsi_cmnd *sc = cmd->sc;
- struct scatterlist *sg = tgt->sg;
- unsigned int idx = 0;
+ struct scatterlist *sgs[4], req, resp;
+ struct sg_table *out, *in;
+ unsigned out_num = 0, in_num = 0;
+
+ out = in = NULL;
+
+ if (sc && sc->sc_data_direction != DMA_NONE) {
+ if (sc->sc_data_direction != DMA_FROM_DEVICE)
+ out = &scsi_out(sc)->table;
+ if (sc->sc_data_direction != DMA_TO_DEVICE)
+ in = &scsi_in(sc)->table;
+ }
/* Request header. */
- sg_set_buf(&sg[idx++], &cmd->req, req_size);
+ sg_init_one(&req, &cmd->req, req_size);
+ sgs[out_num++] = &req;
/* Data-out buffer. */
- if (sc && sc->sc_data_direction != DMA_FROM_DEVICE)
- virtscsi_map_sgl(sg, &idx, scsi_out(sc));
-
- *out_num = idx;
+ if (out)
+ sgs[out_num++] = out->sgl;
/* Response header. */
- sg_set_buf(&sg[idx++], &cmd->resp, resp_size);
+ sg_init_one(&resp, &cmd->resp, resp_size);
+ sgs[out_num + in_num++] = &resp;
/* Data-in buffer */
- if (sc && sc->sc_data_direction != DMA_TO_DEVICE)
- virtscsi_map_sgl(sg, &idx, scsi_in(sc));
+ if (in)
+ sgs[out_num + in_num++] = in->sgl;
- *in_num = idx - *out_num;
+ return virtqueue_add_sgs(vq, sgs, out_num, in_num, cmd, gfp);
}
-static int virtscsi_kick_cmd(struct virtio_scsi_target_state *tgt,
-struct virtio_scsi_vq *vq,
+static int virtscsi_kick_cmd(struct virtio_scsi_vq *vq,
struct virtio_scsi_cmd *cmd,
size_t req_size, size_t resp_size, gfp_t gfp)
{
- unsigned int out_num, in_num;
unsigned long flags;
int err;
bool needs_kick = false;
- spin_lock_irqsave(&tgt->tgt_lock, flags);
- virtscsi_map_cmd(tgt, cmd, &out_num, &in_num, req_size, resp_size);
-
- spin_lock(&vq->vq_lock);
- err = virtqueue_add_buf(vq->vq, tgt->sg, out_num, in_num, cmd, gfp);
- spin_unlock(&tgt->tgt_lock);
+ spin_lock_irqsave(&vq->vq_lock, flags);
+ err = virtscsi_add_cmd(vq->vq, cmd, req_size, resp_size, gfp);
if (!err)
needs_kick = virtqueue_kick_prepare(vq->vq);
@@ -433,7 +416,6 @@ static int virtscsi_kick_cmd(struct
virtio_scsi_target_state *tgt,
Re: [PATCH 0/4] dw_dmac: introduce generic DMA binding for DT
On Wednesday 20 February 2013, Vinod Koul wrote: > Since there is still churn, would it make sense if I just revert the SPEAr13xx > patch (your first patch) and send a pull request to Linus. > Since there are no users and not much testing has been done, I think we can > push > these to 3.10 via arm-soc/slave-dma tree. > > Gives more testing and usage will go along as well. > Since merge window is open, I would like my pull to go soonish and not churn > the > tree much. Reverting the SPEAr13xx would definitely help, yes. The reason why I'd also like to see the second patch get merged is so that we can do the SPEAr changes in 3.10 without having an interdependency between the trees. I tried very hard to make the patch have a minimal impact on the non-DT code path to avoid regressions. Maybe you can send your tree now with just the revert applied, and then send the other one separately next week along with any bug fixes that may have accumulated by then? Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] mm: hotplug: implement non-movable version of get_user_pages() called get_user_pages_non_movable()
On 02/05/2013 09:32 PM, Mel Gorman wrote:
On Tue, Feb 05, 2013 at 11:57:22AM +, Mel Gorman wrote:
+ migrate_pre_flag = 1;
+ }
+
+ if (!isolate_lru_page(pages[i])) {
+ inc_zone_page_state(pages[i], NR_ISOLATED_ANON +
+page_is_file_cache(pages[i]));
+ list_add_tail(&pages[i]->lru, &pagelist);
+ } else {
+ isolate_err = 1;
+ goto put_page;
+ }
isolate_lru_page() takes the LRU lock every time.
Credit to Michal Hocko for bringing this up but with the number of
other issues I missed that this is also broken with respect to huge page
handling. hugetlbfs pages will not be on the LRU so the isolation will mess
up and the migration has to be handled differently. Ordinarily hugetlbfs
pages cannot be allocated from ZONE_MOVABLE but it is possible to configure
it to be allowed via /proc/sys/vm/hugepages_treat_as_movable. If this
encounters a hugetlbfs page, it'll just blow up.
As you said, hugetlbfs pages are not in LRU list, then how can encounter
a hugetlbfs page and blow up?
The other is that this almost certainly broken for transhuge page
handling. gup returns the head and tail pages and ordinarily this is ok
When need gup thp? in kvm case?
because the caller only cares about the physical address. Migration will
also split a hugepage if it receives it but you are potentially adding
tail pages to a list here and then migrating them. The split of the first
page will get very confused. I'm not exactly sure what the result will be
but it won't be pretty.
Was THP enabled when this was tested? Was CONFIG_DEBUG_LIST enabled
during testing?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] dw_dmac: introduce generic DMA binding for DT
On Wed, Feb 20, 2013 at 09:50:25AM +, Arnd Bergmann wrote: > On Wednesday 20 February 2013, Vinod Koul wrote: > > Since there is still churn, would it make sense if I just revert the > > SPEAr13xx > > patch (your first patch) and send a pull request to Linus. > > Since there are no users and not much testing has been done, I think we can > > push > > these to 3.10 via arm-soc/slave-dma tree. > > > > Gives more testing and usage will go along as well. > > Since merge window is open, I would like my pull to go soonish and not > > churn the > > tree much. > > Reverting the SPEAr13xx would definitely help, yes. The reason why I'd also > like > to see the second patch get merged is so that we can do the SPEAr changes in > 3.10 > without having an interdependency between the trees. I tried very hard to > make the patch have a minimal impact on the non-DT code path to avoid > regressions. Ok, i have applied your revert patch. Will send the PULL to linus by friday. > Maybe you can send your tree now with just the revert applied, and then send > the > other one separately next week along with any bug fixes that may have > accumulated > by then? And then makes sense to send second PULL with fixes accumulated and the second patch, so that 3.10 is easier for all. think we can compact() patch is second request as well -- ~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: general protection fault in do_msgrcv [3.8]
On Wed, Feb 20, 2013 at 12:23:22PM +0400, Stanislav Kinsbursky wrote:
> 19.02.2013 22:04, Dave Jones пишет:
> >general protection fault: [#1] PREEMPT SMP DEBUG_PAGEALLOC
> >Modules linked in: can af_rxrpc binfmt_misc scsi_transport_iscsi ax25
> >ipt_ULOG decnet nfc appletalk x25 rds ipx p8023 psnap p8022 llc irda
> >crc_ccitt atm lockd sunrpc ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6
> >xt_conntrack nf_conntrack ip6table_filter ip6_tables btusb bluetooth
> >snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_pcm edac_core
> >snd_page_alloc snd_timer microcode rfkill usb_debug serio_raw pcspkr snd
> >soundcore vhost_net r8169 mii tun macvtap macvlan kvm_amd kvm
> >CPU 2
> >Pid: 887, comm: trinity-child2 Not tainted 3.8.0+ #57 Gigabyte Technology
> >Co., Ltd. GA-MA78GM-S2H/GA-MA78GM-S2H
> >RIP: 0010:[] [] do_msgrcv+0x22a/0x670
> >RSP: 0018:88011892be88 EFLAGS: 00010297
> >RAX: RBX: 0001 RCX: 4000
> >RDX: 7adea6f6 RSI: 6b6b6b6b6b6b6b6b RDI: 8801189ffb60
> >RBP: 88011892bf68 R08: 0001 R09:
> >R10: R11: R12:
> >R13: 8801189ffc10 R14: 8801189ffb60 R15: 6b6b6b6b6b6b6b6b
> >FS: 7f681e955740() GS:88012f20() knlGS:
> >CS: 0010 DS: ES: CR0: 80050033
> >CR2: 7f681e846064 CR3: 00012553d000 CR4: 07e0
> >DR0: DR1: DR2:
> >DR3: DR6: 0ff0 DR7: 0400
> >Process trinity-child2 (pid: 887, threadinfo 88011892a000, task
> >88010bc82490)
> >Stack:
> > 88011892beb8 88010bc82490 88010bc82490 88010bc82490
> > 8801186d8000 812ad5f0 01aba000 81c688c0
> > 7adea6f6 001f 400046a9467e 6b6b6b6b6b6b6b6b
> >Call Trace:
> > [] ? load_msg+0x180/0x180
> > [] ? trace_hardirqs_on_caller+0x115/0x1a0
> > [] ? trace_hardirqs_on_thunk+0x3a/0x3f
> > [] sys_msgrcv+0x15/0x20
> > [] system_call_fastpath+0x16/0x1b
> >Code: 84 14 01 00 00 8b 8d 74 ff ff ff 85 c9 0f 84 52 02 00 00 48 8b 95 60
> >ff ff ff 48 39 55 80 0f 84 4d 02 00 00 4c 89 bd 78 ff ff ff <4d> 8b 3f 48 ff
> >45 80 4d 39 ef 75 9a 66 90 48 81 bd 78 ff ff ff
> >RIP [] do_msgrcv+0x22a/0x670
> > RSP
> >---[ end trace d3cc044a84b1d828 ]---
> >
> >oopsing instruction is..
> >
> >0: 4d 8b 3fmov(%r15),%r15
> >
> >Looks like a use-after-free.
> >
> >Disassembly of ipc/msg.o shows this happens here..
> >
> > msg = ERR_PTR(-EAGAIN);
> > tmp = msq->q_messages.next;
> > 1537: 4d 8b be b0 00 00 00mov0xb0(%r14),%r15
> > while (tmp != &msq->q_messages) {
> > 153e: 4d 8d ae b0 00 00 00lea0xb0(%r14),%r13
> > 1545: 4d 39 efcmp%r13,%r15
> > 1548: 0f 84 5f 03 00 00 je 18ad
> > 154e: 48 c7 45 80 00 00 00movq $0x0,-0x80(%rbp)
> > 1555: 00
> > 1556: 48 c7 85 78 ff ff ffmovq
> > $0xfff5,-0x88(%rbp)
> > 155d: f5 ff ff ff
> > 1561: eb 0d jmp1570
> > 1563: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)
> > }
> > } else
> > break;
> > msg_counter++;
> > }
> > tmp = tmp->next;
> > 1568: 4d 8b 3fmov(%r15),%r15
> > if (ipcperms(ns, &msq->q_perm, S_IRUGO))
> > goto out_unlock;
> >
> > msg = ERR_PTR(-EAGAIN);
> > tmp = msq->q_messages.next;
> > while (tmp != &msq->q_messages) {
> >
> >Looks like Stanislav recently changed this code, so problem was likely
> >introduced
> >in those changes.
> >
>
> Hello.
> Is it easy to reproduce? Do you use KVM?
Jugging by motherboard name in the OOPs it is not KVM. And since r15 is
6b6b6b6b6b6b6b6b you need DEBUG_PAGEALLOC to reproduce.
--
Gleb.
--
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: Re[8]: [PATCH v3] mfd: syscon: Add non-DT support
On Wednesday 20 February 2013, Alexander Shiyan wrote: > On 20 February 2013 13:41, Alexander Shiyan wrote: > > > > One problem is that every user needs to add their syscon compatible device > > support(platform_device_id) in syscon driver first before they can use it. > > But it looks to me just like how other driver generally does. > > I agree, this is a more proper way, but in this case we should create a big > table > here with records for each device... > > > Arnd, > > Do you think this is an issue? I would first like to get an answer to the question I asked in my first mail, which is what the use case of non-DT support in this driver is. If this is used only by a new platform that has to use DT anyway, or by an existing platform that is easy enough to convert, we probably shouldn't do all this at all. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] perf: need to expose sched_clock to correlate user samples with kernel samples
On Tue, 19 Feb 2013, John Stultz wrote: > On 02/19/2013 01:50 PM, Thomas Gleixner wrote: > > 2) Doing #1 will allow to observe the described time going backwards > > scenario in kernel as well. > > > > The reason why we did not get complaints about that scenario at all > > (yet) is that the window and the probability to hit it are small > > enough. Nevertheless it's a real issue for virtualized systems. > > > > Now you came up with the great idea, that the timekeeping core is > > able to calculate what the approximate safe value is for the > > clocksource readout to be in a state where wreckage relative to the > > last update of the clocksource is not observable, not matter how > > long the scheduled out delay is and in which direction the NTP > > update is going. > > So the other bit of caution here, is I realize my idea of "valid cycle ranges" > has the potential for deadlock. > > While it should be fine for use with vdso, we have to be careful if we use > this in-kernel, because if we're in the update path, the valid interval check > could trigger the ktime_get() in hrtimer_interrupt() to spin forever. So we > need to be sure we don't use this method anywhere in the code paths that > trigger the update_wall_time() code. Hmm, right. > So some additional thinking may be necessary here. Though it may be as simple > as making sure we don't loop on the cpu that does the timekeeping update. Either that or make sure to use ktime_get_nocheck() in those code pathes. Thanks, tglx -- 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: [resend] Timer broadcast question
On Tue, 19 Feb 2013, Andy Lutomirski wrote: > On 02/19/2013 10:21 AM, Daniel Lezcano wrote: > > On 02/19/2013 07:10 PM, Thomas Gleixner wrote: > >> On Tue, 19 Feb 2013, Daniel Lezcano wrote: > >>> I am working on identifying the different wakeup sources from the > >>> interrupts and I have a question regarding the timer broadcast. > >>> > >>> The broadcast timer is setup to the next event and that will wake up any > >>> idle cpu belonging to the "broadcast cpumask", right ? > >>> > >>> The cpu which has been woken up will look for each cpu the next-event > >>> and send an IPI to wake it up. > >>> > >>> Although, it is possible the sender of this IPI may not be concerned by > >>> the timer expiration and has been woken up just for sending the IPI, > >>> right ? > >> > >> Correct. > >> > >>> If this is correct, is it possible to setup the timer irq affinity to a > >>> cpu which will be concerned by the timer expiration ? so we prevent an > >>> unnecessary wake up for a cpu. > >> > >> It is possible, but we never implemented it. > >> > >> If we go there, we want to make that conditional on a property flag, > >> because some interrupt controllers especially on x86 only allow to > >> move the affinity from interrupt context, which is pointless. > > > > Thanks Thomas for your quick answer. I will write a RFC patchset. > > I'm curious what the use case is. I played with this code awhile ago, > and AFAICT it's not used on sensible (i.e. modern) systems. Is there > anything other than old x86 machines that needs it? If the local apic timer is not affected by C-States, it's irrelevant, but there are enough machines out there which do not have that. The point is that we want a flag on the broadcast device which tells us whether we should use dynamic affinity settings or not. On x86 we would not set that flag ever. Thanks, tglx -- 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 07/16] virtio_ring: don't count elements twice for add_buf path.
On 02/19/2013 03:56 PM, Rusty Russell wrote:
> Extract the post-counting code into virtqueue_add(), make both callers
> use it.
>
> Signed-off-by: Rusty Russell
Reviewed-by: Wanlong Gao
> ---
> drivers/virtio/virtio_ring.c | 147
> +++---
> 1 file changed, 80 insertions(+), 67 deletions(-)
>
> diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
> index 27e31d3..c537385 100644
> --- a/drivers/virtio/virtio_ring.c
> +++ b/drivers/virtio/virtio_ring.c
> @@ -163,69 +163,17 @@ static int vring_add_indirect(struct vring_virtqueue
> *vq,
> return head;
> }
>
> -/**
> - * virtqueue_add_buf - expose buffer to other end
> - * @vq: the struct virtqueue we're talking about.
> - * @sg: the description of the buffer(s).
> - * @out_num: the number of sg readable by other side
> - * @in_num: the number of sg which are writable (after readable ones)
> - * @data: the token identifying the buffer.
> - * @gfp: how to do memory allocations (if necessary).
> - *
> - * Caller must ensure we don't call this with other virtqueue operations
> - * at the same time (except where noted).
> - *
> - * Returns zero or a negative error (ie. ENOSPC, ENOMEM).
> - */
> -int virtqueue_add_buf(struct virtqueue *_vq,
> - struct scatterlist sg[],
> - unsigned int out,
> - unsigned int in,
> - void *data,
> - gfp_t gfp)
> -{
> - struct scatterlist *sgs[2];
> - unsigned int i;
> -
> - sgs[0] = sg;
> - sgs[1] = sg + out;
> -
> - /* Workaround until callers pass well-formed sgs. */
> - for (i = 0; i < out + in; i++)
> - sg_unmark_end(sg + i);
> -
> - sg_mark_end(sg + out + in - 1);
> - if (out && in)
> - sg_mark_end(sg + out - 1);
> -
> - return virtqueue_add_sgs(_vq, sgs, out ? 1 : 0, in ? 1 : 0, data, gfp);
> -}
> -EXPORT_SYMBOL_GPL(virtqueue_add_buf);
> -
> -/**
> - * virtqueue_add_sgs - expose buffers to other end
> - * @vq: the struct virtqueue we're talking about.
> - * @sgs: array of terminated scatterlists.
> - * @out_num: the number of scatterlists readable by other side
> - * @in_num: the number of scatterlists which are writable (after readable
> ones)
> - * @data: the token identifying the buffer.
> - * @gfp: how to do memory allocations (if necessary).
> - *
> - * Caller must ensure we don't call this with other virtqueue operations
> - * at the same time (except where noted).
> - *
> - * Returns zero or a negative error (ie. ENOSPC, ENOMEM).
> - */
> -int virtqueue_add_sgs(struct virtqueue *_vq,
> - struct scatterlist *sgs[],
> - unsigned int out_sgs,
> - unsigned int in_sgs,
> - void *data,
> - gfp_t gfp)
> +static int virtqueue_add(struct virtqueue *_vq,
> + struct scatterlist *sgs[],
> + unsigned int total_sg,
> + unsigned int out_sgs,
> + unsigned int in_sgs,
> + void *data,
> + gfp_t gfp)
> {
> struct vring_virtqueue *vq = to_vvq(_vq);
> struct scatterlist *sg;
> - unsigned int i, n, avail, uninitialized_var(prev), total_sg;
> + unsigned int i, n, avail, uninitialized_var(prev);
> int head;
>
> START_USE(vq);
> @@ -245,13 +193,6 @@ int virtqueue_add_sgs(struct virtqueue *_vq,
> }
> #endif
>
> - /* Count them first. */
> - for (i = total_sg = 0; i < out_sgs + in_sgs; i++) {
> - struct scatterlist *sg;
> - for (sg = sgs[i]; sg; sg = sg_next(sg))
> - total_sg++;
> - }
> -
> /* If the host supports indirect descriptor tables, and we have multiple
>* buffers, then go indirect. FIXME: tune this threshold */
> if (vq->indirect && total_sg > 1 && vq->vq.num_free) {
> @@ -329,6 +270,78 @@ add_head:
>
> return 0;
> }
> +
> +/**
> + * virtqueue_add_buf - expose buffer to other end
> + * @vq: the struct virtqueue we're talking about.
> + * @sg: the description of the buffer(s).
> + * @out_num: the number of sg readable by other side
> + * @in_num: the number of sg which are writable (after readable ones)
> + * @data: the token identifying the buffer.
> + * @gfp: how to do memory allocations (if necessary).
> + *
> + * Caller must ensure we don't call this with other virtqueue operations
> + * at the same time (except where noted).
> + *
> + * Returns zero or a negative error (ie. ENOSPC, ENOMEM).
> + */
> +int virtqueue_add_buf(struct virtqueue *_vq,
> + struct scatterlist sg[],
> + unsigned int out,
> + unsigned int in,
> + void *data,
> + gfp_t gfp)
> +{
> + struct scatterlist *sgs[2];
> + unsigned int i;
> +
> + sgs[0] = sg;
> + sgs[1] = sg + out;
> +
> + /* Workaround u
Re: [PATCH 08/16] virtio_ring: virtqueue_add_outbuf / virtqueue_add_inbuf.
On 02/19/2013 03:56 PM, Rusty Russell wrote:
> These are specialized versions of virtqueue_add_buf(), which cover
> over 50% of cases and are far clearer.
>
> In particular, the scatterlists passed to these functions don't have
> to be clean (ie. we ignore end markers).
>
> FIXME: I'm not sure about the unclean sglist bit. I had a more
> ambitious one which conditionally ignored end markers in the iterator,
> but it was ugly and I suspect this is just as fast. Maybe we should
> just fix all the drivers?
>
> Signed-off-by: Rusty Russell
Reviewed-by: Wanlong Gao
> ---
> drivers/virtio/virtio_ring.c | 58
> ++
> include/linux/virtio.h | 10
> 2 files changed, 68 insertions(+)
>
> diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
> index c537385..fb282b5 100644
> --- a/drivers/virtio/virtio_ring.c
> +++ b/drivers/virtio/virtio_ring.c
> @@ -345,6 +345,64 @@ int virtqueue_add_sgs(struct virtqueue *_vq,
> EXPORT_SYMBOL_GPL(virtqueue_add_sgs);
>
> /**
> + * virtqueue_add_outbuf - expose output buffers to other end
> + * @vq: the struct virtqueue we're talking about.
> + * @sgs: array of scatterlists (need not be terminated!)
> + * @num: the number of scatterlists readable by other side
> + * @data: the token identifying the buffer.
> + * @gfp: how to do memory allocations (if necessary).
> + *
> + * Caller must ensure we don't call this with other virtqueue operations
> + * at the same time (except where noted).
> + *
> + * Returns zero or a negative error (ie. ENOSPC, ENOMEM).
> + */
> +int virtqueue_add_outbuf(struct virtqueue *vq,
> + struct scatterlist sg[], unsigned int num,
> + void *data,
> + gfp_t gfp)
> +{
> + unsigned int i;
> +
> + /* We're about to iterate, so this is pretty cheap. */
> + for (i = 0; i < num - 1; i++)
> + sg_unmark_end(sg + i);
> + sg_mark_end(sg + i);
> +
> + return virtqueue_add(vq, &sg, num, 1, 0, data, gfp);
> +}
> +EXPORT_SYMBOL_GPL(virtqueue_add_outbuf);
> +
> +/**
> + * virtqueue_add_inbuf - expose input buffers to other end
> + * @vq: the struct virtqueue we're talking about.
> + * @sgs: array of scatterlists (need not be terminated!)
> + * @num: the number of scatterlists writable by other side
> + * @data: the token identifying the buffer.
> + * @gfp: how to do memory allocations (if necessary).
> + *
> + * Caller must ensure we don't call this with other virtqueue operations
> + * at the same time (except where noted).
> + *
> + * Returns zero or a negative error (ie. ENOSPC, ENOMEM).
> + */
> +int virtqueue_add_inbuf(struct virtqueue *vq,
> + struct scatterlist sg[], unsigned int num,
> + void *data,
> + gfp_t gfp)
> +{
> + unsigned int i;
> +
> + /* We're about to iterate, so this is pretty cheap. */
> + for (i = 0; i < num - 1; i++)
> + sg_unmark_end(sg + i);
> + sg_mark_end(sg + i);
> +
> + return virtqueue_add(vq, &sg, num, 0, 1, data, gfp);
> +}
> +EXPORT_SYMBOL_GPL(virtqueue_add_inbuf);
> +
> +/**
> * virtqueue_kick_prepare - first half of split virtqueue_kick call.
> * @vq: the struct virtqueue
> *
> diff --git a/include/linux/virtio.h b/include/linux/virtio.h
> index 6eff15b..b442500 100644
> --- a/include/linux/virtio.h
> +++ b/include/linux/virtio.h
> @@ -40,6 +40,16 @@ int virtqueue_add_buf(struct virtqueue *vq,
> void *data,
> gfp_t gfp);
>
> +int virtqueue_add_outbuf(struct virtqueue *vq,
> + struct scatterlist sg[], unsigned int num,
> + void *data,
> + gfp_t gfp);
> +
> +int virtqueue_add_inbuf(struct virtqueue *vq,
> + struct scatterlist sg[], unsigned int num,
> + void *data,
> + gfp_t gfp);
> +
> int virtqueue_add_sgs(struct virtqueue *vq,
> struct scatterlist *sgs[],
> unsigned int out_sgs,
>
--
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 09/16] virtio_net: use simplified virtqueue accessors.
On 02/19/2013 03:56 PM, Rusty Russell wrote: > We never add buffers with input and output parts, so use the new accessors. > > Signed-off-by: Rusty Russell Reviewed-by: Wanlong Gao > --- > drivers/net/virtio_net.c | 11 +-- > 1 file changed, 5 insertions(+), 6 deletions(-) > > diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c > index dbd5cd1..8ca69c0 100644 > --- a/drivers/net/virtio_net.c > +++ b/drivers/net/virtio_net.c > @@ -443,7 +443,7 @@ static int add_recvbuf_small(struct receive_queue *rq, > gfp_t gfp) > > skb_to_sgvec(skb, rq->sg + 1, 0, skb->len); > > - err = virtqueue_add_buf(rq->vq, rq->sg, 0, 2, skb, gfp); > + err = virtqueue_add_inbuf(rq->vq, rq->sg, 2, skb, gfp); > if (err < 0) > dev_kfree_skb(skb); > > @@ -488,8 +488,8 @@ static int add_recvbuf_big(struct receive_queue *rq, > gfp_t gfp) > > /* chain first in list head */ > first->private = (unsigned long)list; > - err = virtqueue_add_buf(rq->vq, rq->sg, 0, MAX_SKB_FRAGS + 2, > - first, gfp); > + err = virtqueue_add_inbuf(rq->vq, rq->sg, MAX_SKB_FRAGS + 2, > + first, gfp); > if (err < 0) > give_pages(rq, first); > > @@ -507,7 +507,7 @@ static int add_recvbuf_mergeable(struct receive_queue > *rq, gfp_t gfp) > > sg_init_one(rq->sg, page_address(page), PAGE_SIZE); > > - err = virtqueue_add_buf(rq->vq, rq->sg, 0, 1, page, gfp); > + err = virtqueue_add_inbuf(rq->vq, rq->sg, 1, page, gfp); > if (err < 0) > give_pages(rq, page); > > @@ -710,8 +710,7 @@ static int xmit_skb(struct send_queue *sq, struct sk_buff > *skb) > sg_set_buf(sq->sg, &hdr->hdr, sizeof hdr->hdr); > > num_sg = skb_to_sgvec(skb, sq->sg + 1, 0, skb->len) + 1; > - return virtqueue_add_buf(sq->vq, sq->sg, num_sg, > - 0, skb, GFP_ATOMIC); > + return virtqueue_add_outbuf(sq->vq, sq->sg, num_sg, skb, GFP_ATOMIC); > } > > static netdev_tx_t start_xmit(struct sk_buff *skb, struct net_device *dev) > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] backlight: lp855x_bl: support new LP8557 device
On Tue, 19 Feb 2013 20:40:25 -0800, Kim, Milo wrote: > > To support new device LP8557, LP855x device initialization process should be > changed. > This patch-set enables re-designing LP855x driver architecture and > supporting LP8557 device. > Milo(Woogyom) Kim (3): > backlight: lp855x_bl: introduce device configuration flow > backlight: lp855x_bl: support new LP8557 device > backlight: lp855x_bl: simplify bl_get_brightness() These patches look good. Acked-by: Jingoo Han Best regards, Jingoo Han > > Documentation/backlight/lp855x-driver.txt |4 +- > drivers/video/backlight/Kconfig |2 +- > drivers/video/backlight/lp855x_bl.c | 169 > ++--- > include/linux/platform_data/lp855x.h | 19 > 4 files changed, 152 insertions(+), 42 deletions(-) > > -- > 1.7.9.5 > > > Best Regards, > Milo >
Re: general protection fault in do_msgrcv [3.8]
20.02.2013 14:03, Gleb Natapov пишет:
On Wed, Feb 20, 2013 at 12:23:22PM +0400, Stanislav Kinsbursky wrote:
19.02.2013 22:04, Dave Jones пишет:
general protection fault: [#1] PREEMPT SMP DEBUG_PAGEALLOC
Modules linked in: can af_rxrpc binfmt_misc scsi_transport_iscsi ax25 ipt_ULOG
decnet nfc appletalk x25 rds ipx p8023 psnap p8022 llc irda crc_ccitt atm lockd
sunrpc ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_conntrack nf_conntrack
ip6table_filter ip6_tables btusb bluetooth snd_hda_codec_realtek snd_hda_intel
snd_hda_codec snd_pcm edac_core snd_page_alloc snd_timer microcode rfkill
usb_debug serio_raw pcspkr snd soundcore vhost_net r8169 mii tun macvtap
macvlan kvm_amd kvm
CPU 2
Pid: 887, comm: trinity-child2 Not tainted 3.8.0+ #57 Gigabyte Technology Co.,
Ltd. GA-MA78GM-S2H/GA-MA78GM-S2H
RIP: 0010:[] [] do_msgrcv+0x22a/0x670
RSP: 0018:88011892be88 EFLAGS: 00010297
RAX: RBX: 0001 RCX: 4000
RDX: 7adea6f6 RSI: 6b6b6b6b6b6b6b6b RDI: 8801189ffb60
RBP: 88011892bf68 R08: 0001 R09:
R10: R11: R12:
R13: 8801189ffc10 R14: 8801189ffb60 R15: 6b6b6b6b6b6b6b6b
FS: 7f681e955740() GS:88012f20() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: 7f681e846064 CR3: 00012553d000 CR4: 07e0
DR0: DR1: DR2:
DR3: DR6: 0ff0 DR7: 0400
Process trinity-child2 (pid: 887, threadinfo 88011892a000, task
88010bc82490)
Stack:
88011892beb8 88010bc82490 88010bc82490 88010bc82490
8801186d8000 812ad5f0 01aba000 81c688c0
7adea6f6 001f 400046a9467e 6b6b6b6b6b6b6b6b
Call Trace:
[] ? load_msg+0x180/0x180
[] ? trace_hardirqs_on_caller+0x115/0x1a0
[] ? trace_hardirqs_on_thunk+0x3a/0x3f
[] sys_msgrcv+0x15/0x20
[] system_call_fastpath+0x16/0x1b
Code: 84 14 01 00 00 8b 8d 74 ff ff ff 85 c9 0f 84 52 02 00 00 48 8b 95 60 ff ff ff
48 39 55 80 0f 84 4d 02 00 00 4c 89 bd 78 ff ff ff <4d> 8b 3f 48 ff 45 80 4d 39
ef 75 9a 66 90 48 81 bd 78 ff ff ff
RIP [] do_msgrcv+0x22a/0x670
RSP
---[ end trace d3cc044a84b1d828 ]---
oopsing instruction is..
0: 4d 8b 3fmov(%r15),%r15
Looks like a use-after-free.
Disassembly of ipc/msg.o shows this happens here..
msg = ERR_PTR(-EAGAIN);
tmp = msq->q_messages.next;
1537: 4d 8b be b0 00 00 00mov0xb0(%r14),%r15
while (tmp != &msq->q_messages) {
153e: 4d 8d ae b0 00 00 00lea0xb0(%r14),%r13
1545: 4d 39 efcmp%r13,%r15
1548: 0f 84 5f 03 00 00 je 18ad
154e: 48 c7 45 80 00 00 00movq $0x0,-0x80(%rbp)
1555: 00
1556: 48 c7 85 78 ff ff ffmovq $0xfff5,-0x88(%rbp)
155d: f5 ff ff ff
1561: eb 0d jmp1570
1563: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)
}
} else
break;
msg_counter++;
}
tmp = tmp->next;
1568: 4d 8b 3fmov(%r15),%r15
if (ipcperms(ns, &msq->q_perm, S_IRUGO))
goto out_unlock;
msg = ERR_PTR(-EAGAIN);
tmp = msq->q_messages.next;
while (tmp != &msq->q_messages) {
Looks like Stanislav recently changed this code, so problem was likely
introduced
in those changes.
Hello.
Is it easy to reproduce? Do you use KVM?
Jugging by motherboard name in the OOPs it is not KVM. And since r15 is
6b6b6b6b6b6b6b6b you need DEBUG_PAGEALLOC to reproduce.
Ok, thanks!
--
Best regards,
Stanislav Kinsbursky
--
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] perf, x86: add Intel IvyBridge event scheduling constraints
Intel IvyBridge processor has different constraints compared
to SandyBridge. Therefore it needs its own contraint table.
This patch adds the constraint table. Without this patch,
the events listed in the patch may not be scheduled correctly
and bogus counts may be collected.
Signed-off-by: Stephane Eranian
---
arch/x86/kernel/cpu/perf_event_intel.c | 23 ++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kernel/cpu/perf_event_intel.c
b/arch/x86/kernel/cpu/perf_event_intel.c
index 4914e94..529c893 100644
--- a/arch/x86/kernel/cpu/perf_event_intel.c
+++ b/arch/x86/kernel/cpu/perf_event_intel.c
@@ -107,6 +107,27 @@ static struct event_constraint
intel_snb_event_constraints[] __read_mostly =
EVENT_CONSTRAINT_END
};
+static struct event_constraint intel_ivb_event_constraints[] __read_mostly =
+{
+ FIXED_EVENT_CONSTRAINT(0x00c0, 0), /* INST_RETIRED.ANY */
+ FIXED_EVENT_CONSTRAINT(0x003c, 1), /* CPU_CLK_UNHALTED.CORE */
+ FIXED_EVENT_CONSTRAINT(0x0300, 2), /* CPU_CLK_UNHALTED.REF */
+ INTEL_UEVENT_CONSTRAINT(0x0148, 0x4), /* L1D_PEND_MISS.PENDING */
+ INTEL_UEVENT_CONSTRAINT(0x0279, 0xf), /* IDQ.EMTPY */
+ INTEL_UEVENT_CONSTRAINT(0x019c, 0xf), /* IDQ_UOPS_NOT_DELIVERED.CORE */
+ INTEL_UEVENT_CONSTRAINT(0x04a3, 0xf), /*
CYCLE_ACTIVITY.CYCLES_NO_EXECUTE */
+ INTEL_UEVENT_CONSTRAINT(0x05a3, 0xf), /*
CYCLE_ACTIVITY.STALLS_L2_PENDING */
+ INTEL_UEVENT_CONSTRAINT(0x06a3, 0xf), /*
CYCLE_ACTIVITY.STALLS_LDM_PENDING */
+ INTEL_UEVENT_CONSTRAINT(0x08a3, 0x4), /*
CYCLE_ACTIVITY.CYCLES_L1D_PENDING */
+ INTEL_UEVENT_CONSTRAINT(0x0ca3, 0x4), /*
CYCLE_ACTIVITY.STALLS_L1D_PENDING */
+ INTEL_UEVENT_CONSTRAINT(0x01c0, 0x2), /* INST_RETIRED.PREC_DIST */
+ INTEL_EVENT_CONSTRAINT(0xd0, 0xf), /* MEM_UOPS_RETIRED.* */
+ INTEL_EVENT_CONSTRAINT(0xd1, 0xf), /* MEM_LOAD_UOPS_RETIRED.* */
+ INTEL_EVENT_CONSTRAINT(0xd2, 0xf), /* MEM_LOAD_UOPS_LLC_HIT_RETIRED.* */
+ INTEL_EVENT_CONSTRAINT(0xd3, 0xf), /* MEM_LOAD_UOPS_LLC_MISS_RETIRED.*
*/
+ EVENT_CONSTRAINT_END
+};
+
static struct extra_reg intel_westmere_extra_regs[] __read_mostly =
{
INTEL_EVENT_EXTRA_REG(0xb7, MSR_OFFCORE_RSP_0, 0x, RSP_0),
@@ -2095,7 +2116,7 @@ __init int intel_pmu_init(void)
intel_pmu_lbr_init_snb();
- x86_pmu.event_constraints = intel_snb_event_constraints;
+ x86_pmu.event_constraints = intel_ivb_event_constraints;
x86_pmu.pebs_constraints = intel_ivb_pebs_event_constraints;
x86_pmu.pebs_aliases = intel_pebs_aliases_snb;
x86_pmu.extra_regs = intel_snb_extra_regs;
--
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] Fix rq->lock vs logbuf_lock unlock race
On Wed, 2013-02-20 at 09:38 +, Bu, Yitian wrote: > > 2. from printk comment: "This is printk(). It can be called from any > context. > We want it to work. ". I suppose to use printk in any context. Unfortunately that's not quite possible, rq->lock is really out of bounds. At one point I tried 'fixing' this but there's a whole bunch of nasty that's not going to go away. I've since forgotten most of the details, but aside from logbuf problems there's a whole host of issues with the console drivers themselves as well. If you really want to do this, use early_printk. -- 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] [media] stv090x: do not unlock unheld mutex in stv090x_sleep()
On 02/20/2013 10:58 AM, Manu Abraham wrote: > Hi, > > On Wed, Feb 20, 2013 at 12:28 AM, Alexey Khoroshilov > wrote: >> goto err and goto err_gateoff before mutex_lock(&state->internal->demod_lock) >> lead to unlock of unheld mutex in stv090x_sleep(). > Out of curiosity, what happens when you try to unlock an unlocked mutex ? > > Regards, > Manu > Bad things can happen if someone else holds the mutex and it becomes unexpectedly unlocked. Also it can result that the next lock() operation leaves the mutex in unlocked state. The both cases can lead to data races with unpredictable consequences. -- Alexey Khoroshilov -- 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] perf: need to expose sched_clock to correlate user samples with kernel samples
On Tue, 2013-02-19 at 10:25 -0800, John Stultz wrote: > So describe how the perf time domain is different then > CLOCK_MONOTONIC_RAW. The primary difference is that the trace/sched/perf time domain is not strictly monotonic, it is only locally monotonic -- that is two time stamps taken on the same cpu are guaranteed to be monotonic. Furthermore, to make it useful, there's an actual bound on the inter-cpu drift (implemented by limiting the drift to CLOCK_MONOTONIC). Additionally -- to increase use -- we also added a monotonic sync point when cpu A queries time of cpu B. > My concern here is that we're basically creating a kernel interface > that > exports implementation-defined semantics (again: whatever perf does > right now). And I think folks want to do this, because adding > CLOCK_PERF > is easier then trying to: > > 1) Get a lock-free method for accessing CLOCK_MONOTONIC_RAW > > 2) Having perf interpolate its timestamps to CLOCK_MONOTONIC, or > CLOCKMONOTONIC_RAW when it exports the data Mostly cheaper, not easier. Given unstable TSC, MONOTONIC will have to fall back to another clock source (hpet, acpi_pm and other assorted crap). In order to avoid this, we'd had to relax the requirements. Using anything other than TSC is simply not an option. -- 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] lockdep: check that no locks held at freeze time
* Mandeep Singh Baines wrote: > We shouldn't try_to_freeze if locks are held. Verified that > I get no lockdep warnings after applying this patch and > "vfork: don't freezer_count() for in-kernel users of CLONE_VFORK". > > Changes since v1: > * LKML: <20130215111635.ga26...@gmail.com> Ingo Molnar > * Added a msg string that gets passed in. > * LKML: <20130215154449.gd30...@redhat.com> Oleg Nesterov > * Check PF_NOFREEZE in try_to_freeze(). > Changes since v2: > * LKML: <20130216170605.gc4...@redhat.com> Oleg Nesterov > * Avoid unnecessary PF_NOFREEZE check when !CONFIG_LOCKDEP. > * Mandeep Singh Baines > * Generalize an exit specific printk. > > Signed-off-by: Mandeep Singh Baines > CC: Oleg Nesterov > CC: Tejun Heo > CC: Andrew Morton > CC: Rafael J. Wysocki > CC: Ingo Molnar Looks good to me now. Acked-by: Ingo Molnar Which tree should this go through? Thanks, Ingo -- 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] arm: use built-in byte swap function
On Tue, 2013-02-19 at 22:17 -0500, Nicolas Pitre wrote: > > > +$(obj)/bswapsdi2.o: $(obj)/../../../../arch/$(SRCARCH)/lib/bswapsdi2.o > > + $(call cmd,shipped) > > + > > I don't think you can get away with this. The decompressor code is > compiled with -fpic and the main kernel is not. Most toolchains do mark > object files with some flags to prevent the link of incompatible objects > together (normally pic and non pic objects are not compatible even if in > this very simple case that would not matter). Maybe you are able to > link zImage successfully simply because no references to __bswap* needed > to be resolved and therefore the linker didn't need to search/include > that object? This, and the issue with -Os vs. -O2, make me inclined to suggest that we should just provide an asm version of these functions instead of using the compiler. -- Sent with MeeGo's ActiveSync support. David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH] [SCSI] aacraid: silence two GCC warnings
On Sat, 2013-02-09 at 21:09 +0100, Paul Bolle wrote:
> Compiling src.o for a 32 bit system triggers two GCC warnings:
> drivers/scsi/aacraid/src.c: In function ‘aac_src_deliver_message’:
> drivers/scsi/aacraid/src.c:410:3: warning: right shift count >= width of
> type [enabled by default]
> drivers/scsi/aacraid/src.c:434:2: warning: right shift count >= width of
> type [enabled by default]
>
> Silence these warnings by casting the 'address' variable (of type
> dma_addr_t) to u64 on those two lines.
>
> Signed-off-by: Paul Bolle
> ---
> 0) Compile tested only.
>
> 1) Changing '0L' to 'OUL' might be a bit of cargo cult programming. I
> doubt it's necessary. Members of that cult might also change
> '0x' to '0xUL', but I didn't.
>
> drivers/scsi/aacraid/src.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/scsi/aacraid/src.c b/drivers/scsi/aacraid/src.c
> index 3b021ec..dfa8a37 100644
> --- a/drivers/scsi/aacraid/src.c
> +++ b/drivers/scsi/aacraid/src.c
> @@ -407,7 +407,7 @@ static int aac_src_deliver_message(struct fib *fib)
> fib->hw_fib_va->header.StructType = FIB_MAGIC2;
> fib->hw_fib_va->header.SenderFibAddress = (u32)address;
> fib->hw_fib_va->header.u.TimeStamp = 0;
> - BUG_ON((u32)(address >> 32) != 0L);
> + BUG_ON(((u64)address >> 32) != 0UL);
Actually, this isn't the right way to do this. The correct way would be
address >> 16 >> 16, but no-one is expected to remember this, so we have
it macroised in kernel.h as upper_32_bits().
So this should become
BUG_ON(upper_32_bits(address) != 0L);
and a similar change for the below.
James
> address |= fibsize;
> } else {
> /* Calculate the amount to the fibsize bits */
> @@ -431,7 +431,7 @@ static int aac_src_deliver_message(struct fib *fib)
> address |= fibsize;
> }
>
> - src_writel(dev, MUnit.IQ_H, (address >> 32) & 0x);
> + src_writel(dev, MUnit.IQ_H, ((u64)address >> 32) & 0x);
> src_writel(dev, MUnit.IQ_L, address & 0x);
>
> 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/
Re: [PATCH 0/4] rwsem: Implement writer lock-stealing
* Alex Shi wrote: > > Alex, could you go through my patch and see if there is > > anything you find objectionable ? (if not about the details, > > at least about the general approach of enabling writer lock > > stealing on the fast path) > > I did a quick review on the patchset and tested the patches > 1~3, and 1~3 plus 4th, my patch plus 4th. > > The patch looks much complicated, and also goes writing slow > path to steal locking. My patch looks quite straight and > simple. > > This 1~3 patch has very very similar performance effect with > mine. > > The highlight patch is the 4th, seems it can provide about ~2% > aim7 performance gain(base on both of mine or patches 1~3) on > my 4S NHM EX machine. That speedup would be nice to have. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 7/7] ACPI / scan: Make memory hotplug driver use struct acpi_scan_handler
Hi Yasuaki,
On Wed, Feb 20, 2013 at 12:35:48PM +0900, Yasuaki Ishimatsu wrote:
> Hi Vasilis,
>
> 2013/02/20 3:11, Vasilis Liaskovitis wrote:
> >Hi,
> >
> >On Sun, Feb 17, 2013 at 04:27:18PM +0100, Rafael J. Wysocki wrote:
> >>From: Rafael J. Wysocki
> >>
> >>Make the ACPI memory hotplug driver use struct acpi_scan_handler
> >>for representing the object used to set up ACPI memory hotplug
> >>functionality and to remove hotplug memory ranges and data
> >>structures used by the driver before unregistering ACPI device
> >>nodes representing memory. Register the new struct acpi_scan_handler
> >>object with the help of acpi_scan_add_handler_with_hotplug() to allow
> >>user space to manipulate the attributes of the memory hotplug
> >>profile.
> >
> >Let's consider an example where we want acpi memory device ejection to be
> >safely
> >handled by userspace. We do the following:
> >
> >echo 0 > /sys/firmware/acpi/hotplug/memory/autoeject
> >echo 1 > /sys/firmware/acpi/hotplug/memory/uevents
> >
> >We succesfully hotplug acpi device:
> >/sys/devices/LNXSYSTM:00/LNXSYSBUS:00/PNP0C80:00
> >and its corresponding memblocks /sys/devices/system/memory/memoryXX are
> >also successfully onlined.
> >
> >On an eject request, since uevents == 1, the kernel will emit KOBJ_OFFLINE
> >for:
> >/sys/devices/LNXSYSTM:00/LNXSYSBUS:00/PNP0C80:00
> >
> >Can userspace know which memblocks in /sys/devices/system/memory/memoryXX/
> >correspond to the acpi device
> >/sys/devices/LNXSYSTM:00/LNXSYSBUS:00/PNP0C80:00 ?
> >This will be needed so that userspace tries to offline the memblocks (and
> >only
> >if successful, issue the eject operation on the acpi device). As far as I
> >see,
> >we don't create any sysfs links or files for this scenario - can userspace
> >get
> >this info somehow?
>
> >
> >/sys/devices/system/memory/memoryXX/phys_device needs to be properly
> >implemented
> >for this to work I think, see Documentation/ABI/testing/sysfs-memory
> >
> >The following test patch works toward that direction. Let me know if it's of
> >interest or if there are better ideas /comments.
>
> How about use ../PNP0C80:00/physical_node/resources file?
> In my system, the file shows following information.
>
> $ cat /sys/bus/acpi/devices/PNP0C80\:00/physical_node/resources
> state = active
> mem 0x0-0x8000
> mem 0x1-0x8
>
> It means PNP0C80:00's memory ranges are "0x0-0x7fff" and
> "0x1-0x7". In x86 architecture, memory section size is
> 128MiB. So, if these memory range is divided by 128MiB, you can
> calculate memory section number as follow:
>
> 0x0-0x7fff => 0x0-0x10
> 0x1-0x7 => 0x20-0xff
>
> But there is one problem. The problem is that resources file of added memory
> is not created. If the problem is fixed, I think you can use the way.
thanks for your suggestion. Is this resources file a property of the
physical_node or of each acpi devices?
If it's a node specific file could there be a chance that adjacent memory
ranges get merged? We 'd like these to not get merged.
I will look more into this property. I don't see it currently in my system
(probably because initial memory is not backed by acpi devices in my
seabios/virtual machine).
>
[...]
> >+int acpi_memory_phys_device(unsigned long start_pfn)
> >+{
> >+struct acpi_memory_device *mem_dev;
> >+struct acpi_memory_info *info;
> >+unsigned long start_addr = start_pfn << PAGE_SHIFT;
> >+int id = 0;
> >+
> >+list_for_each_entry(mem_dev, &acpi_mem_device_list, mem_device_list) {
> >+list_for_each_entry(info, &mem_dev->res_list, list) {
> >+if ((info->start_addr <= start_addr) &&
> >+(info->start_addr + info->length > start_addr))
> >+return id;
> >+}
> >+id++;
> >+}
>
> I don't think this solve your problem.
>
> When hot adding memory device in my system, consecutive index number is
> applied to PNP0C80 as follows:
>
> $ ls /sys/bus/acpi/devices/ |grep PNP0C80
> PNP0C80:00
> PNP0C80:01 => hot added memory device
> PNP0C80:02 => hot added memory device
>
> In this case, we can know PNP0C80:YY by memoryXX/phys_device file.
> But if hot removing and adding the same device, index number is changed
> as follows:
>
> $ ls /sys/bus/acpi/devices/
> PNP0C80:00
> PNP0C80:03 => hot added memory device
> PNP0C80:04 => hot added memory device
>
> In this case, we cannot know PNP0C80:YY by memoryXX/phys_device file.
>
thanks, yes you are right. I forgot each new hotplug event will create a new
PNP0C80:XX device where XX always increases. So the hot-add/hot-remove/hot-add
scenario would have a problem.
Then it would be enough to be able to return this monotonically increasing
counter from phys_device instead of the current list iterator. Is this counter
available somehwere in drivers/acpi/scan.c or bus.c? I 'll take a look.
thanks,
- Vasilis
--
To unsubscribe from this list: se
Re: [PATCH 06/35] mfd: ab8500-core: Sysfs chip id modification
On Wed, 20 Feb 2013, Marcus Cooper wrote:
> On 20 February 2013 09:13, Lee Jones wrote:
> > On Tue, 19 Feb 2013, Arnd Bergmann wrote:
> >
> >> On Friday 15 February 2013, Lee Jones wrote:
> >> > struct ab8500 *ab8500;
> >> > + int chip_id = -EINVAL;
> >> >
> >> > ab8500 = dev_get_drvdata(dev);
> >> > - return sprintf(buf, "%#x\n", ab8500 ? ab8500->chip_id : -EINVAL);
> >> > + if(ab8500) {
> >> > + chip_id = ab8500->chip_id;
> >> > + if((is_ab8505(ab8500) || is_ab9540(ab8500)) &&
> >> > ab8500->version != 0xFF)
> >> > + chip_id = (ab8500->version << 8) | chip_id;
> >> > + }
> >> > + return sprintf(buf, "%#x\n", chip_id);
> >> > }
> >>
> >> What's the use of printing "ffea" for unknown versions here?
> >
> > You mean instead of -EINVAL? No idea, Marcus?
> >
> Looks like I'm guilty of just making the minimal changes. Arnd is
> right though, getting ffea(-EINVAL) back is pretty useless.
> I'll have to check user land to see what is using this.
Yes, it would be useful to know how it's parsed.
Thanks Marcus.
> Maybe not
> printing and returning 0 should be the correct behaviour
> when an unknown version is found.
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
What does the PG_swapbacked of page flags actually mean?
PG_swapbacked is a bit for page->flags. In kernel code, its comment is "page is backed by RAM/swap". But I couldn't understand it. 1. Does the RAM mean DRAM? How page is backed by RAM? 2. When the page is page-out to swap file, the bit PG_swapbacked will be set to demonstrate this page is backed by swap. Is it right? 3. In general, when will call SetPageSwapBacked() to set the bit? Could anybody kindly explain for me? Thanks very much. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/9] remoteproc: Refactor function rproc_elf_find_rsc_table
Hi Sjur,
Sorry for the (very) late reply.
On Sun, Feb 10, 2013 at 12:39:05PM +0100, sjur.brandel...@stericsson.com wrote:
> From: Sjur Brændeland
>
> Refactor rproc_elf_find_rsc_table and split out the scanning
> for the section header named resource table. This is done to
> prepare for loading firmware once.
>
> Signed-off-by: Sjur Brændeland
> ---
> drivers/remoteproc/remoteproc_elf_loader.c | 79
> ++--
> 1 files changed, 52 insertions(+), 27 deletions(-)
>
> diff --git a/drivers/remoteproc/remoteproc_elf_loader.c
> b/drivers/remoteproc/remoteproc_elf_loader.c
> index 0d36f94..a958950 100644
> --- a/drivers/remoteproc/remoteproc_elf_loader.c
> +++ b/drivers/remoteproc/remoteproc_elf_loader.c
> @@ -208,38 +208,19 @@ rproc_elf_load_segments(struct rproc *rproc, const
> struct firmware *fw)
> return ret;
> }
>
> -/**
> - * rproc_elf_find_rsc_table() - find the resource table
> - * @rproc: the rproc handle
> - * @fw: the ELF firmware image
> - * @tablesz: place holder for providing back the table size
> - *
> - * This function finds the resource table inside the remote processor's
> - * firmware. It is used both upon the registration of @rproc (in order
> - * to look for and register the supported virito devices), and when the
> - * @rproc is booted.
> - *
> - * Returns the pointer to the resource table if it is found, and write its
> - * size into @tablesz. If a valid table isn't found, NULL is returned
> - * (and @tablesz isn't set).
> - */
> -static struct resource_table *
> -rproc_elf_find_rsc_table(struct rproc *rproc, const struct firmware *fw,
> - int *tablesz)
> +static struct elf32_shdr *
> +find_rsc_shdr(struct device *dev, struct elf32_hdr *ehdr, size_t fw_size)
> {
> - struct elf32_hdr *ehdr;
> struct elf32_shdr *shdr;
> + int i;
> const char *name_table;
> - struct device *dev = &rproc->dev;
> struct resource_table *table = NULL;
> - int i;
> - const u8 *elf_data = fw->data;
> + const u8 *elf_data = (void *)ehdr;
>
> - ehdr = (struct elf32_hdr *)elf_data;
> + /* look for the resource table and handle it */
> shdr = (struct elf32_shdr *)(elf_data + ehdr->e_shoff);
> name_table = elf_data + shdr[ehdr->e_shstrndx].sh_offset;
>
> - /* look for the resource table and handle it */
> for (i = 0; i < ehdr->e_shnum; i++, shdr++) {
> int size = shdr->sh_size;
> int offset = shdr->sh_offset;
> @@ -250,7 +231,7 @@ rproc_elf_find_rsc_table(struct rproc *rproc, const
> struct firmware *fw,
> table = (struct resource_table *)(elf_data + offset);
>
> /* make sure we have the entire table */
> - if (offset + size > fw->size) {
> + if (offset + size > fw_size) {
While we're at it, perhaps also verify that there aren't any integer overflows
here?
> dev_err(dev, "resource table truncated\n");
> return NULL;
> }
> @@ -280,10 +261,54 @@ rproc_elf_find_rsc_table(struct rproc *rproc, const
> struct firmware *fw,
> return NULL;
> }
>
> - *tablesz = shdr->sh_size;
> - break;
> + return shdr;
> }
>
> + return NULL;
> +}
> +
> +/**
> + * rproc_elf_find_rsc_table() - find the resource table
> + * @rproc: the rproc handle
> + * @fw: the ELF firmware image
> + * @tablesz: place holder for providing back the table size
> + *
> + * This function finds the resource table inside the remote processor's
> + * firmware. It is used both upon the registration of @rproc (in order
> + * to look for and register the supported virito devices), and when the
> + * @rproc is booted.
> + *
> + * Returns the pointer to the resource table if it is found, and write its
> + * size into @tablesz. If a valid table isn't found, NULL is returned
> + * (and @tablesz isn't set).
> + */
> +static struct resource_table *
> +rproc_elf_find_rsc_table(struct rproc *rproc, const struct firmware *fw,
> + int *tablesz)
> +{
> + struct elf32_hdr *ehdr;
> + struct elf32_shdr *shdr;
> +
> + struct device *dev = &rproc->dev;
> + struct resource_table *table = NULL;
> +
> + const u8 *elf_data = fw->data;
> +
Mind removing empty lines here?
> + ehdr = (struct elf32_hdr *)elf_data;
> +
> + shdr = find_rsc_shdr(dev, ehdr, fw->size);
> + if (!shdr)
> + return NULL;
> +
> + /* make sure we have the entire table */
> + if (shdr->sh_offset + shdr->sh_size > fw->size) {
> + dev_err(dev, "resource table truncated\n");
> + return NULL;
> + }
Any reason for this explicit assertion? It seemed to be checked in
find_rsc_shdr.
> +
> + table = (struct resource_table *)(elf_data + shdr->sh_offset);
> + *tablesz = shdr->sh_size;
> +
> re
Re: [PATCH 3/9] remoteproc: Parse ELF file to find resource table address
Hi Sjur,
On Sun, Feb 10, 2013 at 12:39:06PM +0100, sjur.brandel...@stericsson.com wrote:
> From: Sjur Brændeland
>
> Add function find_rsc_table_va to firmware ops. This function
> returns the location of the resource table in shared memory
> after loading.
>
> Signed-off-by: Sjur Brændeland
> ---
> drivers/remoteproc/remoteproc_elf_loader.c | 17 -
> drivers/remoteproc/remoteproc_internal.h | 13 +
> 2 files changed, 29 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/remoteproc/remoteproc_elf_loader.c
> b/drivers/remoteproc/remoteproc_elf_loader.c
> index a958950..3137fba 100644
> --- a/drivers/remoteproc/remoteproc_elf_loader.c
> +++ b/drivers/remoteproc/remoteproc_elf_loader.c
> @@ -312,9 +312,24 @@ rproc_elf_find_rsc_table(struct rproc *rproc, const
> struct firmware *fw,
> return table;
> }
>
> +struct resource_table *rproc_elf_get_rsctab_addr(struct rproc *rproc,
> + const struct firmware *fw)
> +{
> + struct elf32_shdr *shdr;
> +
> + shdr = find_rsc_shdr(&rproc->dev, (struct elf32_hdr *)fw->data,
> + fw->size);
> + if (!shdr)
> + return NULL;
> +
> + /* Find resource table in loaded segments */
> + return rproc_da_to_va(rproc, shdr->sh_addr, shdr->sh_size);
> +}
> +
> const struct rproc_fw_ops rproc_elf_fw_ops = {
> .load = rproc_elf_load_segments,
> .find_rsc_table = rproc_elf_find_rsc_table,
> .sanity_check = rproc_elf_sanity_check,
> - .get_boot_addr = rproc_elf_get_boot_addr
> + .get_boot_addr = rproc_elf_get_boot_addr,
> + .get_rsctab_addr = rproc_elf_get_rsctab_addr
Since this new op returns a VA (unlike get_boot_addr), it would probably be
better to use an indicative name like get_rsctab_va.
> };
> diff --git a/drivers/remoteproc/remoteproc_internal.h
> b/drivers/remoteproc/remoteproc_internal.h
> index 7bb6648..3a5cb7d 100644
> --- a/drivers/remoteproc/remoteproc_internal.h
> +++ b/drivers/remoteproc/remoteproc_internal.h
> @@ -32,6 +32,7 @@ struct rproc;
> * expects to find it
> * @sanity_check:sanity check the fw image
> * @get_boot_addr: get boot address to entry point specified in firmware
> + * @get_rsctab_addr: get resouce table address as specified in firmware
> */
> struct rproc_fw_ops {
> struct resource_table *(*find_rsc_table) (struct rproc *rproc,
> @@ -40,6 +41,8 @@ struct rproc_fw_ops {
> int (*load)(struct rproc *rproc, const struct firmware *fw);
> int (*sanity_check)(struct rproc *rproc, const struct firmware *fw);
> u32 (*get_boot_addr)(struct rproc *rproc, const struct firmware *fw);
> + struct resource_table *(*get_rsctab_addr)(struct rproc *rproc,
> + const struct firmware *fw);
> };
>
> /* from remoteproc_core.c */
> @@ -102,6 +105,16 @@ struct resource_table *rproc_find_rsc_table(struct rproc
> *rproc,
> return NULL;
> }
>
> +static inline
> +struct resource_table *rproc_get_rsctab_addr(struct rproc *rproc,
> + const struct firmware *fw)
> +{
> + if (rproc->fw_ops->get_rsctab_addr)
> + return rproc->fw_ops->get_rsctab_addr(rproc, fw);
> +
> + return NULL;
> +}
> +
> extern const struct rproc_fw_ops rproc_elf_fw_ops;
>
> #endif /* REMOTEPROC_INTERNAL_H */
> --
> 1.7.5.4
>
Thanks,
Ido.
--
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 6/9] remoteproc: Support virtio config space.
Hi Sjur,
On Sun, Feb 10, 2013 at 12:39:09PM +0100, sjur.brandel...@stericsson.com wrote:
> From: Sjur Brændeland
>
> Support virtio configuration space and device status and
> feature negotiation with remote device. This virtio device
> can now access the resource table in shared memory.
>
> Signed-off-by: Sjur Brændeland
> ---
> drivers/remoteproc/remoteproc_core.c |3 --
> drivers/remoteproc/remoteproc_virtio.c | 38 +--
> include/linux/remoteproc.h |2 -
> 3 files changed, 35 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/remoteproc/remoteproc_core.c
> b/drivers/remoteproc/remoteproc_core.c
> index c12a385..1bf410d 100644
> --- a/drivers/remoteproc/remoteproc_core.c
> +++ b/drivers/remoteproc/remoteproc_core.c
> @@ -368,9 +368,6 @@ static int rproc_handle_vdev(struct rproc *rproc, struct
> fw_rsc_vdev *rsc,
> goto free_rvdev;
> }
>
> - /* remember the device features */
> - rvdev->dfeatures = rsc->dfeatures;
> -
> /* remember the resource entry */
> rvdev->rsc = rsc;
>
> diff --git a/drivers/remoteproc/remoteproc_virtio.c
> b/drivers/remoteproc/remoteproc_virtio.c
> index 9e198e5..d98cdd8 100644
> --- a/drivers/remoteproc/remoteproc_virtio.c
> +++ b/drivers/remoteproc/remoteproc_virtio.c
> @@ -182,16 +182,21 @@ error:
> */
> static u8 rproc_virtio_get_status(struct virtio_device *vdev)
> {
> - return 0;
> + struct rproc_vdev *rvdev = vdev_to_rvdev(vdev);
> + return rvdev->rsc->status;
> }
>
> static void rproc_virtio_set_status(struct virtio_device *vdev, u8 status)
> {
> + struct rproc_vdev *rvdev = vdev_to_rvdev(vdev);
> + rvdev->rsc->status = status;
> dev_dbg(&vdev->dev, "status: %d\n", status);
> }
>
> static void rproc_virtio_reset(struct virtio_device *vdev)
> {
> + struct rproc_vdev *rvdev = vdev_to_rvdev(vdev);
> + rvdev->rsc->status = 0;
> dev_dbg(&vdev->dev, "reset !\n");
> }
>
> @@ -200,7 +205,7 @@ static u32 rproc_virtio_get_features(struct virtio_device
> *vdev)
> {
> struct rproc_vdev *rvdev = vdev_to_rvdev(vdev);
>
> - return rvdev->dfeatures;
> + return rvdev->rsc->dfeatures;
> }
>
> static void rproc_virtio_finalize_features(struct virtio_device *vdev)
> @@ -219,7 +224,31 @@ static void rproc_virtio_finalize_features(struct
> virtio_device *vdev)
>* fixed as part of a small resource table overhaul and then an
>* extension of the virtio resource entries.
>*/
> - rvdev->gfeatures = vdev->features[0];
> + rvdev->rsc->gfeatures = vdev->features[0];
> +}
> +
> +void rproc_virtio_get(struct virtio_device *vdev, unsigned offset,
> + void *buf, unsigned len)
> +{
> + struct rproc_vdev *rvdev = vdev_to_rvdev(vdev);
> + void *cfg = &rvdev->rsc->vring[rvdev->rsc->num_of_vrings];
> + if (offset + len > rvdev->rsc->config_len)
Perhaps check for integer overflow here?
> + dev_err(&vdev->dev,
> + "rproc_virtio_get: access out of bounds\n");
> + else
> + memcpy(buf, cfg + offset, len);
> +}
> +
> +void rproc_virtio_set(struct virtio_device *vdev, unsigned offset,
> + const void *buf, unsigned len)
> +{
> + struct rproc_vdev *rvdev = vdev_to_rvdev(vdev);
> + void *cfg = &rvdev->rsc->vring[rvdev->rsc->num_of_vrings];
> + if (offset + len > rvdev->rsc->config_len)
Here as well.
> + dev_err(&vdev->dev,
> + "rproc_virtio_set: access out of bounds\n");
> + else
> + memcpy(cfg + offset, buf, len);
> }
>
> static struct virtio_config_ops rproc_virtio_config_ops = {
> @@ -230,6 +259,9 @@ static struct virtio_config_ops rproc_virtio_config_ops =
> {
> .reset = rproc_virtio_reset,
> .set_status = rproc_virtio_set_status,
> .get_status = rproc_virtio_get_status,
> + .get= rproc_virtio_get,
> + .set= rproc_virtio_set,
> +
> };
>
> /*
> diff --git a/include/linux/remoteproc.h b/include/linux/remoteproc.h
> index cdacd66..c0c363c 100644
> --- a/include/linux/remoteproc.h
> +++ b/include/linux/remoteproc.h
> @@ -471,8 +471,6 @@ struct rproc_vdev {
> struct rproc *rproc;
> struct virtio_device vdev;
> struct rproc_vring vring[RVDEV_NUM_VRINGS];
> - unsigned long dfeatures;
> - unsigned long gfeatures;
> struct fw_rsc_vdev *rsc;
> };
>
> --
> 1.7.5.4
>
Thanks,
Ido.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 8/9] remoteproc: Calculate max_notifyid by counting vrings
Hi Sjur,
On Sun, Feb 10, 2013 at 12:39:11PM +0100, sjur.brandel...@stericsson.com wrote:
> From: Sjur Brændeland
>
> Simplify handling of max_notifyid by simply counting the
> number of vrings.
>
> Signed-off-by: Sjur Brændeland
> ---
> drivers/remoteproc/remoteproc_core.c | 34
> +++---
> 1 files changed, 19 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/remoteproc/remoteproc_core.c
> b/drivers/remoteproc/remoteproc_core.c
> index ec9f81e..14f40eb 100644
> --- a/drivers/remoteproc/remoteproc_core.c
> +++ b/drivers/remoteproc/remoteproc_core.c
> @@ -226,9 +226,6 @@ int rproc_alloc_vring(struct rproc_vdev *rvdev, int i)
> return ret;
> }
>
> - /* Store largest notifyid */
> - rproc->max_notifyid = max(rproc->max_notifyid, notifyid);
> -
> dev_dbg(dev, "vring%d: va %p dma %llx size %x idr %d\n", i, va,
> (unsigned long long)dma, size, notifyid);
>
> @@ -278,25 +275,13 @@ rproc_parse_vring(struct rproc_vdev *rvdev, struct
> fw_rsc_vdev *rsc, int i)
> return 0;
> }
>
> -static int rproc_max_notifyid(int id, void *p, void *data)
> -{
> - int *maxid = data;
> - *maxid = max(*maxid, id);
> - return 0;
> -}
> -
> void rproc_free_vring(struct rproc_vring *rvring)
> {
> int size = PAGE_ALIGN(vring_size(rvring->len, rvring->align));
> struct rproc *rproc = rvring->rvdev->rproc;
> - int maxid = 0;
>
> dma_free_coherent(rproc->dev.parent, size, rvring->va, rvring->dma);
> idr_remove(&rproc->notifyids, rvring->notifyid);
> -
> - /* Find the largest remaining notifyid */
> - idr_for_each(&rproc->notifyids, rproc_max_notifyid, &maxid);
> - rproc->max_notifyid = maxid;
> }
>
> /**
> @@ -679,6 +664,15 @@ free_carv:
> return ret;
> }
>
> +static int rproc_handle_notifyid(struct rproc *rproc, struct fw_rsc_vdev
> *rsc,
> + int avail)
> +{
> + /* Summerize the number of notification IDs */
> + rproc->max_notifyid += rsc->num_of_vrings;
> +
> + return 0;
> +}
> +
> /*
> * A lookup table for resource handlers. The indices are defined in
> * enum fw_resource_type.
> @@ -694,6 +688,10 @@ static rproc_handle_resource_t
> rproc_handle_vdev_rsc[RSC_LAST] = {
> [RSC_VDEV] = (rproc_handle_resource_t)rproc_handle_vdev,
> };
>
> +static rproc_handle_resource_t rproc_handle_notifyid_rsc[RSC_LAST] = {
> + [RSC_VDEV] = (rproc_handle_resource_t)rproc_handle_notifyid,
> +};
> +
> /* handle firmware resource entries before booting the remote processor */
> static int
> rproc_handle_resource(struct rproc *rproc, struct resource_table *table,
> @@ -868,6 +866,12 @@ static void rproc_fw_config_virtio(const struct firmware
> *fw, void *context)
> if (!table)
> goto out;
>
> + rproc->max_notifyid = 0;
> +
> + /* count the numbe of notify-ids */
Small typo there.
> + ret = rproc_handle_resource(rproc, table, tablesz,
> + rproc_handle_notifyid_rsc);
> +
AFAICT, this will yield a higher max_notifyid than before (by one), since the
notification ids are zero based.
> /* look for virtio devices and register them */
> ret = rproc_handle_resource(rproc, table, tablesz,
> rproc_handle_vdev_rsc);
> --
> 1.7.5.4
>
Thanks,
Ido.
--
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/
