Re: [PATCH] pci: do not try to assign irq 255
On 02/19/2013 08:40 PM, Yinghai Lu wrote: On Mon, Feb 18, 2013 at 2:09 AM, Hannes Reinecke wrote: The PCI config space reseves a byte for the interrupt line, so irq 255 actually refers to 'not set'. However, the 'irq' field for struct pci_dev is an integer, so the original meaning is lost, causing the system to assign an interrupt '255', which fails. So we should _not_ assign an interrupt value here, and allow upper layers to fixup things. This patch make PCI devices with MSI interrupts only (like the xhci device on certain HP laptops) work properly. looks like the bios does not provide _PRT for device in ACPI. Correct. also according to PCI spec, BIOS *must* set interrupt line. Apparently this device is meant to use MSI _only_ so the BIOS developer didn't feel the need to assign an INTx here. According to PCI-3.0, section 6.8 (Message Signalled Interrupts): > It is recommended that devices implement interrupt pins to > provide compatibility in systems that do not support MSI > (devices default to interrupt pins). However, it is expected > that the need for interrupt pins will diminish over time. > Devices that do not support interrupt pins due to pin > constraints (rely on polling for device service) may implement > messages to increase performance without adding additional pins. > Therefore, system configuration software must not assume that a > message capable device has an interrupt pin. Which sounds to me as if the implementation is valid... And in either case, I've added the relevant details plus patch to bnc#52591. Including ACPI dump, so you can check for yourself. And correct me if I'm wrong, of course :-) Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- 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 1/8] preserve cpu runstate
On Thu, Feb 07, 2013 at 11:45:34PM -0200, Marcelo Tosatti wrote:
> On Wed, Jan 23, 2013 at 03:19:22PM +0800, Hu Tao wrote:
> > This patch enables preservation of cpu runstate during save/load vm.
> > So when a vm is restored from snapshot, the cpu runstate is restored,
> > too.
> >
> > See following example:
> >
> > # save two vms: one is running, the other is paused
> > (qemu) info status
> > VM status: running
> > (qemu) savevm running
> > (qemu) stop
> > (qemu) info status
> > VM status: paused
> > (qemu) savevm paused
> >
> > # restore the one running
> > (qemu) info status
> > VM status: paused
> > (qemu) loadvm running
> > (qemu) info status
> > VM status: running
> >
> > # restore the one paused
> > (qemu) loadvm paused
> > (qemu) info status
> > VM status: paused
> > (qemu) cont
> > (qemu)info status
> > VM status: running
> >
> >
> > Signed-off-by: Hu Tao
>
> Lack of pause state on guest images is annoying.
>
> Fail to see why the panic feature depends on preservation of cpu
> runstate.
To preserve the panic state if guest panic happens in the midway of
migration.
>
> > include/sysemu/sysemu.h | 2 ++
> > migration.c | 6 +-
> > monitor.c | 5 ++---
> > savevm.c| 1 +
> > vl.c| 34 ++
> > 5 files changed, 40 insertions(+), 8 deletions(-)
> >
> > diff --git a/include/sysemu/sysemu.h b/include/sysemu/sysemu.h
> > index 337ce7d..7a69fde 100644
> > --- a/include/sysemu/sysemu.h
> > +++ b/include/sysemu/sysemu.h
> > @@ -19,6 +19,8 @@ extern uint8_t qemu_uuid[];
> > int qemu_uuid_parse(const char *str, uint8_t *uuid);
> > #define UUID_FMT
> > "%02hhx%02hhx%02hhx%02hhx-%02hhx%02hhx-%02hhx%02hhx-%02hhx%02hhx-%02hhx%02hhx%02hhx%02hhx%02hhx%02hhx"
> >
> > +void save_run_state(void);
> > +void load_run_state(void);
> > bool runstate_check(RunState state);
> > void runstate_set(RunState new_state);
> > int runstate_is_running(void);
> > diff --git a/migration.c b/migration.c
> > index 77c1971..f96cfd6 100644
> > --- a/migration.c
> > +++ b/migration.c
> > @@ -108,11 +108,7 @@ static void process_incoming_migration_co(void *opaque)
> > /* Make sure all file formats flush their mutable metadata */
> > bdrv_invalidate_cache_all();
> >
> > -if (autostart) {
> > -vm_start();
> > -} else {
> > -runstate_set(RUN_STATE_PAUSED);
> > -}
> > +load_run_state();
> > }
> >
> > static void enter_migration_coroutine(void *opaque)
> > diff --git a/monitor.c b/monitor.c
> > index 20bd19b..9381ed0 100644
> > --- a/monitor.c
> > +++ b/monitor.c
> > @@ -2059,13 +2059,12 @@ void qmp_closefd(const char *fdname, Error **errp)
> >
> > static void do_loadvm(Monitor *mon, const QDict *qdict)
> > {
> > -int saved_vm_running = runstate_is_running();
> > const char *name = qdict_get_str(qdict, "name");
> >
> > vm_stop(RUN_STATE_RESTORE_VM);
> >
> > -if (load_vmstate(name) == 0 && saved_vm_running) {
> > -vm_start();
> > +if (load_vmstate(name) == 0) {
> > +load_run_state();
> > }
> > }
> >
> > diff --git a/savevm.c b/savevm.c
> > index 304d1ef..10f1d56 100644
> > --- a/savevm.c
> > +++ b/savevm.c
> > @@ -2112,6 +2112,7 @@ void do_savevm(Monitor *mon, const QDict *qdict)
> > }
> >
> > saved_vm_running = runstate_is_running();
> > +save_run_state();
> > vm_stop(RUN_STATE_SAVE_VM);
> >
> > memset(sn, 0, sizeof(*sn));
> > diff --git a/vl.c b/vl.c
> > index 4ee1302..b0bcf1e 100644
> > --- a/vl.c
> > +++ b/vl.c
> > @@ -520,6 +520,7 @@ static int default_driver_check(QemuOpts *opts, void
> > *opaque)
> > /* QEMU state */
> >
> > static RunState current_run_state = RUN_STATE_PRELAUNCH;
> > +static RunState saved_run_state = RUN_STATE_PRELAUNCH;
> >
> > typedef struct {
> > RunState from;
> > @@ -543,6 +544,7 @@ static const RunStateTransition
> > runstate_transitions_def[] = {
> > { RUN_STATE_PAUSED, RUN_STATE_FINISH_MIGRATE },
> >
> > { RUN_STATE_POSTMIGRATE, RUN_STATE_RUNNING },
> > +{ RUN_STATE_POSTMIGRATE, RUN_STATE_PAUSED },
> > { RUN_STATE_POSTMIGRATE, RUN_STATE_FINISH_MIGRATE },
> >
> > { RUN_STATE_PRELAUNCH, RUN_STATE_RUNNING },
> > @@ -553,6 +555,7 @@ static const RunStateTransition
> > runstate_transitions_def[] = {
> > { RUN_STATE_FINISH_MIGRATE, RUN_STATE_POSTMIGRATE },
> >
> > { RUN_STATE_RESTORE_VM, RUN_STATE_RUNNING },
> > +{ RUN_STATE_RESTORE_VM, RUN_STATE_PAUSED },
> >
> > { RUN_STATE_RUNNING, RUN_STATE_DEBUG },
> > { RUN_STATE_RUNNING, RUN_STATE_INTERNAL_ERROR },
> > @@ -582,11 +585,39 @@ static const RunStateTransition
> > runstate_transitions_def[] = {
> >
> > static bool runstate_valid_transitions[RUN_STATE_MAX][RUN_STATE_MAX];
> >
> > +void save_run_state(void)
> > +{
> > +saved_run_state = current_run_state;
> > +}
> > +
> > +void load_run_state(void)
> > +{
> > +if (saved_run_state == RUN
Re: kconfig-frontends-3.8.0.0 release
On Wednesday 2013-02-20 00:21, Yann E. MORIN wrote:
>> This seems to install
>> /usr/bin/diff[...]
>
>By default, the binaries should all ne prefixed with 'kconfig-' to avoid
>such name-clashing (as root, in a fresh debootstrap of squeeze here):
Aha. Seems I hit a peculiarity in rpmbuild. Problem solved, nothing to see. :)
$ grep -A5 -e '^%configure' /usr/lib/rpm/macros
%configure \
CFLAGS="${CFLAGS:-%optflags}" ; export CFLAGS ; \
CXXFLAGS="${CXXFLAGS:-%optflags}" ; export CXXFLAGS ; \
FFLAGS="${FFLAGS:-%optflags}" ; export FFLAGS ; \
%{_configure} --host=%{_host} --build=%{_build} \\\
--program-prefix=%{?_program_prefix} \\\
--
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/
[Query]: Regmap v3.8: Compilation Warning: regmap_read_debugfs()
Hi Mark, I am getting compilation warning while compiling v3.8 commit 19f949f52599ba7c3f67a5897ac6be14bfcb1200 Author: Linus Torvalds Date: Mon Feb 18 15:58:34 2013 -0800 Linux 3.8 Warning: CC drivers/base/regmap/regmap-debugfs.o drivers/base/regmap/regmap-debugfs.c: In function ‘regmap_read_debugfs’: drivers/base/regmap/regmap-debugfs.c:180:9: warning: ‘ret’ may be used uninitialized in this function [-Wmaybe-uninitialized] I am unable to understand why this warning is coming and that too on line 180 (as that doesn't use this variable). I can't see how this variable is used uninitialized. Toolchain i used: arm-linux-gnueabihf-gcc (crosstool-NG linaro-1.13.1-4.7-2012.12-20121214 - Linaro GCC 2012.12) 4.7.3 20121205 (prerelease) -- viresh -- 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/
tip/x86/amba
Hello Peter and maintainers. I wonder what are the plans for the branch x86/amba, part of the tip repository. Of the 7 patches in that branch, 2 are already upstream and the other 5 rebase perfectly (only conflicts are in the header stanzas). This is the reverse log from next to my current working tree: 0e7e31f DMA: PL330: use prefix in reg names to build under x86 1e8486a watchdog: sp805_wdt depends on ARM 6417077 mmc: Use the new 52b9f4e drivers/amba: add support for a PCI bridge d8d2313 x86: add CONFIG_ARM_AMBA, selected by STA2X11 They all have the proper acked and signed-off, as well as references to the original mailing list message by my mate Davide who submitted them. Shall I just wait for you to merge or shall I repost to the mailing lists? In the latte case, with or without the various ack/signoff? Thanks /alessandro -- 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/
[ANNOUNCE] Git v1.8.1.4
The latest maintenance release Git v1.8.1.4 is now available at the usual places. This is primarily to tighten the host verification when imap-send is talking to your mail server via TLS/SSL. The topic that was merged to the tip of 'maint' track consists of 3 patches and is based on the 1.7.6 maintenance track. This is to make it easier for the distro folks to merge the topic to their older maintenance branches to issue hotfix binary releases if they wanted to. This release itself also contains many small updates to the user-manual. The release tarballs are found at: http://code.google.com/p/git-core/downloads/list and their SHA-1 checksums are: 553191fe02cfac77386d5bb01df0a79eb7f163c8 git-1.8.1.4.tar.gz bb71df6bc1fdb55b45c59af83102e901d484ef53 git-htmldocs-1.8.1.4.tar.gz 98c41b38d02f09e1fcde335834694616d0a615f7 git-manpages-1.8.1.4.tar.gz Also the following public repositories all have a copy of the v1.8.1.4 tag and the maint branch that the tag points at: url = git://repo.or.cz/alt-git.git url = https://code.google.com/p/git-core/ url = git://git.sourceforge.jp/gitroot/git-core/git.git url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core url = https://github.com/gitster/git Git 1.8.1.4 Release Notes = Fixes since v1.8.1.3 * "git imap-send" talking over imaps:// did make sure it received a valid certificate from the other end, but did not check if the certificate matched the host it thought it was talking to. Also contains various documentation fixes. Changes since v1.8.1.3 are as follows: Junio C Hamano (2): imap-send: move #ifdef around Git 1.8.1.4 Matthieu Moy (1): Replace filepattern with pathspec for consistency Oswald Buddenhagen (2): imap-send: the subject of SSL certificate must match the host imap-send: support subjectAltName as well W. Trevor King (9): user-manual: Fix 'both: so' -> 'both; so' typo user-manual: Fix 'http' -> 'HTTP' typos user-manual: Fix 'you - Git' -> 'you--Git' typo user-manual: Rewrite git-gc section for automatic packing user-manual: use 'remote add' to setup push URLs user-manual: give 'git push -f' as an alternative to +master user-manual: mention 'git remote add' for remote branch config user-manual: use 'git config --global user.*' for setup user-manual: use -o latest.tar.gz to create a gzipped tarball -- 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 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. -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] sched/core: remove obsolete nr_uninterruptible()
From: Sha Zhengju
Signed-off-by: Sha Zhengju
---
kernel/sched/core.c | 17 -
1 file changed, 17 deletions(-)
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/
Re: [PATCH 05/11] mfd: twl6040: use devm_gpio_request_one() and devm_request_threaded_irq()
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?
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 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. 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 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. 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 07/11] mfd: menelaus: use devm_request_irq() and devm_kzalloc()
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.
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: [GIT PULL] (xen) stable/for-jens-3.9
On Tue, Feb 19 2013, Konrad Rzeszutek Wilk wrote: > Hey Jens, > > Please git pull the following branch: > > git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git > stable/for-jens-3.9 > > which has bug-fixes that did not make it in v3.8. They all are marked as > material for the stable tree as well. There are two bug-fixes for > the code that has been in there for some time (that is the Jan's fix > and one of mine). And there are two bug-fixes for the persistent grant > feature that debuted in v3.8 for xen blk[back|front]end. Konrad, the tree is against 3.8, so I'm pulling it into my for-linus branch which will be pushed a bit after the initial for-3.9/drivers goes out. I can't pull it into the latter without getting a whole lot of extra changes too. -- Jens Axboe -- 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] regulator: tps6586x: Use dev_err rather than dev_warn for error message
On 02/19/2013 07:23 PM, Axel Lin wrote: > tps6586x_regulator_set_slew_rate() returns -EINVAL when having slew rate > settings for other than SM0/1, thus use dev_err rather than dev_warn. Reviewed-by: Stephen Warren -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] tmpfs: fix mempolicy object leaks
This patch fixes several mempolicy leaks in the tmpfs mount logic.
These leaks are slow - on the order of one object leaked per mount
attempt.
Leak 1 (umount doesn't free mpol allocated in mount):
while true; do
mount -t tmpfs -o mpol=interleave,size=100M nodev /mnt
umount /mnt
done
Leak 2 (errors parsing remount options will leak mpol):
mount -t tmpfs -o size=100M nodev /mnt
while true; do
mount -o remount,mpol=interleave,size=x /mnt 2> /dev/null
done
umount /mnt
Leak 3 (multiple mpol per mount leak mpol):
while true; do
mount -t tmpfs -o mpol=interleave,mpol=interleave,size=100M nodev /mnt
umount /mnt
done
This patch fixes all of the above. I could have broken the patch into
three pieces but is seemed easier to review as one.
Signed-off-by: Greg Thelen
---
mm/shmem.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/mm/shmem.c b/mm/shmem.c
index efd0b3a..ed2cb26 100644
--- a/mm/shmem.c
+++ b/mm/shmem.c
@@ -2386,6 +2386,7 @@ static int shmem_parse_options(char *options, struct
shmem_sb_info *sbinfo,
bool remount)
{
char *this_char, *value, *rest;
+ struct mempolicy *mpol = NULL;
uid_t uid;
gid_t gid;
@@ -2414,7 +2415,7 @@ static int shmem_parse_options(char *options, struct
shmem_sb_info *sbinfo,
printk(KERN_ERR
"tmpfs: No value for mount option '%s'\n",
this_char);
- return 1;
+ goto error;
}
if (!strcmp(this_char,"size")) {
@@ -2463,19 +2464,23 @@ static int shmem_parse_options(char *options, struct
shmem_sb_info *sbinfo,
if (!gid_valid(sbinfo->gid))
goto bad_val;
} else if (!strcmp(this_char,"mpol")) {
- if (mpol_parse_str(value, &sbinfo->mpol))
+ mpol_put(mpol);
+ if (mpol_parse_str(value, &mpol))
goto bad_val;
} else {
printk(KERN_ERR "tmpfs: Bad mount option %s\n",
this_char);
- return 1;
+ goto error;
}
}
+ sbinfo->mpol = mpol;
return 0;
bad_val:
printk(KERN_ERR "tmpfs: Bad value '%s' for mount option '%s'\n",
value, this_char);
+error:
+ mpol_put(mpol);
return 1;
}
@@ -2551,6 +2556,7 @@ static void shmem_put_super(struct super_block *sb)
struct shmem_sb_info *sbinfo = SHMEM_SB(sb);
percpu_counter_destroy(&sbinfo->used_blocks);
+ mpol_put(sbinfo->mpol);
kfree(sbinfo);
sb->s_fs_info = NULL;
}
--
1.8.1.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] tmpfs: fix use-after-free of mempolicy object
The tmpfs remount logic preserves filesystem mempolicy if the mpol=M
option is not specified in the remount request. A new policy can be
specified if mpol=M is given.
Before this patch remounting an mpol bound tmpfs without specifying
mpol= mount option in the remount request would set the filesystem's
mempolicy object to a freed mempolicy object.
To reproduce the problem boot a DEBUG_PAGEALLOC kernel and run:
# mkdir /tmp/x
# mount -t tmpfs -o size=100M,mpol=interleave nodev /tmp/x
# grep /tmp/x /proc/mounts
nodev /tmp/x tmpfs rw,relatime,size=102400k,mpol=interleave:0-3 0 0
# mount -o remount,size=200M nodev /tmp/x
# grep /tmp/x /proc/mounts
nodev /tmp/x tmpfs rw,relatime,size=204800k,mpol=??? 0 0
# note ? garbage in mpol=... output above
# dd if=/dev/zero of=/tmp/x/f count=1
# panic here
Panic:
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: [< (null)>] (null)
[...]
Oops: 0010 [#1] SMP DEBUG_PAGEALLOC
Call Trace:
[] ? mpol_set_nodemask+0x8d/0x100
[] ? mpol_shared_policy_init+0x8f/0x160
[] mpol_shared_policy_init+0xa5/0x160
[] ? shmem_get_inode+0x1e1/0x270
[] ? shmem_get_inode+0x1e1/0x270
[] ? trace_hardirqs_on+0xd/0x10
[] shmem_get_inode+0x209/0x270
[] shmem_mknod+0x3e/0xf0
[] shmem_create+0x18/0x20
[] vfs_create+0xb5/0x130
[] do_last+0x9a1/0xea0
[] ? link_path_walk+0x7a/0x930
[] path_openat+0xb3/0x4d0
[] ? __alloc_fd+0x31/0x160
[] do_filp_open+0x42/0xa0
[] ? __alloc_fd+0xe0/0x160
[] do_sys_open+0xfe/0x1e0
[] compat_sys_open+0x1b/0x20
[] cstar_dispatch+0x7/0x1f
Non-debug kernels will not crash immediately because referencing the
dangling mpol will not cause a fault. Instead the filesystem will
reference a freed mempolicy object, which will cause unpredictable
behavior.
The problem boils down to a dropped mpol reference below if
shmem_parse_options() does not allocate a new mpol:
config = *sbinfo
shmem_parse_options(data, &config, true)
mpol_put(sbinfo->mpol)
sbinfo->mpol = config.mpol /* BUG: saves unreferenced mpol */
This patch avoids the crash by not releasing the mempolicy if
shmem_parse_options() doesn't create a new mpol.
How far back does this issue go? I see it in both 2.6.36 and 3.3. I
did not look back further.
Signed-off-by: Greg Thelen
---
mm/shmem.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/mm/shmem.c b/mm/shmem.c
index 5dd56f6..efd0b3a 100644
--- a/mm/shmem.c
+++ b/mm/shmem.c
@@ -2487,6 +2487,7 @@ static int shmem_remount_fs(struct super_block *sb, int
*flags, char *data)
unsigned long inodes;
int error = -EINVAL;
+ config.mpol = NULL;
if (shmem_parse_options(data, &config, true))
return error;
@@ -2511,8 +2512,13 @@ static int shmem_remount_fs(struct super_block *sb, int
*flags, char *data)
sbinfo->max_inodes = config.max_inodes;
sbinfo->free_inodes = config.max_inodes - inodes;
- mpol_put(sbinfo->mpol);
- sbinfo->mpol= config.mpol; /* transfers initial ref */
+ /*
+* Preserve previous mempolicy unless mpol remount option was specified.
+*/
+ if (config.mpol) {
+ mpol_put(sbinfo->mpol);
+ sbinfo->mpol = config.mpol; /* transfers initial ref */
+ }
out:
spin_unlock(&sbinfo->stat_lock);
return error;
--
1.8.1.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 1/4] acpi: move x86/mm/srat.c to x86/kernel/acpi/srat.c
在 2013-02-19二的 23:00 -0800，David Rientjes写道： > On Wed, 20 Feb 2013, li guang wrote: > > > Yes, I know there's no new changes in my patch as I said before(not > > based on lasted), but as I try to apply my patch(1/4), it will do > > the right work to move current srat.c from arch/x86/mm/ to > > arch/x86/kernel/acpi/ regardless of what I based is not latest. > > > > Sorry, but that makes no sense. Your patch cannot be used cleanly if > there have been subsequent changes to a hunk prior to applying it -- in > this case the hunk would be the entire file since you're removing it. > > These patches would also be pushed by the x86 maintainers, who are not > cc'd on this patch, and I think it would be unfair to ask them to make up > for your inability to generate a bleeding edge patch with linux-next. The > changes already cited in this thread have been in linux-next for almost > two weeks, yet you refuse to rebase on top of them. OK, I'd like to rebase, Thanks! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] sparc64: Fix gfp_flags setting in tsb_grow().
On Wed, 20 Feb 2013, David Miller wrote: > > We should "|= more_flags" rather than "= more_flags". > > Reported-by: David Rientjes > Signed-off-by: David S. Miller Acked-by: David Rientjes -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 1/4] acpi: move x86/mm/srat.c to x86/kernel/acpi/srat.c
On Wed, 20 Feb 2013, li guang wrote: > Yes, I know there's no new changes in my patch as I said before(not > based on lasted), but as I try to apply my patch(1/4), it will do > the right work to move current srat.c from arch/x86/mm/ to > arch/x86/kernel/acpi/ regardless of what I based is not latest. > Sorry, but that makes no sense. Your patch cannot be used cleanly if there have been subsequent changes to a hunk prior to applying it -- in this case the hunk would be the entire file since you're removing it. These patches would also be pushed by the x86 maintainers, who are not cc'd on this patch, and I think it would be unfair to ask them to make up for your inability to generate a bleeding edge patch with linux-next. The changes already cited in this thread have been in linux-next for almost two weeks, yet you refuse to rebase on top of them. -- 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()
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 -- 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: linux-next: manual merge of the akpm tree with the net-next tree
On 02/20/2013 02:02 PM, Stephen Rothwell wrote:
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in
net/core/dev.c between commit 900ff8c63214 ("net: move procfs code to
net/core/net-procfs.c") from the net-next tree and commit "hlist: drop
the node parameter from iterators" from the akpm tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
Looks good.
Thanks, Stephen!
--
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] sparc64: Handle hugepage TSB being NULL.
Accomodate the possibility that the TSB might be NULL at
the point that update_mmu_cache() is invoked. This is
necessary because we will sometimes need to defer the TSB
allocation to the first fault that happens in the 'mm'.
Seperate out the hugepage PTE test into a seperate function
so that the logic is clearer.
Signed-off-by: David S. Miller
---
arch/sparc/mm/init_64.c | 38 ++
1 file changed, 22 insertions(+), 16 deletions(-)
diff --git a/arch/sparc/mm/init_64.c b/arch/sparc/mm/init_64.c
index c3b7242..0d0bc39 100644
--- a/arch/sparc/mm/init_64.c
+++ b/arch/sparc/mm/init_64.c
@@ -314,16 +314,31 @@ static void __update_mmu_tsb_insert(struct mm_struct *mm,
unsigned long tsb_inde
struct tsb *tsb = mm->context.tsb_block[tsb_index].tsb;
unsigned long tag;
+ if (unlikely(!tsb))
+ return;
+
tsb += ((address >> tsb_hash_shift) &
(mm->context.tsb_block[tsb_index].tsb_nentries - 1UL));
tag = (address >> 22UL);
tsb_insert(tsb, tag, tte);
}
+#if defined(CONFIG_HUGETLB_PAGE) || defined(CONFIG_TRANSPARENT_HUGEPAGE)
+static inline bool is_hugetlb_pte(pte_t pte)
+{
+ if ((tlb_type == hypervisor &&
+(pte_val(pte) & _PAGE_SZALL_4V) == _PAGE_SZHUGE_4V) ||
+ (tlb_type != hypervisor &&
+(pte_val(pte) & _PAGE_SZALL_4U) == _PAGE_SZHUGE_4U))
+ return true;
+ return false;
+}
+#endif
+
void update_mmu_cache(struct vm_area_struct *vma, unsigned long address, pte_t
*ptep)
{
- unsigned long tsb_index, tsb_hash_shift, flags;
struct mm_struct *mm;
+ unsigned long flags;
pte_t pte = *ptep;
if (tlb_type != hypervisor) {
@@ -335,25 +350,16 @@ void update_mmu_cache(struct vm_area_struct *vma,
unsigned long address, pte_t *
mm = vma->vm_mm;
- tsb_index = MM_TSB_BASE;
- tsb_hash_shift = PAGE_SHIFT;
-
spin_lock_irqsave(&mm->context.lock, flags);
#if defined(CONFIG_HUGETLB_PAGE) || defined(CONFIG_TRANSPARENT_HUGEPAGE)
- if (mm->context.tsb_block[MM_TSB_HUGE].tsb != NULL) {
- if ((tlb_type == hypervisor &&
-(pte_val(pte) & _PAGE_SZALL_4V) == _PAGE_SZHUGE_4V) ||
- (tlb_type != hypervisor &&
-(pte_val(pte) & _PAGE_SZALL_4U) == _PAGE_SZHUGE_4U)) {
- tsb_index = MM_TSB_HUGE;
- tsb_hash_shift = HPAGE_SHIFT;
- }
- }
+ if (mm->context.huge_pte_count && is_hugetlb_pte(pte))
+ __update_mmu_tsb_insert(mm, MM_TSB_HUGE, HPAGE_SHIFT,
+ address, pte_val(pte));
+ else
#endif
-
- __update_mmu_tsb_insert(mm, tsb_index, tsb_hash_shift,
- address, pte_val(pte));
+ __update_mmu_tsb_insert(mm, MM_TSB_BASE, PAGE_SHIFT,
+ address, pte_val(pte));
spin_unlock_irqrestore(&mm->context.lock, flags);
}
--
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/
[PATCH 3/3] sparc64: Fix tsb_grow() in atomic context.
If our first THP installation for an MM is via the set_pmd_at() done
during khugepaged's collapsing we'll end up in tsb_grow() trying to do
a GFP_KERNEL allocation with several locks held.
Simply using GFP_ATOMIC in this situation is not the best option
because we really can't have this fail, so we'd really like to keep
this an order 0 GFP_KERNEL allocation if possible.
Also, doing the TSB allocation from khugepaged is a really bad idea
because we'll allocate it potentially from the wrong NUMA node in that
context.
So what we do is defer the hugepage TSB allocation until the first TLB
miss we take on a hugepage. This is slightly tricky because we have
to handle two unusual cases:
1) Taking the first hugepage TLB miss in the window trap handler.
We'll call the winfix_trampoline when that is detected.
2) An initial TSB allocation via TLB miss races with a hugetlb
fault on another cpu running the same MM. We handle this by
unconditionally loading the TSB we see into the current cpu
even if it's non-NULL at hugetlb_setup time.
Reported-by: Meelis Roos
Signed-off-by: David S. Miller
---
arch/sparc/include/asm/hugetlb.h | 1 -
arch/sparc/include/asm/page_64.h | 4 ++--
arch/sparc/kernel/tsb.S | 39 +++
arch/sparc/mm/fault_64.c | 9 +++--
arch/sparc/mm/init_64.c | 24 +++-
arch/sparc/mm/tlb.c | 11 +--
6 files changed, 72 insertions(+), 16 deletions(-)
diff --git a/arch/sparc/include/asm/hugetlb.h b/arch/sparc/include/asm/hugetlb.h
index 9661e9b..7eb57d2 100644
--- a/arch/sparc/include/asm/hugetlb.h
+++ b/arch/sparc/include/asm/hugetlb.h
@@ -12,7 +12,6 @@ pte_t huge_ptep_get_and_clear(struct mm_struct *mm, unsigned
long addr,
static inline void hugetlb_prefault_arch_hook(struct mm_struct *mm)
{
- hugetlb_setup(mm);
}
static inline int is_hugepage_only_range(struct mm_struct *mm,
diff --git a/arch/sparc/include/asm/page_64.h b/arch/sparc/include/asm/page_64.h
index 4b39f74..e155388 100644
--- a/arch/sparc/include/asm/page_64.h
+++ b/arch/sparc/include/asm/page_64.h
@@ -27,8 +27,8 @@
#ifndef __ASSEMBLY__
#if defined(CONFIG_HUGETLB_PAGE) || defined(CONFIG_TRANSPARENT_HUGEPAGE)
-struct mm_struct;
-extern void hugetlb_setup(struct mm_struct *mm);
+struct pt_regs;
+extern void hugetlb_setup(struct pt_regs *regs);
#endif
#define WANT_PAGE_VIRTUAL
diff --git a/arch/sparc/kernel/tsb.S b/arch/sparc/kernel/tsb.S
index d4bdc7a..a313e4a 100644
--- a/arch/sparc/kernel/tsb.S
+++ b/arch/sparc/kernel/tsb.S
@@ -136,12 +136,43 @@ tsb_miss_page_table_walk_sun4v_fastpath:
nop
/* It is a huge page, use huge page TSB entry address we
-* calculated above.
+* calculated above. If the huge page TSB has not been
+* allocated, setup a trap stack and call hugetlb_setup()
+* to do so, then return from the trap to replay the TLB
+* miss.
+*
+* This is necessary to handle the case of transparent huge
+* pages where we don't really have a non-atomic context
+* in which to allocate the hugepage TSB hash table. When
+* the 'mm' faults in the hugepage for the first time, we
+* thus handle it here. This also makes sure that we can
+* allocate the TSB hash table on the correct NUMA node.
*/
TRAP_LOAD_TRAP_BLOCK(%g7, %g2)
- ldx [%g7 + TRAP_PER_CPU_TSB_HUGE_TEMP], %g2
- cmp %g2, -1
- movne %xcc, %g2, %g1
+ ldx [%g7 + TRAP_PER_CPU_TSB_HUGE_TEMP], %g1
+ cmp %g1, -1
+ bne,pt %xcc, 60f
+nop
+
+661: rdpr%pstate, %g5
+ wrpr%g5, PSTATE_AG | PSTATE_MG, %pstate
+ .section.sun4v_2insn_patch, "ax"
+ .word 661b
+ SET_GL(1)
+ nop
+ .previous
+
+ rdpr%tl, %g3
+ cmp %g3, 1
+ bne,pn %xcc, winfix_trampoline
+nop
+ ba,pt %xcc, etrap
+rd %pc, %g7
+ callhugetlb_setup
+add%sp, PTREGS_OFF, %o0
+ ba,pt %xcc, rtrap
+nop
+
60:
#endif
diff --git a/arch/sparc/mm/fault_64.c b/arch/sparc/mm/fault_64.c
index 097aee7..5062ff3 100644
--- a/arch/sparc/mm/fault_64.c
+++ b/arch/sparc/mm/fault_64.c
@@ -472,8 +472,13 @@ good_area:
#if defined(CONFIG_HUGETLB_PAGE) || defined(CONFIG_TRANSPARENT_HUGEPAGE)
mm_rss = mm->context.huge_pte_count;
if (unlikely(mm_rss >
-mm->context.tsb_block[MM_TSB_HUGE].tsb_rss_limit))
- tsb_grow(mm, MM_TSB_HUGE, mm_rss);
+mm->context.tsb_block[MM_TSB_HUGE].tsb_rss_limit)) {
+ if (mm->context.tsb_block[MM_TSB_HUGE].tsb)
+ tsb_grow(mm, MM_TSB_HUGE, mm_rss);
+ else
+ hugetlb_setup(regs);
+
+ }
#endif
return;
diff --git a/arch/sparc/mm/ini
[PATCH 1/3] sparc64: Fix gfp_flags setting in tsb_grow().
We should "|= more_flags" rather than "= more_flags". Reported-by: David Rientjes Signed-off-by: David S. Miller --- arch/sparc/mm/tsb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/sparc/mm/tsb.c b/arch/sparc/mm/tsb.c index 7f64743..428982b 100644 --- a/arch/sparc/mm/tsb.c +++ b/arch/sparc/mm/tsb.c @@ -314,7 +314,7 @@ void tsb_grow(struct mm_struct *mm, unsigned long tsb_index, unsigned long rss) retry_tsb_alloc: gfp_flags = GFP_KERNEL; if (new_size > (PAGE_SIZE * 2)) - gfp_flags = __GFP_NOWARN | __GFP_NORETRY; + gfp_flags |= __GFP_NOWARN | __GFP_NORETRY; new_tsb = kmem_cache_alloc_node(tsb_caches[new_cache_index], gfp_flags, numa_node_id()); -- 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: THP bug and crash on sparc64 3.8
Ok I've written an alternative version of the fix that I've been busy testing all evening. I think it's much better and it's about to be posted as a series of 3 patches. Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] x86/platform changes for v3.9
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? Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: build warning after merge of the akpm tree
Hi Andrew,
After merging the akpm tree, today's linux-next build (powerpc
ppc44x_defconfig) produced this warning:
block/partitions/efi.c: In function 'is_gpt_valid':
block/partitions/efi.c:324:3: warning: format '%lu' expects argument of type
'long unsigned int', but argument 3 has type 'unsigned int' [-Wformat]
Introduced by commit ef25bb0fa6e2 ("block/partitions/efi.c: ensure that
the GPT header is at least the size of the structure").
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpTTipSJ6gHM.pgp
Description: PGP signature
[RESEND][PATCH] gpu: remove gma500 stub driver
In v3.3, the gma500 drm driver moved from staging to drm group by
Alan Cox's 3abcf41fb patch. the gma500 drm driver should control
brightness well and don't need gma500 stub driver anymore.
Reference:
http://lists.freedesktop.org/archives/dri-devel/2012-May/023426.html
http://lists.freedesktop.org/archives/dri-devel/2012-May/023467.html
Cc: randy.dun...@oracle.com
Cc: tr...@suse.de
Cc: valdis.kletni...@vt.edu
Cc: dennis.jan...@web.de
Cc: airl...@redhat.com
Cc: e...@anholt.net
Cc: alexdeuc...@gmail.com
Cc: bske...@redhat.com
Cc: ch...@chris-wilson.co.uk
Cc: Alan Cox
Acked-by: Matthew Garrett
Acked-by: Greg Kroah-Hartman
Signed-off-by: Lee, Chun-Yi
---
drivers/gpu/Makefile |2 +-
drivers/gpu/stub/Kconfig | 18
drivers/gpu/stub/Makefile |1 -
drivers/gpu/stub/poulsbo.c | 64
drivers/video/Kconfig |2 -
5 files changed, 1 insertions(+), 86 deletions(-)
delete mode 100644 drivers/gpu/stub/Kconfig
delete mode 100644 drivers/gpu/stub/Makefile
delete mode 100644 drivers/gpu/stub/poulsbo.c
diff --git a/drivers/gpu/Makefile b/drivers/gpu/Makefile
index cc92778..30879df 100644
--- a/drivers/gpu/Makefile
+++ b/drivers/gpu/Makefile
@@ -1 +1 @@
-obj-y += drm/ vga/ stub/
+obj-y += drm/ vga/
diff --git a/drivers/gpu/stub/Kconfig b/drivers/gpu/stub/Kconfig
deleted file mode 100644
index 4199179..000
--- a/drivers/gpu/stub/Kconfig
+++ /dev/null
@@ -1,18 +0,0 @@
-config STUB_POULSBO
- tristate "Intel GMA500 Stub Driver"
- depends on PCI
- depends on NET # for THERMAL
- # Poulsbo stub depends on ACPI_VIDEO when ACPI is enabled
- # but for select to work, need to select ACPI_VIDEO's dependencies, ick
- select BACKLIGHT_CLASS_DEVICE if ACPI
- select VIDEO_OUTPUT_CONTROL if ACPI
- select INPUT if ACPI
- select ACPI_VIDEO if ACPI
- select THERMAL if ACPI
- help
- Choose this option if you have a system that has Intel GMA500
- (Poulsbo) integrated graphics. If M is selected, the module will
- be called Poulsbo. This driver is a stub driver for Poulsbo that
- will call poulsbo.ko to enable the acpi backlight control sysfs
- entry file because there have no poulsbo native driver can support
- intel opregion.
diff --git a/drivers/gpu/stub/Makefile b/drivers/gpu/stub/Makefile
deleted file mode 100644
index cd940cc..000
--- a/drivers/gpu/stub/Makefile
+++ /dev/null
@@ -1 +0,0 @@
-obj-$(CONFIG_STUB_POULSBO) += poulsbo.o
diff --git a/drivers/gpu/stub/poulsbo.c b/drivers/gpu/stub/poulsbo.c
deleted file mode 100644
index 7edfd27..000
--- a/drivers/gpu/stub/poulsbo.c
+++ /dev/null
@@ -1,64 +0,0 @@
-/*
- * Intel Poulsbo Stub driver
- *
- * Copyright (C) 2010 Novell
- *
- * 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 DRIVER_NAME "poulsbo"
-
-enum {
- CHIP_PSB_8108 = 0,
- CHIP_PSB_8109 = 1,
-};
-
-static DEFINE_PCI_DEVICE_TABLE(pciidlist) = {
- {0x8086, 0x8108, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_PSB_8108}, \
- {0x8086, 0x8109, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_PSB_8109}, \
- {0, 0, 0}
-};
-
-static int poulsbo_probe(struct pci_dev *pdev, const struct pci_device_id *id)
-{
- return acpi_video_register();
-}
-
-static void poulsbo_remove(struct pci_dev *pdev)
-{
- acpi_video_unregister();
-}
-
-static struct pci_driver poulsbo_driver = {
- .name = DRIVER_NAME,
- .id_table = pciidlist,
- .probe = poulsbo_probe,
- .remove = poulsbo_remove,
-};
-
-static int __init poulsbo_init(void)
-{
- return pci_register_driver(&poulsbo_driver);
-}
-
-static void __exit poulsbo_exit(void)
-{
- pci_unregister_driver(&poulsbo_driver);
-}
-
-module_init(poulsbo_init);
-module_exit(poulsbo_exit);
-
-MODULE_AUTHOR("Lee, Chun-Yi ");
-MODULE_DESCRIPTION("Poulsbo Stub Driver");
-MODULE_LICENSE("GPL");
-
-MODULE_DEVICE_TABLE(pci, pciidlist);
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index d08d799..cc99f41 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -21,8 +21,6 @@ source "drivers/gpu/vga/Kconfig"
source "drivers/gpu/drm/Kconfig"
-source "drivers/gpu/stub/Kconfig"
-
config VGASTATE
tristate
default n
--
1.6.0.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/
linux-next: build failure after merge of the akpm tree
Hi Andrew,
After merging the akpm tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/net/ethernet/qlogic/qlcnic/qlcnic_hw.c: In function
'qlcnic_prune_lb_filters':
drivers/net/ethernet/qlogic/qlcnic/qlcnic_hw.c:607:63: error: macro
"hlist_for_each_entry_safe" passed 5 arguments, but takes just 4
drivers/net/ethernet/qlogic/qlcnic/qlcnic_hw.c:607:3: error:
'hlist_for_each_entry_safe' undeclared (first use in this function)
drivers/net/ethernet/qlogic/qlcnic/qlcnic_hw.c:608:3: error: expected ';'
before '{' token
Caused by commit c4b75b428da3 ("hlist: drop the node parameter from
iterators") interacting with commit 53643a75b147 ("qlcnic: fix ping
resumption to a VM after a live migration") from the net-next tree.
I applied this merge fix:
From: Stephen Rothwell
Date: Wed, 20 Feb 2013 17:17:54 +1100
Subject: [PATCH] hlist-drop-the-node-parameter-from-iterators-qlnic-fix
Signed-off-by: Stephen Rothwell
---
drivers/net/ethernet/qlogic/qlcnic/qlcnic_hw.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_hw.c
b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_hw.c
index a5422cd..f89cc7a 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_hw.c
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_hw.c
@@ -604,7 +604,7 @@ void qlcnic_prune_lb_filters(struct qlcnic_adapter *adapter)
for (i = 0; i < adapter->rx_fhash.fbucket_size; i++) {
head = &(adapter->rx_fhash.fhead[i]);
- hlist_for_each_entry_safe(tmp_fil, tmp_hnode, n, head, fnode)
+ hlist_for_each_entry_safe(tmp_fil, n, head, fnode)
{
time = tmp_fil->ftime;
if (jiffies > (QLCNIC_FILTER_AGE * HZ + time)) {
--
1.8.1
which then lead to these erroes:
drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c: In function
'qlcnic_add_lb_filter':
drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c:182:63: error: macro
"hlist_for_each_entry_safe" passed 5 arguments, but takes just 4
drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c:182:3: error:
'hlist_for_each_entry_safe' undeclared (first use in this function)
drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c:182:65: error: expected ';'
before '{' token
drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c:208:63: error: macro
"hlist_for_each_entry_safe" passed 5 arguments, but takes just 4
drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c:208:65: error: expected ';'
before '{' token
for which I applied this merge fix patch:
From: Stephen Rothwell
Date: Wed, 20 Feb 2013 17:25:26 +1100
Subject: [PATCH] hlist-drop-the-node-parameter-from-iterators-qlnic-2-fix
Signed-off-by: Stephen Rothwell
---
drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c
b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c
index 27196ed..0e63006 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c
@@ -162,7 +162,7 @@ void qlcnic_add_lb_filter(struct qlcnic_adapter *adapter,
struct sk_buff *skb,
{
struct ethhdr *phdr = (struct ethhdr *)(skb->data);
struct qlcnic_filter *fil, *tmp_fil;
- struct hlist_node *tmp_hnode, *n;
+ struct hlist_node *n;
struct hlist_head *head;
unsigned long time;
u64 src_addr = 0;
@@ -179,7 +179,7 @@ void qlcnic_add_lb_filter(struct qlcnic_adapter *adapter,
struct sk_buff *skb,
(adapter->fhash.fbucket_size - 1);
head = &(adapter->rx_fhash.fhead[hindex]);
- hlist_for_each_entry_safe(tmp_fil, tmp_hnode, n, head, fnode) {
+ hlist_for_each_entry_safe(tmp_fil, n, head, fnode) {
if (!memcmp(tmp_fil->faddr, &src_addr, ETH_ALEN) &&
tmp_fil->vlan_id == vlan_id) {
time = tmp_fil->ftime;
@@ -205,7 +205,7 @@ void qlcnic_add_lb_filter(struct qlcnic_adapter *adapter,
struct sk_buff *skb,
(adapter->fhash.fbucket_size - 1);
head = &(adapter->rx_fhash.fhead[hindex]);
spin_lock(&adapter->rx_mac_learn_lock);
- hlist_for_each_entry_safe(tmp_fil, tmp_hnode, n, head, fnode) {
+ hlist_for_each_entry_safe(tmp_fil, n, head, fnode) {
if (!memcmp(tmp_fil->faddr, &src_addr, ETH_ALEN) &&
tmp_fil->vlan_id == vlan_id) {
found = 1;
--
1.8.1
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpoliDMBMHH6.pgp
Description: PGP signature
[git pull] Input updates for 3.9-rc0
Hi Linus,
Please pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus
or
master.kernel.org:/pub/scm/linux/kernel/git/dtor/input.git for-linus
to receive first round of updates for the input subsystem.
You will get 2 new touchpad drivers - Cypress APA I2C Trackpad and
Cypress PS/2 touchpad and a big update to ALPS driver from Kevin
Cernekee that adds support for "Rushmore" touchpads and paves way for
adding support for "Dolphin" touchpads.
There is also a new input driver for Goldfish emulator and also Android
keyreset driver was folded into SysRq code.
A few more drivers were updated with device tree bindings and others
got some small cleanups and fixes.
Changelog:
-
Benson Leung (2):
Input: add driver for Cypress APA I2C Trackpad
Input: cyapa - add support for smbus protocol
Brian Swetland (1):
Input: goldfish - virtual input event driver
Daniel Kurtz (1):
Input: synaptics - fix 1->3 contact transition reporting
Dmitry Torokhov (6):
Input: atkbd - fix a typo in a message
Input: walkera0701 - set up input device's parent
Input: walkera0701 - switch to using pr_xxx() for messages
Input: walkera0701 - use proper error codes
Input: walkera0701 - claim parport when opening the device
Input: cyttsp-spi - remove duplicate MODULE_ALIAS()
Dudley Du (1):
Input: add support for Cypress PS/2 Trackpads
Heiko Carstens (1):
Input: add couple of missing GENERIC_HARDIRQS dependencies
Henrik Rydberg (2):
Input: MT - do not apply filtering on emulated events
Input: synaptics - initialize pointer emulation usage
Javier Martin (1):
Input: qt2160 - add support for LEDs
Kamal Mostafa (1):
Input: increase struct ps2dev cmdbuf[] to 8 bytes
Kevin Cernekee (13):
Input: ALPS - document the alps.h data structures
Input: ALPS - copy "model" info into alps_data struct
Input: ALPS - move alps_get_model() down below hw_init code
Input: ALPS - introduce helper function for repeated commands
Input: ALPS - rework detection sequence
Input: ALPS - use function pointers for different protocol handlers
Input: ALPS - move {addr,nibble}_command settings into alps_set_defaults()
Input: ALPS - rework detection of Pinnacle AGx touchpads
Input: ALPS - fix command mode check
Input: ALPS - move pixel and bitmap info into alps_data struct
Input: ALPS - make the V3 packet field decoder "pluggable"
Input: ALPS - add support for "Rushmore" touchpads
Input: ALPS - enable trackstick on Rushmore touchpads
Laxman Dewangan (4):
Input: tegra-kbc - fix build warning
Input: tegra-kbc - use devm_* for resource allocation
Input: tegra-kbc - add support for rows/columns configuration from dt
Input: tegra-kbc - remove default keymap
Liu Ying (1):
Input: imx_keypad - add device tree support
Mark Brown (2):
Input: wm831x-ts - convert to devm_input_allocate_device()
Input: wm831x-on - convert to devm_input_allocate_device()
Mathieu Poirier (1):
Input: sysrq - allow specifying alternate reset sequence
Michael Trimarchi (2):
Input: bma150 - fix checking pm_runtime_get_sync() return value
Input: bma150 - make some defines public and fix some comments
Pali Rohár (1):
Input: tsc2005 - add MODULE_ALIAS
Peter Ujfalusi (4):
Input: twl4030-vibra - switch to using managed resources
Input: twl4030-vibra - Use system workqueue
Input: twl6040-vibra - code cleanup in probe with devm_* conversion
Input: twl6040-vibra - use system workqueue
Ping Cheng (3):
Input: wacom - prepare for syncing with input-mt changes
Input: wacom - use new input-mt routines
Input: wacom - add support for DTH-2242
Sachin Kamat (1):
Input: mms114 - switch to using managed resources
Shawn Nematbakhsh (1):
Input: atkbd - fix multi-byte scancode handling on reconnect
Stephen Warren (1):
Input: tegra-kbc - require CONFIG_OF, remove platform data
Vipul Kumar Samar (1):
Input: stmpe-ts - report BTN_TOUCH event
Wolfram Sang (4):
Input: adxl34x - consistently use read/write encapsulation
Input: adxl34x - don't set THRESH_TAP twice
Input: adxl34x - make platform_data include self contained
Input: adxl34x - default platform_data should not use defines from driver
Diffstat:
.../devicetree/bindings/input/imx-keypad.txt | 53 ++
.../bindings/input/nvidia,tegra20-kbc.txt | 22 +
drivers/input/Kconfig | 2 +-
drivers/input/input-mt.c | 1 +
drivers/input/joystick/walkera0701.c | 82 +-
drivers/input/keyboard/Kconfig | 16 +-
drivers/input/keyboard/Makefile| 1 +
drivers/input/keyboard/atkbd.c | 74 +-
drivers/input/keyboard/goldfish_events.c |
Re: [patch v5 02/15] sched: set initial load avg of new forked task
On 02/18/2013 01:07 PM, Alex Shi wrote:
> New task has no runnable sum at its first runnable time, so its
> runnable load is zero. That makes burst forking balancing just select
> few idle cpus to assign tasks if we engage runnable load in balancing.
>
> Set initial load avg of new forked task as its load weight to resolve
> this issue.
>
patch answering PJT's update here. that merged the 1st and 2nd patches
into one. other patches in serial don't need to change.
=
>From 89b56f2e5a323a0cb91c98be15c94d34e8904098 Mon Sep 17 00:00:00 2001
From: Alex Shi
Date: Mon, 3 Dec 2012 17:30:39 +0800
Subject: [PATCH 01/14] sched: set initial value of runnable avg for new
forked task
We need initialize the se.avg.{decay_count, load_avg_contrib} for a
new forked task.
Otherwise random values of above variables cause mess when do new task
enqueue:
enqueue_task_fair
enqueue_entity
enqueue_entity_load_avg
and make forking balancing imbalance since incorrect load_avg_contrib.
set avg.decay_count = 0, and avg.load_avg_contrib = se->load.weight to
resolve such issues.
Signed-off-by: Alex Shi
---
kernel/sched/core.c | 3 +++
kernel/sched/fair.c | 4
2 files changed, 7 insertions(+)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 26058d0..1452e14 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -1559,6 +1559,7 @@ static void __sched_fork(struct task_struct *p)
#if defined(CONFIG_SMP) && defined(CONFIG_FAIR_GROUP_SCHED)
p->se.avg.runnable_avg_period = 0;
p->se.avg.runnable_avg_sum = 0;
+ p->se.avg.decay_count = 0;
#endif
#ifdef CONFIG_SCHEDSTATS
memset(&p->se.statistics, 0, sizeof(p->se.statistics));
@@ -1646,6 +1647,8 @@ void sched_fork(struct task_struct *p)
p->sched_reset_on_fork = 0;
}
+ p->se.avg.load_avg_contrib = p->se.load.weight;
+
if (!rt_prio(p->prio))
p->sched_class = &fair_sched_class;
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 81fa536..cae5134 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -1509,6 +1509,10 @@ static inline void enqueue_entity_load_avg(struct cfs_rq
*cfs_rq,
* We track migrations using entity decay_count <= 0, on a wake-up
* migration we use a negative decay count to track the remote decays
* accumulated while sleeping.
+*
+* When enqueue a new forked task, the se->avg.decay_count == 0, so
+* we bypass update_entity_load_avg(), use avg.load_avg_contrib initial
+* value: se->load.weight.
*/
if (unlikely(se->avg.decay_count <= 0)) {
se->avg.last_runnable_update = rq_of(cfs_rq)->clock_task;
--
1.7.12
--
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] X.509: Support parse long form of length octets in Authority Key Identifier
Per X.509 spec in 4.2.1.1 section, the structure of Authority Key
Identifier Extension is:
AuthorityKeyIdentifier ::= SEQUENCE {
keyIdentifier [0] KeyIdentifier OPTIONAL,
authorityCertIssuer [1] GeneralNamesOPTIONAL,
authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL }
KeyIdentifier ::= OCTET STRING
When a certificate also provides
authorityCertIssuer and authorityCertSerialNumber then the length of
AuthorityKeyIdentifier SEQUENCE is likely to long form format.
e.g.
The example certificate demos/tunala/A-server.pem in openssl source:
X509v3 Authority Key Identifier:
keyid:49:FB:45:72:12:C4:CC:E1:45:A1:D3:08:9E:95:C4:2C:6D:55:3F:17
DirName:/C=NZ/L=Wellington/O=Really Irresponsible Authorisation Authority
(RIAA)/OU=Cert-stamping/CN=Jackov al-Trades/emailAddress=none@fake.domain
serial:00
Current parsing rule of OID_authorityKeyIdentifier only take care the
short form format, it causes load certificate to modsign_keyring fail:
[ 12.061147] X.509: Extension: 47
[ 12.075121] MODSIGN: Problem loading in-kernel X.509 certificate (-74)
So, this patch add the parsing rule for support long form format against
Authority Key Identifier.
v2:
- Removed comma from author's name.
- Moved 'Short Form length' comment inside the if-body.
- Changed the type of sub to size_t.
- Use ASN1_INDEFINITE_LENGTH rather than writing 0x80 and 127.
- Moved the key_len's value assignment before alter v.
- Fixed the typo of octets.
- Add 2 to v before entering the loop for calculate the length.
- Removed the comment of check vlen.
Cc: David Howells
Cc: Rusty Russell
Cc: Josh Boyer
Cc: Randy Dunlap
Cc: Herbert Xu
Cc: "David S. Miller"
Signed-off-by: Chun-Yi Lee
---
crypto/asymmetric_keys/x509_cert_parser.c | 55
1 files changed, 47 insertions(+), 8 deletions(-)
diff --git a/crypto/asymmetric_keys/x509_cert_parser.c
b/crypto/asymmetric_keys/x509_cert_parser.c
index 7fabc4c..59ab6d2 100644
--- a/crypto/asymmetric_keys/x509_cert_parser.c
+++ b/crypto/asymmetric_keys/x509_cert_parser.c
@@ -373,6 +373,9 @@ int rsa_extract_mpi(void *context, size_t hdrlen,
return 0;
}
+/* The keyIdentifier in AuthorityKeyIdentifier SEQUENCE is tag(CONT,PRIM,0) */
+#define SEQ_TAG_KEYID (ASN1_CONT << 6)
+
/*
* Process certificate extensions that are used to qualify the certificate.
*/
@@ -407,21 +410,57 @@ int x509_process_extension(void *context, size_t hdrlen,
}
if (ctx->last_oid == OID_authorityKeyIdentifier) {
+ size_t key_len;
+
/* Get hold of the CA key fingerprint */
if (vlen < 5)
return -EBADMSG;
- if (v[0] != (ASN1_SEQ | (ASN1_CONS << 5)) ||
- v[1] != vlen - 2 ||
- v[2] != (ASN1_CONT << 6) ||
- v[3] != vlen - 4)
+
+ /* Authority Key Identifier must be a Constructed SEQUENCE */
+ if (v[0] != (ASN1_SEQ | (ASN1_CONS << 5)))
return -EBADMSG;
- v += 4;
- vlen -= 4;
- f = kmalloc(vlen * 2 + 1, GFP_KERNEL);
+ /* Authority Key Identifier is not indefinite length */
+ if (unlikely(vlen == ASN1_INDEFINITE_LENGTH))
+ return -EBADMSG;
+
+ if (vlen < ASN1_INDEFINITE_LENGTH) {
+ /* Short Form length */
+ if (v[1] != vlen - 2 ||
+ v[2] != SEQ_TAG_KEYID ||
+ v[3] != vlen - 4)
+ return -EBADMSG;
+
+ key_len = v[3];
+ v += 4;
+ } else {
+ /* Long Form length */
+ size_t seq_len = 0;
+ size_t sub = v[1] - ASN1_INDEFINITE_LENGTH;
+
+ if (sub > 2)
+ return -EBADMSG;
+
+ /* calculate the length from subsequent octets */
+ v += 2;
+ for (i = 0; i < sub; i++) {
+ seq_len <<= 8;
+ seq_len |= v[i];
+ }
+
+ if (seq_len != vlen - 2 - sub ||
+ v[sub] != SEQ_TAG_KEYID ||
+ v[sub + 1] > vlen - 4 - sub)
+ return -EBADMSG;
+
+ key_len = v[sub + 1];
+ v += (sub + 2);
+ }
+
+ f = kmalloc(key_len * 2 + 1, GFP_KERNEL);
if (!f)
return -ENOMEM;
- for (i = 0; i < vlen; i++)
+ for (i = 0; i < key_len; i++)
sprintf(f + i * 2, "%02x", v[i]);
pr_debug("authority %s\n", f);
ctx->cert-
[PATCH] MIPS: fix access_ok()
From: Yong Zhang Current access_ok() will fail even if the address range is valid when it reaches to the end of TASK_SIZE. For exampe: addr = 0xf0; size = 16; the real address range it want to access is 0xf0~0xf; but addr + size = 0x100 which we will not and can't access. In current realization of access_ok(), the high bit will be 1 thus access_ok() indicates the operation is not allowed. The bug is found in old kerenl(before vdso is realized) in following typical call trace: sys_mount() copy_mount_options() exact_copy_from_user() When the parameter 'from' for exact_copy_from_user() residents in the last page of the task's virtual address, such as stack. But it's still in current kernel. Signed-off-by: Yong Zhang Cc: Ralf Baechle Cc: David Daney --- arch/mips/include/asm/uaccess.h |8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/arch/mips/include/asm/uaccess.h b/arch/mips/include/asm/uaccess.h index 3b92efe..55d4214 100644 --- a/arch/mips/include/asm/uaccess.h +++ b/arch/mips/include/asm/uaccess.h @@ -114,8 +114,12 @@ extern u64 __ua_limit; unsigned long __ok; \ \ __chk_user_ptr(addr); \ - __ok = (signed long)(__mask & (__addr | (__addr + __size) | \ - __ua_size(__size)));\ + if (likely(size)) \ + __ok = (signed long)(__mask & (__addr | \ + (__addr + __size - 1) | \ + __ua_size(__size)));\ + else\ + __ok = 0; \ __ok == 0; \ }) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 11/11] mfd: tc3589x: use devm_request_irq() and devm_kzalloc()
Use devm_request_irq() and devm_kzalloc() to make cleanup paths
more simple.
Signed-off-by: Jingoo Han
---
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/
[PATCH 10/11] mfd: tps65010: use devm_request_irq() and devm_kzalloc()
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;
}
@@ -549,7 +546,7 @@ static int tps65010_probe(struct i2c_client *client,
if (!i2c_check_functionality(client->adapter, I2C_FUNC_SMBUS_BYTE_DATA))
return -EINVAL;
- tps = kzalloc(sizeof *tps, GFP_KERNEL);
+ tps = devm_kzalloc(&client->dev, sizeof(*tps), GFP_KERNEL);
if (!tps)
return -ENOMEM;
@@ -562,12 +559,13 @@ static int tps65010_probe(struct i2c_client *client,
* so this driver uses falling-edge triggers instead.
*/
if (client->irq > 0) {
- status = request_irq(client->irq, tps65010_irq,
-IRQF_TRIGGER_FALLING, DRIVER_NAME, tps);
+ status = devm_request_irq(&client->dev, client->irq,
+ tps65010_irq, IRQF_TRIGGER_FALLING,
+ DRIVER_NAME, tps);
if (status < 0) {
dev_dbg(&client->dev, "can't get IRQ %d, err %d\n",
client->irq, status);
- goto fail1;
+ return status;
}
/* annoying race here, ideally we'd have an option
* to claim the irq now and enable it later.
@@ -667,9 +665,6 @@ static int tps65010_probe(struct i2c_client *client,
}
return 0;
-fail1:
- kfree(tps);
- return status;
}
static const struct i2c_device_id tps65010_id[] = {
--
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 09/11] mfd: da903x: use devm_request_irq() and devm_kzalloc()
Use devm_request_irq() and devm_kzalloc() to make cleanup paths
more simple.
Signed-off-by: Jingoo Han
---
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/
Re: Fwd: mmc card probe not getting called
On Wed, 2013-02-20 at 11:25 +0530, chetan cr123 wrote:
Avoiding top posting.
> Hi Anish,
>
> Thanks for your reply,
>
> I was doing device registration for device by giving same name as
> driver name, This i used to do in platform driver registration,
>
> But i dont know how to do for mmc device registration,
>
> And i also want to know which part of the code(file name) is doing the
> string compare with the driver and device names and calling the probe
> function. can u please point me to that part of code. from many days i
> was searching from which part of code where string compare is done and
> calls the probe function.
>
>
> Kindly point me out to that part of code.
look at drivers/base/dd.c
static int really_probe(struct device *dev, struct device_driver *drv)
{
//snip
if (dev->bus->probe) {
ret = dev->bus->probe(dev);
if (ret)
goto probe_failed;
} else if (drv->probe) {
ret = drv->probe(dev);
if (ret)
goto probe_failed;
}
Tip:Whenever you want to see how some function is being called use
dump_stack().This will give you the call chain leading up to your
function call which you are interested in.
>
>
>
> On Tue, Feb 19, 2013 at 9:25 PM, anish kumar
> wrote:
> > On Tue, 2013-02-19 at 12:16 +0530, chetan cr123 wrote:
> >> HI All,
> >>
> >> I am working on Sd Card/Block driver
> >>
> >> I am registering it as both
> >>
> >> 1. register_blkdev()- BLOCK Regsiter
> >> 2. mmc_register_driver -- MMC regsiter
> >>
> >> and filling the mmc_driver structure.
> >>
> >> I am not able to see the probe of MMC, But i see the return value of
> >> mmc_register function returning success.
> > I am not an expert on MMC driver but AFAIK it is no different in terms
> > of following device/driver model.
> > Probe of a function is only called when device name matches with driver
> > name and when it happens driver calls your probe.
> >
> > So in your case even though you have registered the driver, looks like
> > you are missing the device registration part.Do that and see the magic.
> > If this is SOC then that is done in the board file i.e.
> > arch/arm/plat-xyz/
> >
> >>
> >> Kindly let me know how i make the probe of mmc getting called
> >>
> >> Thanks
> >>
> >>
> >> Chetan
> >> --
> >> 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 08/11] mfd: ezx-pcap: use devm_request_irq() and devm_kzalloc()
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);
-
return 0;
}
@@ -431,7 +428,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 +445,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 +455,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 +488,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;
@@ -510,15 +508,11 @@ 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);
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/
[PATCH v10 2/4] block: add runtime pm helpers
From: Lin Ming
Add runtime pm helper functions:
void blk_pm_runtime_init(struct request_queue *q, struct device *dev)
- Initialization function for drivers to call.
int blk_pre_runtime_suspend(struct request_queue *q)
- If any requests are in the queue, mark last busy and return -EBUSY.
Otherwise set q->rpm_status to RPM_SUSPENDING and return 0.
void blk_post_runtime_suspend(struct request_queue *q, int err)
- If the suspend succeeded then set q->rpm_status to RPM_SUSPENDED.
Otherwise set it to RPM_ACTIVE and mark last busy.
void blk_pre_runtime_resume(struct request_queue *q)
- Set q->rpm_status to RPM_RESUMING.
void blk_post_runtime_resume(struct request_queue *q, int err)
- If the resume succeeded then set q->rpm_status to RPM_ACTIVE
and call __blk_run_queue, then mark last busy and autosuspend.
Otherwise set q->rpm_status to RPM_SUSPENDED.
The idea and API is designed by Alan Stern and described here:
http://marc.info/?l=linux-scsi&m=133727953625963&w=2
Signed-off-by: Lin Ming
Signed-off-by: Aaron Lu
---
block/blk-core.c | 144 +
include/linux/blkdev.h | 27 ++
2 files changed, 171 insertions(+)
diff --git a/block/blk-core.c b/block/blk-core.c
index 66d3168..ce7d366 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -30,6 +30,7 @@
#include
#include
#include
+#include
#define CREATE_TRACE_POINTS
#include
@@ -3043,6 +3044,149 @@ void blk_finish_plug(struct blk_plug *plug)
}
EXPORT_SYMBOL(blk_finish_plug);
+#ifdef CONFIG_PM_RUNTIME
+/**
+ * blk_pm_runtime_init - Block layer runtime PM initialization routine
+ * @q: the queue of the device
+ * @dev: the device the queue belongs to
+ *
+ * Description:
+ *Initialize runtime-PM-related fields for @q and start auto suspend for
+ *@dev. Drivers that want to take advantage of request-based runtime PM
+ *should call this function after @dev has been initialized, and its
+ *request queue @q has been allocated, and runtime PM for it can not happen
+ *yet(either due to disabled/forbidden or its usage_count > 0). In most
+ *cases, driver should call this function before any I/O has taken place.
+ *
+ *This function takes care of setting up using auto suspend for the device,
+ *the autosuspend delay is set to -1 to make runtime suspend impossible
+ *until an updated value is either set by user or by driver. Drivers do
+ *not need to touch other autosuspend settings.
+ *
+ *The block layer runtime PM is request based, so only works for drivers
+ *that use request as their IO unit instead of those directly use bio's.
+ */
+void blk_pm_runtime_init(struct request_queue *q, struct device *dev)
+{
+ q->dev = dev;
+ q->rpm_status = RPM_ACTIVE;
+ pm_runtime_set_autosuspend_delay(q->dev, -1);
+ pm_runtime_use_autosuspend(q->dev);
+}
+EXPORT_SYMBOL(blk_pm_runtime_init);
+
+/**
+ * blk_pre_runtime_suspend - Pre runtime suspend check
+ * @q: the queue of the device
+ *
+ * Description:
+ *This function will check if runtime suspend is allowed for the device
+ *by examining if there are any requests pending in the queue. If there
+ *are requests pending, the device can not be runtime suspended; otherwise,
+ *the queue's status will be updated to SUSPENDING and the driver can
+ *proceed to suspend the device.
+ *
+ *For the not allowed case, we mark last busy for the device so that
+ *runtime PM core will try to autosuspend it some time later.
+ *
+ *This function should be called near the start of the device's
+ *runtime_suspend callback.
+ *
+ * Return:
+ *0- OK to runtime suspend the device
+ *-EBUSY - Device should not be runtime suspended
+ */
+int blk_pre_runtime_suspend(struct request_queue *q)
+{
+ int ret = 0;
+
+ spin_lock_irq(q->queue_lock);
+ if (q->nr_pending) {
+ ret = -EBUSY;
+ pm_runtime_mark_last_busy(q->dev);
+ } else {
+ q->rpm_status = RPM_SUSPENDING;
+ }
+ spin_unlock_irq(q->queue_lock);
+ return ret;
+}
+EXPORT_SYMBOL(blk_pre_runtime_suspend);
+
+/**
+ * blk_post_runtime_suspend - Post runtime suspend processing
+ * @q: the queue of the device
+ * @err: return value of the device's runtime_suspend function
+ *
+ * Description:
+ *Update the queue's runtime status according to the return value of the
+ *device's runtime suspend function and mark last busy for the device so
+ *that PM core will try to auto suspend the device at a later time.
+ *
+ *This function should be called near the end of the device's
+ *runtime_suspend callback.
+ */
+void blk_post_runtime_suspend(struct request_queue *q, int err)
+{
+ spin_lock_irq(q->queue_lock);
+ if (!err) {
+ q->rpm_status = RPM_SUSPENDED;
+ } else {
+ q->rpm_status = RPM_ACTIVE;
+ pm_runtime_mark_last
[PATCH v10 0/4] block layer runtime pm
In August 2010, Jens and Alan discussed about "Runtime PM and the block layer". http://marc.info/?t=12825910841&r=1&w=2 And then Alan has given a detailed implementation guide: http://marc.info/?l=linux-scsi&m=133727953625963&w=2 To test: # ls -l /sys/block/sda /sys/devices/pci:00/:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sda # echo 1 > /sys/devices/pci:00/:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/power/autosuspend_delay_ms # echo auto > /sys/devices/pci:00/:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/power/control Then you'll see sda is suspended after 10secs idle. [ 1767.680192] sd 2:0:0:0: [sda] Synchronizing SCSI cache [ 1767.680317] sd 2:0:0:0: [sda] Stopping disk And if you do some IO, it will resume immediately. [ 1791.052438] sd 2:0:0:0: [sda] Starting disk For test, I often set the autosuspend time to 1 second. If you are using a GUI, the 10 seconds delay may be too long that the disk can not enter runtime suspended state. Note that sd's runtime suspend callback will dump some kernel messages and the syslog daemon will write kernel message to /var/log/messages, making the disk instantly resume after suspended. So for test, the syslog daemon should better be temporarily stopped. A git repo for it, on top of libata/upstream, scsi/for-next and block/for-next: https://github.com/aaronlu/linux.git blockpm v10: - Add link of Alan Stern's ideas on block layer runtime PM to patch 2 and 3's changelog; - Add back code to schdule device suspend if scsi driver return -EBUSY. v9: - No need to mark last busy and autosuspend in blk_pm_runtime_init as suggested by Alan Stern; - mark last busy in blk_runtime_post_suspend if driver failed to runtime suspend the device, so that PM core can try to autosuspend it some time later; - Update scsi bus layer runtime callback to handle scsi devices which use request based runtime PM and which don't. v8: - Set default autosuspend delay to -1 to avoid suspend till an updated value is set as suggested by Alan Stern; - Always check the dev field of the queue structure, as it is incorrect and meaningless to do any operation on devices that do not use block layer runtime PM as reminded by Alan Stern; - Update scsi bus level runtime PM callback to take care of scsi devices that use block layer runtime PM and that don't. v7: - Add kernel doc for block layer runtime PM API as suggested by Alan Stern; - Add back check for q->dev, as that serves as a flag if driver is using block layer runtime PM; - Do not auto suspend when last request is finished, as that's a hot path and auto suspend is not a trivial function. Instead, mark last busy in pre_suspend so that runtim PM core will retry suspend some time later to solve the 1st problem demostrated in v6, suggested by Alan Stern. - Move block layer runtime PM strtegy functions to where they are needed instead of in include/linux/blkdev.h as suggested by Alan Stern since clients of block layer do not need to know those functions. v6: Take over from Lin Ming. - Instead of put the device into autosuspend state in blk_post_runtime_suspend, do it when the last request is finished. This can also solve the problem illustrated below: thread Athread B |suspend timer expired | | ... ... |a new request comes in, | ... ... |blk_pm_add_request | ... ... |skip request_resume due to | ... ... |q->status is still RPM_ACTIVE | rpm_suspend | ... ... |scsi_runtime_suspend | ... ... | blk_pre_runtime_suspend | ... ... | return -EBUSY due to nr_pending | ... ... | rpm_suspend done | ... ... | |blk_pm_put_request, mark last busy But no more trigger point, and the device will stay at RPM_ACTIVE state. Run pm_runtime_autosuspend after the last request is finished solved this problem. - Requests which have the REQ_PM flag should not involve nr_pending counting, or we may lose the condition to resume the device: Suppose queue is active and nr_pending is 0. Then a REQ_PM request comes and nr_pending will be increased to 1, but since the request has REQ_PM flag, it will not cause resume. Before it is finished, a normal request comes in, and since nr_pending is 1 now, it will not trigger the resume of the device either. Bug. - Do not quiesce the device in scsi bus level runtime suspend callback. Since the only reason the device is to be runtime suspended is due to no more requests pending for it, quiesce it is pointless. - Remove scsi_autopm_* from sd_check_events as we are request driven. - Call blk_pm_runtime_init in scsi_sysfs_initialize_dev, so that we do not need to check queue's device in blk_pm_add/put_request. - Do not mark last busy and initiate a
[PATCH 07/11] mfd: menelaus: use devm_request_irq() and devm_kzalloc()
Use devm_request_irq() and devm_kzalloc() to make cleanup paths
more simple.
Signed-off-by: Jingoo Han
---
drivers/mfd/menelaus.c | 23 +--
1 files changed, 9 insertions(+), 14 deletions(-)
diff --git a/drivers/mfd/menelaus.c b/drivers/mfd/menelaus.c
index 998ce8c..28bac1c 100644
--- a/drivers/mfd/menelaus.c
+++ b/drivers/mfd/menelaus.c
@@ -1197,7 +1197,8 @@ static int menelaus_probe(struct i2c_client *client,
return -ENODEV;
}
- menelaus = kzalloc(sizeof *menelaus, GFP_KERNEL);
+ menelaus = devm_kzalloc(&client->dev, sizeof(*menelaus),
+ GFP_KERNEL);
if (!menelaus)
return -ENOMEM;
@@ -1210,8 +1211,7 @@ static int menelaus_probe(struct i2c_client *client,
rev = menelaus_read_reg(MENELAUS_REV);
if (rev < 0) {
pr_err(DRIVER_NAME ": device not found");
- err = -ENODEV;
- goto fail1;
+ return -ENODEV;
}
/* Ack and disable all Menelaus interrupts */
@@ -1226,12 +1226,12 @@ static int menelaus_probe(struct i2c_client *client,
menelaus_write_reg(MENELAUS_MCT_CTRL1, 0x73);
if (client->irq > 0) {
- err = request_irq(client->irq, menelaus_irq, 0,
- DRIVER_NAME, menelaus);
+ err = devm_request_irq(&client->dev, client->irq, menelaus_irq,
+ 0, DRIVER_NAME, menelaus);
if (err) {
dev_dbg(&client->dev, "can't get IRQ %d, err %d\n",
client->irq, err);
- goto fail1;
+ return err;
}
}
@@ -1242,7 +1242,7 @@ static int menelaus_probe(struct i2c_client *client,
val = menelaus_read_reg(MENELAUS_VCORE_CTRL1);
if (val < 0)
- goto fail2;
+ goto fail1;
if (val & (1 << 7))
menelaus->vcore_hw_mode = 1;
else
@@ -1251,17 +1251,14 @@ static int menelaus_probe(struct i2c_client *client,
if (menelaus_pdata != NULL && menelaus_pdata->late_init != NULL) {
err = menelaus_pdata->late_init(&client->dev);
if (err < 0)
- goto fail2;
+ goto fail1;
}
menelaus_rtc_init(menelaus);
return 0;
-fail2:
- free_irq(client->irq, menelaus);
- flush_work(&menelaus->work);
fail1:
- kfree(menelaus);
+ flush_work(&menelaus->work);
return err;
}
@@ -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;
}
--
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 06/11] 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
---
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 v10 3/4] block: implement runtime pm strategy
From: Lin Ming
When a request is added:
If device is suspended or is suspending and the request is not a
PM request, resume the device.
When the last request finishes:
Call pm_runtime_mark_last_busy().
When pick a request:
If device is resuming/suspending, then only PM request is allowed
to go.
The idea and API is designed by Alan Stern and described here:
http://marc.info/?l=linux-scsi&m=133727953625963&w=2
Signed-off-by: Lin Ming
Signed-off-by: Aaron Lu
---
block/blk-core.c | 39 +++
block/elevator.c | 26 ++
2 files changed, 65 insertions(+)
diff --git a/block/blk-core.c b/block/blk-core.c
index ce7d366..81f173e 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -1264,6 +1264,16 @@ void part_round_stats(int cpu, struct hd_struct *part)
}
EXPORT_SYMBOL_GPL(part_round_stats);
+#ifdef CONFIG_PM_RUNTIME
+static void blk_pm_put_request(struct request *rq)
+{
+ if (rq->q->dev && !(rq->cmd_flags & REQ_PM) && !--rq->q->nr_pending)
+ pm_runtime_mark_last_busy(rq->q->dev);
+}
+#else
+static inline void blk_pm_put_request(struct request *rq) {}
+#endif
+
/*
* queue lock must be held
*/
@@ -1274,6 +1284,8 @@ void __blk_put_request(struct request_queue *q, struct
request *req)
if (unlikely(--req->ref_count))
return;
+ blk_pm_put_request(req);
+
elv_completed_request(q, req);
/* this is a bio leak */
@@ -2051,6 +2063,28 @@ static void blk_account_io_done(struct request *req)
}
}
+#ifdef CONFIG_PM_RUNTIME
+/*
+ * Don't process normal requests when queue is suspended
+ * or in the process of suspending/resuming
+ */
+static struct request *blk_pm_peek_request(struct request_queue *q,
+ struct request *rq)
+{
+ if (q->dev && (q->rpm_status == RPM_SUSPENDED ||
+ (q->rpm_status != RPM_ACTIVE && !(rq->cmd_flags & REQ_PM
+ return NULL;
+ else
+ return rq;
+}
+#else
+static inline struct request *blk_pm_peek_request(struct request_queue *q,
+ struct request *rq)
+{
+ return rq;
+}
+#endif
+
/**
* blk_peek_request - peek at the top of a request queue
* @q: request queue to peek at
@@ -2073,6 +2107,11 @@ struct request *blk_peek_request(struct request_queue *q)
int ret;
while ((rq = __elv_next_request(q)) != NULL) {
+
+ rq = blk_pm_peek_request(q, rq);
+ if (!rq)
+ break;
+
if (!(rq->cmd_flags & REQ_STARTED)) {
/*
* This is the first time the device driver
diff --git a/block/elevator.c b/block/elevator.c
index 11683bb..29c5c7e 100644
--- a/block/elevator.c
+++ b/block/elevator.c
@@ -34,6 +34,7 @@
#include
#include
#include
+#include
#include
@@ -515,6 +516,27 @@ void elv_bio_merged(struct request_queue *q, struct
request *rq,
e->type->ops.elevator_bio_merged_fn(q, rq, bio);
}
+#ifdef CONFIG_PM_RUNTIME
+static void blk_pm_requeue_request(struct request *rq)
+{
+ if (rq->q->dev && !(rq->cmd_flags & REQ_PM))
+ rq->q->nr_pending--;
+}
+
+static void blk_pm_add_request(struct request_queue *q, struct request *rq)
+{
+ if (q->dev && !(rq->cmd_flags & REQ_PM) && q->nr_pending++ == 0 &&
+ (q->rpm_status == RPM_SUSPENDED || q->rpm_status == RPM_SUSPENDING))
+ pm_request_resume(q->dev);
+}
+#else
+static inline void blk_pm_requeue_request(struct request *rq) {}
+static inline void blk_pm_add_request(struct request_queue *q,
+ struct request *rq)
+{
+}
+#endif
+
void elv_requeue_request(struct request_queue *q, struct request *rq)
{
/*
@@ -529,6 +551,8 @@ void elv_requeue_request(struct request_queue *q, struct
request *rq)
rq->cmd_flags &= ~REQ_STARTED;
+ blk_pm_requeue_request(rq);
+
__elv_add_request(q, rq, ELEVATOR_INSERT_REQUEUE);
}
@@ -551,6 +575,8 @@ void __elv_add_request(struct request_queue *q, struct
request *rq, int where)
{
trace_block_rq_insert(q, rq);
+ blk_pm_add_request(q, rq);
+
rq->q = q;
if (rq->cmd_flags & REQ_SOFTBARRIER) {
--
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/
[PATCH v10 1/4] block: add a flag to identify PM request
From: Lin Ming
Add a flag REQ_PM to identify the request is PM related, such requests
will not change the device request queue's runtime status. It is
intended to be used in driver's runtime PM callback, so that driver can
perform some IO to the device there with the queue's runtime status
unaffected. e.g. in SCSI disk's runtime suspend callback, the disk will
be put into stopped power state, and this require sending a command to
the device. Such command processing should not change the disk's runtime
status.
As an example, modify scsi code to use this flag.
Signed-off-by: Lin Ming
Signed-off-by: Aaron Lu
---
drivers/scsi/scsi_lib.c| 9 -
drivers/scsi/sd.c | 9 +
include/linux/blk_types.h | 2 ++
include/scsi/scsi_device.h | 16
4 files changed, 23 insertions(+), 13 deletions(-)
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 765398c..23f795f 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -271,11 +271,10 @@ int scsi_execute(struct scsi_device *sdev, const unsigned
char *cmd,
}
EXPORT_SYMBOL(scsi_execute);
-
-int scsi_execute_req(struct scsi_device *sdev, const unsigned char *cmd,
+int scsi_execute_req_flags(struct scsi_device *sdev, const unsigned char *cmd,
int data_direction, void *buffer, unsigned bufflen,
struct scsi_sense_hdr *sshdr, int timeout, int retries,
-int *resid)
+int *resid, int flags)
{
char *sense = NULL;
int result;
@@ -286,14 +285,14 @@ int scsi_execute_req(struct scsi_device *sdev, const
unsigned char *cmd,
return DRIVER_ERROR << 24;
}
result = scsi_execute(sdev, cmd, data_direction, buffer, bufflen,
- sense, timeout, retries, 0, resid);
+ sense, timeout, retries, flags, resid);
if (sshdr)
scsi_normalize_sense(sense, SCSI_SENSE_BUFFERSIZE, sshdr);
kfree(sense);
return result;
}
-EXPORT_SYMBOL(scsi_execute_req);
+EXPORT_SYMBOL(scsi_execute_req_flags);
/*
* Function:scsi_init_cmd_errh()
diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
index 7992635..c6e2b34 100644
--- a/drivers/scsi/sd.c
+++ b/drivers/scsi/sd.c
@@ -1424,8 +1424,9 @@ static int sd_sync_cache(struct scsi_disk *sdkp)
* Leave the rest of the command zero to indicate
* flush everything.
*/
- res = scsi_execute_req(sdp, cmd, DMA_NONE, NULL, 0, &sshdr,
- SD_FLUSH_TIMEOUT, SD_MAX_RETRIES, NULL);
+ res = scsi_execute_req_flags(sdp, cmd, DMA_NONE, NULL, 0,
+&sshdr, SD_FLUSH_TIMEOUT,
+SD_MAX_RETRIES, NULL, REQ_PM);
if (res == 0)
break;
}
@@ -3021,8 +3022,8 @@ static int sd_start_stop_device(struct scsi_disk *sdkp,
int start)
if (!scsi_device_online(sdp))
return -ENODEV;
- res = scsi_execute_req(sdp, cmd, DMA_NONE, NULL, 0, &sshdr,
- SD_TIMEOUT, SD_MAX_RETRIES, NULL);
+ res = scsi_execute_req_flags(sdp, cmd, DMA_NONE, NULL, 0, &sshdr,
+ SD_TIMEOUT, SD_MAX_RETRIES, NULL, REQ_PM);
if (res) {
sd_printk(KERN_WARNING, sdkp, "START_STOP FAILED\n");
sd_print_result(sdkp, res);
diff --git a/include/linux/blk_types.h b/include/linux/blk_types.h
index cdf1119..fcc1ce2 100644
--- a/include/linux/blk_types.h
+++ b/include/linux/blk_types.h
@@ -175,6 +175,7 @@ enum rq_flag_bits {
__REQ_IO_STAT, /* account I/O stat */
__REQ_MIXED_MERGE, /* merge of different types, fail separately */
__REQ_KERNEL, /* direct IO to kernel pages */
+ __REQ_PM, /* runtime pm request */
__REQ_NR_BITS, /* stops here */
};
@@ -223,5 +224,6 @@ enum rq_flag_bits {
#define REQ_MIXED_MERGE(1 << __REQ_MIXED_MERGE)
#define REQ_SECURE (1 << __REQ_SECURE)
#define REQ_KERNEL (1 << __REQ_KERNEL)
+#define REQ_PM (1 << __REQ_PM)
#endif /* __LINUX_BLK_TYPES_H */
diff --git a/include/scsi/scsi_device.h b/include/scsi/scsi_device.h
index a7f9cba..cc64587 100644
--- a/include/scsi/scsi_device.h
+++ b/include/scsi/scsi_device.h
@@ -394,10 +394,18 @@ extern int scsi_execute(struct scsi_device *sdev, const
unsigned char *cmd,
int data_direction, void *buffer, unsigned bufflen,
unsigned char *sense, int timeout, int retries,
int flag, int *resid);
-extern int scsi_execute_req(struct scsi_device *sdev, const unsigned char *cmd,
- int data_direction, void *buffer, unsigned bufflen,
- struct
[PATCH 04/11] mfd: intel_msic: use devm_gpio_request_one()
Use devm_gpio_request_one() to make cleanup paths more simple.
Signed-off-by: Jingoo Han
---
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/
[PATCH 05/11] mfd: twl6040: use devm_gpio_request_one() and devm_request_threaded_irq()
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);
--
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 v10 4/4] sd: change to auto suspend mode
From: Lin Ming
Uses block layer runtime pm helper functions in
scsi_runtime_suspend/resume for devices that take advantage of it.
Remove scsi_autopm_* from sd open/release path and check_events path.
Signed-off-by: Lin Ming
Signed-off-by: Aaron Lu
---
drivers/scsi/scsi_pm.c | 84 ++
drivers/scsi/sd.c | 13 +---
2 files changed, 72 insertions(+), 25 deletions(-)
diff --git a/drivers/scsi/scsi_pm.c b/drivers/scsi/scsi_pm.c
index 8f6b12c..90b12d9 100644
--- a/drivers/scsi/scsi_pm.c
+++ b/drivers/scsi/scsi_pm.c
@@ -144,33 +144,83 @@ static int scsi_bus_restore(struct device *dev)
#ifdef CONFIG_PM_RUNTIME
+static int sdev_blk_runtime_suspend(struct scsi_device *sdev,
+ int (*cb)(struct device *))
+{
+ int err;
+
+ err = blk_pre_runtime_suspend(sdev->request_queue);
+ if (err)
+ return err;
+ if (cb)
+ err = cb(&sdev->sdev_gendev);
+ blk_post_runtime_suspend(sdev->request_queue, err);
+
+ return err;
+}
+
+static int sdev_runtime_suspend(struct device *dev)
+{
+ const struct dev_pm_ops *pm = dev->driver ? dev->driver->pm : NULL;
+ int (*cb)(struct device *) = pm ? pm->runtime_suspend : NULL;
+ struct scsi_device *sdev = to_scsi_device(dev);
+ int ret;
+
+ if (sdev->request_queue->dev)
+ return sdev_blk_runtime_suspend(sdev, cb);
+
+ ret = scsi_dev_type_suspend(dev, cb);
+ if (err == -EAGAIN)
+ pm_schedule_suspend(dev, jiffies_to_msecs(
+ round_jiffies_up_relative(HZ/10)));
+ return ret;
+}
+
static int scsi_runtime_suspend(struct device *dev)
{
int err = 0;
- const struct dev_pm_ops *pm = dev->driver ? dev->driver->pm : NULL;
dev_dbg(dev, "scsi_runtime_suspend\n");
- if (scsi_is_sdev_device(dev)) {
- err = scsi_dev_type_suspend(dev,
- pm ? pm->runtime_suspend : NULL);
- if (err == -EAGAIN)
- pm_schedule_suspend(dev, jiffies_to_msecs(
- round_jiffies_up_relative(HZ/10)));
- }
+ if (scsi_is_sdev_device(dev))
+ err = sdev_runtime_suspend(dev);
/* Insert hooks here for targets, hosts, and transport classes */
return err;
}
-static int scsi_runtime_resume(struct device *dev)
+static int sdev_blk_runtime_resume(struct scsi_device *sdev,
+ int (*cb)(struct device *))
{
int err = 0;
+
+ blk_pre_runtime_resume(sdev->request_queue);
+ if (cb)
+ err = cb(&sdev->sdev_gendev);
+ blk_post_runtime_resume(sdev->request_queue, err);
+
+ return err;
+}
+
+static int sdev_runtime_resume(struct device *dev)
+{
+ struct scsi_device *sdev = to_scsi_device(dev);
const struct dev_pm_ops *pm = dev->driver ? dev->driver->pm : NULL;
+ int (*cb)(struct device *) = pm ? pm->runtime_resume : NULL;
+
+ if (sdev->request_queue->dev)
+ return sdev_blk_runtime_resume(sdev, cb);
+ else
+ return scsi_dev_type_resume(dev, cb);
+}
+
+static int scsi_runtime_resume(struct device *dev)
+{
+ int err = 0;
dev_dbg(dev, "scsi_runtime_resume\n");
if (scsi_is_sdev_device(dev))
- err = scsi_dev_type_resume(dev, pm ? pm->runtime_resume : NULL);
+ err = sdev_runtime_resume(dev);
/* Insert hooks here for targets, hosts, and transport classes */
@@ -185,10 +235,18 @@ static int scsi_runtime_idle(struct device *dev)
/* Insert hooks here for targets, hosts, and transport classes */
- if (scsi_is_sdev_device(dev))
- err = pm_schedule_suspend(dev, 100);
- else
+ if (scsi_is_sdev_device(dev)) {
+ struct scsi_device *sdev = to_scsi_device(dev);
+
+ if (sdev->request_queue->dev) {
+ pm_runtime_mark_last_busy(dev);
+ err = pm_runtime_autosuspend(dev);
+ } else {
+ err = pm_runtime_suspend(dev);
+ }
+ } else {
err = pm_runtime_suspend(dev);
+ }
return err;
}
diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
index c6e2b34..5000bec 100644
--- a/drivers/scsi/sd.c
+++ b/drivers/scsi/sd.c
@@ -1121,10 +1121,6 @@ static int sd_open(struct block_device *bdev, fmode_t
mode)
sdev = sdkp->device;
- retval = scsi_autopm_get_device(sdev);
- if (retval)
- goto error_autopm;
-
/*
* If the device is in error recovery, wait until it is done.
* If the device is offline, then disallow any access to it.
@@ -1169,8 +1165,6 @@ static int sd_open(struct block_device *bdev, fmode_t
mode)
return 0;
error_out:
- scsi_autopm_put_device(sdev)
[PATCH 03/11] mfd: aat2870: use devm_gpio_request_one() and devm_kzalloc()
Use devm_gpio_request_one() and devm_kzalloc() to make cleanup paths
more simple.
Signed-off-by: Jingoo Han
---
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 02/11] mfd: lm3533: use devm_gpio_request_one()
Use devm_gpio_request_one() to make cleanup paths more simple.
Signed-off-by: Jingoo Han
---
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 01/11] 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
---
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/
Re: [PATCH] dw_dmac: adjust slave_id accordingly to request line base
On Tue, Feb 19, 2013 at 11:02:24AM +0200, Andy Shevchenko wrote: > On Mon, 2013-01-28 at 13:04 +0200, Andy Shevchenko wrote: > > On some hardware configurations we have got the request line with the > > offset. > > The patch introduces convert_slave_id() helper for that cases. The request > > line > > base is got from the platform device resources provided by the > > IORESOURCE_DMA > > type. > > Hi, Vinod. > > v3.8 is just out, and we have not got any proposal from anyone how to > make our approach better. So, I'm just wondering about current state. I was trying to go thru ACPI 5 and see a solution, i think we - use IORESOURCE_IO, but they have a specfic meaning - accpet this patch with IORESOURCE_DMA, but again this has specfic dma meaning too. Just becoz you are in slave-dma driver, doesn't justify use of IORESOURCE_DMA as well - use platform_data (somehow get this from CSRT into device parsing logic of ACPI where you create your platform device and add this in platform data > Rafael, could you share your opinion about our case with CSRT and > request line base (perhaps you need to go through the entire thread)? Sure, do we have anything better than above? -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the akpm tree with the net-next tree
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in
net/core/dev.c between commit 900ff8c63214 ("net: move procfs code to
net/core/net-procfs.c") from the net-next tree and commit "hlist: drop
the node parameter from iterators" from the akpm tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --git a/net/core/net-procfs.c b/net/core/net-procfs.c
index 0f6bb6f..3174f19 100644
--- a/net/core/net-procfs.c
+++ b/net/core/net-procfs.c
@@ -16,12 +16,11 @@ static inline struct net_device
*dev_from_same_bucket(struct seq_file *seq, loff
{
struct net *net = seq_file_net(seq);
struct net_device *dev;
- struct hlist_node *p;
struct hlist_head *h;
unsigned int count = 0, offset = get_offset(*pos);
h = &net->dev_name_head[get_bucket(*pos)];
- hlist_for_each_entry_rcu(dev, p, h, name_hlist) {
+ hlist_for_each_entry_rcu(dev, h, name_hlist) {
if (++count == offset)
return dev;
}
pgpOpFt5Hiesd.pgp
Description: PGP signature
Re: Re[8]: [PATCH v3] mfd: syscon: Add non-DT support
On 20 February 2013 13:41, Alexander Shiyan wrote:
>> > ...
>> >> >> >> >> struct regmap *syscon_regmap_lookup_by_compatible(const char *s)
>> >> >> >> >> {
>> >> >> >> >> struct device_node *syscon_np;
>> >> >> >> >> struct regmap *regmap;
>> >> >> >> >> + struct syscon *syscon;
>> >> >> >> >> + struct device *dev;
>> >> >> >> >>
>> >> >> >> >> syscon_np = of_find_compatible_node(NULL, NULL, s);
>> >> >> >> >> - if (!syscon_np)
>> >> >> >> >> + if (syscon_np) {
>> >> >> >> >> + regmap = syscon_node_to_regmap(syscon_np);
>> >> >> >> >> + of_node_put(syscon_np);
>> >> >> >> >> +
>> >> >> >> >> + return regmap;
>> >> >> >> >> + }
>> >> >> >> >> +
>> >> >> >> >> + /* Fallback to search by id_entry.name string */
>> >> >> >> >> + dev = driver_find_device(&syscon_driver.driver, NULL,
>> >> >> >> >> (void *)s,
>> >> >> >> >> + syscon_match_id);
>> >> >> >> >> + if (!dev)
>> >> >> >> >> return ERR_PTR(-ENODEV);
>> >> >> >> >>
>> >> >> >> >> - regmap = syscon_node_to_regmap(syscon_np);
>> >> >> >> >> - of_node_put(syscon_np);
>> >> >> >> >> + syscon = dev_get_drvdata(dev);
>> >> >> >> >>
>> >> >> >> >> - return regmap;
>> >> >> >> >> + return syscon->regmap;
>> >> >> >> >> }
>> >> >> >> >> EXPORT_SYMBOL_GPL(syscon_regmap_lookup_by_compatible);
>> >> >> >> >
>> >> >> >> > Since you are not actually comparing the "compatible" property
>> >> >> >> > here,
>> >> >> >> > I would suggest adding another function here,
>> >> >> >>
>> >> >> >> Yes, i also think like that.
>> >> >> >
>> >> >> > In this case we should provide two paths for drivers which can work
>> >> >> > as with DT
>> >> >> > and without DT.
>> >> >>
>> >> >> Yes.
>> >> >
>> >> > I still think the universal procedure is better for the driver.
>> >> >
>> >>
>> >> Why?
>> >> I did not see your reply on my other comments on the problems of using
>> >> universal
>> >> procedure?
>> >> Please let me know if you think they're not issues.
>> >
>> > Yes, I do not see a problem here.
>> > I will try to show the code.
>> >
>> > In the driver:
>> > struct regmap *r;
>> > r = syscon_regmap_lookup_by_compatible("my_super_syscon");
>> >
>> > For DT case:
>> > syscon@123456 {
>> > compatible = "my_super_syscon", "syscon";
>> > ...
>> > };
>> >
>> > For non-DT case:
>> > struct platform_device_id id = { .name = "my_super_syscon", };
>> > struct platform_device syscon_pdev = {
>> > .name = "syscon",
>> > .id_entry = &id,
>>
>> This is really strange to me and i've never seen such using.
>> Usually the id_table is provided by the driver and the match process then
>> will
>> set the correct id_entry for the platform device once it matches.
>> Please see the platform_bus match process: drivers/base/platform.c
>
> Yes, this is non-standard usage. Currently we do not have platform_device_id
> entries for a "syscon" driver, so this field is untouched for a platform
> device
> and we can use it. At least this works, but, of course, more experts should
> fix me on this question if I think incorrect.
>
Hmm, i'm afraid most people may not accept this.
The platform_device_id are not desgined for such using, i guess.
>>
>> > ...
>> > };
>> > platform_device_register(&syscon_pdev);
>> >
>> > Do I understand what you mean?
>> >
>>
>> My understanding for non-dt case is something like:
>> In client driver:
>> struct regmap *r;
>> r = syscon_regmap_lookup_by_pdevname("my_super_syscon");
>>
>> In board code:
>> struct platform_device syscon_pdev = {
>> .name = "my_super_syscon",
>> ...
>> };
>> platform_device_register(&syscon_pdev);
>>
>> In syscon driver:
>> static struct platform_device_id syscon_device_ids[] = {
>> {
>> .name = "my_super_syscon",
>> }, {
>> /* sentinel */
>> }
>> };
>> MODULE_DEVICE_TABLE(platform, syscon_device_ids);
>>
>> static struct platform_driver syscon_driver = {
>> .driver = {
>> .name = "syscon",
>> .owner = THIS_MODULE,
>> .of_match_table = of_syscon_match,
>> },
>> .id_table = syscon_device_ids,
>> .probe = syscon_probe,
>> .remove = syscon_remove,
>> };
>>
>> 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...
>
Only non-dt needs add it which may not be so many and you're the first one.
Regards
Dong Aisheng
--
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://ww
Re: [TRIVIAL PATCH 00/26] treewide: Add and use vsprintf extension %pSR
On Tue, 2013-01-08 at 21:33 +0100, Jiri Kosina wrote: > On Mon, 7 Jan 2013, Joe Perches wrote: > > > > Remove the somewhat awkward uses of print_symbol and convert all the > > > existing uses to a new vsprintf pointer type of %pSR. > > > > Jiri? Are you going to do anything with this? > > Joe, > > yup, it's still in my TODO queue for trivial.git. Jiri? Is this still in your TODO queue? If so, for what version? -- 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] pch_dma: Use GFP_ATOMIC because called from interrupt context
On Wed, Feb 20, 2013 at 11:26:54AM +0900, Tomoya MORINAGA wrote:
> Hi
>
> Could you review this patch ?
> 8 days have passed...
Sorry looks like I missed it. I have queued it up and will apply after -rc1
--
~Vinod
>
> thanks,
> tomoya
>
> On Tue, Feb 12, 2013 at 11:25 AM, Tomoya MORINAGA
> wrote:
> > pdc_desc_get() is called from pd_prep_slave_sg, and the function is
> > called from interrupt context(e.g. Uart driver "pch_uart.c").
> > In fact, I saw kernel error message.
> > So, GFP_ATOMIC must be used not GFP_NOIO.
> >
> > Signed-off-by: Tomoya MORINAGA
> > ---
> > drivers/dma/pch_dma.c |2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/drivers/dma/pch_dma.c b/drivers/dma/pch_dma.c
> > index 987ab5c..d5cbd44 100644
> > --- a/drivers/dma/pch_dma.c
> > +++ b/drivers/dma/pch_dma.c
> > @@ -476,7 +476,7 @@ static struct pch_dma_desc *pdc_desc_get(struct
> > pch_dma_chan *pd_chan)
> > dev_dbg(chan2dev(&pd_chan->chan), "scanned %d descriptors\n", i);
> >
> > if (!ret) {
> > - ret = pdc_alloc_desc(&pd_chan->chan, GFP_NOIO);
> > + ret = pdc_alloc_desc(&pd_chan->chan, GFP_ATOMIC);
> > if (ret) {
> > spin_lock(&pd_chan->lock);
> > pd_chan->descs_allocated++;
> > --
> > 1.7.4.4
>
> --
> ROHM Co., Ltd.
> tomoya
--
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/8] f2fs: add tracepoints for inode operations
2013/2/19 Steven Rostedt :
> On Tue, 2013-02-19 at 11:33 +0900, Namjae Jeon wrote:
>> From: Namjae Jeon
>
>> +TRACE_EVENT(f2fs_unlink_exit,
>> + TP_PROTO(struct dentry *dentry, int ret),
>> +
>> + TP_ARGS(dentry, ret),
>> +
>> + TP_STRUCT__entry(
>> + __field(ino_t, ino)
>> + __field(dev_t, dev)
>> + __field(int,ret)
>> + ),
>> +
>> + TP_fast_assign(
>> + __entry->ino= dentry->d_inode->i_ino;
>> + __entry->dev= dentry->d_inode->i_sb->s_dev;
>> + __entry->ret= ret;
>> + ),
>> +
>> + TP_printk("dev %d,%d ino %lu ret %d",
>> + MAJOR(__entry->dev), MINOR(__entry->dev),
>> + (unsigned long) __entry->ino,
>> + __entry->ret)
>> +);
>> +
>> #endif /* _TRACE_F2FS_H */
>>
>> /* This part must be outside protection */
>
> If at all possible, try to combine as many tracepoints as possible by a
> class. A TRACE_EVENT() is really a DECLARE_EVENT_CLASS();
> DEFINE_EVENT(); pair that totals about 5k per TRACE_EVENT(). The
> DECLARE_EVENT_CLASS() being the majority of that. A DEFINE_EVENT() adds
> approximately 250 bytes each. Thus, combining the above with the
> TRACE_EVENT() from the previous patch:
>
> +TRACE_EVENT(f2fs_sync_file_exit,
> + TP_PROTO(struct inode *inode, int ret),
> +
> + TP_ARGS(inode, ret),
> +
> + TP_STRUCT__entry(
> + __field(int,ret)
> + __field(ino_t, ino)
> + __field(dev_t, dev)
> + ),
> +
> + TP_fast_assign(
> + __entry->ret= ret;
> + __entry->ino= inode->i_ino;
> + __entry->dev= inode->i_sb->s_dev;
> + ),
> +
> + TP_printk("dev %d,%d ino %lu ret %d",
> + MAJOR(__entry->dev), MINOR(__entry->dev),
> + (unsigned long) __entry->ino,
> + __entry->ret)
> +);
>
> into:
>
> DECLARE_EVENT_CLASS(f2fs_dev_inode_ret,
>TP_PROTO(struct inode *inode, int ret),
>
>TP_ARGS(inode, ret),
>
>TP_STRUCT__entry(
>__field(int,ret)
>__field(ino_t, ino)
>__field(dev_t, dev)
>),
>
>TP_fast_assign(
>__entry->ret= ret;
>__entry->ino= inode->i_ino;
>__entry->dev= inode->i_sb->s_dev;
>),
>
>TP_printk("dev %d,%d ino %lu ret %d",
> MAJOR(__entry->dev), MINOR(__entry->dev),
> (unsigned long) __entry->ino,
> __entry->ret)
> );
>
> DEFINE_EVENT(f2fs_sync_file_exit,
>TP_PROTO(struct inode *inode, int ret),
>TP_ARGS(inode, ret));
>
> DEFINE_EVENT(f2fs_unlink_exit,
>TP_PROTO(struct inode *inode, int ret),
>TP_ARGS(inode, ret));
>
> You can save ~4750 bytes. Note, you will need to pass the inode instead
> of the dentry into f2fs_unlink_exit(), but you don't use the dentry
> anyway.
Hi Steven.
Thanks for review :). I will update patches as your advice.
> -- Steve
>
>
--
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: Fwd: mmc card probe not getting called
Hi Anish, Thanks for your reply, I was doing device registration for device by giving same name as driver name, This i used to do in platform driver registration, But i dont know how to do for mmc device registration, And i also want to know which part of the code(file name) is doing the string compare with the driver and device names and calling the probe function. can u please point me to that part of code. from many days i was searching from which part of code where string compare is done and calls the probe function. Kindly point me out to that part of code. On Tue, Feb 19, 2013 at 9:25 PM, anish kumar wrote: > On Tue, 2013-02-19 at 12:16 +0530, chetan cr123 wrote: >> HI All, >> >> I am working on Sd Card/Block driver >> >> I am registering it as both >> >> 1. register_blkdev()- BLOCK Regsiter >> 2. mmc_register_driver -- MMC regsiter >> >> and filling the mmc_driver structure. >> >> I am not able to see the probe of MMC, But i see the return value of >> mmc_register function returning success. > I am not an expert on MMC driver but AFAIK it is no different in terms > of following device/driver model. > Probe of a function is only called when device name matches with driver > name and when it happens driver calls your probe. > > So in your case even though you have registered the driver, looks like > you are missing the device registration part.Do that and see the magic. > If this is SOC then that is done in the board file i.e. > arch/arm/plat-xyz/ > >> >> Kindly let me know how i make the probe of mmc getting called >> >> Thanks >> >> >> Chetan >> -- >> 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/
Re: [patch v5 10/15] sched: packing transitory tasks in wake/exec power balancing
On 02/18/2013 04:56 PM, Alex Shi wrote:
> On 02/18/2013 04:44 PM, Joonsoo Kim wrote:
>> Hello, Alex.
>>
>> On Mon, Feb 18, 2013 at 01:07:37PM +0800, Alex Shi wrote:
>>> If the waked/execed task is transitory enough, it will has a chance to be
>>> packed into a cpu which is busy but still has time to care it.
>>> For powersaving policy, only the history util < 25% task has chance to
>>> be packed, and for balance policy, only histroy util < 12.5% has chance.
>>> If there is no cpu eligible to handle it, will use a idlest cpu in
>>> leader group.
>>
>> After exec(), task's behavior may be changed, and history util may be
>> changed, too. So, IMHO, exec balancing by history util is not good idea.
>> How do you think about it?
>>
>
> sounds make sense. are there any objections?
>
New patch without exec balance packing:
==
>From 7ed6c68dbd34e40b70c1b4f2563a5af172e289c3 Mon Sep 17 00:00:00 2001
From: Alex Shi
Date: Thu, 14 Feb 2013 22:46:02 +0800
Subject: [PATCH 09/14] sched: packing transitory tasks in wakeup power
balancing
If the waked task is transitory enough, it will has a chance to be
packed into a cpu which is busy but still has time to care it.
For powersaving policy, only the history util < 25% task has chance to
be packed, and for balance policy, only histroy util < 12.5% has chance.
If there is no cpu eligible to handle it, will use a idlest cpu in
leader group.
Morten Rasmussen catch a type bug and suggest using different criteria
for different policy, thanks!
Joonsoo Kim suggests not packing exec task, since the old task utils is
possibly unuseable.
Inspired-by: Vincent Guittot
Signed-off-by: Alex Shi
---
kernel/sched/fair.c | 66 -
1 file changed, 60 insertions(+), 6 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index c2a65f9..24a68af 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -3452,19 +3452,72 @@ static inline int get_sd_sched_balance_policy(struct
sched_domain *sd,
}
/*
+ * find_leader_cpu - find the busiest but still has enough leisure time cpu
+ * among the cpus in group.
+ */
+static int
+find_leader_cpu(struct sched_group *group, struct task_struct *p, int this_cpu,
+ int policy)
+{
+ /* percentage of the task's util */
+ unsigned putil = p->se.avg.runnable_avg_sum * 100
+ / (p->se.avg.runnable_avg_period + 1);
+
+ struct rq *rq = cpu_rq(this_cpu);
+ int nr_running = rq->nr_running > 0 ? rq->nr_running : 1;
+ int vacancy, min_vacancy = INT_MAX, max_util;
+ int leader_cpu = -1;
+ int i;
+
+ if (policy == SCHED_POLICY_POWERSAVING)
+ max_util = FULL_UTIL;
+ else
+ /* maximum allowable util is 60% */
+ max_util = 60;
+
+ /* bias toward local cpu */
+ if (cpumask_test_cpu(this_cpu, tsk_cpus_allowed(p)) &&
+ max_util - (rq->util * nr_running + (putil << 2)) > 0)
+ return this_cpu;
+
+ /* Traverse only the allowed CPUs */
+ for_each_cpu_and(i, sched_group_cpus(group), tsk_cpus_allowed(p)) {
+ if (i == this_cpu)
+ continue;
+
+ rq = cpu_rq(i);
+ nr_running = rq->nr_running > 0 ? rq->nr_running : 1;
+
+ /* only light task allowed, like putil < 25% for powersaving */
+ vacancy = max_util - (rq->util * nr_running + (putil << 2));
+
+ if (vacancy > 0 && vacancy < min_vacancy) {
+ min_vacancy = vacancy;
+ leader_cpu = i;
+ }
+ }
+ return leader_cpu;
+}
+
+/*
* If power policy is eligible for this domain, and it has task allowed cpu.
* we will select CPU from this domain.
*/
static int get_cpu_for_power_policy(struct sched_domain *sd, int cpu,
- struct task_struct *p, struct sd_lb_stats *sds)
+ struct task_struct *p, struct sd_lb_stats *sds, int wakeup)
{
int policy;
int new_cpu = -1;
policy = get_sd_sched_balance_policy(sd, cpu, p, sds);
- if (policy != SCHED_POLICY_PERFORMANCE && sds->group_leader)
- new_cpu = find_idlest_cpu(sds->group_leader, p, cpu);
-
+ if (policy != SCHED_POLICY_PERFORMANCE && sds->group_leader) {
+ if (wakeup)
+ new_cpu = find_leader_cpu(sds->group_leader,
+ p, cpu, policy);
+ /* for fork balancing and a little busy task */
+ if (new_cpu == -1)
+ new_cpu = find_idlest_cpu(sds->group_leader, p, cpu);
+ }
return new_cpu;
}
@@ -3515,14 +3568,15 @@ select_task_rq_fair(struct task_struct *p, int sd_flag,
int flags)
if (tmp->flags & sd_flag) {
sd = tmp;
- new_cpu = get_cpu_for_power_policy(s
linux-next: build failure after merge of the modem_shm tree
Hi Sjur,
After merging the modem_shm tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/remoteproc/remoteproc_virtio.c: In function 'rproc_virtio_new_vringh':
drivers/remoteproc/remoteproc_virtio.c:234:16: error: 'struct rproc_vdev' has
no member named 'dfeatures'
Caused by commit 624f8ef43b6c ("remoteproc: Support virtio config space")
from the modem_shm tree interacting with commit 414a13c3d236
("remoteproc: Add support for vringh (Host vrings)") from the virtio tree.
I applied the following merge fix patch and can carry it as necessary:
From 66e8d9a9dc648db6abc27b7e9b6d99840b25642f Mon Sep 17 00:00:00 2001
From: Stephen Rothwell
Date: Wed, 20 Feb 2013 16:47:58 +1100
Subject: [PATCH] remoteproc: fix for dfeatures change
Signed-off-by: Stephen Rothwell
---
drivers/remoteproc/remoteproc_virtio.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/remoteproc/remoteproc_virtio.c
b/drivers/remoteproc/remoteproc_virtio.c
index 33ca91f..dba33ff 100644
--- a/drivers/remoteproc/remoteproc_virtio.c
+++ b/drivers/remoteproc/remoteproc_virtio.c
@@ -231,7 +231,7 @@ rproc_virtio_new_vringh(struct virtio_device *vdev,
unsigned index,
rvring->vringh = vrh;
err = vringh_init_kern(vrh,
- rvdev->dfeatures,
+ rvdev->rsc->dfeatures,
rvring->len,
false,
vrh->vring.desc,
--
1.8.1
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgprdy6TrDJgH.pgp
Description: PGP signature
Re[8]: [PATCH v3] mfd: syscon: Add non-DT support
> > ...
> >> >> >> >> struct regmap *syscon_regmap_lookup_by_compatible(const char *s)
> >> >> >> >> {
> >> >> >> >> struct device_node *syscon_np;
> >> >> >> >> struct regmap *regmap;
> >> >> >> >> + struct syscon *syscon;
> >> >> >> >> + struct device *dev;
> >> >> >> >>
> >> >> >> >> syscon_np = of_find_compatible_node(NULL, NULL, s);
> >> >> >> >> - if (!syscon_np)
> >> >> >> >> + if (syscon_np) {
> >> >> >> >> + regmap = syscon_node_to_regmap(syscon_np);
> >> >> >> >> + of_node_put(syscon_np);
> >> >> >> >> +
> >> >> >> >> + return regmap;
> >> >> >> >> + }
> >> >> >> >> +
> >> >> >> >> + /* Fallback to search by id_entry.name string */
> >> >> >> >> + dev = driver_find_device(&syscon_driver.driver, NULL, (void
> >> >> >> >> *)s,
> >> >> >> >> + syscon_match_id);
> >> >> >> >> + if (!dev)
> >> >> >> >> return ERR_PTR(-ENODEV);
> >> >> >> >>
> >> >> >> >> - regmap = syscon_node_to_regmap(syscon_np);
> >> >> >> >> - of_node_put(syscon_np);
> >> >> >> >> + syscon = dev_get_drvdata(dev);
> >> >> >> >>
> >> >> >> >> - return regmap;
> >> >> >> >> + return syscon->regmap;
> >> >> >> >> }
> >> >> >> >> EXPORT_SYMBOL_GPL(syscon_regmap_lookup_by_compatible);
> >> >> >> >
> >> >> >> > Since you are not actually comparing the "compatible" property
> >> >> >> > here,
> >> >> >> > I would suggest adding another function here,
> >> >> >>
> >> >> >> Yes, i also think like that.
> >> >> >
> >> >> > In this case we should provide two paths for drivers which can work
> >> >> > as with DT
> >> >> > and without DT.
> >> >>
> >> >> Yes.
> >> >
> >> > I still think the universal procedure is better for the driver.
> >> >
> >>
> >> Why?
> >> I did not see your reply on my other comments on the problems of using
> >> universal
> >> procedure?
> >> Please let me know if you think they're not issues.
> >
> > Yes, I do not see a problem here.
> > I will try to show the code.
> >
> > In the driver:
> > struct regmap *r;
> > r = syscon_regmap_lookup_by_compatible("my_super_syscon");
> >
> > For DT case:
> > syscon@123456 {
> > compatible = "my_super_syscon", "syscon";
> > ...
> > };
> >
> > For non-DT case:
> > struct platform_device_id id = { .name = "my_super_syscon", };
> > struct platform_device syscon_pdev = {
> > .name = "syscon",
> > .id_entry = &id,
>
> This is really strange to me and i've never seen such using.
> Usually the id_table is provided by the driver and the match process then will
> set the correct id_entry for the platform device once it matches.
> Please see the platform_bus match process: drivers/base/platform.c
Yes, this is non-standard usage. Currently we do not have platform_device_id
entries for a "syscon" driver, so this field is untouched for a platform device
and we can use it. At least this works, but, of course, more experts should
fix me on this question if I think incorrect.
>
> > ...
> > };
> > platform_device_register(&syscon_pdev);
> >
> > Do I understand what you mean?
> >
>
> My understanding for non-dt case is something like:
> In client driver:
> struct regmap *r;
> r = syscon_regmap_lookup_by_pdevname("my_super_syscon");
>
> In board code:
> struct platform_device syscon_pdev = {
> .name = "my_super_syscon",
> ...
> };
> platform_device_register(&syscon_pdev);
>
> In syscon driver:
> static struct platform_device_id syscon_device_ids[] = {
> {
> .name = "my_super_syscon",
> }, {
> /* sentinel */
> }
> };
> MODULE_DEVICE_TABLE(platform, syscon_device_ids);
>
> static struct platform_driver syscon_driver = {
> .driver = {
> .name = "syscon",
> .owner = THIS_MODULE,
> .of_match_table = of_syscon_match,
> },
> .id_table = syscon_device_ids,
> .probe = syscon_probe,
> .remove = syscon_remove,
> };
>
> 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?
---
Re: [PATCH] mm: cma: fix accounting of CMA pages placed in high memory
On 02/20/2013 10:57 AM, Kyungmin Park wrote: On Tue, Feb 19, 2013 at 10:27 PM, Simon Jeons wrote: On 02/05/2013 03:10 PM, Marek Szyprowski wrote: Hello, On 2/5/2013 12:34 AM, Minchan Kim wrote: On Mon, Feb 04, 2013 at 11:27:05AM +0100, Marek Szyprowski wrote: The total number of low memory pages is determined as totalram_pages - totalhigh_pages, so without this patch all CMA pageblocks placed in highmem were accounted to low memory. So what's the end user effect? With the effect, we have to decide routing it on stable. Signed-off-by: Marek Szyprowski --- mm/page_alloc.c |4 1 file changed, 4 insertions(+) diff --git a/mm/page_alloc.c b/mm/page_alloc.c index f5bab0a..6415d93 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -773,6 +773,10 @@ void __init init_cma_reserved_pageblock(struct page *page) set_pageblock_migratetype(page, MIGRATE_CMA); __free_pages(page, pageblock_order); totalram_pages += pageblock_nr_pages; +#ifdef CONFIG_HIGHMEM We don't need #ifdef/#endif. #ifdef is required to let this code compile when highmem is not enabled, becuase totalhigh_pages is defined as 0, see include/linux/highmem.h Hi Marek, 1) Why can support CMA regions placed in highmem? Some vendors use reserved memory at highmem, and it's hard to modify to use lowmem, so just CMA can support highmem and no need to adjust address used at reserved memory. CMA is for dma buffer, correct? Then how can old dma device access highmem? What's the "old dma device"? To support it, we also modify I mean dma devices which should still use bounce buffer, then these devices will use bounce buffer to access CMA region in highmem or ...? arch/arm/mm/dma-mapping.c for handling highmem address. 2) Why there is no totalhigh_pages variable define in the case of config highmem? I don't know. it's just defined in case of highmem. that's reason to use #ifdef/endif. we don't know hisotrical reason. Thank you, Kyungmin Park +if (PageHighMem(page)) +totalhigh_pages += pageblock_nr_pages; +#endif } #endif Best regards -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majord...@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: mailto:"d...@kvack.org";> em...@kvack.org -- 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[6]: [PATCH v3] mfd: syscon: Add non-DT support
On 19 February 2013 18:54, Alexander Shiyan wrote:
> ...
>> >> >> >> struct regmap *syscon_regmap_lookup_by_compatible(const char *s)
>> >> >> >> {
>> >> >> >> struct device_node *syscon_np;
>> >> >> >> struct regmap *regmap;
>> >> >> >> + struct syscon *syscon;
>> >> >> >> + struct device *dev;
>> >> >> >>
>> >> >> >> syscon_np = of_find_compatible_node(NULL, NULL, s);
>> >> >> >> - if (!syscon_np)
>> >> >> >> + if (syscon_np) {
>> >> >> >> + regmap = syscon_node_to_regmap(syscon_np);
>> >> >> >> + of_node_put(syscon_np);
>> >> >> >> +
>> >> >> >> + return regmap;
>> >> >> >> + }
>> >> >> >> +
>> >> >> >> + /* Fallback to search by id_entry.name string */
>> >> >> >> + dev = driver_find_device(&syscon_driver.driver, NULL, (void
>> >> >> >> *)s,
>> >> >> >> + syscon_match_id);
>> >> >> >> + if (!dev)
>> >> >> >> return ERR_PTR(-ENODEV);
>> >> >> >>
>> >> >> >> - regmap = syscon_node_to_regmap(syscon_np);
>> >> >> >> - of_node_put(syscon_np);
>> >> >> >> + syscon = dev_get_drvdata(dev);
>> >> >> >>
>> >> >> >> - return regmap;
>> >> >> >> + return syscon->regmap;
>> >> >> >> }
>> >> >> >> EXPORT_SYMBOL_GPL(syscon_regmap_lookup_by_compatible);
>> >> >> >
>> >> >> > Since you are not actually comparing the "compatible" property here,
>> >> >> > I would suggest adding another function here,
>> >> >>
>> >> >> Yes, i also think like that.
>> >> >
>> >> > In this case we should provide two paths for drivers which can work as
>> >> > with DT
>> >> > and without DT.
>> >>
>> >> Yes.
>> >
>> > I still think the universal procedure is better for the driver.
>> >
>>
>> Why?
>> I did not see your reply on my other comments on the problems of using
>> universal
>> procedure?
>> Please let me know if you think they're not issues.
>
> Yes, I do not see a problem here.
> I will try to show the code.
>
> In the driver:
> struct regmap *r;
> r = syscon_regmap_lookup_by_compatible("my_super_syscon");
>
> For DT case:
> syscon@123456 {
> compatible = "my_super_syscon", "syscon";
> ...
> };
>
> For non-DT case:
> struct platform_device_id id = { .name = "my_super_syscon", };
> struct platform_device syscon_pdev = {
> .name = "syscon",
> .id_entry = &id,
This is really strange to me and i've never seen such using.
Usually the id_table is provided by the driver and the match process then will
set the correct id_entry for the platform device once it matches.
Please see the platform_bus match process: drivers/base/platform.c
> ...
> };
> platform_device_register(&syscon_pdev);
>
> Do I understand what you mean?
>
My understanding for non-dt case is something like:
In client driver:
struct regmap *r;
r = syscon_regmap_lookup_by_pdevname("my_super_syscon");
In board code:
struct platform_device syscon_pdev = {
.name = "my_super_syscon",
...
};
platform_device_register(&syscon_pdev);
In syscon driver:
static struct platform_device_id syscon_device_ids[] = {
{
.name = "my_super_syscon",
}, {
/* sentinel */
}
};
MODULE_DEVICE_TABLE(platform, syscon_device_ids);
static struct platform_driver syscon_driver = {
.driver = {
.name = "syscon",
.owner = THIS_MODULE,
.of_match_table = of_syscon_match,
},
.id_table = syscon_device_ids,
.probe = syscon_probe,
.remove = syscon_remove,
};
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.
Arnd,
Do you think this is an issue?
Regards
Dong Aisheng
--
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] add extra free kbytes tunable
> > The problem is that adding this tunable will constrain future VM > implementations. We will forever need to at least retain the > pseudo-file. We will also need to make some effort to retain its > behaviour. > > It would of course be better to fix things so you don't need to tweak > VM internals to get acceptable behaviour. I sympathize with this. It's presently all that keeps us afloat though. I'll whine about it again later if nothing else pans out. > You said: > > : We have a server workload wherein machines with 100G+ of "free" memory > : (used by page cache), scattered but frequent random io reads from 12+ > : SSD's, and 5gbps+ of internet traffic, will frequently hit direct reclaim > : in a few different ways. > : > : 1) It'll run into small amounts of reclaim randomly (a few hundred > : thousand). > : > : 2) A burst of reads or traffic can cause extra pressure, which kswapd > : occasionally responds to by freeing up 40g+ of the pagecache all at once > : (!) while pausing the system (Argh). > : > : 3) A blip in an upstream provider or failover from a peer causes the > : kernel to allocate massive amounts of memory for retransmission > : queues/etc, potentially along with buffered IO reads and (some, but not > : often a ton) of new allocations from an application. This paired with 2) > : can cause the box to stall for 15+ seconds. > > Can we prioritise these? 2) looks just awful - kswapd shouldn't just > go off and free 40G of pagecache. Do you know what's actually in that > pagecache? Large number of small files or small number of (very) large > files? We have a handful of huge files (6-12ish 200g+) that are mmap'ed and accessed via address. occasionally madvise (WILLNEED) applied to the address ranges before attempting to use them. There're a mix of other files but nothing significant. The mmap's are READONLY and writes are done via pwrite-ish functions. I could use some guidance on inspecting/tracing the problem. I've been trying to reproduce it in a lab, and respecting to 2)'s issue I've found: - The amount of memory freed back up is either a percentage of total memory or a percentage of free memory. (a machine with 48G of ram will "only" free up an extra 4-7g) - It's most likely to happen after a fresh boot, or if "3 > drop_caches" is applied with the application down. As it fills it seems to get itself into trouble, but becomes more stable after that. Unfortunately 1) and 3) still apply to a stable instance. - Protecting the DMA32 zone with something like "1 1 32" into lowmem_reserve_ratio makes the mass-reclaiming less likely to happen. - While watching "sar -B 1" I'll see kswapd wake up, and scan up to a few hundred thousand pages before finding anything it actually wants to reclaim (low vmeff). I've only been able to reproduce this from a clean start. It can take up to 3 seconds before kswapd starts actually reclaiming pages. - So far as I can tell we're almost exclusively using 0 order allocations. THP is disabled. There's not much dirty memory involved. It's not flushing out writes while reclaiming, it just kills off massive amount of cached memory. We're not running the machines particularily hard... Often less than 30% CPU usage at peak. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch v4 07/18] sched: set initial load avg of new forked task
> This is my concern about making this a special case with the
> introduction ENQUEUE_NEWTASK flag; enqueue jumps through enough hoops
> as it is.
>
> I still don't see why we can't resolve this at init time in
> __sched_fork(); your patch above just moves an explicit initialization
> of load_avg_contrib into the enqueue path. Adding a call to
> __update_task_entity_contrib() to the previous alternate suggestion
> would similarly seem to resolve this?
>
Without ENQUEUE_NEWTASK flag, we can use the following patch. That embeds
the new fork with a implicate way.
but since the newtask flag just follows existing enqueue path, it also
looks natural and is a explicit way.
I am ok for alternate of solutions.
===
>From 0f5dd6babe899e27cfb78ea49d337e4f0918591b Mon Sep 17 00:00:00 2001
From: Alex Shi
Date: Wed, 20 Feb 2013 12:51:28 +0800
Subject: [PATCH 02/15] sched: set initial load avg of new forked task
New task has no runnable sum at its first runnable time, so its
runnable load is zero. That makes burst forking balancing just select
few idle cpus to assign tasks if we engage runnable load in balancing.
Set initial load avg of new forked task as its load weight to resolve
this issue.
Signed-off-by: Alex Shi
---
kernel/sched/core.c | 2 ++
kernel/sched/fair.c | 4
2 files changed, 6 insertions(+)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 1743746..93a7590 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -1648,6 +1648,8 @@ void sched_fork(struct task_struct *p)
p->sched_reset_on_fork = 0;
}
+ p->se.avg.load_avg_contrib = p->se.load.weight;
+
if (!rt_prio(p->prio))
p->sched_class = &fair_sched_class;
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 81fa536..cae5134 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -1509,6 +1509,10 @@ static inline void enqueue_entity_load_avg(struct cfs_rq
*cfs_rq,
* We track migrations using entity decay_count <= 0, on a wake-up
* migration we use a negative decay count to track the remote decays
* accumulated while sleeping.
+*
+* When enqueue a new forked task, the se->avg.decay_count == 0, so
+* we bypass update_entity_load_avg(), use avg.load_avg_contrib initial
+* value: se->load.weight.
*/
if (unlikely(se->avg.decay_count <= 0)) {
se->avg.last_runnable_update = rq_of(cfs_rq)->clock_task;
--
1.7.12
--
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: ARC Port's linux-next URL update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Stephen, On Wednesday 20 February 2013 04:51 AM, Stephen Rothwell wrote: > Hi Vineet, > > On Tue, 19 Feb 2013 23:41:02 +0530 Vineet Gupta > wrote: >> >> Can you please point ARC's next tree to following: >> >> git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc.git for-next > > Done. Thanks !. > >> This is an exact copy of what I had in github (based off 3.8-rc5) > > Not just a copy, but you did the right thing and it is the same commits. > Thanks. Yeah, that was the idea so that a worst case github branch's (signed tag )pull request matched what I had here. > >> I suppose a week's worth of cooking should be enough to send a pull request >> to Linus. > > Well, you have not rebased it so just moving sites should not affect > you. However, even what is there has only been in -next for 2 days, so > maybe a couple of days wait wouldn't hurt. Cool ! Thx, - -Vineet -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQIcBAEBAgAGBQJRJFjVAAoJEGnX8d3iisJeBp8P/048F3PjD1EsX6jrhLbsCwvP ng9xjd1WN0CrKFziVg7yIedo1DNUg5+Hb6rkkFLy+3YiKp8RJu0tN7bi9QbOxCM6 sMky3HmGRPrfAkNcQZJOKEI+wm4DEikwPSy1C437fR8STBjmdV1Z1YAlni8Nf4XK ZQiPCFh2ytOZQXD9jqU7rKyADDvcQGtcznv9PqcX66WuNgvlIyrOsLK/TrjY9f5G p/pLM2f4/WyANYrkMRqDeEPF+44jbMYLeQsNs9VfccfWxAFSh4ObfZINqCHPcubU XB3yv1+T61yewIw9q2NHh3UK5yhwuAvwdZHJdYNqRvK1YhRib54UUOXaJEBLISzv Sqv3lQ1wTTRku93pI6ut6rj24RcwEMza3SMY9lhekXEpGVEgqcgdbJoX2GUlBWlE rQDEeYoaVwEJ0xFjOiAw62JAaIdkWD1ko/rljWjQK3R7NHTYsNxvOcsyRYs5bjk8 hQaaaK/zPcTWW3HjSYJa43kL5dC2q3GFDA+SB7up6hkTNzOXXjdi/sYkzvOvxh85 Ln/RXhFPc3jLzNwbDH++uilNvBHTE98aI5wcHDXQ/PNxT7ZnbZHfMowmLcbm8kAP mP00s2NA245ayJ5UsqeFvb+YjoB9qtIiPJNAKwPLX21jeAgjMz1Wi1HDbJ0jBkID 8CIpvoeoDA3/eEYlZVek =cfos -END PGP SIGNATURE- -- 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: [BONUS PATCH 2/2] base: core: WARN() about bogus permissions on device attributes
On Tue, Feb 19, 2013 at 11:59:10AM +0200, Felipe Balbi wrote: > Hi, > > On Mon, Feb 18, 2013 at 09:20:10PM +0200, Felipe Balbi wrote: > > On Mon, Feb 18, 2013 at 11:17:19AM -0800, Greg KH wrote: > > > On Mon, Feb 18, 2013 at 09:09:04PM +0200, Felipe Balbi wrote: > > > > 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 > > > > --- > > > > > > > > This is completely untested. I have only compile tested > > > > to make sure I'm not breaking anything. > > > > > > > > Greg, do you think this would be nice to have ? I could > > > > fire up kvm tomorrow and run on a few of my OMAP-based > > > > boards to make sure it works as expected. > > > > > > Looks good, but you better fix up all of the big offenders that this > > > points out, before I apply it, otherwise we will get a ton of bug > > > reports :) > > > > sure, will do that tomorrow though ;-) > > Just tested $SUBJECT and it didn't trigger any extra warnings. Only the > one whose fix you already applied (I reverted it to make sure $SUBJECT > was working as expected). Ok, care to resend so that I can queue it up after 3.9-rc1 is out, for inclusion in 3.10, and we can have lots of time to see what falls out? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the vhost tree with the virtio tree
Hi Michael,
Today's linux-next merge of the vhost tree got a conflict in
drivers/vhost/Makefile between commit 4d8dc8b44748 ("vringh: host-side
implementation of virtio rings") from the virtio tree and commit
0b87bfefde9a ("vhost-blk: Add vhost-blk support v6") from the vhost tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/vhost/Makefile
index 1d37f5e,1a8a4a5..000
--- a/drivers/vhost/Makefile
+++ b/drivers/vhost/Makefile
@@@ -2,5 -2,5 +2,7 @@@ obj-$(CONFIG_VHOST_NET) += vhost_net.
vhost_net-y := vhost.o net.o
obj-$(CONFIG_TCM_VHOST) += tcm_vhost.o
+
+obj-$(CONFIG_VHOST_RING) += vringh.o
+ obj-$(CONFIG_VHOST_BLK) += vhost_blk.o
+ vhost_blk-y := blk.o
pgpZTV6iLd2BA.pgp
Description: PGP signature
Re: [PATCH v2] vt: add init_hide parameter to suppress boot output
On Tue, Feb 19, 2013 at 08:04:05PM -0800, Andy Ross wrote: > On 02/19/2013 05:45 PM, Greg Kroah-Hartman wrote: > >>When vt.init_hide is set, suppress output on newly created consoles > >>until an affirmative switched to that console. This prevents boot > >>output from displaying (and clobbering splash screens, etc...) > >>without disabling the console entirely. > > > >What's wrong with the 'quiet' option we have? And you forgot to > >document this. > > You're right about docs, obviously. I'll write something up and send > it tomorrow morning. > > But setting "quiet" controls logging. It won't prevent the console > from doing a buffer clear or mode switch, nor will it prevent > userspace from writing to it, nor will the buffer rewrites due to the > console switches that happen on suspend and resume (which I didn't > know existed) be suppressed. > > There's a (sort of) similar commonly-used option, vga=current, which > prevents a mode switch for the special case of VGA/vesa. But that > doesn't work with the framebuffer console. Why not? Can't you fix that? > The idea here (and I'm clearly no domain expert) was to leave the > console enabled and active, but invisible by default. So nothing > displays, the splash screen stays put, and nothing fights with other > users of the framebuffer. And it stays that way until something > affirmatively switches to a different VT using chvt or Alt-Fn or > whatever. > > To be fair, a lot of this could be managed in userspace with the VT_* > ioctl interface. Yes, that's what "normal" systems do :) > But the specific application here (Android's surfaceflinger) isn't set > up for that, and it's a non-trivial API (and even doing it "right" > involves racing against other users at startup). How could there be any other users at startup, you "own" the system here, there should not be anyone to race with. > This seemed like a much simpler metaphor that still meets the > requirements. I think you should use the ioctls, that is what they are there for, and is what you need to implement if you want to use a console anyway, right? greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] backlight: lp855x_bl: support new LP8557 device
LP8557 is one of LP855x family device, but it has different register map
and initialization process.
To support this device, device specific configuration is done through the
lp855x_device_config structure.
Few register definitions are fixed for better readability.
BRIGHTNESS_CTRL -> LP855X_BRIGHTNESS_CTRL
DEVICE_CTRL -> LP855X_DEVICE_CTRL
EEPROM_START-> LP855X_EEPROM_START
EEPROM_END -> LP855X_EEPROM_END
EPROM_START -> LP8556_EPROM_START
EPROM_END -> LP8556_EPROM_END
And LP8557 register definitions are added.
New register function, lp855x_update_bit() is added.
Signed-off-by: Milo(Woogyom) Kim
---
Documentation/backlight/lp855x-driver.txt |4 +-
drivers/video/backlight/Kconfig |2 +-
drivers/video/backlight/lp855x_bl.c | 87 -
include/linux/platform_data/lp855x.h | 19 +++
4 files changed, 94 insertions(+), 18 deletions(-)
diff --git a/Documentation/backlight/lp855x-driver.txt
b/Documentation/backlight/lp855x-driver.txt
index 1529394..18b06ca 100644
--- a/Documentation/backlight/lp855x-driver.txt
+++ b/Documentation/backlight/lp855x-driver.txt
@@ -4,7 +4,7 @@ Kernel driver lp855x
Backlight driver for LP855x ICs
Supported chips:
- Texas Instruments LP8550, LP8551, LP8552, LP8553 and LP8556
+ Texas Instruments LP8550, LP8551, LP8552, LP8553, LP8556 and LP8557
Author: Milo(Woogyom) Kim
@@ -24,7 +24,7 @@ Value : pwm based or register based
2) chip_id
The lp855x chip id.
-Value : lp8550/lp8551/lp8552/lp8553/lp8556
+Value : lp8550/lp8551/lp8552/lp8553/lp8556/lp8557
Platform data for lp855x
diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
index 765a945..f24bc79 100644
--- a/drivers/video/backlight/Kconfig
+++ b/drivers/video/backlight/Kconfig
@@ -366,7 +366,7 @@ config BACKLIGHT_LP855X
tristate "Backlight driver for TI LP855X"
depends on BACKLIGHT_CLASS_DEVICE && I2C
help
- This supports TI LP8550, LP8551, LP8552, LP8553 and LP8556
+ This supports TI LP8550, LP8551, LP8552, LP8553, LP8556 and LP8557
backlight driver.
config BACKLIGHT_OT200
diff --git a/drivers/video/backlight/lp855x_bl.c
b/drivers/video/backlight/lp855x_bl.c
index 050cfbb..edd2041 100644
--- a/drivers/video/backlight/lp855x_bl.c
+++ b/drivers/video/backlight/lp855x_bl.c
@@ -17,13 +17,23 @@
#include
#include
-/* Registers */
-#define BRIGHTNESS_CTRL0x00
-#define DEVICE_CTRL0x01
-#define EEPROM_START 0xA0
-#define EEPROM_END 0xA7
-#define EPROM_START0xA0
-#define EPROM_END 0xAF
+/* LP8550/1/2/3/6 Registers */
+#define LP855X_BRIGHTNESS_CTRL 0x00
+#define LP855X_DEVICE_CTRL 0x01
+#define LP855X_EEPROM_START0xA0
+#define LP855X_EEPROM_END 0xA7
+#define LP8556_EPROM_START 0xA0
+#define LP8556_EPROM_END 0xAF
+
+/* LP8557 Registers */
+#define LP8557_BL_CMD 0x00
+#define LP8557_BL_MASK 0x01
+#define LP8557_BL_ON 0x01
+#define LP8557_BL_OFF 0x00
+#define LP8557_BRIGHTNESS_CTRL 0x04
+#define LP8557_CONFIG 0x10
+#define LP8557_EPROM_START 0x10
+#define LP8557_EPROM_END 0x1E
#define BUF_SIZE 20
#define DEFAULT_BL_NAME"lcd-backlight"
@@ -75,6 +85,24 @@ static int lp855x_write_byte(struct lp855x *lp, u8 reg, u8
data)
return i2c_smbus_write_byte_data(lp->client, reg, data);
}
+static int lp855x_update_bit(struct lp855x *lp, u8 reg, u8 mask, u8 data)
+{
+ int ret;
+ u8 tmp;
+
+ ret = i2c_smbus_read_byte_data(lp->client, reg);
+ if (ret < 0) {
+ dev_err(lp->dev, "failed to read 0x%.2x\n", reg);
+ return ret;
+ }
+
+ tmp = (u8)ret;
+ tmp &= ~mask;
+ tmp |= data & mask;
+
+ return lp855x_write_byte(lp, reg, tmp);
+}
+
static bool lp855x_is_valid_rom_area(struct lp855x *lp, u8 addr)
{
u8 start, end;
@@ -84,12 +112,16 @@ static bool lp855x_is_valid_rom_area(struct lp855x *lp, u8
addr)
case LP8551:
case LP8552:
case LP8553:
- start = EEPROM_START;
- end = EEPROM_END;
+ start = LP855X_EEPROM_START;
+ end = LP855X_EEPROM_END;
break;
case LP8556:
- start = EPROM_START;
- end = EPROM_END;
+ start = LP8556_EPROM_START;
+ end = LP8556_EPROM_END;
+ break;
+ case LP8557:
+ start = LP8557_EPROM_START;
+ end = LP8557_EPROM_END;
break;
default:
return false;
@@ -98,9 +130,30 @@ static bool lp855x_is_valid_rom_area(struct lp855x *lp, u8
addr)
return (addr >= start && addr <= end);
[PATCH 3/3] backlight: lp855x_bl: simplify bl_get_brightness()
Getting the brightness value is not critical, no need to read the actual
register value. To simplify it, just return the 'bl->props.brightness' value.
Then, lp855x_read_byte() can be removed, not used any more.
Signed-off-by: Milo(Woogyom) Kim
---
drivers/video/backlight/lp855x_bl.c | 24
1 file changed, 24 deletions(-)
diff --git a/drivers/video/backlight/lp855x_bl.c
b/drivers/video/backlight/lp855x_bl.c
index edd2041..7ae9ae6 100644
--- a/drivers/video/backlight/lp855x_bl.c
+++ b/drivers/video/backlight/lp855x_bl.c
@@ -66,20 +66,6 @@ struct lp855x {
struct pwm_device *pwm;
};
-static int lp855x_read_byte(struct lp855x *lp, u8 reg, u8 *data)
-{
- int ret;
-
- ret = i2c_smbus_read_byte_data(lp->client, reg);
- if (ret < 0) {
- dev_err(lp->dev, "failed to read 0x%.2x\n", reg);
- return ret;
- }
-
- *data = (u8)ret;
- return 0;
-}
-
static int lp855x_write_byte(struct lp855x *lp, u8 reg, u8 data)
{
return i2c_smbus_write_byte_data(lp->client, reg, data);
@@ -274,16 +260,6 @@ static int lp855x_bl_update_status(struct backlight_device
*bl)
static int lp855x_bl_get_brightness(struct backlight_device *bl)
{
- struct lp855x *lp = bl_get_data(bl);
- enum lp855x_brightness_ctrl_mode mode = lp->pdata->mode;
-
- if (mode == REGISTER_BASED) {
- u8 val = 0;
-
- lp855x_read_byte(lp, lp->cfg->reg_brightness, &val);
- bl->props.brightness = val;
- }
-
return bl->props.brightness;
}
--
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 1/3] backlight: lp855x_bl: introduce device configuration flow
At this moment, LP855x device driver has fixed register configuration.
For example, fixed register addresses and values are set on the device
initialization.
But new device of LP855x family, LP8557 has different register map and
initialization sequence.
To support new device architecture, initialization process should be changed.
Introduce new structure: lp855x_device_config
==
With lp855x_device_config, device specific features are configurable.
Use configurable function calls and register addresses rather than fixed
values.
Change on device initialization
===
In old LP855x driver architecture, the device initialization was simple.
- Just update the brightness/device control register/ROM area(optional).
In new LP855x driver architecture, two more works are added - pre_init and
post_init.
Those init functions are optional, used for new device LP8557.
New device initialization flow: generic sequence
=
1) pre_init_device()
2) update the brightness register
3) update the device control register
4) update ROM area if need
5) post_init_device()
Name change
===
Use generic name 'lp855x_configure()' instead of 'lp855x_init_registers()'.
Signed-off-by: Milo(Woogyom) Kim
---
drivers/video/backlight/lp855x_bl.c | 78 ++-
1 file changed, 68 insertions(+), 10 deletions(-)
diff --git a/drivers/video/backlight/lp855x_bl.c
b/drivers/video/backlight/lp855x_bl.c
index 6e4db0c..050cfbb 100644
--- a/drivers/video/backlight/lp855x_bl.c
+++ b/drivers/video/backlight/lp855x_bl.c
@@ -29,9 +29,26 @@
#define DEFAULT_BL_NAME"lcd-backlight"
#define MAX_BRIGHTNESS 255
+struct lp855x;
+
+/*
+ * struct lp855x_device_config
+ * @pre_init_device: init device function call before updating the brightness
+ * @reg_brightness: register address for brigthenss control
+ * @reg_devicectrl: register address for device control
+ * @post_init_device: late init device function call
+ */
+struct lp855x_device_config {
+ int (*pre_init_device)(struct lp855x *);
+ u8 reg_brightness;
+ u8 reg_devicectrl;
+ int (*post_init_device)(struct lp855x *);
+};
+
struct lp855x {
const char *chipname;
enum lp855x_chip_id chip_id;
+ struct lp855x_device_config *cfg;
struct i2c_client *client;
struct backlight_device *bl;
struct device *dev;
@@ -81,21 +98,52 @@ static bool lp855x_is_valid_rom_area(struct lp855x *lp, u8
addr)
return (addr >= start && addr <= end);
}
-static int lp855x_init_registers(struct lp855x *lp)
+static struct lp855x_device_config lp855x_dev_cfg = {
+ .reg_brightness = BRIGHTNESS_CTRL,
+ .reg_devicectrl = DEVICE_CTRL,
+};
+
+/*
+ * Device specific configuration flow
+ *
+ *a) pre_init_device(optional)
+ *b) update the brightness register
+ *c) update device control register
+ *d) update ROM area(optional)
+ *e) post_init_device(optional)
+ *
+ */
+static int lp855x_configure(struct lp855x *lp)
{
u8 val, addr;
int i, ret;
struct lp855x_platform_data *pd = lp->pdata;
+ switch (lp->chip_id) {
+ case LP8550 ... LP8556:
+ lp->cfg = &lp855x_dev_cfg;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ if (lp->cfg->pre_init_device) {
+ ret = lp->cfg->pre_init_device(lp);
+ if (ret) {
+ dev_err(lp->dev, "pre init device err: %d\n", ret);
+ goto err;
+ }
+ }
+
val = pd->initial_brightness;
- ret = lp855x_write_byte(lp, BRIGHTNESS_CTRL, val);
+ ret = lp855x_write_byte(lp, lp->cfg->reg_brightness, val);
if (ret)
- return ret;
+ goto err;
val = pd->device_control;
- ret = lp855x_write_byte(lp, DEVICE_CTRL, val);
+ ret = lp855x_write_byte(lp, lp->cfg->reg_devicectrl, val);
if (ret)
- return ret;
+ goto err;
if (pd->load_new_rom_data && pd->size_program) {
for (i = 0; i < pd->size_program; i++) {
@@ -106,10 +154,21 @@ static int lp855x_init_registers(struct lp855x *lp)
ret = lp855x_write_byte(lp, addr, val);
if (ret)
- return ret;
+ goto err;
+ }
+ }
+
+ if (lp->cfg->post_init_device) {
+ ret = lp->cfg->post_init_device(lp);
+ if (ret) {
+ dev_err(lp->dev, "post init device err: %d\n", ret);
+ goto err;
}
}
+ return 0;
+
+err:
return ret;
}
@@ -271,11 +330,10 @@ static int lp855x_probe(struct i2c_client *cl, const
struct i2c_device_id *id)
lp->chip_id = i
[PATCH 0/3] backlight: lp855x_bl: support new LP8557 device
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() 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 -- 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] iommu: making IOMMU sysfs nodes API public
On Wed, 2013-02-20 at 15:20 +1100, Alexey Kardashevskiy wrote:
> On 20/02/13 14:47, Alex Williamson wrote:
> > On Wed, 2013-02-20 at 13:31 +1100, Alexey Kardashevskiy wrote:
> >> On 20/02/13 07:11, Alex Williamson wrote:
> >>> On Tue, 2013-02-19 at 18:38 +1100, David Gibson wrote:
> On Mon, Feb 18, 2013 at 10:24:00PM -0700, Alex Williamson wrote:
> > On Mon, 2013-02-18 at 17:15 +1100, Alexey Kardashevskiy wrote:
> >> On 13/02/13 04:15, Alex Williamson wrote:
> >>> On Wed, 2013-02-13 at 01:42 +1100, Alexey Kardashevskiy wrote:
> On 12/02/13 16:07, Alex Williamson wrote:
> > On Tue, 2013-02-12 at 15:06 +1100, Alexey Kardashevskiy wrote:
> >> Having this patch in a tree, adding new nodes in sysfs
> >> for IOMMU groups is going to be easier.
> >>
> >> The first candidate for this change is a "dma-window-size"
> >> property which tells a size of a DMA window of the specific
> >> IOMMU group which can be used later for locked pages accounting.
> >
> > I'm still churning on this one; I'm nervous this would basically
> > creat
> > a /proc free-for-all under /sys/kernel/iommu_group/$GROUP/ where any
> > iommu driver can add random attributes. That can get ugly for
> > userspace.
>
> Is not it exactly what sysfs is for (unlike /proc)? :)
> >>>
> >>> Um, I hope it's a little more thought out than /proc.
> >>>
> > On the other hand, for the application of userspace knowing how much
> > memory to lock for vfio use of a group, it's an appealing location
> > to
> > get that information. Something like libvirt would already be
> > poking
> > around here to figure out which devices to bind. Page limits need
> > to be
> > setup prior to use through vfio, so sysfs is more convenient than
> > through vfio ioctls.
>
> True. DMA window properties do not change since boot so sysfs is the
> right
> place to expose them.
>
> > But then is dma-window-size just a vfio requirement leaking over
> > into
> > iommu groups? Can we allow iommu driver based attributes without
> > giving
> > up control of the namespace? Thanks,
>
> Who are you asking these questions? :)
> >>>
> >>> Anyone, including you. Rather than dropping misc files in sysfs to
> >>> describe things about the group, I think the better solution in your
> >>> case might be a link from the group to an existing sysfs directory
> >>> describing the PE. I believe your PE is rooted in a PCI bridge, so
> >>> that
> >>> presumably already has a representation in sysfs. Can the aperture
> >>> size
> >>> be determined from something in sysfs for that bridge already? I'm
> >>> just
> >>> not ready to create a grab bag of sysfs entries for a group yet.
> >>> Thanks,
> >>
> >>
> >> At the moment there is no information neither in sysfs nor
> >> /proc/device-tree about the dma-window. And adding a sysfs entry per PE
> >> (powerpc partitionable end-point which is often a PHB but not always)
> >> just
> >> for VFIO is quite heavy.
> >
> > How do you learn the window size and PE extents in the host kernel?
> >
> >> We could add a ppc64 subfolder under /sys/kernel/iommu/xxx/ and put the
> >> "dma-window" property there. And replace it with a symlink when and if
> >> we
> >> add something for PE later. Would work?
>
> Fwiw, I'd suggest a subfolder named for the type of IOMMU, rather than
> "ppc64".
>
> > To be clear, you're suggesting /sys/kernel/iommu_groups/$GROUP/xxx/,
> > right? A subfolder really only limits the scope of the mess, so it's
> > not much improvement. What does the interface look like to make those
> > subfolders?
> >
> > The problem we're trying to solve is this call flow:
> >
> > containerfd = open("/dev/vfio/vfio");
> > ioctl(containerfd, VFIO_GET_API_VERSION);
> > ioctl(containerfd, VFIO_CHECK_EXTENSION, ...);
> > groupfd = open("/dev/vfio/$GROUP");
> > ioctl(groupfd, VFIO_GROUP_GET_STATUS);
> > ioctl(groupfd, VFIO_GROUP_SET_CONTAINER, &containerfd);
> >
> > You wanted to lock all the memory for the DMA window here, before we can
> > call VFIO_IOMMU_GET_INFO, but does it need to happen there? We still
> > have a MAP_DMA hook. We could do it all on the first mapping.
>
> MAP_DMA isn't quite enough, since the guest can also directly cause
> mappings using hypercalls directly implemented in KVM. I think it
> would be feasible to lock on the first mapping (either via MAP_DMA, or
> H_PUT_TCE) though it would be a bit ugly and require that the first
> H_PUT_TCE always bounce out to virtual mode (Alexey,
Re: linux-next: manual merge of the driver-core tree with the virtio tree
On Wed, Feb 20, 2013 at 03:25:07PM +1100, Stephen Rothwell wrote:
> Hi Greg,
>
> Today's linux-next merge of the driver-core tree got conflicts in
> drivers/vhost/Kconfig and drivers/vhost/Kconfig.tcm between commit
> 4d8dc8b44748 ("vringh: host-side implementation of virtio rings") from
> the virtio tree and commit 43893cbefc1b ("drivers/vhost: remove depends
> on CONFIG_EXPERIMENTAL") from the driver-core tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
Looks good to me, thanks.
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the driver-core tree with the virtio tree
Hi Greg,
Today's linux-next merge of the driver-core tree got conflicts in
drivers/vhost/Kconfig and drivers/vhost/Kconfig.tcm between commit
4d8dc8b44748 ("vringh: host-side implementation of virtio rings") from
the virtio tree and commit 43893cbefc1b ("drivers/vhost: remove depends
on CONFIG_EXPERIMENTAL") from the driver-core tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/vhost/Kconfig
index 613b074,bf24317..000
--- a/drivers/vhost/Kconfig
+++ b/drivers/vhost/Kconfig
@@@ -1,7 -1,6 +1,7 @@@
config VHOST_NET
- tristate "Host kernel accelerator for virtio net (EXPERIMENTAL)"
- depends on NET && EVENTFD && (TUN || !TUN) && (MACVTAP || !MACVTAP) &&
EXPERIMENTAL
+ tristate "Host kernel accelerator for virtio net"
+ depends on NET && EVENTFD && (TUN || !TUN) && (MACVTAP || !MACVTAP)
+ select VHOST_RING
---help---
This kernel module can be loaded in host kernel to accelerate
guest networking with virtio_net. Not to be confused with virtio_net
diff --cc drivers/vhost/Kconfig.tcm
index 0218f77,7e3aa28..000
--- a/drivers/vhost/Kconfig.tcm
+++ b/drivers/vhost/Kconfig.tcm
@@@ -1,7 -1,6 +1,7 @@@
config TCM_VHOST
- tristate "TCM_VHOST fabric module (EXPERIMENTAL)"
- depends on TARGET_CORE && EVENTFD && EXPERIMENTAL && m
+ tristate "TCM_VHOST fabric module"
+ depends on TARGET_CORE && EVENTFD && m
+ select VHOST_RING
default n
---help---
Say M here to enable the TCM_VHOST fabric module for use with
virtio-scsi guests
pgpBDmL12bvwv.pgp
Description: PGP signature
Linux 3.2.39
I'm announcing the release of the 3.2.39 kernel. All users of the 3.2 kernel series should upgrade. The updated 3.2.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-3.2.y and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git Ben. MAINTAINERS|6 +- Makefile |2 +- arch/x86/ia32/ia32entry.S |4 +- arch/x86/kernel/step.c | 54 ++-- arch/x86/xen/xen-asm_32.S | 14 +- drivers/ata/ahci.c | 32 +- drivers/atm/iphase.h | 146 - drivers/char/virtio_console.c |3 +- drivers/gpu/drm/i915/intel_display.c |4 +- drivers/gpu/drm/radeon/radeon_combios.c|8 + drivers/gpu/drm/radeon/radeon_display.c|4 +- drivers/gpu/drm/radeon/radeon_ring.c |3 + drivers/hid/hid-ids.h |3 + drivers/hid/usbhid/hid-quirks.c|1 + drivers/isdn/gigaset/capi.c|2 + drivers/media/video/gspca/kinect.c |1 + drivers/net/can/c_can/c_can.c |6 +- drivers/net/ethernet/broadcom/tg3.c| 62 ++-- .../net/ethernet/qlogic/netxen/netxen_nic_init.c |2 +- .../net/ethernet/qlogic/netxen/netxen_nic_main.c |2 + drivers/net/ethernet/realtek/r8169.c |7 - drivers/net/loopback.c |5 + drivers/net/wireless/mwifiex/scan.c|9 +- drivers/net/wireless/rt2x00/rt2500usb.c|2 +- drivers/net/wireless/rt2x00/rt2800usb.c|2 + drivers/net/wireless/rt2x00/rt73usb.c |1 + drivers/net/wireless/rtlwifi/usb.c |4 +- drivers/net/xen-netback/common.h |3 + drivers/net/xen-netback/interface.c| 23 +- drivers/net/xen-netback/netback.c | 115 --- drivers/rtc/rtc-isl1208.c |3 + drivers/rtc/rtc-pl031.c|8 +- drivers/usb/host/ehci-sched.c |2 +- drivers/usb/host/pci-quirks.c |1 + drivers/usb/host/xhci-ring.c | 11 +- drivers/usb/serial/ftdi_sio.c |2 + drivers/usb/serial/ftdi_sio_ids.h |9 +- drivers/usb/serial/option.c| 13 + drivers/usb/serial/qcserial.c |1 + drivers/usb/storage/initializers.c | 76 - drivers/usb/storage/initializers.h |4 +- drivers/usb/storage/unusual_devs.h | 329 +--- drivers/usb/storage/usb.c | 12 + drivers/usb/storage/usual-tables.c | 15 + fs/nilfs2/ioctl.c |5 +- fs/splice.c|4 +- include/linux/sched.h | 11 +- kernel/ptrace.c| 72 - kernel/resource.c | 50 ++- kernel/sched.c |3 +- kernel/sched_rt.c |2 +- kernel/signal.c| 19 +- net/bluetooth/hci_event.c |2 +- net/bluetooth/smp.c| 13 + net/bridge/br_netfilter.c |3 + net/core/pktgen.c |9 +- net/ipv4/ip_sockglue.c |2 +- net/ipv4/tcp_input.c |5 + net/ipv6/addrconf.c|2 +- net/ipv6/ip6_output.c |4 +- net/ipv6/route.c |3 +- net/packet/af_packet.c | 10 +- net/sctp/endpointola.c |5 + net/sctp/outqueue.c| 12 +- net/sctp/socket.c |2 +- 65 files changed, 649 insertions(+), 605 deletions(-) Alan Stern (2): USB: XHCI: fix memory leak of URB-private data USB: EHCI: fix bug in scheduling periodic split transfers Alessandro Rubini (1): ahci: support the STA2X11 I/O Hub Alex Deucher (2): drm/radeon: add quirk for RV100 board drm/radeon: prevent crash in the ring space allocation Alexander Stein (1): can: c_can: Set reserved bit in IFx_MASK2 to 1 on write Ben Hutchings (2): drm/i915: Fix misplaced intel_mark_page_flip_active() Linux 3.2.3
Re: [patch v4 07/18] sched: set initial load avg of new forked task
Hi everyone,
On 02/19/2013 05:04 PM, Paul Turner wrote:
> On Fri, Feb 15, 2013 at 2:07 AM, Alex Shi wrote:
>>
>>> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
>>> index 1dff78a..9d1c193 100644
>>> --- a/kernel/sched/core.c
>>> +++ b/kernel/sched/core.c
>>> @@ -1557,8 +1557,8 @@ static void __sched_fork(struct task_struct *p)
>>> * load-balance).
>>> */
>>> #if defined(CONFIG_SMP) && defined(CONFIG_FAIR_GROUP_SCHED)
>>> - p->se.avg.runnable_avg_period = 0;
>>> - p->se.avg.runnable_avg_sum = 0;
>>> + p->se.avg.runnable_avg_period = 1024;
>>> + p->se.avg.runnable_avg_sum = 1024;
>>
>> It can't work.
>> avg.decay_count needs to be set to 0 before enqueue_entity_load_avg(), then
>> update_entity_load_avg() can't be called, so, runnable_avg_period/sum
>> are unusable.
>
> Well we _could_ also use a negative decay_count here and treat it like
> a migration; but the larger problem is the visibility of p->on_rq;
> which is gates whether we account the time as runnable and occurs
> after activate_task() so that's out.
>
>>
>> Even we has chance to call __update_entity_runnable_avg(),
>> avg.last_runnable_update needs be set before that, usually, it needs to
>> be set as 'now', that cause __update_entity_runnable_avg() function
>> return 0, then update_entity_load_avg() still can not reach to
>> __update_entity_load_avg_contrib().
>>
>> If we embed a simple new task load initialization to many functions,
>> that is too hard for future reader.
>
> This is my concern about making this a special case with the
> introduction ENQUEUE_NEWTASK flag; enqueue jumps through enough hoops
> as it is.
>
> I still don't see why we can't resolve this at init time in
> __sched_fork(); your patch above just moves an explicit initialization
> of load_avg_contrib into the enqueue path. Adding a call to
> __update_task_entity_contrib() to the previous alternate suggestion
> would similarly seem to resolve this?
We could do this(Adding a call to __update_task_entity_contrib()),but the
cfs_rq->runnable_load_avg gets updated only if the task is on the runqueue.
But in the forked task's case the on_rq flag is not yet set.Something like
the below:
---
kernel/sched/fair.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 8691b0d..841e156 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -1451,14 +1451,20 @@ static inline void update_entity_load_avg(struct
sched_entity *se,
else
now = cfs_rq_clock_task(group_cfs_rq(se));
- if (!__update_entity_runnable_avg(now, &se->avg, se->on_rq))
- return;
-
+ if (!__update_entity_runnable_avg(now, &se->avg, se->on_rq)) {
+ if (!(flags & ENQUEUE_NEWTASK))
+ return;
+ }
contrib_delta = __update_entity_load_avg_contrib(se);
if (!update_cfs_rq)
return;
+ /* But the cfs_rq->runnable_load_avg does not get updated in case of
+* a forked task,because the se->on_rq = 0,although we update the
+* task's load_avg_contrib above in
+* __update_entity_laod_avg_contrib().
+*/
if (se->on_rq)
cfs_rq->runnable_load_avg += contrib_delta;
else
@@ -1538,12 +1544,6 @@ static inline void enqueue_entity_load_avg(struct cfs_rq
*cfs_rq,
subtract_blocked_load_contrib(cfs_rq, se->avg.load_avg_contrib);
update_entity_load_avg(se, 0);
}
- /*
-* set the initial load avg of new task same as its load
-* in order to avoid brust fork make few cpu too heavier
-*/
- if (flags & ENQUEUE_NEWTASK)
- se->avg.load_avg_contrib = se->load.weight;
cfs_rq->runnable_load_avg += se->avg.load_avg_contrib;
/* we force update consideration on load-balancer moves */
Thanks
Regards
Preeti U Murthy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] iommu: making IOMMU sysfs nodes API public
On 20/02/13 14:47, Alex Williamson wrote:
On Wed, 2013-02-20 at 13:31 +1100, Alexey Kardashevskiy wrote:
On 20/02/13 07:11, Alex Williamson wrote:
On Tue, 2013-02-19 at 18:38 +1100, David Gibson wrote:
On Mon, Feb 18, 2013 at 10:24:00PM -0700, Alex Williamson wrote:
On Mon, 2013-02-18 at 17:15 +1100, Alexey Kardashevskiy wrote:
On 13/02/13 04:15, Alex Williamson wrote:
On Wed, 2013-02-13 at 01:42 +1100, Alexey Kardashevskiy wrote:
On 12/02/13 16:07, Alex Williamson wrote:
On Tue, 2013-02-12 at 15:06 +1100, Alexey Kardashevskiy wrote:
Having this patch in a tree, adding new nodes in sysfs
for IOMMU groups is going to be easier.
The first candidate for this change is a "dma-window-size"
property which tells a size of a DMA window of the specific
IOMMU group which can be used later for locked pages accounting.
I'm still churning on this one; I'm nervous this would basically creat
a /proc free-for-all under /sys/kernel/iommu_group/$GROUP/ where any
iommu driver can add random attributes. That can get ugly for
userspace.
Is not it exactly what sysfs is for (unlike /proc)? :)
Um, I hope it's a little more thought out than /proc.
On the other hand, for the application of userspace knowing how much
memory to lock for vfio use of a group, it's an appealing location to
get that information. Something like libvirt would already be poking
around here to figure out which devices to bind. Page limits need to be
setup prior to use through vfio, so sysfs is more convenient than
through vfio ioctls.
True. DMA window properties do not change since boot so sysfs is the right
place to expose them.
But then is dma-window-size just a vfio requirement leaking over into
iommu groups? Can we allow iommu driver based attributes without giving
up control of the namespace? Thanks,
Who are you asking these questions? :)
Anyone, including you. Rather than dropping misc files in sysfs to
describe things about the group, I think the better solution in your
case might be a link from the group to an existing sysfs directory
describing the PE. I believe your PE is rooted in a PCI bridge, so that
presumably already has a representation in sysfs. Can the aperture size
be determined from something in sysfs for that bridge already? I'm just
not ready to create a grab bag of sysfs entries for a group yet.
Thanks,
At the moment there is no information neither in sysfs nor
/proc/device-tree about the dma-window. And adding a sysfs entry per PE
(powerpc partitionable end-point which is often a PHB but not always) just
for VFIO is quite heavy.
How do you learn the window size and PE extents in the host kernel?
We could add a ppc64 subfolder under /sys/kernel/iommu/xxx/ and put the
"dma-window" property there. And replace it with a symlink when and if we
add something for PE later. Would work?
Fwiw, I'd suggest a subfolder named for the type of IOMMU, rather than
"ppc64".
To be clear, you're suggesting /sys/kernel/iommu_groups/$GROUP/xxx/,
right? A subfolder really only limits the scope of the mess, so it's
not much improvement. What does the interface look like to make those
subfolders?
The problem we're trying to solve is this call flow:
containerfd = open("/dev/vfio/vfio");
ioctl(containerfd, VFIO_GET_API_VERSION);
ioctl(containerfd, VFIO_CHECK_EXTENSION, ...);
groupfd = open("/dev/vfio/$GROUP");
ioctl(groupfd, VFIO_GROUP_GET_STATUS);
ioctl(groupfd, VFIO_GROUP_SET_CONTAINER, &containerfd);
You wanted to lock all the memory for the DMA window here, before we can
call VFIO_IOMMU_GET_INFO, but does it need to happen there? We still
have a MAP_DMA hook. We could do it all on the first mapping.
MAP_DMA isn't quite enough, since the guest can also directly cause
mappings using hypercalls directly implemented in KVM. I think it
would be feasible to lock on the first mapping (either via MAP_DMA, or
H_PUT_TCE) though it would be a bit ugly and require that the first
H_PUT_TCE always bounce out to virtual mode (Alexey, correct me if I'm
wrong here). IIRC there is also a call to bind the vfio container to
a (qemu assigned) LIOBN, before the guest can use H_PUT_TCE directly,
so that might be another place we could do the lock.
Somehow hypercall mappings have to be gated by the userspace setup,
right?
There is a KVM ioctl (and a KVM capability) which hooks LIOBN (PCI bus ID)
with IOMMU ID. It basically creates an entry in the list of all LIOBNs and
when TCE call occurs, the host finds correct IOMMU group to pass this call to.
It happens from spapr_register_vfio_container() in QEMU, i.e. after getting
DMA window properties but only if the host supports real mode TCE handling.
It also
has a flags field that could augment the behavior to trigger page
locking.
I don't see how the flags help us - we can't have userspace choose to
skip the locked memory accounting. Or are you suggesting a flag to
open the container in some sort of dummy mode where only GET_INFO is
possible, then re-open with t
Re: [PATCH v2] vt: add init_hide parameter to suppress boot output
On 02/19/2013 05:45 PM, Greg Kroah-Hartman wrote: When vt.init_hide is set, suppress output on newly created consoles until an affirmative switched to that console. This prevents boot output from displaying (and clobbering splash screens, etc...) without disabling the console entirely. What's wrong with the 'quiet' option we have? And you forgot to document this. You're right about docs, obviously. I'll write something up and send it tomorrow morning. But setting "quiet" controls logging. It won't prevent the console from doing a buffer clear or mode switch, nor will it prevent userspace from writing to it, nor will the buffer rewrites due to the console switches that happen on suspend and resume (which I didn't know existed) be suppressed. There's a (sort of) similar commonly-used option, vga=current, which prevents a mode switch for the special case of VGA/vesa. But that doesn't work with the framebuffer console. The idea here (and I'm clearly no domain expert) was to leave the console enabled and active, but invisible by default. So nothing displays, the splash screen stays put, and nothing fights with other users of the framebuffer. And it stays that way until something affirmatively switches to a different VT using chvt or Alt-Fn or whatever. To be fair, a lot of this could be managed in userspace with the VT_* ioctl interface. But the specific application here (Android's surfaceflinger) isn't set up for that, and it's a non-trivial API (and even doing it "right" involves racing against other users at startup). This seemed like a much simpler metaphor that still meets the requirements. Andy -- 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 4/7] ktest: Add make_warnings_file and process full warnings
From: "Steven Rostedt (Red Hat)"
Although the patchcheck test checks for warnings in the files that were
changed, this check does not catch warnings that were caused by header
file changes and the warnings appear in C files not touched by the
commit.
Add a new option called WARNINGS_FILE. If this option is set, then the
file it points to is read before bulid, and the file should contain a
list of known warnings. If a warning appears in the build, this file is
checked, and if the warning does not exist in this file, then it fails
the build showing the new warning.
If the WARNINGS_FILE points to a file that does not exist, this will
cause any warning in the build to fail.
A new test is also added called "make_warnings_file". This test will
create do a build and record any warnings it finds into the
WARNINGS_FILE. This test is something that can be run before other tests
to build a warnings file of "known warnings", ie, warnings that were
there before your changes.
Signed-off-by: Steven Rostedt
---
.../testing/ktest/examples/include/patchcheck.conf | 37 +++
tools/testing/ktest/ktest.pl | 110 ++--
tools/testing/ktest/sample.conf| 44
3 files changed, 185 insertions(+), 6 deletions(-)
diff --git a/tools/testing/ktest/examples/include/patchcheck.conf
b/tools/testing/ktest/examples/include/patchcheck.conf
index 339d3e1..0eb0a5a 100644
--- a/tools/testing/ktest/examples/include/patchcheck.conf
+++ b/tools/testing/ktest/examples/include/patchcheck.conf
@@ -14,6 +14,16 @@
PATCH_START := HEAD~3
PATCH_END := HEAD
+# Use the oldconfig if build_type wasn't defined
+DEFAULTS IF NOT DEFINED BUILD_TYPE
+DO_BUILD_TYPE := oldconfig
+
+DEFAULTS ELSE
+DO_BUILD_TYPE := ${BUILD_TYPE}
+
+DEFAULTS
+
+
# Change PATCH_CHECKOUT to be the branch you want to test. The test will
# do a git checkout of this branch before starting. Obviously both
# PATCH_START and PATCH_END must be in this branch (and PATCH_START must
@@ -43,6 +53,31 @@ PATCH_TEST_TYPE := boot
# (space delimited)
#IGNORE_WARNINGS = 39eaf7ef884dcc44f7ff1bac803ca2a1dcf43544
6edb2a8a385f0cdef51dae37ff23e74d76d8a6ce
+# Instead of just checking for warnings to files that are changed
+# it can be advantageous to check for any new warnings. If a
+# header file is changed, it could cause a warning in a file not
+# touched by the commit. To detect these kinds of warnings, you
+# can use the WARNINGS_FILE option.
+#
+# If the variable CREATE_WARNINGS_FILE is set, this config will
+# enable the WARNINGS_FILE during the patchcheck test. Also,
+# before running the patchcheck test, it will create the
+# warnings file.
+#
+DEFAULTS IF DEFINED CREATE_WARNINGS_FILE
+WARNINGS_FILE = ${OUTPUT_DIR}/warnings_file
+
+TEST_START IF DEFINED CREATE_WARNINGS_FILE
+# WARNINGS_FILE is already set by the DEFAULTS above
+TEST_TYPE = make_warnings_file
+# Checkout the commit before the patches to test,
+# and record all the warnings that exist before the patches
+# to test are added
+CHECKOUT = ${PATCHCHECK_START}~1
+# Force a full build
+BUILD_NOCLEAN = 0
+BUILD_TYPE = ${DO_BUILD_TYPE}
+
# If you are running a multi test, and the test failed on the first
# test but on, say the 5th patch. If you want to restart on the
# fifth patch, set PATCH_START1. This will make the first test start
@@ -61,6 +96,7 @@ PATCHCHECK_TYPE = ${PATCH_TEST_TYPE}
PATCHCHECK_START = ${PATCH_START1}
PATCHCHECK_END = ${PATCH_END}
CHECKOUT = ${PATCH_CHECKOUT}
+BUILD_TYPE = ${DO_BUILD_TYPE}
TEST_START IF ${TEST} == patchcheck && ${MULTI}
TEST_TYPE = patchcheck
@@ -72,3 +108,4 @@ PATCHCHECK_END = ${PATCH_END}
CHECKOUT = ${PATCH_CHECKOUT}
# Use multi to test different compilers?
MAKE_CMD = CC=gcc-4.5.1 make
+BUILD_TYPE = ${DO_BUILD_TYPE}
diff --git a/tools/testing/ktest/ktest.pl b/tools/testing/ktest/ktest.pl
index 3d19ee4..3fd768e 100755
--- a/tools/testing/ktest/ktest.pl
+++ b/tools/testing/ktest/ktest.pl
@@ -126,6 +126,7 @@ my $start_minconfig_defined;
my $output_minconfig;
my $minconfig_type;
my $use_output_minconfig;
+my $warnings_file;
my $ignore_config;
my $ignore_errors;
my $addconfig;
@@ -193,6 +194,9 @@ my $patchcheck_end;
# which would require more options.
my $buildonly = 1;
+# tell build not to worry about warnings, even when WARNINGS_FILE is set
+my $warnings_ok = 0;
+
# set when creating a new config
my $newconfig = 0;
@@ -235,6 +239,7 @@ my %option_map = (
"START_MIN_CONFIG" => \$start_minconfig,
"MIN_CONFIG_TYPE" => \$minconfig_type,
"USE_OUTPUT_MIN_CONFIG"=> \$use_output_minconfig,
+"WARNINGS_FILE"=> \$warnings_file,
"IGNORE_CONFIG"=> \$ignore_config,
"TEST" => \$run_test,
"ADD_CONFIG" => \$addconfig,
@@ -1924,7 +1929,60 @@ sub start_monitor_and_boot {
return monitor;
}
+my $check_build_re = ".*:.*(warning|error|Error):.*";
+my $utf8_quote = "\\x{e2}\\x{80}(\\x{98}|\\x{9
[PATCH 6/7] ktest: Ignore warnings during reboot
From: "Steven Rostedt (Red Hat)"
The reboot just wants to get to the next kernel. But if a warning (Call
Trace) appears, the monitor will report an error, and the reboot will
think something went wrong and power cycle the box, even though we
successfully made it to the next kernel.
Ignore warnings during the reboot until we get to the next kernel. It
will still timeout if we never get to the next kernel and then a power
cycle will happen. That's what we want it to do.
Signed-off-by: Steven Rostedt
---
tools/testing/ktest/ktest.pl |8
1 file changed, 8 insertions(+)
diff --git a/tools/testing/ktest/ktest.pl b/tools/testing/ktest/ktest.pl
index 839989d..f3bb5da 100755
--- a/tools/testing/ktest/ktest.pl
+++ b/tools/testing/ktest/ktest.pl
@@ -1212,6 +1212,12 @@ sub reboot {
}
if (defined($time)) {
+
+ # We only want to get to the new kernel, don't fail
+ # if we stumble over a call trace.
+ my $save_ignore_errors = $ignore_errors;
+ $ignore_errors = 1;
+
# Look for the good kernel to boot
if (wait_for_monitor($time, "Linux version")) {
# reboot got stuck?
@@ -1219,6 +1225,8 @@ sub reboot {
run_command "$power_cycle";
}
+ $ignore_errors = $save_ignore_errors;
+
# Still need to wait for the reboot to finish
wait_for_monitor($time, $reboot_success_line);
--
1.7.10.4
signature.asc
Description: This is a digitally signed message part
[PATCH 0/7] [GIT PULL] ktest: updates for v3.9
Linus, Updates include: o Added ability to have all builds test warnings. o Fixed failing reboot when the reboot produces a non fatal error. o Config reading fixes and other cleanups. Please pull the latest ktest-v3.9 tree, which can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-ktest.git ktest-v3.9 Head SHA1: b4e059fa0c07e0c054dab9a48c2e3f7d7d4563be Steven Rostedt (Red Hat) (7): ktest: Do not require CONSOLE for build or install bisects ktest: Strip off '\n' when reading which files were modified ktest: Allow a test option to use its default option ktest: Add make_warnings_file and process full warnings ktest: Search for linux banner for successful reboot ktest: Ignore warnings during reboot ktest: Remove indexes from warnings check .../testing/ktest/examples/include/patchcheck.conf | 37 tools/testing/ktest/ktest.pl | 190 ++-- tools/testing/ktest/sample.conf| 44 + 3 files changed, 253 insertions(+), 18 deletions(-) signature.asc Description: This is a digitally signed message part
[PATCH 3/7] ktest: Allow a test option to use its default option
From: "Steven Rostedt (Red Hat)"
Options are allowed to use other options, for example:
LOG_FILE = ${OUTPUT_DIR}/${MACHINE}.log
where the option LOG_FILE used the options OUTPUT_DIR and MACHINE.
But if a test option were to use a default option, it will not get
substituted:
OUTPUT_DIR = ${THIS_DIR}/${MACHINE}
TEST_START
OUTPUT_DIR = ${OUTPUT_DIR}/t1
For the above test, OUTPUT_DIR will stay literally "${OUTPUT_DIR}/t1"
and not be converted to "${THIS_DIR}/${MACHINE}/t1". When the test runs,
it will pass the ${OUTPUT_DIR} to the shell, which would probaly
interpret it as "", and the output directory will end up as "/t1".
Change the code where if a test option has its own option name in
its defined field, and a default option exists, then substitute the
default option in its place.
Signed-off-by: Steven Rostedt
---
tools/testing/ktest/ktest.pl | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/tools/testing/ktest/ktest.pl b/tools/testing/ktest/ktest.pl
index cc9925a..3d19ee4 100755
--- a/tools/testing/ktest/ktest.pl
+++ b/tools/testing/ktest/ktest.pl
@@ -1074,7 +1074,7 @@ sub read_config {
}
sub __eval_option {
-my ($option, $i) = @_;
+my ($name, $option, $i) = @_;
# Add space to evaluate the character before $
$option = " $option";
@@ -1106,7 +1106,11 @@ sub __eval_option {
my $o = "$var\[$i\]";
my $parento = "$var\[$parent\]";
- if (defined($opt{$o})) {
+ # If a variable contains itself, use the default var
+ if (($var eq $name) && defined($opt{$var})) {
+ $o = $opt{$var};
+ $retval = "$retval$o";
+ } elsif (defined($opt{$o})) {
$o = $opt{$o};
$retval = "$retval$o";
} elsif ($repeated && defined($opt{$parento})) {
@@ -1130,7 +1134,7 @@ sub __eval_option {
}
sub eval_option {
-my ($option, $i) = @_;
+my ($name, $option, $i) = @_;
my $prev = "";
@@ -1146,7 +1150,7 @@ sub eval_option {
"Check for recursive variables\n";
}
$prev = $option;
- $option = __eval_option($option, $i);
+ $option = __eval_option($name, $option, $i);
}
return $option;
@@ -3683,7 +3687,7 @@ EOF
read_config $ktest_config;
if (defined($opt{"LOG_FILE"})) {
-$opt{"LOG_FILE"} = eval_option($opt{"LOG_FILE"}, -1);
+$opt{"LOG_FILE"} = eval_option("LOG_FILE", $opt{"LOG_FILE"}, -1);
}
# Append any configs entered in manually to the config file.
@@ -3760,7 +3764,7 @@ sub set_test_option {
my $option = __set_test_option($name, $i);
return $option if (!defined($option));
-return eval_option($option, $i);
+return eval_option($name, $option, $i);
}
# First we need to do is the builds
--
1.7.10.4
signature.asc
Description: This is a digitally signed message part
[PATCH 5/7] ktest: Search for linux banner for successful reboot
From: "Steven Rostedt (Red Hat)"
Sometimes when a test kernel passed fine, but on reboot it crashed,
ktest could get stuck and not proceed. This would be frustrating if you
let a test run overnight to find out the next morning that it was stuck
on the first test.
To fix this, I made reboot check for the REBOOT_SUCCESS_LINE. If the
line was not detected, then it would power cycle the box.
What it didn't cover was if the REBOOT_SUCCESS_LINE wasn't defined or if
a 'good' kernel did not display the line. Instead have it search for the
Linux banner "Linux version". The reboot just needs to get to the start
of the next kernel, it does not need to test if the next kernel makes it
to a boot prompt.
After we find the next kernel has booted, then we just wait for either
the REBOOT_SUCCESS_LINE to appear or the timeout.
Signed-off-by: Steven Rostedt
---
tools/testing/ktest/ktest.pl |7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/tools/testing/ktest/ktest.pl b/tools/testing/ktest/ktest.pl
index 3fd768e..839989d 100755
--- a/tools/testing/ktest/ktest.pl
+++ b/tools/testing/ktest/ktest.pl
@@ -1212,11 +1212,16 @@ sub reboot {
}
if (defined($time)) {
- if (wait_for_monitor($time, $reboot_success_line)) {
+ # Look for the good kernel to boot
+ if (wait_for_monitor($time, "Linux version")) {
# reboot got stuck?
doprint "Reboot did not finish. Forcing power cycle\n";
run_command "$power_cycle";
}
+
+ # Still need to wait for the reboot to finish
+ wait_for_monitor($time, $reboot_success_line);
+
end_monitor;
}
}
--
1.7.10.4
signature.asc
Description: This is a digitally signed message part
[PATCH 7/7] ktest: Remove indexes from warnings check
From: "Steven Rostedt (Red Hat)"
The index of a line where a warning is tested can be returned
differently on different versions of gcc (or same version compiled
differently). That is, a tab + space can give different results. This
causes the warning check to produce a false positive. Removing the
index from the check fixes this issue.
Signed-off-by: Steven Rostedt
---
tools/testing/ktest/ktest.pl | 34 ++
1 file changed, 26 insertions(+), 8 deletions(-)
diff --git a/tools/testing/ktest/ktest.pl b/tools/testing/ktest/ktest.pl
index f3bb5da..4e67d52 100755
--- a/tools/testing/ktest/ktest.pl
+++ b/tools/testing/ktest/ktest.pl
@@ -1945,6 +1945,27 @@ sub start_monitor_and_boot {
my $check_build_re = ".*:.*(warning|error|Error):.*";
my $utf8_quote = "\\x{e2}\\x{80}(\\x{98}|\\x{99})";
+sub process_warning_line {
+my ($line) = @_;
+
+chomp $line;
+
+# for distcc heterogeneous systems, some compilers
+# do things differently causing warning lines
+# to be slightly different. This makes an attempt
+# to fixe those issues.
+
+# chop off the index into the line
+# using distcc, some compilers give different indexes
+# depending on white space
+$line =~ s/^(\s*\S+:\d+:)\d+/$1/;
+
+# Some compilers use UTF-8 extended for quotes and some don't.
+$line =~ s/$utf8_quote/'/g;
+
+return $line;
+}
+
# Read buildlog and check against warnings file for any
# new warnings.
#
@@ -1965,8 +1986,9 @@ sub check_buildlog {
while () {
if (/$check_build_re/) {
- chomp;
- $warnings_list{$_} = 1;
+ my $warning = process_warning_line $_;
+
+ $warnings_list{$warning} = 1;
}
}
close(IN);
@@ -1978,13 +2000,9 @@ sub check_buildlog {
open(IN, $buildlog) or dodie "Can't open $buildlog";
while () {
if (/$check_build_re/) {
+ my $warning = process_warning_line $_;
- # Some compilers use UTF-8 extended for quotes
- # for distcc heterogeneous systems, this causes issues
- s/$utf8_quote/'/g;
-
- chomp;
- if (!defined $warnings_list{$_}) {
+ if (!defined $warnings_list{$warning}) {
fail "New warning found (not in $warnings_file)\n$_\n";
$no_reboot = $save_no_reboot;
return 0;
--
1.7.10.4
signature.asc
Description: This is a digitally signed message part
[PATCH 2/7] ktest: Strip off \n when reading which files were modified
From: "Steven Rostedt (Red Hat)"
The patchcheck test looks at what files are modified for each patch it
checks and makes sure that those files do not produce any warnings.
Unfortunately, when it read the diffstat, the newlines were added on the
files and this made compares miss warnings, and commits that should not
have passed, ktest let pass.
Fix this by using the perl command "chomp" that strips off whitespace at
the end of lines.
Signed-off-by: Steven Rostedt
---
tools/testing/ktest/ktest.pl |4
1 file changed, 4 insertions(+)
diff --git a/tools/testing/ktest/ktest.pl b/tools/testing/ktest/ktest.pl
index d6690df..cc9925a 100755
--- a/tools/testing/ktest/ktest.pl
+++ b/tools/testing/ktest/ktest.pl
@@ -1925,6 +1925,10 @@ sub check_buildlog {
my @files = `git show $patch | diffstat -l`;
+foreach my $file (@files) {
+ chomp $file;
+}
+
open(IN, "git show $patch |") or
dodie "failed to show $patch";
while () {
--
1.7.10.4
signature.asc
Description: This is a digitally signed message part
[PATCH 1/7] ktest: Do not require CONSOLE for build or install bisects
From: "Steven Rostedt (Red Hat)"
If the user is doing a build or install bisect, there's no reason to
have them define CONSOLE, as the console does not need to be read. The
console only needs to be read for boot tests.
CONSOLE is not required for normal build or install tests, let's not
require it for bisect tests with BISECT_TYPE of build or install.
Signed-off-by: Steven Rostedt
---
tools/testing/ktest/ktest.pl | 27 ++-
1 file changed, 22 insertions(+), 5 deletions(-)
diff --git a/tools/testing/ktest/ktest.pl b/tools/testing/ktest/ktest.pl
index 35fc584..d6690df 100755
--- a/tools/testing/ktest/ktest.pl
+++ b/tools/testing/ktest/ktest.pl
@@ -619,6 +619,18 @@ sub set_value {
# Note if a test is something other than build, then we
# will need other manditory options.
if ($prvalue ne "install") {
+ # for bisect, we need to check BISECT_TYPE
+ if ($prvalue ne "bisect") {
+ $buildonly = 0;
+ }
+ } else {
+ # install still limits some manditory options.
+ $buildonly = 2;
+ }
+}
+
+if ($buildonly && $lvalue =~ /^BISECT_TYPE(\[.*\])?$/ && $prvalue ne
"build") {
+ if ($prvalue ne "install") {
$buildonly = 0;
} else {
# install still limits some manditory options.
@@ -1279,6 +1291,7 @@ sub start_monitor {
}
sub end_monitor {
+return if (!defined $console);
if (--$monitor_cnt) {
return;
}
@@ -1585,7 +1598,7 @@ sub wait_for_input
$rin = '';
vec($rin, fileno($fp), 1) = 1;
-$ready = select($rin, undef, undef, $time);
+($ready, $time) = select($rin, undef, undef, $time);
$line = "";
@@ -1891,15 +1904,19 @@ sub get_version {
sub start_monitor_and_boot {
# Make sure the stable kernel has finished booting
-start_monitor;
-wait_for_monitor 5;
-end_monitor;
+
+# Install bisects, don't need console
+if (defined $console) {
+ start_monitor;
+ wait_for_monitor 5;
+ end_monitor;
+}
get_grub_index;
get_version;
install;
-start_monitor;
+start_monitor if (defined $console);
return monitor;
}
--
1.7.10.4
signature.asc
Description: This is a digitally signed message part
[PATCH 1/4] documentation: add palmas dts definition
From: Graeme Gregory
Add the DTS definition for the palmas device including the MFD children.
Signed-off-by: Graeme Gregory
[j-keer...@ti.com: changed the DT node property names to follow the
convention]
Signed-off-by: J Keerthy
---
Documentation/devicetree/bindings/mfd/palmas.txt | 67 ++
1 files changed, 67 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mfd/palmas.txt
diff --git a/Documentation/devicetree/bindings/mfd/palmas.txt
b/Documentation/devicetree/bindings/mfd/palmas.txt
new file mode 100644
index 000..5fa922e
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/palmas.txt
@@ -0,0 +1,67 @@
+Texas Instruments Palmas family
+
+The Palmas familly are Integrated Power Management Chips.
+These chips are connected to an i2c bus.
+
+
+Required properties:
+- compatible : Must be "ti,palmas";
+ For Integrated power-management in the palmas series, twl6035, twl6037,
+ tps65913
+- interrupts : This i2c device has an IRQ line connected to the main SoC
+- interrupt-controller : Since the palmas support several interrupts
internally,
+ it is considered as an interrupt controller cascaded to the SoC one.
+- #interrupt-cells = <1>;
+- interrupt-parent : The parent interrupt controller.
+
+Optional node:
+- Child nodes contain in the palmas. The palmas family is made of several
+ variants that support a different number of features.
+ The child nodes will thus depend of the capability of the variant.
+- mux-pad1 if a value is given it will be used for the pad1 mux
+- mux-pad2 if a value us given it will be used for the pad2 mux
+- power-ctrl if a value is given it will be written to the POWER_CTRL register
+
+Example:
+/*
+ * Integrated Power Management Chip Palmas
+ */
+palmas@48 {
+compatible = "ti,palmas";
+reg = <0x48>;
+interrupts = <39>; /* IRQ_SYS_1N cascaded to gic */
+interrupt-controller;
+#interrupt-cells = <1>;
+interrupt-parent = <&gic>;
+#address-cells = <1>;
+#size-cells = <0>;
+
+ ti,mux-pad1 = <0x00>;
+ ti,mux-pad2 = <0x00>;
+ ti,power-ctrl = <0x03>;
+
+ palmas_pmic {
+ compatible = "ti,palmas_pmic";
+ regulators {
+ smps12_reg: smps12 {
+ regulator-min-microvolt = < 60>;
+regulator-max-microvolt = <150>;
+ regulator-always-on;
+ regulator-boot-on;
+ti,warm-sleep = <0>;
+ti,roof-floor = <0>;
+ti,mode-sleep = <0>;
+ti,warm-reset = <0>;
+ti,tstep = <0>;
+ti,vsel = <0>;
+ };
+ };
+ ti,ldo6-vibrator = <0>;
+ };
+
+palmas_rtc {
+compatible = "ti,palmas_rtc";
+interrupts = <8 9>;
+reg = <0>;
+};
+};
--
1.7.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 4/4] regulator: palmas: Change the DT node property names to follow the convention
Hi Mark, > -Original Message- > From: Mark Brown [mailto:broo...@opensource.wolfsonmicro.com] > Sent: Wednesday, February 20, 2013 1:43 AM > To: J, KEERTHY > Cc: lgirdw...@gmail.com; linux-kernel@vger.kernel.org; > g...@slimlogic.co.uk > Subject: Re: [PATCH 4/4] regulator: palmas: Change the DT node property > names to follow the convention > > On Tue, Feb 19, 2013 at 05:10:01PM +, J, KEERTHY wrote: > > > > This must need an update to the binding document too, and probably > > > any DT files that ended up getting merged for it? > > > I have sent a patch with the document update. That is the first patch > > in The series. > > You sent the patches as unthreaded mails and didn't CC me on the first > patch so I've not actually seen the documentation. Incremental updates > like this really ought to be done as part of a single patch anyway, > there's no point in splitting things up and as we've just seen it can > make it harder to review. Extremely sorry about that. I am resending the Patch 1. Regards, Keerthy -- 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] iommu: making IOMMU sysfs nodes API public
On Wed, 2013-02-20 at 13:31 +1100, Alexey Kardashevskiy wrote:
> On 20/02/13 07:11, Alex Williamson wrote:
> > On Tue, 2013-02-19 at 18:38 +1100, David Gibson wrote:
> >> On Mon, Feb 18, 2013 at 10:24:00PM -0700, Alex Williamson wrote:
> >>> On Mon, 2013-02-18 at 17:15 +1100, Alexey Kardashevskiy wrote:
> On 13/02/13 04:15, Alex Williamson wrote:
> > On Wed, 2013-02-13 at 01:42 +1100, Alexey Kardashevskiy wrote:
> >> On 12/02/13 16:07, Alex Williamson wrote:
> >>> On Tue, 2013-02-12 at 15:06 +1100, Alexey Kardashevskiy wrote:
> Having this patch in a tree, adding new nodes in sysfs
> for IOMMU groups is going to be easier.
>
> The first candidate for this change is a "dma-window-size"
> property which tells a size of a DMA window of the specific
> IOMMU group which can be used later for locked pages accounting.
> >>>
> >>> I'm still churning on this one; I'm nervous this would basically creat
> >>> a /proc free-for-all under /sys/kernel/iommu_group/$GROUP/ where any
> >>> iommu driver can add random attributes. That can get ugly for
> >>> userspace.
> >>
> >> Is not it exactly what sysfs is for (unlike /proc)? :)
> >
> > Um, I hope it's a little more thought out than /proc.
> >
> >>> On the other hand, for the application of userspace knowing how much
> >>> memory to lock for vfio use of a group, it's an appealing location to
> >>> get that information. Something like libvirt would already be poking
> >>> around here to figure out which devices to bind. Page limits need to
> >>> be
> >>> setup prior to use through vfio, so sysfs is more convenient than
> >>> through vfio ioctls.
> >>
> >> True. DMA window properties do not change since boot so sysfs is the
> >> right
> >> place to expose them.
> >>
> >>> But then is dma-window-size just a vfio requirement leaking over into
> >>> iommu groups? Can we allow iommu driver based attributes without
> >>> giving
> >>> up control of the namespace? Thanks,
> >>
> >> Who are you asking these questions? :)
> >
> > Anyone, including you. Rather than dropping misc files in sysfs to
> > describe things about the group, I think the better solution in your
> > case might be a link from the group to an existing sysfs directory
> > describing the PE. I believe your PE is rooted in a PCI bridge, so that
> > presumably already has a representation in sysfs. Can the aperture size
> > be determined from something in sysfs for that bridge already? I'm just
> > not ready to create a grab bag of sysfs entries for a group yet.
> > Thanks,
>
>
> At the moment there is no information neither in sysfs nor
> /proc/device-tree about the dma-window. And adding a sysfs entry per PE
> (powerpc partitionable end-point which is often a PHB but not always)
> just
> for VFIO is quite heavy.
> >>>
> >>> How do you learn the window size and PE extents in the host kernel?
> >>>
> We could add a ppc64 subfolder under /sys/kernel/iommu/xxx/ and put the
> "dma-window" property there. And replace it with a symlink when and if we
> add something for PE later. Would work?
> >>
> >> Fwiw, I'd suggest a subfolder named for the type of IOMMU, rather than
> >> "ppc64".
> >>
> >>> To be clear, you're suggesting /sys/kernel/iommu_groups/$GROUP/xxx/,
> >>> right? A subfolder really only limits the scope of the mess, so it's
> >>> not much improvement. What does the interface look like to make those
> >>> subfolders?
> >>>
> >>> The problem we're trying to solve is this call flow:
> >>>
> >>> containerfd = open("/dev/vfio/vfio");
> >>> ioctl(containerfd, VFIO_GET_API_VERSION);
> >>> ioctl(containerfd, VFIO_CHECK_EXTENSION, ...);
> >>> groupfd = open("/dev/vfio/$GROUP");
> >>> ioctl(groupfd, VFIO_GROUP_GET_STATUS);
> >>> ioctl(groupfd, VFIO_GROUP_SET_CONTAINER, &containerfd);
> >>>
> >>> You wanted to lock all the memory for the DMA window here, before we can
> >>> call VFIO_IOMMU_GET_INFO, but does it need to happen there? We still
> >>> have a MAP_DMA hook. We could do it all on the first mapping.
> >>
> >> MAP_DMA isn't quite enough, since the guest can also directly cause
> >> mappings using hypercalls directly implemented in KVM. I think it
> >> would be feasible to lock on the first mapping (either via MAP_DMA, or
> >> H_PUT_TCE) though it would be a bit ugly and require that the first
> >> H_PUT_TCE always bounce out to virtual mode (Alexey, correct me if I'm
> >> wrong here). IIRC there is also a call to bind the vfio container to
> >> a (qemu assigned) LIOBN, before the guest can use H_PUT_TCE directly,
> >> so that might be another place we could do the lock.
> >
> > Somehow hypercall mappings have to be gated by the userspace setup,
> > right?
>
>
> There is a KVM ioctl (and a KVM capability) which hooks LIOBN (PCI
Re: [PATCH 7/7] ACPI / scan: Make memory hotplug driver use struct acpi_scan_handler
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. From: Vasilis Liaskovitis Date: Tue, 19 Feb 2013 18:36:25 +0100 Subject: [RFC PATCH] acpi / memory-hotplug: implement phys_device In order for userspace to know which memblocks in: /sys/devices/system/memory/memoryXX correspond to which acpi memory devices in: /sys/devices/LNXSYSTM:00/LNXSYSBUS:00/PNP0C80:YY, /sys/devices/system/memory/memoryXX/phys_device should return a name (or index YY) of the memory device each memblock XX belongs to. WIth this patch, the acpi mem_hotplug driver keeps a global list of acpi memory devices (inserted in hotplug_order). The base memory driver checks against this list in arch_get_memory_phys_device to determine the zero-based index of the physical memory device each new memblock belongs to. For initial memory or for non-acpi/hotplug enabled systems, phys_device is always -1. Signed-off-by: Vasilis Liaskovitis --- Documentation/ABI/testing/sysfs-devices-memory |8 ++- drivers/acpi/acpi_memhotplug.c | 27 drivers/base/memory.c |7 +- include/linux/acpi.h |2 + 4 files changed, 42 insertions(+), 2 deletions(-) diff --git a/Documentation/ABI/testing/sysfs-devices-memory b/Documentation/ABI/testing/sysfs-devices-memory index 7405de2..290c62a 100644 --- a/Documentation/ABI/testing/sysfs-devices-memory +++ b/Documentation/ABI/testing/sysfs-devices-memory @@ -27,7 +27,13 @@ Contact: Badari Pulavarty Description: The file /sys/devices/system/memory/memoryX/phys_device is read-only and is designed to show the name of physical - memory device. Implementation is currently incomplete. + memory device. Implementation is currently incomplete. In a + system with CONFIG_ACPI_HOTPLUG_MEMORY=n, phys_device is always + -1. In a system with CONFIG_ACPI_HOTPLUG_MEMORY=y, phys_device + is -1 for all initial / non-hot-removable memory. For + memory that has been hot-plugged, phys_device will return the + zero-based index of the physical device that this memory block + belongs to. Indices are determined by hotplug order. What: /sys/devices/system/memory/memoryX/phys_index Date: September 2008 diff --git a/drivers/acpi/acpi_memhotplug.c b/drivers/acpi/acpi_memhotplug.c index 3be9501..4154dc5 100644
[PATCH 5/5] HID: Correct Logitech order in hid-ids.h
Reorders a couple of device IDs (Logitech controllers) to ensure that they are in hexidecimal order. Signed-off-by: Simon Wood --- drivers/hid/hid-ids.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h index 34e2547..865492c 100644 --- a/drivers/hid/hid-ids.h +++ b/drivers/hid/hid-ids.h @@ -525,8 +525,8 @@ #define USB_DEVICE_ID_LOGITECH_WINGMAN_F3D 0xc283 #define USB_DEVICE_ID_LOGITECH_FORCE3D_PRO 0xc286 #define USB_DEVICE_ID_LOGITECH_FLIGHT_SYSTEM_G940 0xc287 -#define USB_DEVICE_ID_LOGITECH_WHEEL 0xc294 #define USB_DEVICE_ID_LOGITECH_WINGMAN_FFG 0xc293 +#define USB_DEVICE_ID_LOGITECH_WHEEL 0xc294 #define USB_DEVICE_ID_LOGITECH_MOMO_WHEEL 0xc295 #define USB_DEVICE_ID_LOGITECH_DFP_WHEEL 0xc298 #define USB_DEVICE_ID_LOGITECH_G25_WHEEL 0xc299 -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/5] HID: LG: Fix detection of Logitech Speed Force Wireless (WiiWheel)
Previously 'LG4FF' was only used for the WiiWheel, however it is now used
for all the Logitech Wheels. This patch corrects the detection mechanism
for the patching the report descriptor to ensure only the WiiWheel will
be patched.
Signed-off-by: Simon Wood
---
drivers/hid/hid-lg.c | 20 +++-
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/drivers/hid/hid-lg.c b/drivers/hid/hid-lg.c
index 160c489..c065598 100644
--- a/drivers/hid/hid-lg.c
+++ b/drivers/hid/hid-lg.c
@@ -242,15 +242,6 @@ static __u8 *lg_report_fixup(struct hid_device *hdev, __u8
*rdesc,
"fixing up rel/abs in Logitech report descriptor\n");
rdesc[33] = rdesc[50] = 0x02;
}
- if ((drv_data->quirks & LG_FF4) && *rsize >= 101 &&
- rdesc[41] == 0x95 && rdesc[42] == 0x0B &&
- rdesc[47] == 0x05 && rdesc[48] == 0x09) {
- hid_info(hdev, "fixing up Logitech Speed Force Wireless button
descriptor\n");
- rdesc[41] = 0x05;
- rdesc[42] = 0x09;
- rdesc[47] = 0x95;
- rdesc[48] = 0x0B;
- }
switch (hdev->product) {
@@ -292,6 +283,17 @@ static __u8 *lg_report_fixup(struct hid_device *hdev, __u8
*rdesc,
*rsize = sizeof(dfp_rdesc_fixed);
}
break;
+
+ case USB_DEVICE_ID_LOGITECH_WII_WHEEL:
+ if (*rsize >= 101 && rdesc[41] == 0x95 && rdesc[42] == 0x0B &&
+ rdesc[47] == 0x05 && rdesc[48] == 0x09) {
+ hid_info(hdev, "fixing up Logitech Speed Force Wireless
report descriptor\n");
+ rdesc[41] = 0x05;
+ rdesc[42] = 0x09;
+ rdesc[47] = 0x95;
+ rdesc[48] = 0x0B;
+ }
+ break;
}
return rdesc;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: False-positive RCU stall warnings on large systems...
On 20/02/2013 02:16, Paul E. McKenney wrote:
On Wed, Feb 20, 2013 at 12:34:12AM +0800, Daniel J Blueman wrote:
Hi Paul,
On some of our larger servers with many hundreds of cores and when
under high duress, we can see scheduler RCU stall warnings [1], so
find we have to increase the hardcoded RCU_STALL_RAT_DELAY up from 2
and RCU_JIFFIES_TILL_FORCE_QS up from 3.
Is there a more sustainable way to account for this to avoid it
being hard-coded, such as making it and dependent timeouts a
fraction of CONFIG_RCU_CPU_STALL_TIMEOUT?
On the other hand, perhaps this is just caused by clock jitter (eg
due to distance from a contended clock source)? So increasing these
a bit may just be adequate in general...
Hmmm... What version of the kernel are you running?
The example below occurs with v3.8, but we see the same with previous
kernels eg v3.5.
Of course, when using the local TSC, you'd see no jitter relative to
coherent transactions (eg memory writes), but when the HPET is used
across a large system, coherent transactions to distant cores are just
so much faster, as there's massive congestion to the shared HPET behind
various HT and PCIe bridges. This could be where the jitter arises from,
if I'm guessing jitter is the problem here.
Thanks,
Daniel
--- [1]
[ 3939.010085] INFO: rcu_sched detected stalls on CPUs/tasks: {}
(detected by 1, t=29662 jiffies, g=3053, c=3052, q=598)
[ 3939.020008] INFO: Stall ended before state dump start
--
Daniel J Blueman
Principal Software Engineer, Numascale Asia
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/5] HID: LG: Add support for Logitech Momo Force (Red) Wheel
This patch provides a modified report descriptor to split accelerator
and brake, and adds the 'NO_GET' flag to prevent it hanging on
connection.
Note: for convience this patch is against the follow patch which was applied
earlier this week.
https://patchwork.kernel.org/patch/2153471/
Signed-off-by: Simon Wood
---
drivers/hid/hid-lg.c | 58 +-
1 file changed, 57 insertions(+), 1 deletion(-)
diff --git a/drivers/hid/hid-lg.c b/drivers/hid/hid-lg.c
index 6bb7f05..160c489 100644
--- a/drivers/hid/hid-lg.c
+++ b/drivers/hid/hid-lg.c
@@ -45,6 +45,7 @@
/* Size of the original descriptors of the Driving Force (and Pro) wheels */
#define DF_RDESC_ORIG_SIZE 130
#define DFP_RDESC_ORIG_SIZE97
+#define MOMO_RDESC_ORIG_SIZE 87
/* Fixed report descriptors for Logitech Driving Force (and Pro)
* wheel controllers
@@ -169,6 +170,52 @@ static __u8 dfp_rdesc_fixed[] = {
0xC0/* End Collection */
};
+static __u8 momo_rdesc_fixed[] = {
+0x05, 0x01, /* Usage Page (Desktop), */
+0x09, 0x04, /* Usage (Joystik),*/
+0xA1, 0x01, /* Collection (Application), */
+0xA1, 0x02, /* Collection (Logical), */
+0x95, 0x01, /* Report Count (1), */
+0x75, 0x0A, /* Report Size (10), */
+0x15, 0x00, /* Logical Minimum (0),*/
+0x26, 0xFF, 0x03, /* Logical Maximum (1023), */
+0x35, 0x00, /* Physical Minimum (0), */
+0x46, 0xFF, 0x03, /* Physical Maximum (1023),*/
+0x09, 0x30, /* Usage (X), */
+0x81, 0x02, /* Input (Variable), */
+0x95, 0x08, /* Report Count (8), */
+0x75, 0x01, /* Report Size (1),*/
+0x25, 0x01, /* Logical Maximum (1),*/
+0x45, 0x01, /* Physical Maximum (1), */
+0x05, 0x09, /* Usage Page (Button),*/
+0x19, 0x01, /* Usage Minimum (01h),*/
+0x29, 0x08, /* Usage Maximum (08h),*/
+0x81, 0x02, /* Input (Variable), */
+0x06, 0x00, 0xFF, /* Usage Page (FF00h), */
+0x75, 0x0E, /* Report Size (14), */
+0x95, 0x01, /* Report Count (1), */
+0x26, 0xFF, 0x00, /* Logical Maximum (255), */
+0x46, 0xFF, 0x00, /* Physical Maximum (255), */
+0x09, 0x00, /* Usage (00h),*/
+0x81, 0x02, /* Input (Variable), */
+0x05, 0x01, /* Usage Page (Desktop), */
+0x75, 0x08, /* Report Size (8),*/
+0x09, 0x31, /* Usage (Y), */
+0x81, 0x02, /* Input (Variable), */
+0x09, 0x32, /* Usage (Z), */
+0x81, 0x02, /* Input (Variable), */
+0x06, 0x00, 0xFF, /* Usage Page (FF00h), */
+0x09, 0x01, /* Usage (01h),*/
+0x81, 0x02, /* Input (Variable), */
+0xC0, /* End Collection, */
+0xA1, 0x02, /* Collection (Logical), */
+0x09, 0x02, /* Usage (02h),*/
+0x95, 0x07, /* Report Count (7), */
+0x91, 0x02, /* Output (Variable), */
+0xC0, /* End Collection, */
+0xC0/* End Collection */
+};
+
/*
* Certain Logitech keyboards send in report #3 keys which are far
* above the logical maximum described in descriptor. This extends
@@ -228,6 +275,15 @@ static __u8 *lg_report_fixup(struct hid_device *hdev, __u8
*rdesc,
}
break;
+ case USB_DEVICE_ID_LOGITECH_MOMO_WHEEL:
+ if (*rsize == MOMO_RDESC_ORIG_SIZE) {
+ hid_info(hdev,
+ "fixing up Logitech Momo Force (Red) report
descriptor\n");
+ rdesc = momo_rdesc_fixed;
+ *rsize = sizeof(momo_rdesc_fixed);
+ }
+ break;
+
case USB_DEVICE_ID_LOGITECH_DFP_WHEEL:
if (*rsize == DFP_RDESC_ORIG_SIZE) {
hid_info(hdev,
@@ -558,7 +614,7 @@ static const struct hid_device_id lg_devices[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH,
USB_DEVICE_ID_LOGITECH_FORCE3D_PRO),
.driver_data = LG_FF },
{ HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH,
USB_DEVICE_ID_LOGITECH_MOMO_WHEEL),
- .driver_data = LG_FF4 },
+ .driver_data = LG_NOGET | LG_FF4 },
{ HID_USB_DEV
[PATCH 4/5] HID: LG4FF: Remove unnecessary deadzone code
This patch removes code which is now unnecessary for setting the fuzz/flat
characterics for the logitech DFP wheel. This is now done in the previous
patch by marking the wheel as a multi-axis device.
Signed-off-by: Simon Wood
---
drivers/hid/hid-lg4ff.c | 17 -
1 file changed, 17 deletions(-)
diff --git a/drivers/hid/hid-lg4ff.c b/drivers/hid/hid-lg4ff.c
index d7947c7..65a6ec8 100644
--- a/drivers/hid/hid-lg4ff.c
+++ b/drivers/hid/hid-lg4ff.c
@@ -43,11 +43,6 @@
#define G27_REV_MAJ 0x12
#define G27_REV_MIN 0x38
-#define DFP_X_MIN 0
-#define DFP_X_MAX 16383
-#define DFP_PEDAL_MIN 0
-#define DFP_PEDAL_MAX 255
-
#define to_hid_device(pdev) container_of(pdev, struct hid_device, dev)
static void hid_lg4ff_set_range_dfp(struct hid_device *hid, u16 range);
@@ -598,18 +593,6 @@ int lg4ff_init(struct hid_device *hid)
return error;
dbg_hid("sysfs interface created\n");
- /* Set default axes parameters */
- switch (lg4ff_devices[i].product_id) {
- case USB_DEVICE_ID_LOGITECH_DFP_WHEEL:
- dbg_hid("Setting axes parameters for Driving Force Pro\n");
- input_set_abs_params(dev, ABS_X, DFP_X_MIN, DFP_X_MAX, 0, 0);
- input_set_abs_params(dev, ABS_Y, DFP_PEDAL_MIN, DFP_PEDAL_MAX,
0, 0);
- input_set_abs_params(dev, ABS_RZ, DFP_PEDAL_MIN, DFP_PEDAL_MAX,
0, 0);
- break;
- default:
- break;
- }
-
/* Set the maximum range to start with */
entry->range = entry->max_range;
if (entry->set_range != NULL)
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/5] HID: LG: Prevent the Logitech Gaming Wheels deadzone
This patch ensures that the Logitech wheels are not initialised with
default fuzz/flat values, by marking them as multiaxis devices (rather
than joysticks).
Signed-off-by: Simon Wood
---
drivers/hid/hid-lg.c | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/hid/hid-lg.c b/drivers/hid/hid-lg.c
index c065598..5d3c861 100644
--- a/drivers/hid/hid-lg.c
+++ b/drivers/hid/hid-lg.c
@@ -479,6 +479,26 @@ static int lg_input_mapped(struct hid_device *hdev, struct
hid_input *hi,
usage->type == EV_REL || usage->type == EV_ABS))
clear_bit(usage->code, *bit);
+ /* Ensure that Logitech wheels are not given a default fuzz/flat value
*/
+ if (usage->type == EV_ABS && (usage->code == ABS_X ||
+ usage->code == ABS_Y || usage->code == ABS_Z ||
+ usage->code == ABS_RZ)) {
+ switch (hdev->product) {
+ case USB_DEVICE_ID_LOGITECH_WHEEL:
+ case USB_DEVICE_ID_LOGITECH_MOMO_WHEEL:
+ case USB_DEVICE_ID_LOGITECH_DFP_WHEEL:
+ case USB_DEVICE_ID_LOGITECH_G25_WHEEL:
+ case USB_DEVICE_ID_LOGITECH_DFGT_WHEEL:
+ case USB_DEVICE_ID_LOGITECH_G27_WHEEL:
+ case USB_DEVICE_ID_LOGITECH_WII_WHEEL:
+ case USB_DEVICE_ID_LOGITECH_MOMO_WHEEL2:
+ field->application = HID_GD_MULTIAXIS;
+ break;
+ default:
+ break;
+ }
+ }
+
return 0;
}
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [ 0/1] 3.4.33-stable review
On Tue, Feb 19, 2013 at 7:51 PM, Greg Kroah-Hartman wrote: > On Mon, Feb 18, 2013 at 07:50:16PM -0700, Shuah Khan wrote: >> On Mon, Feb 18, 2013 at 11:24 AM, Greg Kroah-Hartman >> wrote: >> > This is the start of the stable review cycle for the 3.4.33 release. >> > There is 1 patch in this series, which will be posted as a response to >> > this one. If anyone has any issues with it being applied, please let me >> > know. >> > >> > Responses should be made by Wed Feb 20 18:13:44 UTC 2013. >> > Anything received after that time might be too late. >> > >> > The whole patch series can be found in one patch at: >> > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.4.33-rc1.gz >> > and the diffstat can be found below. >> > >> > thanks, >> > >> > greg k-h >> > >> > - >> >> Patches applied cleanly to 3.0.65, and 3.4.32 >> Compiled and booted on the following systems: >> HP EliteBook 6930p Intel(R) Core(TM)2 Duo CPU T9400 @ 2.53GHz >> HP ProBook 6475b AMD A10-4600M APU with Radeon(tm) HD Graphics >> >> Reviewed patches >> >> Skipped Cross-compile tests > > Thanks for testing, your kernel log messages looked correct, right? > > greg k-h Yes, should have mentioned that I checked dmesg and syslog both and compared dmesg with the old dmesg I saved from the previous rc-1 testing for each of these releases. Didn't see anything that jumped out at me. I usually save dmesg from rc cycles to look for regressions if any from one rc cycle to the next. -- Shuah -- 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: WARNING: at kernel/mutex.c:386 __mutex_lock_common()
> > [0.00] > > [0.00] [ cut here ] > > [0.00] WARNING: at /c/kernel-tests/src/tip/kernel/mutex.c:386 > > __mutex_lock_common+0x5a9/0x870() > > [0.00] Hardware name: Bochs > > [0.00] Modules linked in: > > [0.00] Pid: 0, comm: swapper/0 Not tainted 3.8.0-rc7-00071-g11eb5a2 > > #180 > > [0.00] Call Trace: > > [0.00] [] warn_slowpath_common+0xb2/0x120 > > [0.00] [] warn_slowpath_null+0x25/0x30 > > [0.00] [] __mutex_lock_common+0x5a9/0x870 > > [0.00] [] ? rcu_cpu_notify+0xa8/0x451 > > [0.00] [] ? trace_hardirqs_off_caller+0xaf/0x120 > > [0.00] [] ? rcu_cpu_notify+0xa8/0x451 > > [0.00] [] ? lockdep_init_map+0xfc/0x230 > > [0.00] [] mutex_lock_nested+0x61/0x80 > > [0.00] [] ? trace_hardirqs_off+0x1d/0x30 > > [0.00] [] rcu_cpu_notify+0xa8/0x451 > > [0.00] [] ? mutex_unlock+0x11/0x20 > > [0.00] [] rcu_init+0x3b3/0x408 > > [0.00] [] start_kernel+0x34a/0x744 > > [0.00] [] ? repair_env_string+0x81/0x81 > > [0.00] [] ? early_idt_handlers+0x120/0x120 > > [0.00] [] x86_64_start_reservations+0x185/0x190 > > [0.00] [] x86_64_start_kernel+0x1a0/0x1b6 > > [0.00] ---[ end trace 8e966724b1809892 ]--- > Weird, that code path should not be hit from __mutex_lock_common from > mutex_lock_nested, I'll create a patch with some tests to make sure > that lib/locking-selftests.c will perform tests on common mutexes to > ensure that code path is not hit, and this bug will not happen again. > > Can you change __mutex_lock_common from inline to __always_inline and > check if that gets rid of the warning? Maarten, that trick worked! Thanks! Fengguang -- 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, 19 Feb 2013, Kim Phillips wrote: > On Fri, 8 Feb 2013 22:16:47 -0500 > Nicolas Pitre wrote: > > > Not only that, but in many cases the results are wildly different given > > the same config: > > > > > imx_v6_v7_defconfig: 7637605 7636935 -670 > > > lart_defconfig: 2922550 2926600 4050 > > > mxs_defconfig:1107113911070893-246 > > > > The mxs_defconfig became much better while lart_defconfig regressed a > > lot. > > > > > Haven't looked at why. > > > > Would be a good idea since this is rather weird and gcc could benefit > > from your findings. > > The following is next-20130207 built with Linaro gcc 4.7.1 [1], and > before and after the diff at the bottom of this email (and with > normalized linux version string sizes): > > lart_defconfig: 2752106 120864 56444 2929414 2cb306 vmlinux > lart_defconfig: 2756092 120864 56444 2933400 2cc298 vmlinux > #builtin-bswap > > mxs_defconfig:5229115 280572 5569648 11079335 a90ea7 vmlinux > mxs_defconfig:5228969 280552 5569648 11079169 a90e01 vmlinux > #builtin-bswap > > imx_v6_v7_defconfig: 6935025 356172 360648 7651845 74c205 vmlinux > imx_v6_v7_defconfig: 6934091 356180 360648 7650919 74be67 vmlinux > #builtin-bswap > > > so builtin-bswap improved mxs and imx_v6_v7 but in lart, it _added_ > 3986 bytes to .text -> not good. > > Getting a closer look at lart, bloat-o-meter says the code actually > shrunk: > > add/remove: 7/1 grow/shrink: 11/19 up/down: 298/-356 (-58) > function old new delta > inet_abc_len - 96 +96 > __bswapdi2 - 52 +52 > __bswapsi2 - 32 +32 > icmp_unreach 472 492 +20 > xfrm_selector_match 9881000 +12 > fib_table_insert21762188 +12 > __kstrtab___bswapsi2 - 11 +11 > __kstrtab___bswapdi2 - 11 +11 > __ksymtab___bswapsi2 - 8 +8 > __ksymtab___bswapdi2 - 8 +8 > vermagic 51 57 +6 > linux_banner 230 236 +6 > xfrm_replay_check_esn320 324 +4 > xfrm_replay_check_bmp200 204 +4 > xfrm_replay_check152 156 +4 > static.tcp_parse_aligned_timestamp80 84 +4 > fib_table_delete 708 712 +4 > cookie_v4_check 13161320 +4 > tcp_tso_segment 728 724 -4 > tcp_options_write724 720 -4 > ip_rt_ioctl 11521148 -4 > fib_trie_seq_show724 720 -4 > crc32_be 448 444 -4 > xfrm_stateonly_find 640 632 -8 > tcp_finish_connect 276 268 -8 > static.tcp_v4_send_ack 480 472 -8 > __xfrm_state_lookup 356 348 -8 > __xfrm_state_bump_genids 436 428 -8 > __find_acq_core 12561248 -8 > cookie_v4_init_sequence 272 260 -12 > __xfrm_state_insert 616 600 -16 > sys_swapon 25002480 -20 > xfrm_state_find 24202396 -24 > xfrm_hash_resize16201596 -24 > fib_route_seq_show 560 536 -24 > fib_table_dump 704 676 -28 > devinet_ioctl 18561796 -60 > static.inet_abc_len 80 - -80 > > Comparing System.maps, .rodata starts at the same address: > > c020a000 R __start_rodata > c020a000 R __start_rodata #builtin-bswap > > however, changes including the __bswap[sd]i2 implementation pushes > the .rodata section size just over the 4KiB alignment boundary > specified in arm/kernel/vmlinux.lds: > > no builtin_bswap: > > c028ffc4 R __stop___modver > c029 R __end_rodata > c029 R __start___ex_table > > with builtin_bswap: > > c0290068 R __stop___modver > c0291000 R __end_rodata > c0291000 R __start___ex_table > > So, AFAICT, that's why we see a total increase in .text for lart, > and, looking at both numbers being a little less than 4KiB, I > suspect the same with whatever happened with mxs above. OK. At least we do have a plausible explanation now. The act
