Re: [PATCH 1/3] usb: ohci-exynos: Make provision for vdd regulators
On Thursday, April 24, 2014 3:40 PM, Vivek Gautam wrote:
> On Thu, Apr 24, 2014 at 6:56 AM, Jingoo Han wrote:
> > On Thursday, April 24, 2014 9:33 AM, Jingoo Han wrote:
> >> On Thursday, April 24, 2014 9:18 AM, Anton Tikhomirov wrote:
> >> > On Monday, April 21, 2014 9:17 PM, Vivek Gautam wrote:
> >> > >
> >> > > Facilitate getting required 3.3V and 1.0V VDD supply for
> >> > > OHCI controller on Exynos.
> >> > >
> >> > > With patches for regulators' nodes merged in 3.15:
> >> > > c8c253f ARM: dts: Add regulator entries to smdk5420
> >> > > 275dcd2 ARM: dts: add max77686 pmic node for smdk5250,
> >> > >
> >> > > certain perripherals will now need to ensure that,
> >> > > they request VDD regulators in their drivers, and enable
> >> > > them so as to make them working.
> >> > >
> >> > > Signed-off-by: Vivek Gautam
> >> > > Cc: Jingoo Han
> >> > > ---
> >> > >
> >> > > Based on 'usb-next' branch of Greg's usb tree.
> >> > >
> >> > > drivers/usb/host/ohci-exynos.c | 47
> >> > >
> >> > > 1 file changed, 47 insertions(+)
> >> > >
> >> > > diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-
> >> > > exynos.c
> >> > > index 68588d8..e2e72a8 100644
> >> > > --- a/drivers/usb/host/ohci-exynos.c
> >> > > +++ b/drivers/usb/host/ohci-exynos.c
>
> [snip]
>
> >> > > @@ -98,6 +101,28 @@ static int exynos_ohci_probe(struct platform_device
> >> > > *pdev)
> >> > > exynos_ohci->otg = phy->otg;
> >> > > }
> >> > >
> >> > > + exynos_ohci->vdd33 = devm_regulator_get(&pdev->dev, "vdd33");
> >> > > + if (IS_ERR(exynos_ohci->vdd33)) {
> >> > > + err = PTR_ERR(exynos_ohci->vdd33);
> >> > > + goto fail_regulator1;
> >> > > + }
> >> > > + err = regulator_enable(exynos_ohci->vdd33);
> >> > > + if (err) {
> >> > > + dev_err(&pdev->dev, "Failed to enable VDD33 supply\n");
> >> > > + goto fail_regulator1;
> >> > > + }
> >> > > +
> >> > > + exynos_ohci->vdd10 = devm_regulator_get(&pdev->dev, "vdd10");
> >> > > + if (IS_ERR(exynos_ohci->vdd10)) {
> >> > > + err = PTR_ERR(exynos_ohci->vdd10);
> >> > > + goto fail_regulator2;
> >> > > + }
> >> > > + err = regulator_enable(exynos_ohci->vdd10);
> >> > > + if (err) {
> >> > > + dev_err(&pdev->dev, "Failed to enable VDD10 supply\n");
> >> > > + goto fail_regulator2;
> >> > > + }
> >> > > +
> >> >
> >> > Do we need to skip regulator settings together with PHY configuration
> >> > in case of exynos5440?
> >>
> >> Oh, right. In the case of exynos5440, regulator settings is not
> >> necessary. Vivek, would you fix it in order skip regulator settings
> >> in exynos5440? It also applies to ehci-exynos.
> >
> > Sorry, in the case of exynos5440, this patch already skips
> > regulator settings.
> >
> > In the case of exynos5440, there is no need to set PHY setting
> > and regulator setting.
>
> Right, in case of exynos5440, we are skipping PHY setting and regulator
> setting.
> Actually i had missed taking into account 5440, so just curious. Do we
> really not need a regulator
> settings for Exynos5440 ?
To be more specific, there is no regulator on ssdk5440 board
which is the Exynos5440-based board.
Best regards,
Jingoo Han
> > How about making regulator setting "optional"?
> > Then, regulator setting can be done, only when regulator
> > is supported.
>
> True, so with Exynos5440 not needing the regulator, we should make the
> regulator settings optional.
[.]
> Thanks for the suggestion.
> I will make the required changes, and post the patchset again.
OK, I see.
Thank you for accepting my suggestion.
Best regards,
Jingoo Han
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: extcon-next regression ?
Hi, On Thu, Apr 24, 2014 at 02:35:44PM +0900, Chanwoo Choi wrote: > Hi Felipe, > > Thanks for your test and review. > > On 04/24/2014 03:28 AM, Felipe Balbi wrote: > > Hi, > > > > On Wed, Apr 23, 2014 at 12:20:52PM -0500, Felipe Balbi wrote: > >>> I've been testing extcon-next to make sure USB3 on OMAP5 will work out > >>> of the box but I see a regression when I merge your tree on top of > >>> v3.15-rc2 + Tony's DT fixes. > >>> > >>> Here's what I see (trimmed): > >>> > >>> [1.805870] palmas 0-0048: Muxing GPIO 2, PWM 0, LED 0 > >>> [1.812516] [ cut here ] > >>> [1.817387] WARNING: CPU: 0 PID: 6 at include/linux/kref.h:47 > >>> kobject_get+0x64/0x78() > >>> [1.817691] mmcblk0boot1: unknown partition table > >>> [1.830601] Modules linked in: > >>> [1.833827] CPU: 0 PID: 6 Comm: kworker/u4:0 Tainted: GW > >>> 3.15.0-rc2-00041-g3019b77 #308 > >>> [1.84] Workqueue: deferwq deferred_probe_work_func > >>> [1.848728] mmcblk0boot0: unknown partition table > >>> [1.853928] [] (unwind_backtrace) from [] > >>> (show_stack+0x10/0x14) > >>> [1.862086] [] (show_stack) from [] > >>> (dump_stack+0x84/0x9c) > >>> [1.869667] [] (dump_stack) from [] > >>> (warn_slowpath_common+0x6c/0x90) > >>> [1.878181] [] (warn_slowpath_common) from [] > >>> (warn_slowpath_null+0x1c/0x24) > >>> [1.887421] [] (warn_slowpath_null) from [] > >>> (kobject_get+0x64/0x78) > >>> [1.895837] [] (kobject_get) from [] > >>> (device_add+0x18/0x520) > >>> [1.903629] [] (device_add) from [] > >>> (extcon_dev_register+0x48/0x104) > >>> [1.912145] [] (extcon_dev_register) from [] > >>> (devm_extcon_dev_register+0x2c/0x68) > >>> [1.921847] [] (devm_extcon_dev_register) from [] > >>> (palmas_usb_probe+0x110/0x304) > >>> [1.931453] [] (palmas_usb_probe) from [] > >>> (platform_drv_probe+0x18/0x48) > >>> [1.940333] [] (platform_drv_probe) from [] > >>> (driver_probe_device+0x110/0x22c) > >>> [1.949664] [] (driver_probe_device) from [] > >>> (bus_for_each_drv+0x58/0x8c) > >>> [1.958634] [] (bus_for_each_drv) from [] > >>> (device_attach+0x74/0x8c) > >>> [1.967003] [] (device_attach) from [] > >>> (bus_probe_device+0x88/0xb0) > >>> [1.975387] [] (bus_probe_device) from [] > >>> (device_add+0x420/0x520) > >>> [1.983678] [] (device_add) from [] > >>> (of_platform_device_create_pdata+0x6c/0x8c) > >>> [1.993155] [] (of_platform_device_create_pdata) from > >>> [] (of_platform_bus_create+0xdc/0x168) > >>> [2.003818] [] (of_platform_bus_create) from [] > >>> (of_platform_populate+0x5c/0xa0) > >>> [2.013399] [] (of_platform_populate) from [] > >>> (palmas_i2c_probe+0x30c/0x584) > >>> [2.022606] [] (palmas_i2c_probe) from [] > >>> (driver_probe_device+0x110/0x22c) > >>> [2.031722] [] (driver_probe_device) from [] > >>> (bus_for_each_drv+0x58/0x8c) > >>> [2.040715] [] (bus_for_each_drv) from [] > >>> (device_attach+0x74/0x8c) > >>> [2.049098] [] (device_attach) from [] > >>> (bus_probe_device+0x88/0xb0) > >>> [2.057482] [] (bus_probe_device) from [] > >>> (device_add+0x420/0x520) > >>> [2.065774] [] (device_add) from [] > >>> (i2c_new_device+0x12c/0x18c) > >>> [2.073885] [] (i2c_new_device) from [] > >>> (i2c_register_adapter+0x278/0x498) > >>> [2.082903] [] (i2c_register_adapter) from [] > >>> (omap_i2c_probe+0x4a4/0x6d0) > >>> [2.091925] [] (omap_i2c_probe) from [] > >>> (platform_drv_probe+0x18/0x48) > >>> [2.100582] [] (platform_drv_probe) from [] > >>> (driver_probe_device+0x110/0x22c) > >>> [2.109883] [] (driver_probe_device) from [] > >>> (bus_for_each_drv+0x58/0x8c) > >>> [2.118823] [] (bus_for_each_drv) from [] > >>> (device_attach+0x74/0x8c) > >>> [2.127194] [] (device_attach) from [] > >>> (bus_probe_device+0x88/0xb0) > >>> [2.135584] [] (bus_probe_device) from [] > >>> (deferred_probe_work_func+0x64/0x94) > >>> [2.144975] [] (deferred_probe_work_func) from [] > >>> (process_one_work+0x1ac/0x4cc) > >>> [2.154545] [] (process_one_work) from [] > >>> (worker_thread+0x114/0x3b4) > >>> [2.163119] [] (worker_thread) from [] > >>> (kthread+0xd4/0xf0) > >>> [2.170695] [] (kthread) from [] > >>> (ret_from_fork+0x14/0x2c) > >>> [2.178259] ---[ end trace 3006de6450234d28 ]--- > >>> [2.183081] kobject 'palmas_usb' (eca58c38): tried to add an > >>> uninitialized object, something is seriously wrong. > >>> [2.193731] CPU: 0 PID: 6 Comm: kworker/u4:0 Tainted: GW > >>> 3.15.0-rc2-00041-g3019b77 #308 > >>> [2.203201] Workqueue: deferwq deferred_probe_work_func > >>> [2.208687] [] (unwind_backtrace) from [] > >>> (show_stack+0x10/0x14) > >>> [2.216789] [] (show_stack) from [] > >>> (dump_stack+0x84/0x9c) > >>> [2.224357] [] (dump_stack) from [] > >>> (kobject_add+0x88/0x98) > >>> [2.232014] [] (kobject_add) from [] > >>> (device_add+0xe0/0x520) > >>> [2.239758] [
Re: [GIT PULL 0/4] perf/urgent fixes
* Jiri Olsa wrote: > On Wed, Apr 23, 2014 at 03:14:33PM +0200, Ingo Molnar wrote: > > > > (Just reporting two bugs I found today - unrelated to your the > > perf/urgent pull request.) > > > > 1) > > > > Even when the most modern unwind library is found, the autodetection > > is spammy: > > > > > > Auto-detecting system features: > > ... dwarf: [ on ] > > ... glibc: [ on ] > > ... gtk2: [ on ] > > ... libaudit: [ on ] > > ...libbfd: [ on ] > > ...libelf: [ on ] > > ... libnuma: [ on ] > > ... libperl: [ on ] > > ... libpython: [ on ] > > ... libslang: [ on ] > > ... libunwind: [ on ] > > ...libdw-dwarf-unwind: [ on ] > > ... DWARF post unwind library: libunwind > > > > The 'DWARF post unwind library' line is somewhat superfluous. I > > realize that it prints out the library selected - but that's obvious > > from the 'libdw-dwarf-unwind' line above it already, right? > > > > Furthermore, it breaks the autodetection output format. > > > > 2) > > > > On latest Ubuntu (14.04) the tip:master build fails with: > > > > /usr/bin/ld: cannot find -liberty > > collect2: error: ld returned 1 exit status > > > > The autodetection sequence reports all green entries, so something's > > funky going on there. > > we add -liberty once -lbfd is detected, I guess we > assumed that was common case > > perf tools: fix BFD detection on opensuse > commit 280e7c48c3b873e4987a63da276ecab25383f494 > Author: Andi Kleen > Date: Sat Jan 11 11:42:51 2014 -0800 > > could you please try patch below? it adds that only > if thats detected > > 'make VF=1' should display more status now > > Andi, > could you please try that on opensuse? > > thanks, > jirka > > > --- > diff --git a/tools/perf/config/Makefile b/tools/perf/config/Makefile > index ee21fa9..f511658 100644 > --- a/tools/perf/config/Makefile > +++ b/tools/perf/config/Makefile > @@ -186,7 +186,10 @@ VF_FEATURE_TESTS = \ > stackprotector-all \ > timerfd \ > libunwind-debug-frame \ > - bionic > + bionic \ > + liberty \ > + liberty-z \ > + cplus-demangle In any case, your patch fixes the bug. With VF=1 I get this output: Auto-detecting system features: ... dwarf: [ on ] ... glibc: [ on ] ... gtk2: [ on ] ... libaudit: [ on ] ...libbfd: [ on ] ...libelf: [ on ] ... libnuma: [ on ] ... libperl: [ on ] ... libpython: [ on ] ... libslang: [ on ] ... libunwind: [ on ] ...libdw-dwarf-unwind: [ on ] ... DWARF post unwind library: libunwind ... backtrace: [ on ] ...fortify-source: [ on ] ... gtk2-infobar: [ on ] ... libelf-getphdrnum: [ on ] ... libelf-mmap: [ on ] ... libpython-version: [ on ] ... on-exit: [ on ] ...stackprotector-all: [ on ] ... timerfd: [ on ] ... libunwind-debug-frame: [ OFF ] ...bionic: [ OFF ] ... liberty: [ OFF ] ... liberty-z: [ OFF ] ...cplus-demangle: [ OFF ] So yes, your obervation that it's the -liberty +libbfd combination is correct. Tested-by: Ingo Molnar Btw., when reading the patch and the Makefile it was not obvious to me what 'VF' stood for. It's pretty clear what CORE_FEATURE_TESTS and LIB_FEATURE_TESTS means, but there's no comment for VF_FEATURE_TESTS and the name is not self-explanatory. I figured it out from a bit of git log digging that its purpose is to generate the 'verbose feature check' output. But the variable is not commented and the features it lists overlaps CORE_FEATURE_TESTS and LIB_FEATURE_TESTS - so perhaps a bit more explanation (and possible reduction in duplication) might be useful? If it said ALL_FEATURE_TESTS and used $(CORE_FEATURE_TESTS) as a baseline then that would be self-explanatory. (In a separate patch from the fix.) Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: extcon-next regression ?
Hi, On Thu, Apr 24, 2014 at 02:31:29PM +0900, Chanwoo Choi wrote: > On 04/24/2014 02:20 AM, Felipe Balbi wrote: > > Hi, > > > > On Wed, Apr 23, 2014 at 11:40:33AM -0500, Felipe Balbi wrote: > >> Hi Chanwoo, > >> > >> I've been testing extcon-next to make sure USB3 on OMAP5 will work out > >> of the box but I see a regression when I merge your tree on top of > >> v3.15-rc2 + Tony's DT fixes. > >> > >> Here's what I see (trimmed): > >> > >> [1.805870] palmas 0-0048: Muxing GPIO 2, PWM 0, LED 0 > >> [1.812516] [ cut here ] > >> [1.817387] WARNING: CPU: 0 PID: 6 at include/linux/kref.h:47 > >> kobject_get+0x64/0x78() > >> [1.817691] mmcblk0boot1: unknown partition table > >> [1.830601] Modules linked in: > >> [1.833827] CPU: 0 PID: 6 Comm: kworker/u4:0 Tainted: GW > >> 3.15.0-rc2-00041-g3019b77 #308 > >> [1.84] Workqueue: deferwq deferred_probe_work_func > >> [1.848728] mmcblk0boot0: unknown partition table > >> [1.853928] [] (unwind_backtrace) from [] > >> (show_stack+0x10/0x14) > >> [1.862086] [] (show_stack) from [] > >> (dump_stack+0x84/0x9c) > >> [1.869667] [] (dump_stack) from [] > >> (warn_slowpath_common+0x6c/0x90) > >> [1.878181] [] (warn_slowpath_common) from [] > >> (warn_slowpath_null+0x1c/0x24) > >> [1.887421] [] (warn_slowpath_null) from [] > >> (kobject_get+0x64/0x78) > >> [1.895837] [] (kobject_get) from [] > >> (device_add+0x18/0x520) > >> [1.903629] [] (device_add) from [] > >> (extcon_dev_register+0x48/0x104) > >> [1.912145] [] (extcon_dev_register) from [] > >> (devm_extcon_dev_register+0x2c/0x68) > >> [1.921847] [] (devm_extcon_dev_register) from [] > >> (palmas_usb_probe+0x110/0x304) > >> [1.931453] [] (palmas_usb_probe) from [] > >> (platform_drv_probe+0x18/0x48) > >> [1.940333] [] (platform_drv_probe) from [] > >> (driver_probe_device+0x110/0x22c) > >> [1.949664] [] (driver_probe_device) from [] > >> (bus_for_each_drv+0x58/0x8c) > >> [1.958634] [] (bus_for_each_drv) from [] > >> (device_attach+0x74/0x8c) > >> [1.967003] [] (device_attach) from [] > >> (bus_probe_device+0x88/0xb0) > >> [1.975387] [] (bus_probe_device) from [] > >> (device_add+0x420/0x520) > >> [1.983678] [] (device_add) from [] > >> (of_platform_device_create_pdata+0x6c/0x8c) > >> [1.993155] [] (of_platform_device_create_pdata) from > >> [] (of_platform_bus_create+0xdc/0x168) > >> [2.003818] [] (of_platform_bus_create) from [] > >> (of_platform_populate+0x5c/0xa0) > >> [2.013399] [] (of_platform_populate) from [] > >> (palmas_i2c_probe+0x30c/0x584) > >> [2.022606] [] (palmas_i2c_probe) from [] > >> (driver_probe_device+0x110/0x22c) > >> [2.031722] [] (driver_probe_device) from [] > >> (bus_for_each_drv+0x58/0x8c) > >> [2.040715] [] (bus_for_each_drv) from [] > >> (device_attach+0x74/0x8c) > >> [2.049098] [] (device_attach) from [] > >> (bus_probe_device+0x88/0xb0) > >> [2.057482] [] (bus_probe_device) from [] > >> (device_add+0x420/0x520) > >> [2.065774] [] (device_add) from [] > >> (i2c_new_device+0x12c/0x18c) > >> [2.073885] [] (i2c_new_device) from [] > >> (i2c_register_adapter+0x278/0x498) > >> [2.082903] [] (i2c_register_adapter) from [] > >> (omap_i2c_probe+0x4a4/0x6d0) > >> [2.091925] [] (omap_i2c_probe) from [] > >> (platform_drv_probe+0x18/0x48) > >> [2.100582] [] (platform_drv_probe) from [] > >> (driver_probe_device+0x110/0x22c) > >> [2.109883] [] (driver_probe_device) from [] > >> (bus_for_each_drv+0x58/0x8c) > >> [2.118823] [] (bus_for_each_drv) from [] > >> (device_attach+0x74/0x8c) > >> [2.127194] [] (device_attach) from [] > >> (bus_probe_device+0x88/0xb0) > >> [2.135584] [] (bus_probe_device) from [] > >> (deferred_probe_work_func+0x64/0x94) > >> [2.144975] [] (deferred_probe_work_func) from [] > >> (process_one_work+0x1ac/0x4cc) > >> [2.154545] [] (process_one_work) from [] > >> (worker_thread+0x114/0x3b4) > >> [2.163119] [] (worker_thread) from [] > >> (kthread+0xd4/0xf0) > >> [2.170695] [] (kthread) from [] > >> (ret_from_fork+0x14/0x2c) > >> [2.178259] ---[ end trace 3006de6450234d28 ]--- > >> [2.183081] kobject 'palmas_usb' (eca58c38): tried to add an > >> uninitialized object, something is seriously wrong. > >> [2.193731] CPU: 0 PID: 6 Comm: kworker/u4:0 Tainted: GW > >> 3.15.0-rc2-00041-g3019b77 #308 > >> [2.203201] Workqueue: deferwq deferred_probe_work_func > >> [2.208687] [] (unwind_backtrace) from [] > >> (show_stack+0x10/0x14) > >> [2.216789] [] (show_stack) from [] > >> (dump_stack+0x84/0x9c) > >> [2.224357] [] (dump_stack) from [] > >> (kobject_add+0x88/0x98) > >> [2.232014] [] (kobject_add) from [] > >> (device_add+0xe0/0x520) > >> [2.239758] [] (device_add) from [] > >> (extcon_dev_register+0x48/0x104) > >> [2.248235] [] (extcon_dev_register) from [] > >> (devm_extcon_dev
Re: [PATCH RFC 2/2] ARM: shmobile: armadillo800eva defconfig: Enable REGULATOR_GPIO and LEDS_GPIO
On Wed, Apr 23, 2014 at 9:50 AM, Simon Horman wrote: > On Tue, Apr 22, 2014 at 03:01:07PM +0200, Geert Uytterhoeven wrote: >> Refresh armadillo800eva_defconfig, and enable missing options for devices >> in platform data and/or DT: >> - REGULATOR_GPIO >> - LEDS_GPIO > > I would prefer if changes were made in a more incremental patch. > > * A patch to enable LEDS_GPIO and REGULATOR_GPIO. > * Then a cleanup patch, if you really want to do that: but why? > >> >> Signed-off-by: Geert Uytterhoeven >> --- >> Do we want SHMOBILE_IOMMU, too? The help text says "If unsure, say N." >> If yes, is the default SHMOBILE_IOMMU_ADDRSIZE_2048MB OK? > > I defer to Magnus on that one. I think it's best to go with a "N" here. Unless someone can prove to me that we need it and that it is working! In general I'd like to begin by integrating IOMMU support for R-Car Gen2 in a controlled manner and once that is in place I think we can revisit this older case. At that time hopefully we will be dealing with the multiplatform defconfig for r8a7740 and Armadillo. Cheers, / magnus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/28] nios2: MMU Fault handling
On Tue, Apr 22, 2014 at 10:30 PM, Ezequiel Garcia
wrote:
> Hello Ley Foon,
>
> On Apr 18, Ley Foon Tan wrote:
>> +
>> +bad_area_nosemaphore:
>> + /* User mode accesses just cause a SIGSEGV */
>> + if (user_mode(regs)) {
>
> I found that it's useful to add some printing here, just as ARM
> does. I carry this patch on my kernel:
>
> + printk(KERN_INFO "%s: unhandled page fault (%d) at 0x%08lx,
> cause %ld\n",
> + current->comm, SIGSEGV, address, cause);
> + show_regs(regs);
>
> Do you think we could do something like it? Maybe with a compile time option?
Yes, this is useful debug message. I can add this.
Prefer not to add new compile time option, I think this shouldn't
happen frequently.
>
>> + _exception(SIGSEGV, regs, code, address);
>> + return;
>> + }
>> +
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] usb: ohci-exynos: Make provision for vdd regulators
Hi Jingoo,
On Thu, Apr 24, 2014 at 6:56 AM, Jingoo Han wrote:
> On Thursday, April 24, 2014 9:33 AM, Jingoo Han wrote:
>> On Thursday, April 24, 2014 9:18 AM, Anton Tikhomirov wrote:
>> > On Monday, April 21, 2014 9:17 PM, Vivek Gautam wrote:
>> > >
>> > > Facilitate getting required 3.3V and 1.0V VDD supply for
>> > > OHCI controller on Exynos.
>> > >
>> > > With patches for regulators' nodes merged in 3.15:
>> > > c8c253f ARM: dts: Add regulator entries to smdk5420
>> > > 275dcd2 ARM: dts: add max77686 pmic node for smdk5250,
>> > >
>> > > certain perripherals will now need to ensure that,
>> > > they request VDD regulators in their drivers, and enable
>> > > them so as to make them working.
>> > >
>> > > Signed-off-by: Vivek Gautam
>> > > Cc: Jingoo Han
>> > > ---
>> > >
>> > > Based on 'usb-next' branch of Greg's usb tree.
>> > >
>> > > drivers/usb/host/ohci-exynos.c | 47
>> > >
>> > > 1 file changed, 47 insertions(+)
>> > >
>> > > diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-
>> > > exynos.c
>> > > index 68588d8..e2e72a8 100644
>> > > --- a/drivers/usb/host/ohci-exynos.c
>> > > +++ b/drivers/usb/host/ohci-exynos.c
[snip]
>> > > @@ -98,6 +101,28 @@ static int exynos_ohci_probe(struct platform_device
>> > > *pdev)
>> > > exynos_ohci->otg = phy->otg;
>> > > }
>> > >
>> > > + exynos_ohci->vdd33 = devm_regulator_get(&pdev->dev, "vdd33");
>> > > + if (IS_ERR(exynos_ohci->vdd33)) {
>> > > + err = PTR_ERR(exynos_ohci->vdd33);
>> > > + goto fail_regulator1;
>> > > + }
>> > > + err = regulator_enable(exynos_ohci->vdd33);
>> > > + if (err) {
>> > > + dev_err(&pdev->dev, "Failed to enable VDD33 supply\n");
>> > > + goto fail_regulator1;
>> > > + }
>> > > +
>> > > + exynos_ohci->vdd10 = devm_regulator_get(&pdev->dev, "vdd10");
>> > > + if (IS_ERR(exynos_ohci->vdd10)) {
>> > > + err = PTR_ERR(exynos_ohci->vdd10);
>> > > + goto fail_regulator2;
>> > > + }
>> > > + err = regulator_enable(exynos_ohci->vdd10);
>> > > + if (err) {
>> > > + dev_err(&pdev->dev, "Failed to enable VDD10 supply\n");
>> > > + goto fail_regulator2;
>> > > + }
>> > > +
>> >
>> > Do we need to skip regulator settings together with PHY configuration
>> > in case of exynos5440?
>>
>> Oh, right. In the case of exynos5440, regulator settings is not
>> necessary. Vivek, would you fix it in order skip regulator settings
>> in exynos5440? It also applies to ehci-exynos.
>
> Sorry, in the case of exynos5440, this patch already skips
> regulator settings.
>
> In the case of exynos5440, there is no need to set PHY setting
> and regulator setting.
Right, in case of exynos5440, we are skipping PHY setting and regulator setting.
Actually i had missed taking into account 5440, so just curious. Do we
really not need a regulator
settings for Exynos5440 ?
>
> How about making regulator setting "optional"?
> Then, regulator setting can be done, only when regulator
> is supported.
True, so with Exynos5440 not needing the regulator, we should make the
regulator settings optional.
>
> exynos_ohci_probe()
> exynos_ohci->vdd33 = devm_regulator_get(&pdev->dev, "vdd33");
> if (IS_ERR(exynos_ohci->vdd33)) {
> dev_err(&pdev->dev, "Failed to get VDD33 supply\n");
> } else {
> err = regulator_enable(exynos_ohci->vdd33);
> if (err) {
> dev_err(&pdev->dev, "Failed to enable VDD33
> supply\n");
> goto fail_regulator1;
> }
> }
>
> exynos_ohci->vdd10 = devm_regulator_get(&pdev->dev, "vdd10");
> if (IS_ERR(exynos_ohci->vdd10)) {
> dev_err(&pdev->dev, "Failed to get VDD10 supply\n");
> } else {
> err = regulator_enable(exynos_ohci->vdd10);
> if (err) {
> dev_err(&pdev->dev, "Failed to enable VDD10
> supply\n");
> goto fail_regulator2;
> }
> }
>
> In this case, suspend/resume can be fixed as below.
>
> exynos_ohci_suspend()
> if (exynos_ohci->vdd10)
> regulator_disable(exynos_ohci->vdd10);
> if (exynos_ohci->vdd33)
> regulator_disable(exynos_ohci->vdd33);
>
> exynos_ohci_resume()
>
> if (exynos_ohci->vdd33) {
> ret = regulator_enable(exynos_ohci->vdd33);
> if (ret) {
> dev_err(dev, "Failed to enable VDD33 supply\n");
> return ret;
> }
> }
> if (exynos_ohci->vdd10) {
> ret = regulator_enable(exynos_ohci->vdd10);
> if (ret) {
> dev_err(dev, "Failed to enable VDD10 supply\n");
> return ret;
> }
> }
Thanks for the suggestion.
I will make the required changes, and post the patchset
[PATCH] module: remove warning about waiting module removal.
We remove the waiting module removal in commit 3f2b9c9cdf38 (September
2013), but it turns out that modprobe in kmod (< version 16) was
asking for waiting module removal. Noone noticed since modprobe would
check for 0 usage immediately before trying to remove the module, and
the race is unlikely.
However, it means that anyone running old (but not ancient) kmod
versions is hitting the printk designed to see if anyone was running
"rmmod -w". All reports so far have been false positives, so remove
the warning.
Fixes: 3f2b9c9cdf389e303b2273679af08aab5f153517
Reported-by: Valerio Vanni
Cc: Elliott, Robert (Server Storage)
Cc: sta...@kernel.org
Signed-off-by: Rusty Russell
diff --git a/kernel/module.c b/kernel/module.c
index 11869408f79b..ae7821898bf2 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -815,9 +815,6 @@ SYSCALL_DEFINE2(delete_module, const char __user *,
name_user,
return -EFAULT;
name[MODULE_NAME_LEN-1] = '\0';
- if (!(flags & O_NONBLOCK))
- pr_warn("waiting module removal not supported: please
upgrade\n");
-
if (mutex_lock_interruptible(&module_mutex) != 0)
return -EINTR;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 0/4] perf/urgent fixes
* Jiri Olsa wrote: > On Wed, Apr 23, 2014 at 03:14:33PM +0200, Ingo Molnar wrote: > > > > (Just reporting two bugs I found today - unrelated to your the > > perf/urgent pull request.) > > > > 1) > > > > Even when the most modern unwind library is found, the autodetection > > is spammy: > > > > > > Auto-detecting system features: > > ... dwarf: [ on ] > > ... glibc: [ on ] > > ... gtk2: [ on ] > > ... libaudit: [ on ] > > ...libbfd: [ on ] > > ...libelf: [ on ] > > ... libnuma: [ on ] > > ... libperl: [ on ] > > ... libpython: [ on ] > > ... libslang: [ on ] > > ... libunwind: [ on ] > > ...libdw-dwarf-unwind: [ on ] > > ... DWARF post unwind library: libunwind > > > > The 'DWARF post unwind library' line is somewhat superfluous. I > > realize that it prints out the library selected - but that's obvious > > from the 'libdw-dwarf-unwind' line above it already, right? > > nope, the on/off output is only whats detected in system, > you've got both libunwind and libdw-dwarf-unwind detected > > libunwind is default unless you use NO_LIBUNWIND=1 Okay, so the problem is that we don't have a simple binary-state feature in this case, but three possible states: 'libunwind', or 'libdw-dwarf-unwind', or 'OFF', right? If so then the solution would be to replace those 3 last lines with just this line: ...DWARF unwind library: [ libunwind ] Where 'libunwind' is printed in green (like the 'on' lines are printed). If there's no suitable library available then output: ...DWARF unwind library: [ OFF ] Because the user looking at the output is really only interested in 'is an unwind library available', and maybe in 'which one'. Is there preference between library choices? I.e. is 'libunwind' preferred over 'libdw-dwarf-unwind', or the other way around? If yes then if we pick an inferior library we could print it in yellow color - and only use green if it's the 'best' choice. That way the color codes also still keep working: red means problem, green means OK, yellow something inbetween. But in any case we should try to keep the 'one feature, one line' fundamental output concept. ( Under V=1 we can output whatever details might be useful to developers, there's no restriction on what to output there. ) Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] usb: ohci-exynos: Make provision for vdd regulators
Hi,
On Thu, Apr 24, 2014 at 6:08 AM, Anton Tikhomirov
wrote:
> Hi,
>
>> Hi,
>>
>> > -Original Message-
>> > From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-
>> > ow...@vger.kernel.org] On Behalf Of Vivek Gautam
>> > Sent: Monday, April 21, 2014 9:17 PM
>> >
>> > Facilitate getting required 3.3V and 1.0V VDD supply for
>> > OHCI controller on Exynos.
>> >
>> > With patches for regulators' nodes merged in 3.15:
>> > c8c253f ARM: dts: Add regulator entries to smdk5420
>> > 275dcd2 ARM: dts: add max77686 pmic node for smdk5250,
>> >
>> > certain perripherals will now need to ensure that,
>> > they request VDD regulators in their drivers, and enable
>> > them so as to make them working.
>> >
>> > Signed-off-by: Vivek Gautam
>> > Cc: Jingoo Han
>> > ---
>> >
>> > Based on 'usb-next' branch of Greg's usb tree.
>> >
>> > drivers/usb/host/ohci-exynos.c | 47
>> >
>> > 1 file changed, 47 insertions(+)
>> >
>> > diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-
>> > exynos.c
>> > index 68588d8..e2e72a8 100644
>> > --- a/drivers/usb/host/ohci-exynos.c
>> > +++ b/drivers/usb/host/ohci-exynos.c
[snip]
>> > static void exynos_ohci_phy_enable(struct platform_device *pdev)
>> > @@ -98,6 +101,28 @@ static int exynos_ohci_probe(struct
>> platform_device
>> > *pdev)
>> > exynos_ohci->otg = phy->otg;
>> > }
>> >
>> > + exynos_ohci->vdd33 = devm_regulator_get(&pdev->dev, "vdd33");
>> > + if (IS_ERR(exynos_ohci->vdd33)) {
>> > + err = PTR_ERR(exynos_ohci->vdd33);
>> > + goto fail_regulator1;
>> > + }
>> > + err = regulator_enable(exynos_ohci->vdd33);
>> > + if (err) {
>> > + dev_err(&pdev->dev, "Failed to enable VDD33 supply\n");
>> > + goto fail_regulator1;
>> > + }
>> > +
>> > + exynos_ohci->vdd10 = devm_regulator_get(&pdev->dev, "vdd10");
>> > + if (IS_ERR(exynos_ohci->vdd10)) {
>> > + err = PTR_ERR(exynos_ohci->vdd10);
>> > + goto fail_regulator2;
>> > + }
>> > + err = regulator_enable(exynos_ohci->vdd10);
>> > + if (err) {
>> > + dev_err(&pdev->dev, "Failed to enable VDD10 supply\n");
>> > + goto fail_regulator2;
>> > + }
>> > +
>>
>> Do we need to skip regulator settings together with PHY configuration
>> in case of exynos5440?
>>
>> > skip_phy:
>> > exynos_ohci->clk = devm_clk_get(&pdev->dev, "usbhost");
>> >
[snip]
>> > @@ -218,6 +253,18 @@ static int exynos_ohci_resume(struct device *dev)
>> > struct usb_hcd *hcd = dev_get_drvdata(dev);
>> > struct exynos_ohci_hcd *exynos_ohci = to_exynos_ohci(hcd);
>> > struct platform_device *pdev= to_platform_device(dev);
>> > + int ret;
>> > +
>> > + ret = regulator_enable(exynos_ohci->vdd33);
>> > + if (ret) {
>> > + dev_err(dev, "Failed to enable VDD33 supply\n");
>> > + return ret;
>>
>> Not sure, but shall we continue resuming and do everything
>> we can in case of error? At least it will avoid
>> WARN_ON(clk->enable_count == 0) on next system suspend.
True, i will modify it.
>
> On the other hand, if power is not applied to the controller,
> register access in ohci_resume() may lead to undefined behavior.
> What's your opinion?
AFA i think, it is obvious that the regulators would not work without
a VDD supply.
So the question is, do we have VDD LDOs available on all Exynos
systems for usb ?
>From the schemata of Exynos5250 and Exynos5420 boards, i can see the
required VDD LDOs
for USB. Unfortunately at present i don't have a Exynos4* schemata.
If regulator is not a mandatory, then we can make it option similar to
what Jingoo has also suggested
in subsequent mail.
[snip]
--
Best Regards
Vivek Gautam
Samsung R&D Institute, Bangalore
India
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 1/1] pinctrl: add Intel BayTrail GPIO/pinctrl support
On Wed, Apr 23, 2014 at 10:14:20AM -0500, Timur Tabi wrote: > Westerberg, Mika wrote: > >It doesn't do any pin control nor muxing and I'm not sure if it is > >required. Can you elaborate why you think pin muxing is required with > >GpioIo/GpioInt resources? > > How are the pin muxes normally configured in ACPI? All of our GPIOs > have a pinmux on them, and so if you want to use the pin for the > non-default functionality, you need to configure the mux. Isn't > that supposed to happen with the through the pinctrl driver? It's the BIOS that handles all this even though there are several "alternate functions" in the GPIO hardware. BIOS goes and configures those according what the platform needs and those that are GPIOs/IRQs it will create corresponding GpioIo/GpioInt along with the device that uses them. Of course if you have a custom board and your BIOS doesn't handle this, you are going to need some sort of pinctrl driver. > That is, when the kernel parses the ASL, and it seems a command to > configure pin #3 to function #4, it calls the local pinctrl driver to do > that? I'm not aware of ASL code that allows you to do that. Do you have examples? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: Tree for Apr 24
Hi all, This tree still fails (more than usual) the powerpc allyesconfig build. Changes since 20140423: New tree: usb-gadget-fixes The arm tree lost its flurry of build warnings. The powerpc tree still had its build failure. The vfs tree lost its build failure. The libata tree gained a build failure so I used the version from next-20140423. The net-next tree gained conflicts against the net tree. The wireless-next tree still had its build failure for which I applied a patch. The mfd-lj tree gained a build failure so I used the version from next-20140423. The tip tree gained a build failure for which I applied a merge fix patch. The akpm-current tree still had its build failure and gained conflicts against the arm and Linus' trees. Non-merge commits (relative to Linus' tree): 2421 2255 files changed, 80025 insertions(+), 48805 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" as mentioned in the FAQ on the wiki (see below). You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64 and a multi_v7_defconfig for arm. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (this fails its final link) and i386, sparc, sparc64 and arm defconfig. Below is a summary of the state of the merge. I am currently merging 216 trees (counting Linus' and 29 trees of patches pending for Linus' tree). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. There is a wiki covering stuff to do with linux-next at http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (1aae31c8306e Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input) Merging fixes/master (b0031f227e47 Merge tag 's2mps11-build' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator) Merging kbuild-current/rc-fixes (38dbfb59d117 Linus 3.14-rc1) Merging arc-current/for-curr (a798c10faf62 Linux 3.15-rc2) Merging arm-current/fixes (556d3f7f4d79 ARM: add renameat2 syscall) Merging m68k-current/for-linus (50be9eba831d m68k: Update defconfigs for v3.14-rc1) Merging metag-fixes/fixes (a798c10faf62 Linux 3.15-rc2) Merging powerpc-merge/merge (cc4f265ad9a3 powerpc/powernv Adapt opal-elog and opal-dump to new sysfs_remove_file_self) Merging sparc/master (a798c10faf62 Linux 3.15-rc2) Merging net/master (83d5b7ef99c9 net: filter: initialize A and X registers) Merging ipsec/master (a32452366b72 vti4: Don't count header length twice.) CONFLICT (content): Merge conflict in net/ipv4/ip_vti.c Merging sound-current/for-linus (8dc9abb93dde ALSA: hda/realtek - Add headset Mic support for Dell machine) Merging pci-current/for-linus (f5d3352b2751 PCI: tegra: Use new OF interrupt mapping when possible) Merging wireless/master (c82552c5b0cb ath9k: add a recv budget) Merging driver-core.current/driver-core-linus (a798c10faf62 Linux 3.15-rc2) Merging tty.current/tty-linus (a798c10faf62 Linux 3.15-rc2) Merging usb.current/usb-linus (a798c10faf62 Linux 3.15-rc2) Merging usb-gadget-fixes/fixes (a31a942a148e usb: phy: am335x-control: wait 1ms after power-up transitions) Merging staging.current/staging-linus (8b425aa19343 Merge tag 'iio-fixes-for-3.15a' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linus) Merging char-misc.current/char-misc-linus (a798c10faf62 Linux 3.15-rc2) Merging input-current/for-linus (ae4bedf0679d Input: elantech - add support for newer elantech touchpads) Merging md-current/for-linus (d47648fcf061 raid5: avoid finding "discard" stripe) Merging crypto-current/master (eb4a5346e777 hwrng: bcm2835 - fix oops when rng h/w is accessed during registration) Merging ide/master (5b40dd30bbfa ide: Fix SC1200 dependencies) Merging dwmw2/master (5950f0803ca9 pcmcia: remove RPX board stuff) Merging devicetree-current/dev
Re: [PATCH 00/28] nios2 Linux kernel port
On 2014/4/24 上午 02:15, Pinski, Andrew wrote: > >> > On Apr 23, 2014, at 10:59 AM, "Chung-Lin Tang" >> > wrote: >> > >>> >> On 2014/4/22 07:20 PM, Ley Foon Tan wrote: >>> >> On Tue, Apr 22, 2014 at 6:56 PM, Arnd Bergmann wrote: > On Tuesday 22 April 2014 18:37:11 Ley Foon Tan wrote: >>> >> Hi Arnd and Peter Anvin, >>> >> >>> >> Other than 64-bit time_t, clock_t and suseconds_t, can you >>> >> confirm >>> >> that we don't need to have 64 bit off_t? See detail in link >>> >> below. >>> >> I can submit the patches for 64-bit time changes >>> >> (include/asm-generic/posix_types.h and other archs) if everyone >>> >> is >>> >> agreed on this. > > Yes. >>> >> Okay, will doing that. >> > >> > I believe that arm64 ILP32 will also be affected. What is the status of >> > this configuration? Has the glibc/kernel ABI been finalized? > Not yet. I am still working out the signal handling part. But we already > agreed on 64bit time_t, clock_t, and suseconds_t. And we agreed to a 64bit > offset_t too. > > On a related note suseconds in the timespec in posix is defined to be long. > So it would nice if the kernel ignores the upper 32bits so we (glibc > developers) can fix this for new targets including x32 and arm64/ilp32. Hmm, but that means for purely 32-bit architectures like nios2, which unlike x86_64 or arm64, never has a 64-bit mode, suseconds_t as a 64-bit type in the kernel is simply wasted. Chung-Lin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
nfsd bug fixes for 3.15
Please pull the following bug fixes for 3.15 from: git://linux-nfs.org/~bfields/linux.git for-3.15 Three small nfsd bugfixes (including one locks.c fix for a bug triggered only from nfsd). Jeff's patches are for long-existing problems that became easier to trigger since the addition of vfs delegation support. --b. J. Bruce Fields (1): Revert "nfsd4: fix nfs4err_resource in 4.1 case" Jeff Layton (2): locks: allow __break_lease to sleep even when break_time is 0 nfsd: set timeparms.to_maxval in setup_callback_client fs/locks.c | 7 +++ fs/nfsd/nfs4callback.c | 4 +++- fs/nfsd/nfs4xdr.c | 8 3 files changed, 6 insertions(+), 13 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] X86: Hook apic vector allocation domain only when interrupt routing are set to ignore
* Oren Twaig wrote: > Set all inclusive vector allocation domain only if interrupt routing > is set to ignore. When in comply mode, vector allocation behavior > isn't changed. This changelog is too terse: Please update the changelog to describe the current behavior, and how it affects your platform. (I.e. how do users notice, if at all?) Then describe why you think that behavior should be changed. ie: what's the reason for this patch. Only then describe the details of the change itself. > -apic->vector_allocation_domain = fill_vector_allocation_domain; > + > +if (!irc) > +apic->vector_allocation_domain = fill_vector_allocation_domain; Please also run scripts/checkpatch.pl over your patch which will report trivial coding style problems like the one here. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 1/1] pinctrl: add Intel BayTrail GPIO/pinctrl support
On Thu, Apr 24, 2014 at 12:20:12AM +0200, Linus Walleij wrote: > On Wed, Apr 23, 2014 at 5:14 PM, Timur Tabi wrote: > > > How are the pin muxes normally configured in ACPI? > > VERY good question. Typically this is done by the boot firmware (BIOS in this case). So the OS doesn't need to deal with that. AFAICT ACPI doesn't know anything about pin muxing. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] thermal: samsung: Only update available threshold limits
On 4/14/14, Tushar Behera wrote:
> Currently the threshold limits are updated in 2 stages, once for all
> software trigger levels and again for hardware trip point.
I guess the first stage is bootloader as could not find this in this file.
Anyways the changes looks fine to me.
Acked-by: Amit Daniel Kachhap
>
> While updating the software trigger levels, it overwrites the threshold
> limit for hardware trip point thereby forcing the Exynos core to issue
> an emergency shutdown.
>
> Updating only the required fields in threshold register fixes this issue.
>
> Signed-off-by: Tushar Behera
> ---
> Based on v3.15-rc1.
>
> drivers/thermal/samsung/exynos_tmu.c |4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/thermal/samsung/exynos_tmu.c
> b/drivers/thermal/samsung/exynos_tmu.c
> index 0d96a51..ffccc89 100644
> --- a/drivers/thermal/samsung/exynos_tmu.c
> +++ b/drivers/thermal/samsung/exynos_tmu.c
> @@ -225,6 +225,8 @@ skip_calib_data:
> trigger_levs++;
> }
>
> + rising_threshold = readl(data->base + reg->threshold_th0);
> +
> if (data->soc == SOC_ARCH_EXYNOS4210) {
> /* Write temperature code for threshold */
> threshold_code = temp_to_code(data, pdata->threshold);
> @@ -249,6 +251,7 @@ skip_calib_data:
> ret = threshold_code;
> goto out;
> }
> + rising_threshold &= ~(0xff << 8 * i);
> rising_threshold |= threshold_code << 8 * i;
> if (pdata->threshold_falling) {
> threshold_code = temp_to_code(data,
> @@ -281,6 +284,7 @@ skip_calib_data:
> }
> if (i == EXYNOS_MAX_TRIGGER_PER_REG - 1) {
> /* 1-4 level to be assigned in th0 reg */
> + rising_threshold &= ~(0xff << 8 * i);
> rising_threshold |= threshold_code << 8 * i;
> writel(rising_threshold,
> data->base + reg->threshold_th0);
> --
> 1.7.9.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc"
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Microblaze image hanging in qemu with 3.15-rc
On 04/23/2014 05:45 PM, Guenter Roeck wrote:
> On Wed, Apr 23, 2014 at 04:12:59PM +0200, Michal Simek wrote:
>> On 04/23/2014 03:38 PM, Guenter Roeck wrote:
>>> On 04/22/2014 10:32 PM, Michal Simek wrote:
Hi Guenter,
On 04/22/2014 07:23 PM, Guenter Roeck wrote:
> Hi all,
>
> when trying to run a microblaze image with 3.15-rc1 or 3.15-rc2 in qemu,
> I get the following hangup. This used to work with earlier kernels
> with the same configuration.
>
> Is this a known problem, or is something wrong with my configuration
> or with my qemu command line ?
Is this BE/LE version? Which qemu do you use?
>>>
>>> BE.
>>>
>>> file vmlinux:
>>>
>>> vmlinux: ELF 32-bit MSB executable, version 1 (SYSV), statically linked,
>>> BuildID[sha1]=5e1872c08df2956eddaed6fc1f6528a8540375b7, not stripped
>>>
>>> qemu-system-microblaze --version:
>>>
>>> QEMU emulator version 1.7.0, Copyright (c) 2003-2008 Fabrice Bellard
>>>
>>> gcc --version:
>>>
>>> microblaze-linux-gcc (GCC) 4.8.0
>>> Copyright (C) 2013 Free Software Foundation, Inc.
>>> This is free software; see the source for copying conditions. There is NO
>>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>>>
There is endian autodetection in timer and intc driver
which can caused this problem.
>>> Is this new code ? I didn't see the problem in 3.13 (same compile options,
>>> same configuration, same compiler, same qemu version).
>>
>> yes it was added to 3.15-rc1.
>>
>> Try to rever this one
>> a66a626 microblaze: Use asm-generic/io.h
>>
>> but the problem is probably here because you are not getting proper
>> reaction from qemu model.
>> a1715bb microblaze: Make timer driver endian aware
>> 1aa1243 microblaze: Make intc driver endian aware
>>
>> I have tested it on the latest petalinux qemu and there shouldn't be
>> any problem.
>>
> Hi Michal,
>
> qemu 2.0.0 still has the problem. Bisect points to
>
> commit a66a626538af65cbfc611e2b2fce500ed3f24518
> Author: Michal Simek
> Date: Thu Feb 7 15:12:24 2013 +0100
>
> microblaze: Use asm-generic/io.h
>
> as the culprit, so you were right on the money. Reverting this commit
> fixes the problem.
yep. But it is just side effect of previous two commits I have mentioned.
Can you just please check if you are setting up correct IO functions?
write_fn = timer_write32;
read_fn = timer_read32;
write_fn(TCSR_MDT, timer_baseaddr + TCSR0);
if (!(read_fn(timer_baseaddr + TCSR0) & TCSR_MDT)) {
write_fn = timer_write32_be;
read_fn = timer_read32_be;
}
git
> Assuming this is in fact a problem with qemu, can you point me to a set
> of qemu patches necessary to fix it ? Also, do you know if there are plans
> to send the patches upstream ? I don't find anything related in the qemu
> repository (though of course I may have missed it).
Yes, it should be qemu issue. I am not aware about particular qemu patches
but you can try to use https://github.com/Xilinx/qemu
but now sure if Peter updating this repository.
Anyway if you look at code above and I expect that the problem is just
that autodetection is broken in your qemu it should be pretty simple
to fix it.
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform
signature.asc
Description: OpenPGP digital signature
Re: [PATCH 04/28] nios2: Exception handling
On Wed, Apr 23, 2014 at 8:23 PM, Arnd Bergmann wrote: >> >> We really shouldn't be doing new architecture specific procfs files >> >> any more. I suggest you drop this one for now, and add back the >> >> functionality using perf or ftrace at a later point. >> > >> > Okay, will remove this. >> >> MIPS and powerpc handle this through debugfs, cfr. >> arch/mips/kernel/unaligned.c and arch/powerpc/kernel/traps.c. > > Ah, right, that would work too. Being able to use perf from user > space sounds more flexible though. It's certainly something that > can be decided later. Yes, we can add this back through debugfs or perf in later. Regards Ley Foon -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/28] nios2: I/O Mapping
On Tue, Apr 22, 2014 at 9:59 PM, Arnd Bergmann wrote:
> On Friday 18 April 2014, Ley Foon Tan wrote:
>
>> +
>> +#include
>> +
>> +#define IO_SPACE_LIMIT 0x
>
> Please use 0x here, this should work for almost any PCI bus.
Ah, CONFIG_PCI is not enable in nios2. So, I think IO_SPACE_LIMIT
should set to 0.
>> +
>> +/* Use "Duff's Device" to unroll the loops. */
>> +#define __IO_OUT_LOOP(a, b, l) \
>> + do {\
>> + if (l > 0) {\
>> + int _n = (l + 7) / 8; \
>> + switch (l % 8) {\
>> + case 0: \
>> + do {\
>> + *a = *b++; \
>
> I would recommend just doing all of this in out-of-line implementations
> rather than macros and inline functions.
Okay. Will move the macros to out-of-line function.
>
>> +
>> +/*
>> + * make the short names macros so specific devices
>> + * can override them as required
>> + */
>> +#define inb(addr)readb(addr)
>> +#define inw(addr)readw(addr)
>> +#define inl(addr)readl(addr)
>> +#define outb(x, addr)((void) writeb(x, addr))
>> +#define outw(x, addr)((void) writew(x, addr))
>> +#define outl(x, addr)((void) writel(x, addr))
>
> This makes no sense: the legacy PC I/O accessors take a completely
> different argument type: I would recommend to make both inline
> functions so you can ensure that readl() gets passed an __iomem
> pointer, while inl() gets an integer number.
>
> Please see the asm-generic version for an example. You should also
> define a non-NULL PCI_IOBASE to which the PCI I/O space gets mapped.
I think these macros can be removed if PCI is not enabled in Nios2.
>
>> +#define virt_to_bus virt_to_phys
>> +#define bus_to_virt phys_to_virt
>
> Please drop these, and the CONFIG_VIRT_TO_BUS Kconfig option,
> and fix all drivers that rely on it.
Okay. Will remove these.
>
>> +#define ioport_map(port, nr) ioremap(port, nr)
>> +#define ioport_unmap(port) iounmap(port)
>
> Use this one instead:
>
> #ifdef CONFIG_PCI
> static inline void __iomem *ioport_map(unsigned long port, unsigned int nr)
> {
> return PCI_IOBASE + port;
> }
>
> static inline void __iomem *ioport_unmap(void __iomem *)
> {
> }
> #endif
These also can be removed.
>
>> +/* Macros used for smc91x.c driver */
>> +#define readsb(p, d, l) insb(p, d, l)
>> +#define readsw(p, d, l) insw(p, d, l)
>> +#define readsl(p, d, l) insl(p, d, l)
>> +#define writesb(p, d, l) outsb(p, d, l)
>> +#define writesw(p, d, l) outsw(p, d, l)
>> +#define writesl(p, d, l) outsl(p, d, l)
>
> These should of course not fall back to the PCI I/O space functions.
> You can do it the other way round.
Okay, these will change to something like:
#define readsb(p, d, l) io_insb(p, d, l)
#define readsw(p, d, l) io_insw(p, d, l)
(etc)
Regards
Ley Foon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: 3.15-rc2: i915 regression: only top 20% of screen works in X
On Thu, Apr 24, 2014 at 7:50 AM, Chris Wilson wrote: > That says that i915.ko failed to initialise the GPU (or rather the GPU > wasn't responding) and bailed during module load. The key line here is > > [drm:init_ring_common] *ERROR* render ring initialization failed ctl > 0001f001 head 2034 tail start 0012f000 > > Jiri has been seeing a similar issue creep in during resume, but it is > not reliable enough to bisect. Is your boot failure reliable enough to > bisect? Also drm-intel-nightly should mitigate this failure and allow > i915.ko to continue to load and run X, which would be worth testing to > make sure that works as intended. Oh right, g4x going beserk :( Apparently something changed in 3.15 somewhere which made this much more likely, but like Chris said in Jiri's case it's too unreliable to reproduce for a bisect. We've had this come&go pretty much ever since kms support was merged and never tracked it down. The bug is https://bugs.freedesktop.org/show_bug.cgi?id=76554 Like Chris said please test latest drm-intel-nighlty from http://cgit.freedesktop.org/drm-intel to make sure that the recently merged mitigation measures work properly. But those won't get your gpu back, only the display and it's only for 3.16. We're still hunting a proper fix for 3.15. And if you can indeed reliably reproduce this a bisect could be really useful. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] nohz: delayed iowait accounting for nohz idle time stats
(2014/04/23 18:41), Peter Zijlstra wrote: > On Wed, Apr 23, 2014 at 04:40:18PM +0900, Hidetoshi Seto wrote: >> (2014/04/23 4:45), Peter Zijlstra wrote: >>> On Thu, Apr 17, 2014 at 06:41:41PM +0900, Hidetoshi Seto wrote: [TARGET OF THIS PATCH]: Complete rework for iowait accounting implies that some user interfaces might be replaced completely. It will introduce new counter or so, and kill per-cpu iowait counter which is known to being nonsense. It will take long time to be achieved, considering time to make the problem to a public knowledge, and also time for interface transition. Anyway as long as linux try to be reliable OS, such drastic change must be placed on mainline kernel in development sooner or later. OTOH, drastic change like above is not acceptable for conservative environment, such as stable kernels, some distributor's kernel and so on, due to respect for compatibility. Still these kernel expects per-cpu iowait counter works as well as it might have been. Therefore for such environment, applying a simple patch to fix behavior of counter will be appreciated rather than replacing an over-used interface or changing an existing usage/semantics. This patch targets latter kernels mainly. It does not do too much, but intend to fix the idle stats counters to be monotonic. I believe that mainline kernel should pick up this patch too, because it surely fix a hidden bug and does not intercept upcoming drastic change. Again, in summary, this patch does not do drastic change to cope with problem 2. But it just fix behavior of idle/iowait counter of /proc/stats. [WHAT THIS PATCH PROPOSED]: The main reason of the bug is that observers have no idea to determine the delta to be idle or iowait at the first place. So I introduced delayed iowait accounting to allow observers to assign delta based on status of observed cpu at idle entry. >>> >>> So the problem I have with this is that it makes CONFIG_NOHZ=[ny] >>> kernels behave quite differently. >> >> It is not true. >> There are already differences before applying my patches. >> The behavior of NOHZ=y kernel diverged from original since it was born. > > But if you argue about not actually fixing iowait properly, then this > difference is the only actual regression. A difference is not always a regression. >> Please note that no one complained about this difference. > > Then why are you working on this? You're the one that said there was a > regression between unnamed enterprise distro 5 and unnamed enterprise > distro 6. e.g. regression: a counter loses monotonicity improvement: drop power consumption by skipping tick during in idle not matter: useless fuzzy crap value turned to be another crap If you say every difference is regression, then all kernel config must be nop. >> I just want to fix a counter not to go backward. >> It's a simple bug, isn't it? > > Seeing how we managed to send as many patches as we did, I'd say that's > a fairly big clue as to how its not as simple. I think the situation is that a simple small bug is glued to big complicated background. I want to separate them and handle only a small bug, therefore I wrote patch description a lot for background and my target. > Just make the value unconditionally 0 then. That's guaranteed not to go > backwards and just about as useful as the random fwd walk you make it. > Plus, its a lot easier. I'd like to hire constant 0 if it is acceptable for stables. I suppose it could be considered as improvement for mainline kernel since it will be the first step for upcoming drastic changes. But I also suppose it could be classified as regression for stable kernels because one counter ordinarily used stops its progress. >>> Ideally NOHZ=y and NOHZ=n behave the same, my proposed solution the >>> other day does just that. This one OTOH seems to generate entirely >>> different results between those kernels. >> >> As you know, behaviors of NOHZ=[ny] are both crap because of per-cpu >> iowait accounting. >> >> I guess we should say: >> Ideally NOHZ=[ny] behave the same "in the proper way." > > No, the premise of NOHZ is that behaviour should not change, we found a > change in behaviour, we should make it go away. > > Secondly, with or without NOHZ iowait accounting is complete crap. We > should also fix that. Humm..? I could not catch the reason why you say no here. I think wasting time to unify 2 craps into 1 crap is not necessary before replacing craps by a proper thing. >> What you proposed will do too much to make one nonsense to another >> nonsense. It will be unhelpful for people... > > I proposed that if you don't want to fix the actual iowait is crap > problem, you at least fix the NOHZ regression proper. I'd like to target only a part of differen
Re: 3.15-rc2: i915 regression: only top 20% of screen works in X
On Thu, Apr 24, 2014 at 12:09:52AM +0200, Pavel Machek wrote: > Hi! > > > > After update to 3.15-rc2, only top 20% of screen works on X. > > > > > > 00:02.0 VGA compatible controller: Intel Corporation 4 Series Chipset > > > Integrated Graphics Controller (rev 03) > > > > > > 00:02.1 Display controller: Intel Corporation 4 Series Chipset > > > Integrated Graphics Controller (rev 03) > > >Subsystem: Intel Corporation Device d614 > > >Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- > > >ParErr- Stepping- SERR- FastB2B- DisINTx- > > >Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast > > >>TAbort- SERR- > >Latency: 0 > > >Region 0: Memory at d040 (64-bit, non-prefetchable) > > >[size=1M] > > >Capabilities: > > > > > > This worked before. I believe it worked in 3.14. It definitely works > > > in 3.11-rc2. > > > > Screenshot or more detailed description of what "only top 20% of > > screen works in X" means? > > Anything in dmesg? > > Actually yes, dmesg suggests it is quite > sick. drivers/gpu/drm/drm_mm.c:767 warning triggered > repeatedly. Also.. initial framebuffer does not work ; I don't seem to > see anything before X start up. (This is Debian 6.0.9) That says that i915.ko failed to initialise the GPU (or rather the GPU wasn't responding) and bailed during module load. The key line here is [drm:init_ring_common] *ERROR* render ring initialization failed ctl 0001f001 head 2034 tail start 0012f000 Jiri has been seeing a similar issue creep in during resume, but it is not reliable enough to bisect. Is your boot failure reliable enough to bisect? Also drm-intel-nightly should mitigate this failure and allow i915.ko to continue to load and run X, which would be worth testing to make sure that works as intended. -Chris -- Chris Wilson, Intel Open Source Technology Centre -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] Input: evdev - get rid of old workaround for EVIOCGBIT
On Wed, Apr 23, 2014 at 10:27:20PM -0700, Dmitry Torokhov wrote:
> We put this workaround in 2008 and the offending userspace has been fixed
> up long time ago; the link in the message is no longer valid either, so it
> is time to retire it.
>
> Signed-off-by: Dmitry Torokhov
works for me, Reviewed-by: Peter Hutterer
Cheers,
Peter
> ---
> drivers/input/evdev.c | 18 --
> 1 file changed, 18 deletions(-)
>
> diff --git a/drivers/input/evdev.c b/drivers/input/evdev.c
> index ce953d8..fd325ec 100644
> --- a/drivers/input/evdev.c
> +++ b/drivers/input/evdev.c
> @@ -629,12 +629,10 @@ static int str_to_user(const char *str, unsigned int
> maxlen, void __user *p)
> return copy_to_user(p, str, len) ? -EFAULT : len;
> }
>
> -#define OLD_KEY_MAX 0x1ff
> static int handle_eviocgbit(struct input_dev *dev,
> unsigned int type, unsigned int size,
> void __user *p, int compat_mode)
> {
> - static unsigned long keymax_warn_time;
> unsigned long *bits;
> int len;
>
> @@ -652,24 +650,8 @@ static int handle_eviocgbit(struct input_dev *dev,
> default: return -EINVAL;
> }
>
> - /*
> - * Work around bugs in userspace programs that like to do
> - * EVIOCGBIT(EV_KEY, KEY_MAX) and not realize that 'len'
> - * should be in bytes, not in bits.
> - */
> - if (type == EV_KEY && size == OLD_KEY_MAX) {
> - len = OLD_KEY_MAX;
> - if (printk_timed_ratelimit(&keymax_warn_time, 10 * 1000))
> - pr_warning("(EVIOCGBIT): Suspicious buffer size %u, "
> -"limiting output to %zu bytes. See "
> -
> "http://userweb.kernel.org/~dtor/eviocgbit-bug.html\n";,
> -OLD_KEY_MAX,
> -BITS_TO_LONGS(OLD_KEY_MAX) * sizeof(long));
> - }
> -
> return bits_to_user(bits, len, size, p, compat_mode);
> }
> -#undef OLD_KEY_MAX
>
> static int evdev_handle_get_keycode(struct input_dev *dev, void __user *p)
> {
> --
> 1.9.0
>
>
> --
> 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 1/1] fanotify: for FAN_MARK_FLUSH check flags
On 04/23/2014 11:55 PM, Heinrich Schuchardt wrote: > If fanotify_mark is called with illegal value of arguments flags and marks > it usually returns EINVAL. > > When fanotify_mark is called with FAN_MARK_FLUSH the argument flags is not > checked for irrelevant flags like FAN_MARK_IGNORED_MASK. > > The patch removes this inconsistency. > > If an irrelevant flag is set error EINVAL is returned. > > Signed-off-by: Heinrich Schuchardt So, a small heads up that this change may of course break existing code. (Heinrich, see https://lwn.net/Articles/588444/ ). However, there is some precedent for such changes (examples in https://lwn.net/Articles/588444/), and * The number of applications out there using fanotify is probably very low * The number that are using FAN_MARK_FLUSH and misusing the flags will be even lower So the risk of breakage is likely vanishingly small. So, a qualified Acked-by: Michael Kerrisk Cheers, Michael > --- > fs/notify/fanotify/fanotify_user.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/fs/notify/fanotify/fanotify_user.c > b/fs/notify/fanotify/fanotify_user.c > index 287a22c..8bba549 100644 > --- a/fs/notify/fanotify/fanotify_user.c > +++ b/fs/notify/fanotify/fanotify_user.c > @@ -819,7 +819,10 @@ SYSCALL_DEFINE5(fanotify_mark, int, fanotify_fd, > unsigned int, flags, > case FAN_MARK_REMOVE: > if (!mask) > return -EINVAL; > + break; > case FAN_MARK_FLUSH: > + if (flags & ~(FAN_MARK_MOUNT | FAN_MARK_FLUSH)) > + return -EINVAL; > break; > default: > return -EINVAL; > -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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-current tree with Linus' tree
Hi Andrew,
Today's linux-next merge of the akpm-current tree got a conflict in
mm/memory.c between commit 1b17844b29ae ("mm: make fixup_user_fault()
check the vma access rights too") from Linus' tree and commit
0d84be787c23 ("mm: move get_user_pages()-related code to separate file")
from the akpm-current tree.
I fixed it up (I applied Linus' patch to the new file) and can carry the
fix as necessary (no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpPMW2p5Q_1I.pgp
Description: PGP signature
Re: [PATCH 5/4] ipc,shm: minor cleanups
On 04/23/2014 07:25 AM, Davidlohr Bueso wrote:
> On Wed, 2014-04-23 at 07:07 +0200, Michael Kerrisk (man-pages) wrote:
>> On 04/23/2014 04:53 AM, Davidlohr Bueso wrote:
>>> - Breakup long function names/args.
>>> - Cleaup variable declaration.
>>> - s/current->mm/mm
>>>
>>> Signed-off-by: Davidlohr Bueso
>>> ---
>>> ipc/shm.c | 40 +---
>>> 1 file changed, 17 insertions(+), 23 deletions(-)
>>>
>>> diff --git a/ipc/shm.c b/ipc/shm.c
>>> index f000696..584d02e 100644
>>> --- a/ipc/shm.c
>>> +++ b/ipc/shm.c
>>> @@ -480,15 +480,13 @@ static const struct vm_operations_struct shm_vm_ops =
>>> {
>>> static int newseg(struct ipc_namespace *ns, struct ipc_params *params)
>>> {
>>> key_t key = params->key;
>>> - int shmflg = params->flg;
>>> + int id, error, shmflg = params->flg;
>>
>> It's largely a matter of taste (and I may be in a minority), and I know
>> there's certainly precedent in the kernel code, but I don't much like the
>> style of mixing variable declarations that have initializers, with other
>> unrelated declarations (e.g., variables without initializers). What is
>> the gain? One less line of text? That's (IMO) more than offset by the
>> small loss of readability.
>
> Yes, it's taste. And yes, your in the minority, at least in many core
> kernel components and ipc.
Davidlohr,
So, noting that the minority is less small than we thought, I'll just
add this: I'd have appreciated it if your reply had been less
dismissive, and you'd actually responded to my concrete point about
loss of readability.
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: extcon-next regression ?
Hi Felipe, Thanks for your test and review. On 04/24/2014 03:28 AM, Felipe Balbi wrote: > Hi, > > On Wed, Apr 23, 2014 at 12:20:52PM -0500, Felipe Balbi wrote: >>> I've been testing extcon-next to make sure USB3 on OMAP5 will work out >>> of the box but I see a regression when I merge your tree on top of >>> v3.15-rc2 + Tony's DT fixes. >>> >>> Here's what I see (trimmed): >>> >>> [1.805870] palmas 0-0048: Muxing GPIO 2, PWM 0, LED 0 >>> [1.812516] [ cut here ] >>> [1.817387] WARNING: CPU: 0 PID: 6 at include/linux/kref.h:47 >>> kobject_get+0x64/0x78() >>> [1.817691] mmcblk0boot1: unknown partition table >>> [1.830601] Modules linked in: >>> [1.833827] CPU: 0 PID: 6 Comm: kworker/u4:0 Tainted: GW >>> 3.15.0-rc2-00041-g3019b77 #308 >>> [1.84] Workqueue: deferwq deferred_probe_work_func >>> [1.848728] mmcblk0boot0: unknown partition table >>> [1.853928] [] (unwind_backtrace) from [] >>> (show_stack+0x10/0x14) >>> [1.862086] [] (show_stack) from [] >>> (dump_stack+0x84/0x9c) >>> [1.869667] [] (dump_stack) from [] >>> (warn_slowpath_common+0x6c/0x90) >>> [1.878181] [] (warn_slowpath_common) from [] >>> (warn_slowpath_null+0x1c/0x24) >>> [1.887421] [] (warn_slowpath_null) from [] >>> (kobject_get+0x64/0x78) >>> [1.895837] [] (kobject_get) from [] >>> (device_add+0x18/0x520) >>> [1.903629] [] (device_add) from [] >>> (extcon_dev_register+0x48/0x104) >>> [1.912145] [] (extcon_dev_register) from [] >>> (devm_extcon_dev_register+0x2c/0x68) >>> [1.921847] [] (devm_extcon_dev_register) from [] >>> (palmas_usb_probe+0x110/0x304) >>> [1.931453] [] (palmas_usb_probe) from [] >>> (platform_drv_probe+0x18/0x48) >>> [1.940333] [] (platform_drv_probe) from [] >>> (driver_probe_device+0x110/0x22c) >>> [1.949664] [] (driver_probe_device) from [] >>> (bus_for_each_drv+0x58/0x8c) >>> [1.958634] [] (bus_for_each_drv) from [] >>> (device_attach+0x74/0x8c) >>> [1.967003] [] (device_attach) from [] >>> (bus_probe_device+0x88/0xb0) >>> [1.975387] [] (bus_probe_device) from [] >>> (device_add+0x420/0x520) >>> [1.983678] [] (device_add) from [] >>> (of_platform_device_create_pdata+0x6c/0x8c) >>> [1.993155] [] (of_platform_device_create_pdata) from >>> [] (of_platform_bus_create+0xdc/0x168) >>> [2.003818] [] (of_platform_bus_create) from [] >>> (of_platform_populate+0x5c/0xa0) >>> [2.013399] [] (of_platform_populate) from [] >>> (palmas_i2c_probe+0x30c/0x584) >>> [2.022606] [] (palmas_i2c_probe) from [] >>> (driver_probe_device+0x110/0x22c) >>> [2.031722] [] (driver_probe_device) from [] >>> (bus_for_each_drv+0x58/0x8c) >>> [2.040715] [] (bus_for_each_drv) from [] >>> (device_attach+0x74/0x8c) >>> [2.049098] [] (device_attach) from [] >>> (bus_probe_device+0x88/0xb0) >>> [2.057482] [] (bus_probe_device) from [] >>> (device_add+0x420/0x520) >>> [2.065774] [] (device_add) from [] >>> (i2c_new_device+0x12c/0x18c) >>> [2.073885] [] (i2c_new_device) from [] >>> (i2c_register_adapter+0x278/0x498) >>> [2.082903] [] (i2c_register_adapter) from [] >>> (omap_i2c_probe+0x4a4/0x6d0) >>> [2.091925] [] (omap_i2c_probe) from [] >>> (platform_drv_probe+0x18/0x48) >>> [2.100582] [] (platform_drv_probe) from [] >>> (driver_probe_device+0x110/0x22c) >>> [2.109883] [] (driver_probe_device) from [] >>> (bus_for_each_drv+0x58/0x8c) >>> [2.118823] [] (bus_for_each_drv) from [] >>> (device_attach+0x74/0x8c) >>> [2.127194] [] (device_attach) from [] >>> (bus_probe_device+0x88/0xb0) >>> [2.135584] [] (bus_probe_device) from [] >>> (deferred_probe_work_func+0x64/0x94) >>> [2.144975] [] (deferred_probe_work_func) from [] >>> (process_one_work+0x1ac/0x4cc) >>> [2.154545] [] (process_one_work) from [] >>> (worker_thread+0x114/0x3b4) >>> [2.163119] [] (worker_thread) from [] >>> (kthread+0xd4/0xf0) >>> [2.170695] [] (kthread) from [] >>> (ret_from_fork+0x14/0x2c) >>> [2.178259] ---[ end trace 3006de6450234d28 ]--- >>> [2.183081] kobject 'palmas_usb' (eca58c38): tried to add an >>> uninitialized object, something is seriously wrong. >>> [2.193731] CPU: 0 PID: 6 Comm: kworker/u4:0 Tainted: GW >>> 3.15.0-rc2-00041-g3019b77 #308 >>> [2.203201] Workqueue: deferwq deferred_probe_work_func >>> [2.208687] [] (unwind_backtrace) from [] >>> (show_stack+0x10/0x14) >>> [2.216789] [] (show_stack) from [] >>> (dump_stack+0x84/0x9c) >>> [2.224357] [] (dump_stack) from [] >>> (kobject_add+0x88/0x98) >>> [2.232014] [] (kobject_add) from [] >>> (device_add+0xe0/0x520) >>> [2.239758] [] (device_add) from [] >>> (extcon_dev_register+0x48/0x104) >>> [2.248235] [] (extcon_dev_register) from [] >>> (devm_extcon_dev_register+0x2c/0x68) >>> [2.257901] [] (devm_extcon_dev_register) from [] >>> (palmas_usb_probe+0x110/0x304) >>> [2.267467] [] (palmas_usb_probe) from
Re: [GIT PULL] serial: Cadence
On 04/24/2014 01:48 AM, Greg Kroah-Hartman wrote: > On Wed, Apr 23, 2014 at 08:11:15AM +0200, Michal Simek wrote: >> Hi Greg, >> >> this is around for a while and I would like to close it. >> I have applied patches 1-7 from v3. >> Patches 8 and 9 should go through arm-soc tree and I will add them >> to my zynq/dt branch. >> >> Please apply these patches to your tree. >> If this should go through different tree please let me know. >> >> Thanks, >> Michal >> >> >> The following changes since commit c9eaa447e77efe77b7fa4c953bd62de8297fd6c5: >> >> Linux 3.15-rc1 (2014-04-13 14:18:35 -0700) >> >> are available in the git repository at: >> >> git://git.monstr.eu/linux-2.6-microblaze.git tags/cadence-uart-for-3.16 > > I can't take git pulles from random internet sites, sorry. Just send > these as email and I will queue them up. I wouldn't say random. This repo is listed in my Microblaze maintainer fragment and I used signed tag and you have sign my key that's why you can easily check it. Anyway we have sent v3 patches via email twice. Origin v3: https://lkml.org/lkml/2014/3/12/499 Resent v3: https://lkml.org/lkml/2014/4/4/523 Patches 1-7 should go through your tree. That's why please apply these 7 patches to your tree. If you want to get just these 7 patches as v4, please let us know we can easily resent it. Thanks, Michal -- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/ Maintainer of Linux kernel - Xilinx Zynq ARM architecture Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform signature.asc Description: OpenPGP digital signature
Re: extcon-next regression ?
Hi Felipe, Thanks for your test and review. On 04/24/2014 02:20 AM, Felipe Balbi wrote: > Hi, > > On Wed, Apr 23, 2014 at 11:40:33AM -0500, Felipe Balbi wrote: >> Hi Chanwoo, >> >> I've been testing extcon-next to make sure USB3 on OMAP5 will work out >> of the box but I see a regression when I merge your tree on top of >> v3.15-rc2 + Tony's DT fixes. >> >> Here's what I see (trimmed): >> >> [1.805870] palmas 0-0048: Muxing GPIO 2, PWM 0, LED 0 >> [1.812516] [ cut here ] >> [1.817387] WARNING: CPU: 0 PID: 6 at include/linux/kref.h:47 >> kobject_get+0x64/0x78() >> [1.817691] mmcblk0boot1: unknown partition table >> [1.830601] Modules linked in: >> [1.833827] CPU: 0 PID: 6 Comm: kworker/u4:0 Tainted: GW >> 3.15.0-rc2-00041-g3019b77 #308 >> [1.84] Workqueue: deferwq deferred_probe_work_func >> [1.848728] mmcblk0boot0: unknown partition table >> [1.853928] [] (unwind_backtrace) from [] >> (show_stack+0x10/0x14) >> [1.862086] [] (show_stack) from [] >> (dump_stack+0x84/0x9c) >> [1.869667] [] (dump_stack) from [] >> (warn_slowpath_common+0x6c/0x90) >> [1.878181] [] (warn_slowpath_common) from [] >> (warn_slowpath_null+0x1c/0x24) >> [1.887421] [] (warn_slowpath_null) from [] >> (kobject_get+0x64/0x78) >> [1.895837] [] (kobject_get) from [] >> (device_add+0x18/0x520) >> [1.903629] [] (device_add) from [] >> (extcon_dev_register+0x48/0x104) >> [1.912145] [] (extcon_dev_register) from [] >> (devm_extcon_dev_register+0x2c/0x68) >> [1.921847] [] (devm_extcon_dev_register) from [] >> (palmas_usb_probe+0x110/0x304) >> [1.931453] [] (palmas_usb_probe) from [] >> (platform_drv_probe+0x18/0x48) >> [1.940333] [] (platform_drv_probe) from [] >> (driver_probe_device+0x110/0x22c) >> [1.949664] [] (driver_probe_device) from [] >> (bus_for_each_drv+0x58/0x8c) >> [1.958634] [] (bus_for_each_drv) from [] >> (device_attach+0x74/0x8c) >> [1.967003] [] (device_attach) from [] >> (bus_probe_device+0x88/0xb0) >> [1.975387] [] (bus_probe_device) from [] >> (device_add+0x420/0x520) >> [1.983678] [] (device_add) from [] >> (of_platform_device_create_pdata+0x6c/0x8c) >> [1.993155] [] (of_platform_device_create_pdata) from >> [] (of_platform_bus_create+0xdc/0x168) >> [2.003818] [] (of_platform_bus_create) from [] >> (of_platform_populate+0x5c/0xa0) >> [2.013399] [] (of_platform_populate) from [] >> (palmas_i2c_probe+0x30c/0x584) >> [2.022606] [] (palmas_i2c_probe) from [] >> (driver_probe_device+0x110/0x22c) >> [2.031722] [] (driver_probe_device) from [] >> (bus_for_each_drv+0x58/0x8c) >> [2.040715] [] (bus_for_each_drv) from [] >> (device_attach+0x74/0x8c) >> [2.049098] [] (device_attach) from [] >> (bus_probe_device+0x88/0xb0) >> [2.057482] [] (bus_probe_device) from [] >> (device_add+0x420/0x520) >> [2.065774] [] (device_add) from [] >> (i2c_new_device+0x12c/0x18c) >> [2.073885] [] (i2c_new_device) from [] >> (i2c_register_adapter+0x278/0x498) >> [2.082903] [] (i2c_register_adapter) from [] >> (omap_i2c_probe+0x4a4/0x6d0) >> [2.091925] [] (omap_i2c_probe) from [] >> (platform_drv_probe+0x18/0x48) >> [2.100582] [] (platform_drv_probe) from [] >> (driver_probe_device+0x110/0x22c) >> [2.109883] [] (driver_probe_device) from [] >> (bus_for_each_drv+0x58/0x8c) >> [2.118823] [] (bus_for_each_drv) from [] >> (device_attach+0x74/0x8c) >> [2.127194] [] (device_attach) from [] >> (bus_probe_device+0x88/0xb0) >> [2.135584] [] (bus_probe_device) from [] >> (deferred_probe_work_func+0x64/0x94) >> [2.144975] [] (deferred_probe_work_func) from [] >> (process_one_work+0x1ac/0x4cc) >> [2.154545] [] (process_one_work) from [] >> (worker_thread+0x114/0x3b4) >> [2.163119] [] (worker_thread) from [] >> (kthread+0xd4/0xf0) >> [2.170695] [] (kthread) from [] >> (ret_from_fork+0x14/0x2c) >> [2.178259] ---[ end trace 3006de6450234d28 ]--- >> [2.183081] kobject 'palmas_usb' (eca58c38): tried to add an >> uninitialized object, something is seriously wrong. >> [2.193731] CPU: 0 PID: 6 Comm: kworker/u4:0 Tainted: GW >> 3.15.0-rc2-00041-g3019b77 #308 >> [2.203201] Workqueue: deferwq deferred_probe_work_func >> [2.208687] [] (unwind_backtrace) from [] >> (show_stack+0x10/0x14) >> [2.216789] [] (show_stack) from [] >> (dump_stack+0x84/0x9c) >> [2.224357] [] (dump_stack) from [] >> (kobject_add+0x88/0x98) >> [2.232014] [] (kobject_add) from [] >> (device_add+0xe0/0x520) >> [2.239758] [] (device_add) from [] >> (extcon_dev_register+0x48/0x104) >> [2.248235] [] (extcon_dev_register) from [] >> (devm_extcon_dev_register+0x2c/0x68) >> [2.257901] [] (devm_extcon_dev_register) from [] >> (palmas_usb_probe+0x110/0x304) >> [2.267467] [] (palmas_usb_probe) from [] >> (platform_drv_probe+0x18/0x48) >> [2.276298] [] (platform_drv_probe) from [] >>
[PATCH] Input: evdev - get rid of old workaround for EVIOCGBIT
We put this workaround in 2008 and the offending userspace has been fixed
up long time ago; the link in the message is no longer valid either, so it
is time to retire it.
Signed-off-by: Dmitry Torokhov
---
drivers/input/evdev.c | 18 --
1 file changed, 18 deletions(-)
diff --git a/drivers/input/evdev.c b/drivers/input/evdev.c
index ce953d8..fd325ec 100644
--- a/drivers/input/evdev.c
+++ b/drivers/input/evdev.c
@@ -629,12 +629,10 @@ static int str_to_user(const char *str, unsigned int
maxlen, void __user *p)
return copy_to_user(p, str, len) ? -EFAULT : len;
}
-#define OLD_KEY_MAX0x1ff
static int handle_eviocgbit(struct input_dev *dev,
unsigned int type, unsigned int size,
void __user *p, int compat_mode)
{
- static unsigned long keymax_warn_time;
unsigned long *bits;
int len;
@@ -652,24 +650,8 @@ static int handle_eviocgbit(struct input_dev *dev,
default: return -EINVAL;
}
- /*
-* Work around bugs in userspace programs that like to do
-* EVIOCGBIT(EV_KEY, KEY_MAX) and not realize that 'len'
-* should be in bytes, not in bits.
-*/
- if (type == EV_KEY && size == OLD_KEY_MAX) {
- len = OLD_KEY_MAX;
- if (printk_timed_ratelimit(&keymax_warn_time, 10 * 1000))
- pr_warning("(EVIOCGBIT): Suspicious buffer size %u, "
- "limiting output to %zu bytes. See "
-
"http://userweb.kernel.org/~dtor/eviocgbit-bug.html\n";,
- OLD_KEY_MAX,
- BITS_TO_LONGS(OLD_KEY_MAX) * sizeof(long));
- }
-
return bits_to_user(bits, len, size, p, compat_mode);
}
-#undef OLD_KEY_MAX
static int evdev_handle_get_keycode(struct input_dev *dev, void __user *p)
{
--
1.9.0
--
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/
linux-next: manual merge of the akpm-current tree with the arm tree
Hi Andrew,
Today's linux-next merge of the akpm-current tree got a conflict in
arch/arm/include/asm/fixmap.h between commits 4221e2e6b316 ("ARM: 8031/1:
fixmap: remove FIX_KMAP_BEGIN and FIX_KMAP_END") and a05e54c103b0 ("ARM:
8031/2: change fixmap mapping region to support 32 CPUs") from the arm
tree and commit a665f864487d ("arm: use generic fixmap.h") from the
akpm-current tree.
I fixed it up (I have just dropped the akpm-current tree patch for now)
and can carry the fix as necessary (no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpuhQDck2At7.pgp
Description: PGP signature
Re: [PATCH] Input: atkbd - fix keyboard LG Electronics
On Tue, Apr 22, 2014 at 06:51:22PM -0700, Sheng-Liang Song wrote:
> After issuing ATKBD_CMD_RESET_DIS, LG Keyboard stop working.
> The workaround is to remove ATKBD_CMD_RESET_DIS for LG Keyboards.
>
> In order to keep the minimum changes to the current atkbd driver,
> I add logic to apply the patch if and only if the device is LG LW25-B7HV or
> P1-J273B.
How about if we rework this just a little bit... Does the version of the
patch below work for you?
Also, I do need your "signed-off-by".
Thanks!
--
Dmitry
Input: atkbd - fix keyboard LG Electronics
From: Sheng-Liang Song
After issuing ATKBD_CMD_RESET_DIS, LG Keyboard stop working. The
workaround is to remove ATKBD_CMD_RESET_DIS for LG Keyboards.
In order to keep the minimum changes to the current atkbd driver, I add
logic to apply the patch if and only if the device is LG LW25-B7HV or
P1-J273B.
Signed-off-by: Dmitry Torokhov
---
drivers/input/keyboard/atkbd.c | 30 --
1 file changed, 28 insertions(+), 2 deletions(-)
diff --git a/drivers/input/keyboard/atkbd.c b/drivers/input/keyboard/atkbd.c
index 2626773..06a4b0d 100644
--- a/drivers/input/keyboard/atkbd.c
+++ b/drivers/input/keyboard/atkbd.c
@@ -243,6 +243,12 @@ static void (*atkbd_platform_fixup)(struct atkbd *, const
void *data);
static void *atkbd_platform_fixup_data;
static unsigned int (*atkbd_platform_scancode_fixup)(struct atkbd *, unsigned
int);
+/*
+ * Certain keyboards to not like ATKBD_CMD_RESET_DIS and stop responding
+ * to many commands until full reset (ATKBD_CMD_RESET_BAT) is performed.
+ */
+static bool atkbd_skip_deactivate;
+
static ssize_t atkbd_attr_show_helper(struct device *dev, char *buf,
ssize_t (*handler)(struct atkbd *, char *));
static ssize_t atkbd_attr_set_helper(struct device *dev, const char *buf,
size_t count,
@@ -698,7 +704,6 @@ static int atkbd_activate(struct atkbd *atkbd)
* atkbd_deactivate() resets and disables the keyboard from sending
* keystrokes.
*/
-
static void atkbd_deactivate(struct atkbd *atkbd)
{
struct ps2dev *ps2dev = &atkbd->ps2dev;
@@ -768,7 +773,8 @@ static int atkbd_probe(struct atkbd *atkbd)
* Make sure nothing is coming from the keyboard and disturbs our
* internal state.
*/
- atkbd_deactivate(atkbd);
+ if (!atkbd_skip_deactivate)
+ atkbd_deactivate(atkbd);
return 0;
}
@@ -1638,6 +1644,12 @@ static int __init atkbd_setup_scancode_fixup(const
struct dmi_system_id *id)
return 1;
}
+static int __init atkbd_deactivate_fixup(const struct dmi_system_id *id)
+{
+ atkbd_skip_deactivate = true;
+ return 1;
+}
+
static const struct dmi_system_id atkbd_dmi_quirk_table[] __initconst = {
{
.matches = {
@@ -1775,6 +1787,20 @@ static const struct dmi_system_id
atkbd_dmi_quirk_table[] __initconst = {
.callback = atkbd_setup_scancode_fixup,
.driver_data = atkbd_oqo_01plus_scancode_fixup,
},
+ {
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "LG Electronics"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "LW25-B7HV"),
+ },
+ .callback = atkbd_deactivate_fixup,
+ },
+ {
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "LG Electronics"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "P1-J273B"),
+ },
+ .callback = atkbd_deactivate_fixup,
+ },
{ }
};
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: in kernel 2.6.x, tun/tap nic supports vlan packets
On Thu, Apr 24, 2014 at 10:10:08AM +0800, zhuyj wrote: > On 04/23/2014 07:41 PM, Ben Hutchings wrote: > >On Wed, 2014-04-23 at 15:48 +0800, zhuyj wrote: > >>On 04/23/2014 01:53 AM, Ben Hutchings wrote: > >[...] > >>>For what it's worth, I would recommend against applying this. I don't > >>>think even Red Hat has backported the VLAN changes, and they have been > >>>quite aggressive about backporting features to RHEL 6. > >>If we do not merge these patches, maybe RHEL 6 can not make tap driver > >>support vlan well. > >RHEL 6 isn't based on 2.6.32.y, they do all their own backporting. > Hi, Ben > > It is well known that extraction vlan tag is not implemented in kernel > 2.6.32.y. Kernel 2.6.32.y depends on nic hardware to extract vlan tag. > So if the patches are not applied, tap driver can not support vlan well. What Ben is saying is that RHEL doesn't use 2.6.32.y, but did their own fork of 2.6.32 so even if we merged your patch, they wouldn't pick it from this tree anyway. However they could possibly take your patch if some customers requested the feature even if it's not in 2.6.32.y. Clearly, the fact that nobody complained about this in 4.5 years of 2.6.32 means that there's no particular reason any user would suddenly miss it now. 2.6.32.y is mostly used to update existing deployments but rarely for new deployments. That's why the usefulness of your backport in this kernel for its users is likely limited, and at the same time the risk of causing a regression is far from being null for existing users (eg: if some worked around the issue a different way, their workaround would likely not work anymore). Best regards, Willy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [REGRESSION] Media keys cause "ACPI: \_SB_.ATKD: Unsupported event" on ASUS laptop
On Thu, Apr 17, 2014 at 02:11:15PM +0300, Mantas Mikulėnas wrote: > After commit 1a699476e258 [two months ago], Linux has stopped > recognizing the media & function keys on my laptop's keyboard (the > laptop is ASUS K52JT.206). > > When I press any of the Fn keys (Play/Pause, Stop, Prev, Next, Vol+, > Vol-, Mute, WiFi, Brightness +/-...), I get the following messages in dmesg: > > | ACPI: \_SB_.ATKD: Unsupported event type 0x45 > | ACPI: \_SB_.ATKD: Unsupported event type 0x43 > | ACPI: \_SB_.ATKD: Unsupported event type 0x40 > | etc. I'm seeing the same problem with an EeePC 900's volume and brightness keys: [ 90.098518] ACPI: \_SB_.ATKD: Unsupported event type 0x14 [ 90.785202] ACPI: \_SB_.ATKD: Unsupported event type 0x15 [ 457.062072] ACPI: \_SB_.ATKD: Unsupported event type 0x2e [ 457.926754] ACPI: \_SB_.ATKD: Unsupported event type 0x2d [ 458.418740] ACPI: \_SB_.ATKD: Unsupported event type 0x2c [ 458.821482] ACPI: \_SB_.ATKD: Unsupported event type 0x2b [ 459.240896] ACPI: \_SB_.ATKD: Unsupported event type 0x2a > In the past (v3.14 and earlier), those used to be reported as ACPI and > input events. From `acpi_listen` on a good kernel: > > | hotkey ATK0100:00 0045 > | cd/play CDPLAY 0080 K > | > | hotkey ATK0100:00 0031 000d > | button/volumedown VOLDN 0080 K > | > | hotkey ATK0100:00 0016 > | > | hotkey ATK0100:00 0025 0001 > > Bisect output: > > 1a699476e25814343766342672c655fb135224cc is the first bad commit > commit 1a699476e25814343766342672c655fb135224cc > Author: Rafael J. Wysocki > Date: Thu Feb 6 13:58:13 2014 +0100 > > ACPI / hotplug / PCI: Hotplug notifications from acpi_bus_notify() > > Since acpi_bus_notify() is executed on all notifications for all > devices anyway, make it execute acpi_device_hotplug() for all > hotplug events instead of installing notify handlers pointing to > the same function for all hotplug devices. > [...] > > * Linux 3.14.0-rc1-00023-g1a699476e258 (bad) > * Linux 3.14.0-rc1-00022-g5e6f236c2631 (good) > > (I'm not quite sure why they show up as 3.14-rc1 if they're after 3.14?) > > The kernel config is close to that of stock Arch Linux, except with > entirely irrelevant devices disabled (PATA, SCSI, tuner, etc.) Adding email addresses recommended by get_maintainer.pl to see if that helps this to get noticed... -- Sitsofe | http://sucs.org/~sits/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv2 6/9] extcon: palmas: Use devm_extcon_dev_allocate for extcon_dev
Hi Kishon, Felipe,
If you possible, I'd like you to test or review this patch.
And then I'll apply it on extcon-next branch if you could give
me a acked or tested message.
- This patch has a depenency on extcon-next branch.
Following patchset support devm_extcon_dev_* function.
[1] https://lkml.org/lkml/2014/4/21/140
[2] https://lkml.org/lkml/2014/4/21/164
Thanks,
Chanwoo Choi
On 04/21/2014 09:02 PM, Chanwoo Choi wrote:
> This patch use devm_extcon_dev_allocate() to simplify the memory control
> of extcon device.
>
> Cc: Graeme Gregory
> Cc: Kishon Vijay Abraham I
> Cc: Felipe Balbi
> Cc: Samuel Ortiz
> Cc: Lee Jones
> Signed-off-by: Chanwoo Choi
> ---
> drivers/extcon/extcon-palmas.c | 35 ---
> include/linux/mfd/palmas.h | 2 +-
> 2 files changed, 21 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/extcon/extcon-palmas.c b/drivers/extcon/extcon-palmas.c
> index 1a770e0..a9299ea 100644
> --- a/drivers/extcon/extcon-palmas.c
> +++ b/drivers/extcon/extcon-palmas.c
> @@ -57,7 +57,7 @@ static irqreturn_t palmas_vbus_irq_handler(int irq, void
> *_palmas_usb)
> if (vbus_line_state & PALMAS_INT3_LINE_STATE_VBUS) {
> if (palmas_usb->linkstat != PALMAS_USB_STATE_VBUS) {
> palmas_usb->linkstat = PALMAS_USB_STATE_VBUS;
> - extcon_set_cable_state(&palmas_usb->edev, "USB", true);
> + extcon_set_cable_state(palmas_usb->edev, "USB", true);
> dev_info(palmas_usb->dev, "USB cable is attached\n");
> } else {
> dev_dbg(palmas_usb->dev,
> @@ -66,7 +66,7 @@ static irqreturn_t palmas_vbus_irq_handler(int irq, void
> *_palmas_usb)
> } else if (!(vbus_line_state & PALMAS_INT3_LINE_STATE_VBUS)) {
> if (palmas_usb->linkstat == PALMAS_USB_STATE_VBUS) {
> palmas_usb->linkstat = PALMAS_USB_STATE_DISCONNECT;
> - extcon_set_cable_state(&palmas_usb->edev, "USB", false);
> + extcon_set_cable_state(palmas_usb->edev, "USB", false);
> dev_info(palmas_usb->dev, "USB cable is detached\n");
> } else {
> dev_dbg(palmas_usb->dev,
> @@ -93,7 +93,7 @@ static irqreturn_t palmas_id_irq_handler(int irq, void
> *_palmas_usb)
> PALMAS_USB_ID_INT_LATCH_CLR,
> PALMAS_USB_ID_INT_EN_HI_CLR_ID_GND);
> palmas_usb->linkstat = PALMAS_USB_STATE_ID;
> - extcon_set_cable_state(&palmas_usb->edev, "USB-HOST", true);
> + extcon_set_cable_state(palmas_usb->edev, "USB-HOST", true);
> dev_info(palmas_usb->dev, "USB-HOST cable is attached\n");
> } else if ((set & PALMAS_USB_ID_INT_SRC_ID_FLOAT) &&
> (id_src & PALMAS_USB_ID_INT_SRC_ID_FLOAT)) {
> @@ -101,17 +101,17 @@ static irqreturn_t palmas_id_irq_handler(int irq, void
> *_palmas_usb)
> PALMAS_USB_ID_INT_LATCH_CLR,
> PALMAS_USB_ID_INT_EN_HI_CLR_ID_FLOAT);
> palmas_usb->linkstat = PALMAS_USB_STATE_DISCONNECT;
> - extcon_set_cable_state(&palmas_usb->edev, "USB-HOST", false);
> + extcon_set_cable_state(palmas_usb->edev, "USB-HOST", false);
> dev_info(palmas_usb->dev, "USB-HOST cable is detached\n");
> } else if ((palmas_usb->linkstat == PALMAS_USB_STATE_ID) &&
> (!(set & PALMAS_USB_ID_INT_SRC_ID_GND))) {
> palmas_usb->linkstat = PALMAS_USB_STATE_DISCONNECT;
> - extcon_set_cable_state(&palmas_usb->edev, "USB-HOST", false);
> + extcon_set_cable_state(palmas_usb->edev, "USB-HOST", false);
> dev_info(palmas_usb->dev, "USB-HOST cable is detached\n");
> } else if ((palmas_usb->linkstat == PALMAS_USB_STATE_DISCONNECT) &&
> (id_src & PALMAS_USB_ID_INT_SRC_ID_GND)) {
> palmas_usb->linkstat = PALMAS_USB_STATE_ID;
> - extcon_set_cable_state(&palmas_usb->edev, "USB-HOST", true);
> + extcon_set_cable_state(palmas_usb->edev, "USB-HOST", true);
> dev_info(palmas_usb->dev, " USB-HOST cable is attached\n");
> }
>
> @@ -187,15 +187,20 @@ static int palmas_usb_probe(struct platform_device
> *pdev)
>
> platform_set_drvdata(pdev, palmas_usb);
>
> - palmas_usb->edev.supported_cable = palmas_extcon_cable;
> - palmas_usb->edev.dev.parent = palmas_usb->dev;
> - palmas_usb->edev.name = kstrdup(node->name, GFP_KERNEL);
> - palmas_usb->edev.mutually_exclusive = mutually_exclusive;
> + palmas_usb->edev = devm_extcon_dev_allocate(&pdev->dev,
> + palmas_extcon_cable);
> + if (!palmas_usb->edev) {
> + dev_err(&pdev->dev, "failed to allocate extcon device\n");
> + return -ENOMEM;
> + }
> + palmas_usb->
Re: How do I make a clean mount namespace?
On Wed, Apr 23, 2014 at 7:39 PM, Al Viro wrote:
> On Tue, Apr 22, 2014 at 03:12:11PM -0700, Andy Lutomirski wrote:
>> I want to set up a little container. So I unshare the mount namespace
>> and mount something somewhere (say /mnt) that I want to be my new
>> root. Now what?
>>
>> pivot_root("/mnt", "/mnt/garbage") seems to frequently return -EBUSY.
>
> RTFM. Literally - man 2 pivot_root and look for the only place where
> it mentions EBUSY.
>
> If you get that error, check what you've got in /proc/mounts (in the
> namespace your process is in, obviously) just before the syscall.
> With these arguments you really want /mnt to be a mountpoint. If your
> new root really lives on the same fs as the old one, just do
> mount --bind /mnt /mnt before any other mounts.
Wow -- thanks! I read that part, but I'm apparently bad at following
directions.
Should I expect things to work if I unshare mounts but don't do a
mount --make-rprivate / before the pivot_rot?
--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 v2] dma: imx-sdma: add support for sdma memory copy
add "device_prep_dma_memcpy" and "device_prep_dma_sg" for memory copy by sdma.
Signed-off-by: Robin Gong
---
change:
--v2:
1. correct some printk format, such as %pad for dma_addr_t
2. split duplicated code in prep_dma_memcpy and prep_dma_sg to make code
clean.
---
drivers/dma/imx-sdma.c | 253 ---
1 files changed, 194 insertions(+), 59 deletions(-)
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index 4e79183..eb62ebc 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -229,6 +229,7 @@ struct sdma_context_data {
} __attribute__ ((packed));
#define NUM_BD (int)(PAGE_SIZE / sizeof(struct sdma_buffer_descriptor))
+#define SDMA_BD_MAX_CNT(0xfffc) /* align with 4 bytes */
struct sdma_engine;
@@ -260,6 +261,7 @@ struct sdma_channel {
unsigned intpc_from_device, pc_to_device;
unsigned long flags;
dma_addr_t per_address;
+ unsigned intpc_to_pc;
unsigned long event_mask[2];
unsigned long watermark_level;
u32 shp_addr, per_addr;
@@ -694,6 +696,7 @@ static void sdma_get_pc(struct sdma_channel *sdmac,
sdmac->pc_from_device = 0;
sdmac->pc_to_device = 0;
+ sdmac->pc_to_pc = 0;
switch (peripheral_type) {
case IMX_DMATYPE_MEMORY:
@@ -763,6 +766,7 @@ static void sdma_get_pc(struct sdma_channel *sdmac,
sdmac->pc_from_device = per_2_emi;
sdmac->pc_to_device = emi_2_per;
+ sdmac->pc_to_pc = emi_2_emi;
}
static int sdma_load_context(struct sdma_channel *sdmac)
@@ -775,11 +779,12 @@ static int sdma_load_context(struct sdma_channel *sdmac)
int ret;
unsigned long flags;
- if (sdmac->direction == DMA_DEV_TO_MEM) {
+ if (sdmac->direction == DMA_DEV_TO_MEM)
load_address = sdmac->pc_from_device;
- } else {
+ else if (sdmac->direction == DMA_MEM_TO_MEM)
+ load_address = sdmac->pc_to_pc;
+ else
load_address = sdmac->pc_to_device;
- }
if (load_address < 0)
return load_address;
@@ -1010,99 +1015,206 @@ static void sdma_free_chan_resources(struct dma_chan
*chan)
clk_disable(sdma->clk_ahb);
}
-static struct dma_async_tx_descriptor *sdma_prep_slave_sg(
- struct dma_chan *chan, struct scatterlist *sgl,
- unsigned int sg_len, enum dma_transfer_direction direction,
- unsigned long flags, void *context)
+static int sdma_transfer_init(struct sdma_channel *sdmac,
+ enum dma_transfer_direction direction)
+{
+ int ret = 0;
+
+ sdmac->status = DMA_IN_PROGRESS;
+ sdmac->buf_tail = 0;
+ sdmac->flags = 0;
+ sdmac->direction = direction;
+
+ ret = sdma_load_context(sdmac);
+ if (ret)
+ return ret;
+
+ sdmac->chn_count = 0;
+
+ return ret;
+}
+
+static int check_bd_buswidth(struct sdma_buffer_descriptor *bd,
+struct sdma_channel *sdmac, int count,
+dma_addr_t dma_dst, dma_addr_t dma_src)
+{
+ int ret = 0;
+
+ if (sdmac->word_size > DMA_SLAVE_BUSWIDTH_4_BYTES)
+ ret = -EINVAL;
+
+ switch (sdmac->word_size) {
+ case DMA_SLAVE_BUSWIDTH_4_BYTES:
+ bd->mode.command = 0;
+ if ((count | dma_dst | dma_src) & 3)
+ ret = -EINVAL;
+ break;
+ case DMA_SLAVE_BUSWIDTH_2_BYTES:
+ bd->mode.command = 2;
+ if ((count | dma_dst | dma_src) & 1)
+ ret = -EINVAL;
+ break;
+ case DMA_SLAVE_BUSWIDTH_1_BYTE:
+ bd->mode.command = 1;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ return ret;
+}
+
+static struct dma_async_tx_descriptor *sdma_prep_memcpy(
+ struct dma_chan *chan, dma_addr_t dma_dst,
+ dma_addr_t dma_src, size_t len, unsigned long flags)
{
struct sdma_channel *sdmac = to_sdma_chan(chan);
struct sdma_engine *sdma = sdmac->sdma;
- int ret, i, count;
int channel = sdmac->channel;
- struct scatterlist *sg;
+ size_t count;
+ int i = 0, param;
+ struct sdma_buffer_descriptor *bd;
- if (sdmac->status == DMA_IN_PROGRESS)
+ if (!chan || !len || sdmac->status == DMA_IN_PROGRESS)
return NULL;
- sdmac->status = DMA_IN_PROGRESS;
- sdmac->flags = 0;
-
- sdmac->buf_tail = 0;
+ if (len >= NUM_BD * SDMA_BD_MAX_CNT) {
+ dev_err(sdma->dev, "channel%d: maximum bytes exceeded:%zu >
%d\n"
+ , channel, len, NUM_BD * SDMA_BD_MAX_CNT);
+ goto err_out;
+ }
- dev_dbg(sdma-
RE: [RFC PATCH 2/2] PCI: exynos: Add PCIe support for Samsung GH7 SoC
Arnd Bergmann wrote: > > On Wednesday 23 April 2014 15:23:16 Liviu Dudau wrote: > > > Unfortunately we are in a tricky situation on arm64 because we have > > > to support both server-type SoCs and embedded-type SoCs. In an > > > embedded system, you can't trust the boot loader to do a proper > > > setup of all the hardware, so the kernel needs full control over > > > all the initialization. In a server, the initialization is the > > > responsibility of the firmware, and we don't want the kernel to > > > even know about those registers. BTW, actually we can trust boot-loader to do required things in mobile also ;-) > > > > > > My hope is that all server chips use an SBSA compliant PCIe > > > implementation, but we already have X-Gene, which is doing server > > > workloads with a nonstandard PCIe, and it's possible that there > > > will also be server-like systems with a DesignWare PCIe block > > > instead of an SBSA compliant one. We can still support those, but > > > I don't want to see more than one implementation of dw-pcie > > > on servers. Just like we have the generic PCIe support that Will > > > is doing for virtual machines and SBSA compliant systems, we > > > would do one dw-pcie variant for all systems that come with a > > > host firmware and rely on it being set up already. OK and I think, just one device driver would be nice for whatever embedded or server. > > > > There is nothing in the SBSA that mandates firmware setup. All it requires Yeah, I couldn't look at that in the SBSA... > > is that hardware is setup in a way that is not specific to a board > > or a particular OEM. Surely if the setup being done for GH7 is always > > the same it should fit the bill? > But Arnd's comments are about firmware based on each SoC not board?... > GH7 is already not SBSA compliant because it uses a nonstandard config > space access method, and it uses its own MSI controller rather than GIC. > This means it violates at least two out of the four clauses in SBSA > describing PCIe. > OK, I see. Honestly, we just focused on how to support PCI on both exynos5440 and GH7 SoCs. > Regardless of this, the level of detail describing config space and > MSI handling in SBSA can only make sense if the purpose is to handle > all compliant implementations without platform specific code. If you > require platform specific setup code in the OS, this underlying assumption > no longer holds true and there is no point in having a spec in the > first place. > OK, your assumption makes sense to us. > I think we should treat DW-PCIe in the same way if anyone attempts > to use that in a server, e.g. in SBSA level 0. As you can see here, Agreed. BTW, how about GICv2m for level 1? It can be supported with the same way in one DW-PCIe driver? > even when reusing hardware between Exynos and GH7, you can't just > use the same init code, so it has to be in firmware to be any good. > On a real server platform, you can't require a kernel upgrade every > time a new SoC comes out, any basic functionality like PCI just has to > work with existing OS images. > OK, when Will's driver is ready, we will test it on GH7 with the setup for PCIe included in firmware. Anyway I hope we can use the driver in 3.16 :-) Thanks, Kukjin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] x86-64: espfix for 64-bit mode *PROTOTYPE*
On Wed, Apr 23, 2014 at 9:13 PM, comex wrote: > On Mon, Apr 21, 2014 at 6:47 PM, H. Peter Anvin wrote: >> This is a prototype of espfix for the 64-bit kernel. espfix is a >> workaround for the architectural definition of IRET, which fails to >> restore bits [31:16] of %esp when returning to a 16-bit stack >> segment. We have a workaround for the 32-bit kernel, but that >> implementation doesn't work for 64 bits. > > Hi, > > A comment: The main purpose of espfix is to prevent attackers from > learning sensitive addresses, right? But as far as I can tell, this > mini-stack becomes itself somewhat sensitive: > > - The user can put arbitrary data in registers before returning to the > LDT in order to get it saved at a known address accessible from the > kernel. With SMAP and KASLR this might otherwise be difficult. For one thing, this only matters on Haswell. Otherwise the user can put arbitrary data in userspace. On Haswell, the HPET fixmap is currently a much simpler vector that can do much the same thing, as long as you're willing to wait for the HPET counter to contain some particular value. I have patches that will fix that as a side effect. Would it pay to randomize the location of the espfix area? Another somewhat silly idea is to add some random offset to the CPU number mod NR_CPUS so that at attacker won't know which ministack is which. > - If the iret faults, kernel addresses will get stored there (and not > cleared). If a vulnerability could return data from an arbitrary > specified address to the user, this would be harmful. Can this be fixed by clearing the ministack in bad_iret? There will still be a window in which the kernel address is in there, but it'll be short. > > I guess with the current KASLR implementation you could get the same > effects via brute force anyway, by filling up and browsing memory, > respectively, but ideally there wouldn't be any virtual addresses > guaranteed not to fault. > > - If a vulnerability allowed overwriting data at an arbitrary > specified address, the exception frame could get overwritten at > exactly the right moment between the copy and iret (or right after the > iret to mess up fixup_exception)? You probably know better than I > whether or not caches prevent this from actually being possible. To attack this, you'd change the saved CS value. I don't think caches would make a difference. This particular vector hurts: you can safely keep trying until it works. This just gave me an evil idea: what if we make the whole espfix area read-only? This has some weird effects. To switch to the espfix stack, you have to write to an alias. That's a little strange but harmless and barely complicates the implementation. If the iret faults, though, I think the result will be a #DF. This may actually be a good thing: if the #DF handler detects that the cause was a bad espfix iret, it could just return directly to bad_iret or send the signal itself the same way that do_stack_segment does. This could even be written in C :) Peter, is this idea completely nuts? The only exceptions that can happen there are NMI, MCE, #DB, #SS, and #GP. The first four use IST, so they won't double-fault. --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/
Re: [Query]: hrtimers: why don't we consider hrtimers in get_next_timer_interrupt()
Hi Preeti, On 23 April 2014 17:54, Preeti Murthy wrote: > On Wed, Apr 23, 2014 at 3:08 PM, Viresh Kumar wrote: > In case of high resolution mode, the clock device would have > already been programmed for the upcoming hrtimer, the last > time the list of hrtimers was evaluated. So we have > already taken care of hrtimers to expire next. I actually missed this part and things look correct with this. We aren't choosing the next device event here but just the next time we need tick. 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] iio: adc: Nothing in ADC should be a bool CONFIG
On 23/04/14 22:54, Doug Anderson wrote: Jonathan, On Wed, Apr 23, 2014 at 1:54 PM, Jonathan Cameron wrote: On 22/04/14 01:03, Doug Anderson wrote: The whole IIO subsystem can be moved to a module. If you make it a module then stuff marked as "Y" in the adc directory simply won't be linked in properly. The two configs that were wrong were EXYNOS_ADC and LP8788_ADC. I know for a fact that EXYNOS_ADC will work as a module (though it appears to crash when you unload it--that needs to be addressed separately). I'd really like to see this pinned down before taking this patch. I can see you argument that the current approach is clearly wrong, but swapping one issue for another is not an approach I'd particularly like to take... I can't immediately spot the cause of the crash, but there are certainly some interesting order issues in this driver. Not enabling the vdd regulator until after the userspace interfaces are exposed (by the iio_device_register call) is interesting for a start. The remove doesn't run in the reverse of the probe order (see clocks vs regulators for example.) Gah, my reviewing for one clearly missed some things in this driver. OK, fair enough. I took a quick look and couldn't spot anything either. I've requested that Samsung dig into these problems. If they are unable to I will take a crack at it as time permits. ;) Cool and good luck (either way ;) Thanks! -Doug -- To unsubscribe from this list: send the line "unsubscribe linux-iio" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 6/9] drivers/staging/speakup/: avoid world-writable sysfs files.
Greg Kroah-Hartman writes: > On Tue, Apr 22, 2014 at 01:03:29PM +0930, Rusty Russell wrote: >> In line with practice for module parameters, we're adding a build-time >> check that sysfs files aren't world-writable. > > Then why not just use the __ATTR_RO() macro? Hmm, I didn't know those variants existed :( But most of these are not amenable to __ATTR_RO etc, since they call generic helpers, eg: __ATTR(delimiters, S_IWUGO|S_IRUGO, punc_show, punc_store); I dislike the __ATTR_RO etc macros: hiding the references to the function from grep is Too Much Magic. (Sure, I do it in module_param, but that has the excuse that it allows typechecking as well). > I'd prefer some "standard" permissions for all of these sysfs files, > it's quite confusing otherwise, don't you agree? Agreed. So I used S_IWUSR | S_IRUGO everywhere, which is what ATTR_RW uses. Cheers, Rusty. Subject: drivers/staging/speakup/: avoid world-writable sysfs files. In line with practice for module parameters, we're adding a build-time check that sysfs files aren't world-writable. Cc: Christopher Brannon Cc: Samuel Thibault Cc: Greg Kroah-Hartman Signed-off-by: Rusty Russell diff --git a/drivers/staging/speakup/kobjects.c b/drivers/staging/speakup/kobjects.c index 1ca91f7092b1..bca5f4f8a8bb 100644 --- a/drivers/staging/speakup/kobjects.c +++ b/drivers/staging/speakup/kobjects.c @@ -851,75 +851,75 @@ static ssize_t message_store(struct kobject *kobj, struct kobj_attribute *attr, * Declare the attributes. */ static struct kobj_attribute keymap_attribute = - __ATTR(keymap, S_IWUSR|S_IRUGO, keymap_show, keymap_store); + __ATTR_RW(keymap); static struct kobj_attribute silent_attribute = - __ATTR(silent, S_IWUGO, NULL, silent_store); + __ATTR_WO(silent); static struct kobj_attribute synth_attribute = - __ATTR(synth, S_IWUGO|S_IRUGO, synth_show, synth_store); + __ATTR_RW(synth); static struct kobj_attribute synth_direct_attribute = - __ATTR(synth_direct, S_IWUGO, NULL, synth_direct_store); + __ATTR_WO(synth_direct); static struct kobj_attribute version_attribute = __ATTR_RO(version); static struct kobj_attribute delimiters_attribute = - __ATTR(delimiters, S_IWUGO|S_IRUGO, punc_show, punc_store); + __ATTR(delimiters, S_IWUSR|S_IRUGO, punc_show, punc_store); static struct kobj_attribute ex_num_attribute = - __ATTR(ex_num, S_IWUGO|S_IRUGO, punc_show, punc_store); + __ATTR(ex_num, S_IWUSR|S_IRUGO, punc_show, punc_store); static struct kobj_attribute punc_all_attribute = - __ATTR(punc_all, S_IWUGO|S_IRUGO, punc_show, punc_store); + __ATTR(punc_all, S_IWUSR|S_IRUGO, punc_show, punc_store); static struct kobj_attribute punc_most_attribute = - __ATTR(punc_most, S_IWUGO|S_IRUGO, punc_show, punc_store); + __ATTR(punc_most, S_IWUSR|S_IRUGO, punc_show, punc_store); static struct kobj_attribute punc_some_attribute = - __ATTR(punc_some, S_IWUGO|S_IRUGO, punc_show, punc_store); + __ATTR(punc_some, S_IWUSR|S_IRUGO, punc_show, punc_store); static struct kobj_attribute repeats_attribute = - __ATTR(repeats, S_IWUGO|S_IRUGO, punc_show, punc_store); + __ATTR(repeats, S_IWUSR|S_IRUGO, punc_show, punc_store); static struct kobj_attribute attrib_bleep_attribute = - __ATTR(attrib_bleep, S_IWUGO|S_IRUGO, spk_var_show, spk_var_store); + __ATTR(attrib_bleep, S_IWUSR|S_IRUGO, spk_var_show, spk_var_store); static struct kobj_attribute bell_pos_attribute = - __ATTR(bell_pos, S_IWUGO|S_IRUGO, spk_var_show, spk_var_store); + __ATTR(bell_pos, S_IWUSR|S_IRUGO, spk_var_show, spk_var_store); static struct kobj_attribute bleep_time_attribute = - __ATTR(bleep_time, S_IWUGO|S_IRUGO, spk_var_show, spk_var_store); + __ATTR(bleep_time, S_IWUSR|S_IRUGO, spk_var_show, spk_var_store); static struct kobj_attribute bleeps_attribute = - __ATTR(bleeps, S_IWUGO|S_IRUGO, spk_var_show, spk_var_store); + __ATTR(bleeps, S_IWUSR|S_IRUGO, spk_var_show, spk_var_store); static struct kobj_attribute cursor_time_attribute = - __ATTR(cursor_time, S_IWUGO|S_IRUGO, spk_var_show, spk_var_store); + __ATTR(cursor_time, S_IWUSR|S_IRUGO, spk_var_show, spk_var_store); static struct kobj_attribute key_echo_attribute = - __ATTR(key_echo, S_IWUGO|S_IRUGO, spk_var_show, spk_var_store); + __ATTR(key_echo, S_IWUSR|S_IRUGO, spk_var_show, spk_var_store); static struct kobj_attribute no_interrupt_attribute = - __ATTR(no_interrupt, S_IWUGO|S_IRUGO, spk_var_show, spk_var_store); + __ATTR(no_interrupt, S_IWUSR|S_IRUGO, spk_var_show, spk_var_store); static struct kobj_attribute punc_level_attribute = - __ATTR(punc_level, S_IWUGO|S_IRUGO, spk_var_show, spk_var_store); + __ATTR(punc_level, S_IWUSR|S_IRUGO, spk_var_show, spk_var_store); static struct kobj_attribute reading_punc_attribute = - __ATTR(reading_punc, S_IWUGO|S_IRUGO, spk_var_show, spk_var_store);
[PATCH] speakup: fix incorrect perms on speakup_acntsa.c
22c9bcad859d5c969289b3b37084a96c621f8f2c contained a bad substitution for ROOT_W => S_IRUSR|S_IRUGO instead of S_IWUSR|S_IRUGO. Fixes: 22c9bcad859d5c969289b3b37084a96c621f8f2c Signed-off-by: Rusty Russell diff --git a/drivers/staging/speakup/speakup_acntsa.c b/drivers/staging/speakup/speakup_acntsa.c index c7f014ed9628..5079dbd5d7ad 100644 --- a/drivers/staging/speakup/speakup_acntsa.c +++ b/drivers/staging/speakup/speakup_acntsa.c @@ -60,15 +60,15 @@ static struct kobj_attribute vol_attribute = __ATTR(vol, S_IWUGO|S_IRUGO, spk_var_show, spk_var_store); static struct kobj_attribute delay_time_attribute = - __ATTR(delay_time, S_IRUSR|S_IRUGO, spk_var_show, spk_var_store); + __ATTR(delay_time, S_IWUSR|S_IRUGO, spk_var_show, spk_var_store); static struct kobj_attribute direct_attribute = __ATTR(direct, S_IWUGO|S_IRUGO, spk_var_show, spk_var_store); static struct kobj_attribute full_time_attribute = - __ATTR(full_time, S_IRUSR|S_IRUGO, spk_var_show, spk_var_store); + __ATTR(full_time, S_IWUSR|S_IRUGO, spk_var_show, spk_var_store); static struct kobj_attribute jiffy_delta_attribute = - __ATTR(jiffy_delta, S_IRUSR|S_IRUGO, spk_var_show, spk_var_store); + __ATTR(jiffy_delta, S_IWUSR|S_IRUGO, spk_var_show, spk_var_store); static struct kobj_attribute trigger_time_attribute = - __ATTR(trigger_time, S_IRUSR|S_IRUGO, spk_var_show, spk_var_store); + __ATTR(trigger_time, S_IWUSR|S_IRUGO, spk_var_show, spk_var_store); /* * Create a group of attributes so that we can create and destroy them all -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/9] drivers/hid/hid-lg4ff.c: avoid world-writable sysfs files.
si...@mungewell.org writes: >> si...@mungewell.org writes: >>> Yep I'm OK with that, however what it the recommended way to make sure >>> that the end user is able to send changes to this /sys portal? I asked >>> the >>> same question before regarding the led class /sys interface, but never >>> got >>> any suggestions. >>> >>> Signed-off-by: Simon Wood >> >> If you need that, we'll need to make an exception. That's one purpose >> of spamming everyone with these changs... > > > What's the right way of doing it?... I don't need to be 'special'. ;-) > > The '/sys/.../range' control allows the user to limit the rotation of the > gaming wheel from a maximum of 900' down to match the 'car' they > sim-driving. Probably not many people use it, but it probably should be > assigned properly. > > With gaming controllers the /dev/input/event* seem to get set > appropriately, but I'm not sure how this happens. > > The same /should/ also happen for all the LED class controls, I don't want > to have to 'sudo' just to set a LED on/off. This is currently a problem > for (at least) hid-lg, hid-sony and hid-steelseries. > Simon I think this is a udev duty. Someone needs to chmod/chown/chgrp the files if you want to allow a particular group/user access (I just checked, that works fot sysfs files). I have no idea about HID, so I don't know how you'd figure out who that user/group is... Cheers, Rusty. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] [RFC] timekeeping: Rework frequency adjustments to work better w/ nohz
Hey Miroslav! Once again, a few months pass and I finally get some more time to look at this. :( Sorry for how slow this has been going. On 02/12/2014 07:42 AM, Miroslav Lichvar wrote: > On Mon, Jan 06, 2014 at 07:57:03PM -0800, John Stultz wrote: >> Got a few cycles to take another look at this, and tried to address >> Miroslav's latest comments. Please let me know if you have further >> thoughts! > In the simulations this version of the patch does indeed work better > than the previous one. I tested it with the ntp_error correction added > back as per your previous mail. It converges, the measured frequency > matches the value set by adjtimex and the ntp error stays close to > zero. I'm concerned about two things now and I'm not sure if they can > be fixed easily. > > One is that the convergence still seems too slow to me. > > ./tk_test -t 500 -n 4000 > samples: 1-500 reg: 1-500 slope: 1.00 dev: 1947.5 max: 36940.9 freq: > -100.08081 > samples: 501-1000 reg: 501-1000 slope: 1.00 dev: 430.7 max: 1669.6 freq: > -100.07168 > samples: 1001-1500 reg: 1001-1500 slope: 1.00 dev: 675.3 max: 3172.9 freq: > -100.07393 > samples: 1501-2000 reg: 1501-2000 slope: 1.00 dev: 453.9 max: 2223.4 freq: > -100.07177 > samples: 2001-2500 reg: 2001-2500 slope: 1.00 dev: 2601.2 max: 10875.4 freq: > -100.03978 > samples: 2501-3000 reg: 2501-3000 slope: 1.00 dev: 185.6 max: 1251.6 freq: > -99.99987 > samples: 3001-3500 reg: 3001-3500 slope: 1.00 dev: 160.1 max: 1181.7 freq: > -99.6 > samples: 3501-4000 reg: 3501-4000 slope: 1.00 dev: 150.7 max: 1103.2 freq: > -99.0 > > You can see in this test it takes about 2500 updates to correct the > initial ntp error and settle down. That's with 1GHz clocksource. In > some tests I did with smaller clock frequencies or different frequency > offsets it took much longer than that. So I started to look into this slow update issue. I was a little confused, as the logarithmic approximation done in the frequency correction shouldn't let *that* much initial error accumulate before get to the +1/0 adjustments. It ends up this is more a reflection of a different part of your patch. Particularly the tk->ntp_tick storage. Bascially the ntp_tick variable is a cache of the ntp_tick_length() value, however it doesn't get set to ntp_tick_length() until *after* you do the first frequency correction. Basically this avoids accumulating any error until after the first correction is made. My main concern is that this seems like an accounting error. By basically avoiding accumulating the initial error it seems it would never be corrected, no? If I add a similar ntp_tick caching to my current implementation, it converges practically as fast (with the only initial error coming from the logarithmic approximation of the divide being quite small). Similarly, if you remove the usage of tk->ntp_tick in the error accumulation loop, using ntp_tick_length() your patch behaves quite similarly to mine. Does this align with your view of the code? Or am I misunderstanding something? > $ ./tk_test -s 2500 -n 5000 > samples: 1-5000 reg: 2501-5000 slope: 1.00 dev: 135942.4 max: 390761.8 freq: > -100.0 > > Here the regression line is calculated only through the latter half of > the samples (where it was already settled down) and we can see the > total ntp error corrected since the first update is around 390 > microseconds. > > I'm not saying ntpd or linuxptp can't work with this. The PLL and PI > controllers seem to handle this slowness in the frequency adjustment > well. I'm more worried about designs that may change the frequency > quickly and rely on accurate prediction of the clock in their feedback > loop. > > The other thing I'm concerned about is that the multiplier doesn't > change only between two closest values when the loop has settled down, > but in a larger range. With the 1GHz clock I see the multiplier is > moving in range of 8387767-8387772, which makes the ntp error several > times larger than it would be if the multiplier switched just between > 8387769 and 8387770. So this point is valid. I spent some time reworking things and I'm not totally happy with it currently (there's a little mess to it), but its much closer to your implementation logically, but again just avoids the divide and keeps the accounting closer to what we already have. I'll hopefully clean up my current work and send it out tomorrow. Also I do really appreciate your submissions here and apologize I've not been able to put more time towards it recently. I also know having me rewrite your patch over and over with various mistakes is probably frustrating, but I do really want to make sure I both understand all the subtleties of your changes (which resynthesizing helps) as well as make sure the accounting is really correct (or at least not changed subtlety without clear reason). Thanks so much again! -john -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to ma
Re: [PATCH] x86-64: espfix for 64-bit mode *PROTOTYPE*
On Mon, Apr 21, 2014 at 6:47 PM, H. Peter Anvin wrote: > This is a prototype of espfix for the 64-bit kernel. espfix is a > workaround for the architectural definition of IRET, which fails to > restore bits [31:16] of %esp when returning to a 16-bit stack > segment. We have a workaround for the 32-bit kernel, but that > implementation doesn't work for 64 bits. Hi, A comment: The main purpose of espfix is to prevent attackers from learning sensitive addresses, right? But as far as I can tell, this mini-stack becomes itself somewhat sensitive: - The user can put arbitrary data in registers before returning to the LDT in order to get it saved at a known address accessible from the kernel. With SMAP and KASLR this might otherwise be difficult. - If the iret faults, kernel addresses will get stored there (and not cleared). If a vulnerability could return data from an arbitrary specified address to the user, this would be harmful. I guess with the current KASLR implementation you could get the same effects via brute force anyway, by filling up and browsing memory, respectively, but ideally there wouldn't be any virtual addresses guaranteed not to fault. - If a vulnerability allowed overwriting data at an arbitrary specified address, the exception frame could get overwritten at exactly the right moment between the copy and iret (or right after the iret to mess up fixup_exception)? You probably know better than I whether or not caches prevent this from actually being possible. Just raising the issue. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] autofs - fix lockref lookup
On Wed, 2014-04-23 at 14:46 -0700, Andrew Morton wrote: > On Wed, 23 Apr 2014 13:20:36 +0800 Ian Kent wrote: > > > autofs needs to be able to see private data dentry flags for > > its dentrys that are being created but not yet hashed and for > > its dentys that have been rmdir()ed but not yet freed. It > > needs to do this so it can block processes in these states > > until a status has been returned to indicate the given > > operation is complete. > > > > It does this by keeping two lists, active and expring, of > > dentrys in this state and uses ->d_release() to keep them > > stable while it checks the reference count to determine > > if they should be used. > > > > But with the recent lockref changes dentrys being freed > > sometimes don't transition to a reference count of 0 before > > being freed so autofs can occassionally use a dentry that > > is invalid which can lead to a panic. > > What's the value of "recent"? I assume 3.14 is OK? I'll need to look again but from memory it's broken from 3.12 onward. The breakage happened when lockref_mark_dead() was introduced because it sets lockref->count = -128 instead of reducing count by one as was done previously. Ian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] 3.14-rt1
Turning lockdep on, it says it's busted. (I'll go stare at it, maybe the beast will blink first for a change) [0.00] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar [0.00] ... MAX_LOCKDEP_SUBCLASSES: 8 [0.00] ... MAX_LOCK_DEPTH: 48 [0.00] ... MAX_LOCKDEP_KEYS:8191 [0.00] ... CLASSHASH_SIZE: 4096 [0.00] ... MAX_LOCKDEP_ENTRIES: 16384 [0.00] ... MAX_LOCKDEP_CHAINS: 32768 [0.00] ... CHAINHASH_SIZE: 16384 [0.00] memory used by lock dependency info: 6367 kB [0.00] per task-struct memory footprint: 2688 bytes [0.00] [0.00] | Locking API testsuite: [0.00] [0.00] | spin |wlock |rlock |mutex | wsem | rsem | [0.00] -- [0.00] A-A deadlock: ok | ok |FAILED| [0.00] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.14.1-rt1 #16 [0.00] Hardware name: MEDIONPC MS-7502/MS-7502, BIOS 6.00 PG 12/26/2007 [0.00] 0002 81a01f28 815e12a5 810b7727 [0.00] 0001 81a01f58 815e1db2 [0.00] 81a01f68 [0.00] Call Trace: [0.00] [] dump_stack+0x4f/0x7c [0.00] [] ? console_trylock_for_printk+0x37/0xf0 [0.00] [] dotest+0x5f/0xc7 [0.00] [] locking_selftest+0xdf/0xb30 [0.00] [] start_kernel+0x215/0x327 [0.00] [] ? repair_env_string+0x5a/0x5a [0.00] [] ? memblock_reserve+0x49/0x4e [0.00] [] x86_64_start_reservations+0x2a/0x2c [0.00] [] x86_64_start_kernel+0xf0/0xf7 [0.00] ok | ok | ok | [0.00] A-B-B-A deadlock: ok | ok |FAILED| [0.00] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.14.1-rt1 #16 [0.00] Hardware name: MEDIONPC MS-7502/MS-7502, BIOS 6.00 PG 12/26/2007 [0.00] 0002 81a01f28 815e12a5 810b7727 [0.00] 0001 81a01f58 815e1db2 [0.00] 81a01f68 [0.00] Call Trace: [0.00] [] dump_stack+0x4f/0x7c [0.00] [] ? console_trylock_for_printk+0x37/0xf0 [0.00] [] dotest+0x5f/0xc7 [0.00] [] locking_selftest+0x16e/0xb30 [0.00] [] start_kernel+0x215/0x327 [0.00] [] ? repair_env_string+0x5a/0x5a [0.00] [] ? memblock_reserve+0x49/0x4e [0.00] [] x86_64_start_reservations+0x2a/0x2c [0.00] [] x86_64_start_kernel+0xf0/0xf7 [0.00] ok | ok | ok | [0.00] A-B-B-C-C-A deadlock: ok | ok |FAILED| [0.00] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.14.1-rt1 #16 [0.00] Hardware name: MEDIONPC MS-7502/MS-7502, BIOS 6.00 PG 12/26/2007 [0.00] 0002 81a01f28 815e12a5 810b7727 [0.00] 0001 81a01f58 815e1db2 [0.00] 81a01f68 [0.00] Call Trace: [0.00] [] dump_stack+0x4f/0x7c [0.00] [] ? console_trylock_for_printk+0x37/0xf0 [0.00] [] dotest+0x5f/0xc7 [0.00] [] locking_selftest+0x1fd/0xb30 [0.00] [] start_kernel+0x215/0x327 [0.00] [] ? repair_env_string+0x5a/0x5a [0.00] [] ? memblock_reserve+0x49/0x4e [0.00] [] x86_64_start_reservations+0x2a/0x2c [0.00] [] x86_64_start_kernel+0xf0/0xf7 [0.00] ok | ok | ok | [0.00] A-B-C-A-B-C deadlock: ok | ok |FAILED| [0.00] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.14.1-rt1 #16 [0.00] Hardware name: MEDIONPC MS-7502/MS-7502, BIOS 6.00 PG 12/26/2007 [0.00] 0002 81a01f28 815e12a5 810b7727 [0.00] 0001 81a01f58 815e1db2 [0.00] 81a01f68 [0.00] Call Trace: [0.00] [] dump_stack+0x4f/0x7c [0.00] [] ? console_trylock_for_printk+0x37/0xf0 [0.00] [] dotest+0x5f/0xc7 [0.00] [] locking_selftest+0x28c/0xb30 [0.00] [] start_kernel+0x215/0x327 [0.00] [] ? repair_env_string+0x5a/0x5a [0.00] [] ? memblock_reserve+0x49/0x4e [0.00] [] x86_64_start_reservations+0x2a/0x2c [0.00] [] x86_64_start_kernel+0xf0/0xf7 [0.00] ok | ok | ok | [0.00] A-B-B-C-C-D-D-A deadlock: ok | ok |FAILED| [0.00] CPU: 0 PID: 0 C
Re: vmstat: On demand vmstat workers V3
On 23 April 2014 22:20, Max Krasnyansky wrote: > On 04/22/2014 03:32 AM, Viresh Kumar wrote: >> This vmstat interrupt is disturbing my core isolation :), have you got >> any far with this patchset? > > You don't mean an interrupt, right? Sorry for not being clear enough. I meant the interruption caused due to these works. > The updates are done via the regular priority workqueue. > > I'm playing with isolation as well (has been more or less a background thing > for the last 6+ years). Our threads that run on the isolated cores are > SCHED_FIFO > and therefor low prio workqueue stuff, like vmstat, doesn't get in the way. Initially I thought that's not enough. As there were queued with a delayed work and so a timer+work. Because there is a timer to fire, kernel wouldn't stop the tick for long with NO_HZ_FULL as get_next_timer_interrupt() wouldn't return KTIME_MAX. And so we will stop the tick for some time but will still queue a hrtimer after say 'n' seconds. But the clockevent device will have a max value of counter it is running and it will disturb isolation with a interrupt after end of counter, for me it is 90 seconds. BUT, it looks there is something else as well here. For the first time this theory would probably work, but because we wouldn't allow the work to run, the timer wouldn't get queued again. And so things will start working soon after. While writing this mail, I got another vision at this point. Because there will be one task running and another queued for the work, tick wouldn't be stopped (nr_running > 1) :( .. And so isolation wouldn't work again. @Frederic/Kevin: Did we ever had a discussion about stopping tick even if we have more than a task in queue but are SCHED_FIFO ? > I do have a few patches for the workqueues to make things better for > isolation. Please share them, even if they aren't mainlinable. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 tip tree
Hi all,
After merging the tip tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
In file included from arch/arm/include/asm/outercache.h:24:0,
from arch/arm/include/asm/barrier.h:5,
from arch/arm/include/asm/bitops.h:28,
from include/linux/bitops.h:33,
from include/linux/kernel.h:10,
from include/asm-generic/bug.h:13,
from arch/arm/include/asm/bug.h:61,
from arch/arm/include/asm/div64.h:63,
from include/linux/math64.h:5,
from include/linux/jiffies.h:4,
from init/calibrate.c:7:
include/linux/bug.h:91:47: warning: 'struct bug_entry' declared inside
parameter list [enabled by default]
include/linux/bug.h:91:47: warning: its scope is only this definition or
declaration, which is probably not what you want [enabled by default]
include/linux/bug.h: In function 'is_warning_bug':
include/linux/bug.h:93:12: error: dereferencing pointer to incomplete type
In file included from include/linux/kernel.h:11:0,
from include/asm-generic/bug.h:13,
from arch/arm/include/asm/bug.h:61,
from include/linux/bug.h:4,
from arch/arm/include/asm/outercache.h:24,
from arch/arm/include/asm/barrier.h:5,
from arch/arm/include/asm/bitops.h:28,
from include/linux/bitops.h:33,
from include/linux/signal.h:35,
from arch/arm/kernel/signal.c:12:
include/linux/log2.h: In function '__ilog2_u32':
include/linux/log2.h:34:2: error: implicit declaration of function 'fls'
[-Werror=implicit-function-declaration]
include/linux/log2.h: In function '__ilog2_u64':
include/linux/log2.h:42:2: error: implicit declaration of function 'fls64'
[-Werror=implicit-function-declaration]
include/linux/log2.h: In function '__roundup_pow_of_two':
include/linux/log2.h:63:2: error: implicit declaration of function 'fls_long'
[-Werror=implicit-function-declaration]
In file included from include/linux/bitops.h:33:0,
from include/linux/signal.h:35,
from arch/arm/kernel/signal.c:12:
arch/arm/include/asm/bitops.h: At top level:
arch/arm/include/asm/bitops.h:273:19: error: static declaration of 'fls'
follows non-static declaration
include/linux/log2.h:34:9: note: previous implicit declaration of 'fls' was here
And many more ...
Guessing ... caused by commit febdbfe8a91c ("arch: Prepare for smp_mb__
{before,after}_atomic()") and following interacting with commit
735e532e0f25 ("ARM: outer cache: add WARN_ON() to outer_disable()") from
the arm tree?
I applied this fix patch for today:
From: Stephen Rothwell
Date: Thu, 24 Apr 2014 13:46:08 +1000
Subject: [PATCH] ARM: outer cache: remove include of linux/bug.h from
outercache.h
It causes a circular inclusion and looks like it is not necessary anyway.
Signed-off-by: Stephen Rothwell
---
arch/arm/include/asm/outercache.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/include/asm/outercache.h
b/arch/arm/include/asm/outercache.h
index eaa8a28c6871..891a56b35bcf 100644
--- a/arch/arm/include/asm/outercache.h
+++ b/arch/arm/include/asm/outercache.h
@@ -21,7 +21,6 @@
#ifndef __ASM_OUTERCACHE_H
#define __ASM_OUTERCACHE_H
-#include
#include
struct outer_cache_fns {
--
2.0.0.rc0
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpszmASFOpK9.pgp
Description: PGP signature
[PATCH] misc: genwqe: Fix format string mismatch in card_debugfs.c
Fix two format string mismatch in genwqe_init_debugfs()
Signed-off-by: Masanari Iida
---
drivers/misc/genwqe/card_debugfs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/misc/genwqe/card_debugfs.c
b/drivers/misc/genwqe/card_debugfs.c
index 50d2096..0a33ade 100644
--- a/drivers/misc/genwqe/card_debugfs.c
+++ b/drivers/misc/genwqe/card_debugfs.c
@@ -348,7 +348,7 @@ int genwqe_init_debugfs(struct genwqe_dev *cd)
char name[64];
unsigned int i;
- sprintf(card_name, "%s%u_card", GENWQE_DEVNAME, cd->card_idx);
+ sprintf(card_name, "%s%d_card", GENWQE_DEVNAME, cd->card_idx);
root = debugfs_create_dir(card_name, cd->debugfs_genwqe);
if (!root) {
@@ -454,7 +454,7 @@ int genwqe_init_debugfs(struct genwqe_dev *cd)
}
for (i = 0; i < GENWQE_MAX_VFS; i++) {
- sprintf(name, "vf%d_jobtimeout_msec", i);
+ sprintf(name, "vf%u_jobtimeout_msec", i);
file = debugfs_create_u32(name, 0666, root,
&cd->vf_jobtimeout_msec[i]);
--
2.0.0.rc0.26.g779792a
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] thermal: samsung: Only update available threshold limits
On 04/14/2014 11:08 AM, Tushar Behera wrote:
> Currently the threshold limits are updated in 2 stages, once for all
> software trigger levels and again for hardware trip point.
>
> While updating the software trigger levels, it overwrites the threshold
> limit for hardware trip point thereby forcing the Exynos core to issue
> an emergency shutdown.
>
> Updating only the required fields in threshold register fixes this issue.
>
> Signed-off-by: Tushar Behera
> ---
> Based on v3.15-rc1.
>
> drivers/thermal/samsung/exynos_tmu.c |4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/thermal/samsung/exynos_tmu.c
> b/drivers/thermal/samsung/exynos_tmu.c
> index 0d96a51..ffccc89 100644
> --- a/drivers/thermal/samsung/exynos_tmu.c
> +++ b/drivers/thermal/samsung/exynos_tmu.c
> @@ -225,6 +225,8 @@ skip_calib_data:
> trigger_levs++;
> }
>
> + rising_threshold = readl(data->base + reg->threshold_th0);
> +
> if (data->soc == SOC_ARCH_EXYNOS4210) {
> /* Write temperature code for threshold */
> threshold_code = temp_to_code(data, pdata->threshold);
> @@ -249,6 +251,7 @@ skip_calib_data:
> ret = threshold_code;
> goto out;
> }
> + rising_threshold &= ~(0xff << 8 * i);
> rising_threshold |= threshold_code << 8 * i;
> if (pdata->threshold_falling) {
> threshold_code = temp_to_code(data,
> @@ -281,6 +284,7 @@ skip_calib_data:
> }
> if (i == EXYNOS_MAX_TRIGGER_PER_REG - 1) {
> /* 1-4 level to be assigned in th0 reg */
> + rising_threshold &= ~(0xff << 8 * i);
> rising_threshold |= threshold_code << 8 * i;
> writel(rising_threshold,
> data->base + reg->threshold_th0);
>
Adding Amit to get Samsung specific review.
--
Tushar Behera
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] uprobes/tracing: uprobe_perf_open() forgets to handle the error from uprobe_apply()
On Wed, 23 Apr 2014 18:58:30 +0200
Oleg Nesterov wrote:
> uprobe_perf_open()->uprobe_apply() can fail, but this error is wrongly
> ignored. Change uprobe_perf_open() to do uprobe_perf_close() and return
> the error code in this case.
>
> Change uprobe_perf_close() to propogate the error from uprobe_apply()
> as well, although it should not fail.
>
> The patch looks more complicated because it moves uprobe_perf_close()
> up to make it visible to uprobe_perf_open().
>
> Signed-off-by: Oleg Nesterov
> ---
> kernel/trace/trace_uprobe.c | 46 +++---
> 1 files changed, 25 insertions(+), 21 deletions(-)
>
> diff --git a/kernel/trace/trace_uprobe.c b/kernel/trace/trace_uprobe.c
> index 930e514..9aad3e2 100644
> --- a/kernel/trace/trace_uprobe.c
> +++ b/kernel/trace/trace_uprobe.c
> @@ -1003,56 +1003,60 @@ uprobe_filter_event(struct trace_uprobe *tu, struct
> perf_event *event)
> return __uprobe_perf_filter(&tu->filter, event->hw.tp_target->mm);
> }
>
> -static int uprobe_perf_open(struct trace_uprobe *tu, struct perf_event
> *event)
> +static int uprobe_perf_close(struct trace_uprobe *tu, struct perf_event
> *event)
Egad, this confused the heck out of me. I didn't notice the swap in
functions and was wondering what you were doing. I didn't realize this
is what you meant by moving the uprobe_perf_close() up. I was thinking
you moved the call up or something, not the function itself physically
in the file.
/me tries to continue dazed and confused.
> {
> bool done;
>
> write_lock(&tu->filter.rwlock);
> if (event->hw.tp_target) {
> - /*
> - * event->parent != NULL means copy_process(), we can avoid
> - * uprobe_apply(). current->mm must be probed and we can rely
> - * on dup_mmap() which preserves the already installed bp's.
> - *
> - * attr.enable_on_exec means that exec/mmap will install the
> - * breakpoints we need.
> - */
> + list_del(&event->hw.tp_list);
> done = tu->filter.nr_systemwide ||
> - event->parent || event->attr.enable_on_exec ||
> + (event->hw.tp_target->flags & PF_EXITING) ||
> uprobe_filter_event(tu, event);
> - list_add(&event->hw.tp_list, &tu->filter.perf_events);
> } else {
> + tu->filter.nr_systemwide--;
> done = tu->filter.nr_systemwide;
> - tu->filter.nr_systemwide++;
> }
> write_unlock(&tu->filter.rwlock);
>
> if (!done)
> - uprobe_apply(tu->inode, tu->offset, &tu->consumer, true);
> + return uprobe_apply(tu->inode, tu->offset, &tu->consumer,
> false);
>
> return 0;
> }
>
> -static int uprobe_perf_close(struct trace_uprobe *tu, struct perf_event
> *event)
> +static int uprobe_perf_open(struct trace_uprobe *tu, struct perf_event
> *event)
> {
> bool done;
> + int err;
>
> write_lock(&tu->filter.rwlock);
> if (event->hw.tp_target) {
> - list_del(&event->hw.tp_list);
> + /*
> + * event->parent != NULL means copy_process(), we can avoid
> + * uprobe_apply(). current->mm must be probed and we can rely
> + * on dup_mmap() which preserves the already installed bp's.
> + *
> + * attr.enable_on_exec means that exec/mmap will install the
> + * breakpoints we need.
> + */
> done = tu->filter.nr_systemwide ||
> - (event->hw.tp_target->flags & PF_EXITING) ||
> + event->parent || event->attr.enable_on_exec ||
> uprobe_filter_event(tu, event);
> + list_add(&event->hw.tp_list, &tu->filter.perf_events);
> } else {
> - tu->filter.nr_systemwide--;
> done = tu->filter.nr_systemwide;
> + tu->filter.nr_systemwide++;
> }
> write_unlock(&tu->filter.rwlock);
>
> - if (!done)
> - uprobe_apply(tu->inode, tu->offset, &tu->consumer, false);
> -
> - return 0;
> + err = 0;
> + if (!done) {
> + err = uprobe_apply(tu->inode, tu->offset, &tu->consumer, true);
> + if (err)
> + uprobe_perf_close(tu, event);
> + }
> + return err;
You can add by Acked-by, but next time, please make this into two
patches. One to do the move, the other to do the change.
Thanks!
-- Steve
> }
>
> static bool uprobe_perf_filter(struct uprobe_consumer *uc,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v7 0/3] Add support for PCI in AArch64
On 24 April 2014 02:02, Tanmay Inamdar wrote:
> Hello Sandeepa,
>
> On Tue, Apr 22, 2014 at 4:50 AM, Sandeepa Prabhu
> wrote:
>> On 22 April 2014 15:41, Liviu Dudau wrote:
>>> On Tue, Apr 22, 2014 at 09:58:28AM +0100, Sandeepa Prabhu wrote:
On 14 March 2014 21:04, Liviu Dudau wrote:
> Hi,
>
> This patch adds support for PCI to AArch64. It is based on my v7 patch
> that adds support for creating generic host bridge structure from
> device tree. With that in place, I was able to boot a platform that
> has PCIe host bridge support and use a PCIe network card.
Hi Liviu,
Are these patches (including your other patchset for device tree host
bridge support ) available on a public git repo I can checkout from?
>>>
>>> Yes, I have pushed them into git://linux-arm.org/linux-ld.git
>> Thanks Liviu,
>> Just to understand, is the X-gene PCIe
>> (https://lwn.net/Articles/589733/) verified using the same patchset?
>
> Yes. V5 version of X-Gene PCIe patches have verified Liviu's patchset
> on X-Gene platform.
Thanks Tanmay!
>
>>
>> ~Sandeepa
>>>
>>> Best regards,
>>> Liviu
>>>
Thanks,
~Sandeepa
>
> I have dropped the RFC tag from the subject as I now have the ambitious
> goal
> of trying to get it mainlined.
>
> Changes from v6:
> - Guard the pci_domain_nr() inline implementation with #ifdef
> CONFIG_PCI as
> to avoid conflict with default empty version present in
> include/linux/pci.h.
> Thanks to Jingoo Han for catching this.
>
> Changes from v5:
> - Removed pcibios_fixup_bridge_ranges() as the week default version is
> fine.
> - Removed the ALIGN() call in pcibios_align_resource()
> - Stopped exporting pcibios_align_resource()
>
> Changes from v4:
> - Fixed the pci_domain_nr() implementation for arm64. Now we use
> find_pci_host_bride() to find the host bridge before we retrieve
> the domain number.
>
> Changes from v3:
> - Added Acks accumulated so far ;)
> - Still carrying Catalin's patch for moving the PCI_IO_BASE until it
> lands in linux-next or mainline, in order to ease applying the series
>
> Changes from v2:
> - Implement an arch specific version of pci_register_io_range() and
> pci_address_to_pio().
> - Return 1 from pci_proc_domain().
>
> Changes from v1:
> - Added Catalin's patch for moving the PCI_IO_BASE location and extend
> its size to 16MB
> - Integrated Arnd's version of pci_ioremap_io that uses a bitmap for
> keeping track of assigned IO space and returns an io_offset. At the
> moment the code is added in arch/arm64 but it can be moved in
> drivers/pci.
> - Added a fix for the generic ioport_map() function when
> !CONFIG_GENERIC_IOMAP
> as suggested by Arnd.
>
> v6 thread here: https://lkml.org/lkml/2014/3/5/41
> v5 thread here: https://lkml.org/lkml/2014/3/4/307
> v4 thread here: https://lkml.org/lkml/2014/3/3/298
> v3 thread here: https://lkml.org/lkml/2014/2/28/211
> v2 thread here: https://lkml.org/lkml/2014/2/27/255
> v1 thread here: https://lkml.org/lkml/2014/2/3/389
>
>
> The API used is different from the one used by ARM architecture. There is
> no pci_common_init_dev() function and no hw_pci structure, as that is no
> longer needed. Once the last signature is added to the legal agreement, I
> will post the host bridge driver code that I am using. Meanwhile, here
> is an example of what the probe function looks like, posted as an
> example:
>
> static int myhostbridge_probe(struct platform_device *pdev)
> {
> int err;
> struct device_node *dev;
> struct pci_host_bridge *bridge;
> struct myhostbridge_port *pp;
> resource_size_t lastbus;
>
> dev = pdev->dev.of_node;
>
> if (!of_device_is_available(dev)) {
> pr_warn("%s: disabled\n", dev->full_name);
> return -ENODEV;
> }
>
> pp = kzalloc(sizeof(struct myhostbridge_port), GFP_KERNEL);
> if (!pp)
> return -ENOMEM;
>
> bridge = of_create_pci_host_bridge(&pdev->dev,
> &myhostbridge_ops, pp);
> if (IS_ERR(bridge)) {
> err = PTR_ERR(bridge);
> goto bridge_create_fail;
> }
>
> err = myhostbridge_setup(bridge->bus);
> if (err)
> goto bridge_setup_fail;
>
> /* We always enable PCI domains and we keep domain 0 backward
> * compatible in /proc for video cards
> */
> pci_add_flags(PCI_ENABLE_PROC_DOMAINS);
linux-next: build failure after merge of the mfd-lj tree
Hi Lee,
After merging the mfd-lj tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
drivers/mfd/db8500-prcmu.c: In function 'round_armss_rate':
drivers/mfd/db8500-prcmu.c:1744:2: error: implicit declaration of function
'cpufreq_for_each_entry' [-Werror=implicit-function-declaration]
drivers/mfd/db8500-prcmu.c:1744:52: error: expected ';' before '{' token
drivers/mfd/db8500-prcmu.c:1738:7: warning: unused variable 'freq'
[-Wunused-variable]
drivers/mfd/db8500-prcmu.c:1752:1: warning: no return statement in function
returning non-void [-Wreturn-type]
drivers/mfd/db8500-prcmu.c: In function 'set_armss_rate':
drivers/mfd/db8500-prcmu.c:1895:3: error: expected ';' before 'if'
Caused by commit 2eb3cfd03d60 ("mfd: db8500-prcmu: Use
cpufreq_for_each_entry macro for iteration").
I have used the mfd-lj tree from next-20140423 for today.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpFYWcZreoOw.pgp
Description: PGP signature
Re: [Bugfix] sched: fix possible invalid memory access caused by CPU hot-addition
On 2014/4/24 1:46, Luck, Tony wrote: 1) Handle CPU hot-addition event 1.a) gather platform specific information 1.b) associate hot-added CPU with a node 1.c) create CPU device 2) User online hot-added CPUs through sysfs: 2.a) cpu_up() 2.b) ->try_online_node() 2.c) ->hotadd_new_pgdat() 2.d) ->node_set_online() So between 1.b and 2.c, kmalloc_node(nid) may cause invalid memory access without the node_online(nid) check. >>> >>> Any why was all this not in the Changelog? >> >> Also, do explain what kind of hardware you needed to trigger this. This >> code has been like this for a good while. > > With your proposed fix in place the allocations will succeed - but they > will be done from other nodes ... and this cpu will have to do a remote > NUMA access for the rest of time. > > It would be better to switch the order above - add the memory first, > then add the cpus. Is that possible? Hi Tony, The BIOS always sends CPU hot-addition events before memory hot-addition events, so it's hard to change the order. And we couldn't completely solve this performance penalty because the affected code tries to allocate memory for all possible CPUs instead of onlined CPUs. Best Regards! Gerry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] ARM: mm: support big-endian page tables
On 2014/4/23 21:20, Will Deacon wrote: > Hi Jianguo, > > On Thu, Apr 17, 2014 at 10:43:01AM +0100, Marc Zyngier wrote: >> On Thu, Apr 17 2014 at 10:31:37 am BST, Jianguo Wu >> wrote: >>> When enable LPAE and big-endian in a hisilicon board, while specify >>> mem=384M mem=512M@7680M, will get bad page state: >>> >>> Freeing unused kernel memory: 180K (c0466000 - c0493000) >>> BUG: Bad page state in process init pfn:fa442 >>> page:c7749840 count:0 mapcount:-1 mapping: (null) index:0x0 >>> page flags: 0x4400(reserved) >>> Modules linked in: >>> CPU: 0 PID: 1 Comm: init Not tainted 3.10.27+ #66 >>> [] (unwind_backtrace+0x0/0x11c) from [] >>> (show_stack+0x10/0x14) >>> [] (show_stack+0x10/0x14) from [] (bad_page+0xd4/0x104) >>> [] (bad_page+0xd4/0x104) from [] >>> (free_pages_prepare+0xa8/0x14c) >>> [] (free_pages_prepare+0xa8/0x14c) from [] >>> (free_hot_cold_page+0x18/0xf0) >>> [] (free_hot_cold_page+0x18/0xf0) from [] >>> (handle_pte_fault+0xcf4/0xdc8) >>> [] (handle_pte_fault+0xcf4/0xdc8) from [] >>> (handle_mm_fault+0xf4/0x120) >>> [] (handle_mm_fault+0xf4/0x120) from [] >>> (do_page_fault+0xfc/0x354) >>> [] (do_page_fault+0xfc/0x354) from [] >>> (do_DataAbort+0x2c/0x90) >>> [] (do_DataAbort+0x2c/0x90) from [] >>> (__dabt_usr+0x34/0x40) > > > [...] > > Please can you put this into Russell's patch system? You can also add my > ack: > > Acked-by: Will Deacon > > You should also CC stable in the commit log. > Hi Will, I have submit to http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=8037/1. Thanks, Jianguo Wu. > Cheers, > > Will > > . > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] sched, fair: Stop searching for tasks in newidle balance if there are runnable tasks
On Wed, 2014-04-23 at 18:30 -0700, Jason Low wrote: > It was found that when running some workloads (such as AIM7) on large systems > with many cores, CPUs do not remain idle for long. Thus, tasks can > wake/get enqueued while doing idle balancing. > > In this patch, while traversing the domains in idle balance, in addition to > checking for pulled_task, we add an extra check for this_rq->nr_running for > determining if we should stop searching for tasks to pull. If there are > runnable tasks on this rq, then we will stop traversing the domains. This > reduces the chance that idle balance delays a task from running. > > This patch resulted in approximately a 6% performance improvement when > running a Java Server workload on an 8 socket machine. Checking rq->lock for contention before ever going to idle balancing as well should give you a bit more. No need to run around looking for work that's trying to arrive. By not going there, perhaps stacking tasks, you may head off a future bounce as well. -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/
Re: kaslr should avoid setup_data region
On 04/23/14 at 07:43pm, Kees Cook wrote: > On Wed, Apr 23, 2014 at 7:35 PM, Dave Young wrote: > > Hello Kees > > > > I'm worrying that setup_data regions could be overwitten by randomize > > kernel base. Would you like to fix it in kaslr code? > > > > One problem is there could be a lot of setup_data regions but current > > mem_avoid is an fixed array. > > Sure, can you give me some examples? Seems like it shouldn't be too > hard to have the mem_avoid logic walk additional areas. Great, To walk through the list just like the function parse_setup_data in arch/x86/kernel/setup.c Thanks Dave -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 net-next tree with the net tree
From: Jeff Kirsher
Date: Wed, 23 Apr 2014 19:24:38 -0700
> On Thu, 2014-04-24 at 11:47 +1000, Stephen Rothwell wrote:
>> Hi all,
>>
>> Today's linux-next merge of the net-next tree got a conflict in
>> drivers/net/ethernet/intel/igb/e1000_mac.c between commit c5ffe7e1f745
>> ("e1000e/igb/ixgbe/i40e: fix message terminations") from the net tree
>> and
>> commit c75c4edfc38d ("igb: Cleanups for messaging") from the net-next
>> tree.
>>
>> I fixed it up (the former was a superset of the latter) and can carry
>> the
>> fix as necessary (no action is required).
>
> Huh, I thought the commit c75c4edfc38d ("igb: Cleanups for messaging")
> in Dave's net-next already took into account the changes in net. I will
> take a look at your fix Stephen, thanks for letting us know.
Stephen may have pulled net-next before that went in.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] mfd: pm8x41: add support for Qualcomm 8x41 PMICs
On Wed, Apr 23, 2014 at 8:19 AM, Ivan T. Ivanov wrote:
>
> Hi,
>
> On Tue, 2014-04-22 at 17:31 -0700, Courtney Cavin wrote:
>> From: Josh Cartwright
>>
>> The Qualcomm 8941 and 8841 PMICs are components used with the Snapdragon
>> 800 series SoC family. This driver exists largely as a glue mfd component,
>> it exists to be an owner of an SPMI regmap for children devices
>> described in device tree.
>>
>
> Thanks. This is exactly what I have planed to do :-)
>
>> Signed-off-by: Josh Cartwright
>> Signed-off-by: Courtney Cavin
>> ---
>> drivers/mfd/Kconfig | 13 +++
>> drivers/mfd/Makefile | 1 +
>> drivers/mfd/pm8x41.c | 63
>>
>> 3 files changed, 77 insertions(+)
>> create mode 100644 drivers/mfd/pm8x41.c
>>
>
>
>
>> +
>> +static int pm8x41_probe(struct spmi_device *sdev)
>> +{
>> + struct regmap *regmap;
>> +
>> + regmap = devm_regmap_init_spmi_ext(sdev, &pm8x41_regmap_config);
>> + if (IS_ERR(regmap)) {
>> + dev_dbg(&sdev->dev, "regmap creation failed.\n");
>> + return PTR_ERR(regmap);
>> + }
>> +
>> + return of_platform_populate(sdev->dev.of_node, NULL, NULL, &sdev->dev);
>
> I think that this will not going to work. For example in this particular
> case, both controllers have "qcom,qpnp-revid" peripheral which is
> located at offset 0x100.
>
> And the result is:
>
> [0.963944] sysfs: cannot create duplicate filename
> '/bus/platform/devices/100.revid'
>
> DT looks like this:
>
> spmi {
> compatible = "qcom,spmi-pmic-arb";
> reg-names = "core", "intr", "cnfg";
> reg = <0xfc4cf000 0x1000>,
> <0xfc4cb000 0x1000>,
> <0xfc4ca000 0x1000>;
>
> interrupt-names = "periph_irq";
> interrupts = <0 190 0>;
>
> qcom,ee = <0>;
> qcom,channel = <0>;
>
> #address-cells = <2>;
> #size-cells = <0>;
>
> interrupt-controller;
> #interrupt-cells = <4>;
>
> pm8941@0 {
> compatible = "qcom,pm8941";
> reg = <0x0 SPMI_USID>;
>
> #address-cells = <1>;
> #size-cells = <0>;
>
> revid@100 {
> compatible = "qcom,qpnp-revid";
> reg = <0x100 0x100>;
> };
> };
>
> pm8841@4 {
> compatible = "qcom,pm8941";
> reg = <0x4 SPMI_USID>;
>
> #address-cells = <1>;
> #size-cells = <0>;
>
> revid@100 {
> compatible = "qcom,qpnp-revid";
> reg = <0x100 0x100>;
> };
> };
> };
>
> Any suggestions?
Probably we should only use the unit address when we have translatable
addresses. Or we could append the parent reg address to the name, but
you may have cases that don't have a parent reg value.
Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: kaslr should avoid setup_data region
On Wed, Apr 23, 2014 at 7:35 PM, Dave Young wrote: > Hello Kees > > I'm worrying that setup_data regions could be overwitten by randomize > kernel base. Would you like to fix it in kaslr code? > > One problem is there could be a lot of setup_data regions but current > mem_avoid is an fixed array. Sure, can you give me some examples? Seems like it shouldn't be too hard to have the mem_avoid logic walk additional areas. -Kees -- Kees Cook Chrome OS Security -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] spi-bfin: Add missing gpio.h include
Running my ktest.pl tests on all the archs, I stumbled over this for 3.15-rc2: drivers/spi/spi-bfin5xx.c: In function 'bfin_spi_cs_active': drivers/spi/spi-bfin5xx.c:169:3: error: implicit declaration of function 'gpio_set_value' [-Werror=implicit-function-declaration] drivers/spi/spi-bfin5xx.c: In function 'bfin_spi_setup': drivers/spi/spi-bfin5xx.c:1097:4: error: implicit declaration of function 'gpio_request' [-Werror=implicit-function-declaration] drivers/spi/spi-bfin5xx.c:1102:4: error: implicit declaration of function 'gpio_direction_output' [-Werror=implicit-function-declaration] drivers/spi/spi-bfin5xx.c:1130:3: error: implicit declaration of function 'gpio_free' [-Werror=implicit-function-declaration] The problem is that the spi-bfin5xx driver is missing an include for the gpio.h file. Signed-off-by: Steven Rostedt --- diff --git a/drivers/spi/spi-bfin5xx.c b/drivers/spi/spi-bfin5xx.c index 55e57c3..da8baa5 100644 --- a/drivers/spi/spi-bfin5xx.c +++ b/drivers/spi/spi-bfin5xx.c @@ -15,6 +15,7 @@ #include #include #include +#include #include #include #include -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: How do I make a clean mount namespace?
On Tue, Apr 22, 2014 at 03:12:11PM -0700, Andy Lutomirski wrote:
> I want to set up a little container. So I unshare the mount namespace
> and mount something somewhere (say /mnt) that I want to be my new
> root. Now what?
>
> pivot_root("/mnt", "/mnt/garbage") seems to frequently return -EBUSY.
RTFM. Literally - man 2 pivot_root and look for the only place where
it mentions EBUSY.
If you get that error, check what you've got in /proc/mounts (in the
namespace your process is in, obviously) just before the syscall.
With these arguments you really want /mnt to be a mountpoint. If your
new root really lives on the same fs as the old one, just do
mount --bind /mnt /mnt before any other mounts.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
kaslr should avoid setup_data region
Hello Kees I'm worrying that setup_data regions could be overwitten by randomize kernel base. Would you like to fix it in kaslr code? One problem is there could be a lot of setup_data regions but current mem_avoid is an fixed array. Thanks Dave -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 06/10] ARM: EXYNOS: Add support for mapping PMU base address via DT
Hi Vikas,
On 04/23/2014 10:02 PM, Vikas Sajjan wrote:
Hi,
On Wed, Apr 2, 2014 at 1:20 PM, Pankaj Dubey wrote:
From: Young-Gun Jang
Add support for mapping Exynos Power Management Unit (PMU) base address
from device tree. Code will use existing samsung pmu binding information.
This patch also adds "get_exynos_pmubase" a helper function to return mapped
base
address to various other files under "mach-exynos".
Signed-off-by: Young-Gun Jang
Signed-off-by: Pankaj Dubey
---
arch/arm/mach-exynos/common.h |2 ++
arch/arm/mach-exynos/exynos.c | 44 +
2 files changed, 46 insertions(+)
diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
index ff28334..9a55cf6 100644
--- a/arch/arm/mach-exynos/common.h
+++ b/arch/arm/mach-exynos/common.h
@@ -61,4 +61,6 @@ struct exynos_pmu_conf {
extern void exynos_sys_powerdown_conf(enum sys_powerdown mode);
+extern void __iomem *get_exynos_pmubase(void);
+
#endif /* __ARCH_ARM_MACH_EXYNOS_COMMON_H */
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index a5e1349..a5127fb 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -35,6 +35,8 @@
#define L2_AUX_VAL 0x7C470001
#define L2_AUX_MASK 0xC200
+static void __iomem *exynos_pmu_base __initdata;
Are you sure you want to keep exynos_pmu_base in .init section.
I am seeing a crash in platform_do_lowpower()
I think you should remove __initdata.
Thanks for review and testing.
You are right we do not need __initdata here.
I will take care of this in V2.
+
static struct map_desc exynos4_iodesc[] __initdata = {
{
.virtual= (unsigned long)S3C_VA_SYS,
@@ -245,6 +247,47 @@ void __init exynos_init_late(void)
exynos_pm_init();
}
+static char const *exynos_dt_pmu_match[] __initconst = {
+ "samsung,exynos4210-pmu",
+ "samsung,exynos4212-pmu",
+ "samsung,exynos4412-pmu",
+ "samsung,exynos5250-pmu",
+ NULL
+};
+
+static int __init exynos_fdt_map_pmu(unsigned long node,
+ const char *uname, int depth, void *data)
+{
+ struct map_desc iodesc;
+ __be32 *reg;
+ unsigned long len;
+
+ if (of_flat_dt_match(node, exynos_dt_pmu_match)) {
+ phys_addr_t phys_addr;
+ reg = of_get_flat_dt_prop(node, "reg", &len);
+ if (reg == NULL || len != (sizeof(unsigned long) * 2))
+ return 0;
+
+ phys_addr = be32_to_cpu(reg[0]);
+ iodesc.pfn = __phys_to_pfn(phys_addr);
+ iodesc.length = be32_to_cpu(reg[1]) - 1;
+ iodesc.virtual = (unsigned long)S5P_VA_PMU;
+ iodesc.type = MT_DEVICE;
+ iotable_init(&iodesc, 1);
+
+ exynos_pmu_base = ioremap(phys_addr, be32_to_cpu(reg[1]));
+ if (WARN_ON(!exynos_pmu_base))
+ return -EFAULT;
+ }
+
+ return 0;
+}
+
+inline void __iomem *get_exynos_pmubase()
+{
+ return exynos_pmu_base;
+}
+
static int __init exynos_fdt_map_chipid(unsigned long node, const char *uname,
int depth, void *data)
{
@@ -301,6 +344,7 @@ void __init exynos_init_io(void)
debug_ll_io_init();
of_scan_flat_dt(exynos_fdt_map_chipid, NULL);
+ of_scan_flat_dt(exynos_fdt_map_pmu, NULL);
/* detect cpu id and rev. */
s5p_init_cpu(S5P_VA_CHIPID);
--
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/
--
Best Regards,
Pankaj Dubey
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: How do I make a clean mount namespace?
On Wed, Apr 23, 2014 at 05:54:31PM -0700, Andy Lutomirski wrote:
> This requires CAP_SYS_ADMIN and it requires that the caller is not
> chrooted. path must be a mountpoint and flags must be zero.
>
> It lazy-unmounts everything outside path, and it moves path to /.
> When it's done, the current process's root is '/'. If you want to
> retain temporary access to outside things, you can keep an fd open.
> If the old root is shared, it is made private. It's okay for path to
> be shared (I think).
>
> If other things are already running in the current mount namespace,
> then their root directory stays the same, so they keep working, but
> they may be a little confused.
>
> I think this could replace pivot_root for most use cases, and it could
> simplify programs like switch_root.
>
> Thoughts?
chdir(new);
pivot_root(".", old);
umount(old, MNT_DETACH);
chroot(".");
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 net-next tree with the net tree
On Thu, 2014-04-24 at 11:47 +1000, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the net-next tree got a conflict in
> drivers/net/ethernet/intel/igb/e1000_mac.c between commit c5ffe7e1f745
> ("e1000e/igb/ixgbe/i40e: fix message terminations") from the net tree
> and
> commit c75c4edfc38d ("igb: Cleanups for messaging") from the net-next
> tree.
>
> I fixed it up (the former was a superset of the latter) and can carry
> the
> fix as necessary (no action is required).
Huh, I thought the commit c75c4edfc38d ("igb: Cleanups for messaging")
in Dave's net-next already took into account the changes in net. I will
take a look at your fix Stephen, thanks for letting us know.
signature.asc
Description: This is a digitally signed message part
Re: [PATCH 10/13] tty: serial: omap: remove some dead code
On Wed, 23 Apr 2014 20:43:34 -0500 Felipe Balbi wrote: > so, Ack for $subject or not ? > Just at the moment I'm finding it hard to care. So Acked-by: NeilBrown Whatever NeilBrown signature.asc Description: PGP signature
Re: in kernel 2.6.x, tun/tap nic supports vlan packets
On 04/23/2014 07:41 PM, Ben Hutchings wrote: On Wed, 2014-04-23 at 15:48 +0800, zhuyj wrote: On 04/23/2014 01:53 AM, Ben Hutchings wrote: [...] For what it's worth, I would recommend against applying this. I don't think even Red Hat has backported the VLAN changes, and they have been quite aggressive about backporting features to RHEL 6. If we do not merge these patches, maybe RHEL 6 can not make tap driver support vlan well. RHEL 6 isn't based on 2.6.32.y, they do all their own backporting. Hi, Ben It is well known that extraction vlan tag is not implemented in kernel 2.6.32.y. Kernel 2.6.32.y depends on nic hardware to extract vlan tag. So if the patches are not applied, tap driver can not support vlan well. Best Regards! Zhu Yanjun Ben. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RESEND] zram: correct offset usage in zram_bio_discard
Hello,
On Wed, Apr 23, 2014 at 04:41:15PM +0800, Weijie Yang wrote:
> We want to skip the physical block(PAGE_SIZE) which is partially
> covered by the discard bio, so we check the remaining size and
> subtract it if there is a need to goto the next physical block.
>
> The current offset usage in zram_bio_discard is incorrect, it will
> cause its upper filesystem breakdown.
> Consider the following scenario:
> on some architecture or config, PAGE_SIZE is 64K for example,
> filesystem is set up on zram disk without PAGE_SIZE aligned,
> a discard bio leads to a offset = 4K and size=72K,
> normally, it should not really discard any physical block as it
> partially cover two physical blocks.
> However, with the current offset usage, it will discard the second
> physical block and free its memory, which will cause filesystem breakdown.
>
> This patch corrects the offset usage in zram_bio_discard.
Nice catch.
Surely we need fix but I'd like to go further. Let's think.
How do you find that? Real problem or code review?
I'd like to know how much that happens in real practice because if it's
a lot, it means discard support is just an overhead without any benefit.
If you just found it with code review(ie, don't have any data),
would you mind adding some stat like 'num_discard/failed_discard' so
we can keep an eye on that. Although it's for rare case, I think it's worth.
Because someone would do swapon zram with --discard,
it could make same problem due to early page freeing of zram-swap to
avoid duplicating VM-owned memory and ZRAM-owned memory.
We can guide to zram-swap user not to use swapon with --discard but
I don't want it because swap_slot_free_notify is really mess which
violates layering so I hope replace it with discard finally so such
statistics really help us to drive that way more quickly.
>
> Signed-off-by: Weijie Yang
> Acked-by: Joonsoo Kim
> ---
> drivers/block/zram/zram_drv.c |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
> index 9849b52..48eccb3 100644
> --- a/drivers/block/zram/zram_drv.c
> +++ b/drivers/block/zram/zram_drv.c
> @@ -572,10 +572,10 @@ static void zram_bio_discard(struct zram *zram, u32
> index,
>* skipping this logical block is appropriate here.
>*/
> if (offset) {
> - if (n < offset)
> + if (n <= (PAGE_SIZE - offset))
> return;
>
> - n -= offset;
> + n -= (PAGE_SIZE - offset);
> index++;
> }
>
> --
> 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/
--
Kind regards,
Minchan Kim
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 0/3] usb: chipidea: msm: Clean and fix glue layer driver
On Wed, Apr 23, 2014 at 03:28:01PM +0300, Ivan T. Ivanov wrote: > From: "Ivan T. Ivanov" > > This series intend to fix driver, which was broken for a while. > It is used to create peripheral role device, which in coordination > with phy-usb-msm driver could provide USB2.0 gadget support for > Qualcomm targets. > > Changes since version 3. > > - Fix typo in devicetree description file. > > Previews version can be found here: Since in your phy's patchset, you also access portsc which is in chipidea register region, it is not a standard way. In case, you will change something at chipidea driver in future when you re-work your next revision phy's patchset, I do not send this patchset to Greg right now. Once your phy's patchset has accepted, notify me. I will send this patchset to Greg. Peter > > https://lkml.org/lkml/2014/4/22/195 > > Ivan T. Ivanov (3): > usb: chipidea: msm: Add device tree binding information > usb: chipidea: msm: Add device tree support > usb: chipidea: msm: Initialize offset of the capability registers > > .../devicetree/bindings/usb/ci-hdrc-qcom.txt | 17 +++ > drivers/usb/chipidea/ci_hdrc_msm.c | 24 > +- > 2 files changed, 40 insertions(+), 1 deletion(-) > create mode 100644 Documentation/devicetree/bindings/usb/ci-hdrc-qcom.txt > > -- > 1.8.3.2 > > > -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 RFC] sysrq: rcu-ify __handle_sysrq
On Wed, Apr 23, 2014 at 11:51:55PM +0200, Jiri Kosina wrote:
> On Wed, 23 Apr 2014, Rik van Riel wrote:
>
> > >> Echoing values into /proc/sysrq-trigger seems to be a popular way to
> > >> get information out of the kernel. However, dumping information about
> > >> thousands of processes, or hundreds of CPUs to serial console can
> > >> result in IRQs being blocked for minutes, resulting in various kinds
> > >> of cascade failures.
> > >>
> > >> The most common failure is due to interrupts being blocked for a very
> > >> long time. This can lead to things like failed IO requests, and other
> > >> things the system cannot easily recover from.
> > >>
> > >> This problem is easily fixable by making __handle_sysrq use RCU
> > >> instead of spin_lock_irqsave.
> > >>
> > >> This leaves the warning that RCU grace periods have not elapsed for a
> > >> long time, but the system will come back from that automatically.
> > >
> > > This, however, will make RCU stall detector to send NMI to all online
> > > CPUs
> > > so that they can dump their stacks.
Hey, if dumping the stacks once is a good idea, dumping them twice
must be twice as good, right? ;-)
> > It already does that, since several of the longer-running
> > sysrq handlers already grab rcu_read_lock(), for example
> > show_state().
> >
> > > IOW, this might actually make the whole sysrq dump last for much longer,
> > > and have the log polluted with all-CPU dumps for no good reason.
> > >
> > > I wonder whether explicitly setting rcu_cpu_stall_suppress during sysrq
> > > handling might be a viable workaround for this.
> >
> > I suppose that would do the trick.
>
> I can imagine Paul opposing this though ... this variable is supposed to
> be changed only by cmdline/modparam, not really flipped during runtime as
> a bandaid ... let's add Paul to CC.
Well, we already crowbar it to 1 when panic starts, see rcu_panic().
How about something like the following?
void rcu_sysrq_start(void)
{
rcu_cpu_stall_suppress = 2;
}
void rcu_sysrq_end(void)
{
if (rcu_cpu_stall_suppress == 2)
rcu_cpu_stall_suppress = 0;
}
If there get to be too many more different reasons for temporarily
suppressing RCU CPU stall warnings, I can then swap out to a better
implementation, for some definition or another of "better".
Thanx, Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: dropping capabilities in user namespace
On Wed, Apr 23, 2014 at 2:17 AM, Eric W. Biederman
wrote:
> Aditya Kali writes:
>
>> Hi all,
>>
>> I am trying to understand the behavior of how we can drop capabilities
>> inside user namespace. i.e., I want to start a process inside user
>> namespace with its effective and permitted capability sets cleared.
>
> Please note to start with that at the point you are in a user namespace
> all of your capabilities are relative to that user namespace.
>
> Now I have not had any problem dropping capabilities in a user namespace
> so you are doing something weird. Let me see if I can see what that
> weird thing is.
>
>> A typical way in which a root (uid=0) process can drop its privileges is:
>>
>> prctl(PR_SET_KEEPCAPS, 0, 0, 0, 0);
>
> You clear this bit in securebits that should already be clear anyay.
>
>> setresuid(uid, uid, uid); // At this point, permitted and effective
>> capabilities are cleared
>> exec()
>>
>> But this sequence of operation inside a user namespace does not work
>> as expected:
>
>
> As I look at this it seems to work as designed. By not starting with
> uid 0 you are triggered the non-zero uid with caps section of the code
> that has always behaved differently.
>
>> Assume /proc/pid/uid_map has entry: uid uid 1
>>
>> attach_user_ns(pid); // OR create_user_ns() & write_uid_map()
>> prctl(PR_SET_KEEPCAPS, 0, 0, 0, 0);
>> setresuid(uid, uid, uid); // Fails to reset capabilities
>> exec()
>>
>> The exec()ed process starts with correct uid set, but still with all
>> the capabilities.
>>
>> The differentiating factor here seems to be the 'root_uid' value in
>> security/commoncap.c:cap_emulate_setxuid():
>>
>> static inline void cap_emulate_setxuid(struct cred *new, const struct cred
>> *old)
>> {
>> kuid_t root_uid = make_kuid(old->user_ns, 0);
>>
>> if ((uid_eq(old->uid, root_uid) ||
>> uid_eq(old->euid, root_uid) ||
>> uid_eq(old->suid, root_uid)) &&
>> (!uid_eq(new->uid, root_uid) &&
>> !uid_eq(new->euid, root_uid) &&
>> !uid_eq(new->suid, root_uid)) &&
>> !issecure(SECURE_KEEP_CAPS)) {
>> cap_clear(new->cap_permitted);
>> cap_clear(new->cap_effective);
>> }
>> ...
>>
>> There are couple of problems here:
>> (1) In above example when there is no mapping for uid 0 inside
>> old->user_ns, make_kuid() returns INVALID_UID. Since we go on to
>> compare root_uid without first checking if its even valid, we never
>> satisfy the 'if' condition and never clear the caps. This looks like a
>> bug.
>
> INVALID_UID will never be in a capability set, so the comparison is
> guaranteed against root_uid is guaranteed to fail if there is not a root
> uid. That is correct.
>
So this does seem like a regression in userns w.r.t.
global/init-user-ns. (See below for correct example when the behavior
is different).
>> (2) Even if there is some mapping for uid 0 inside old->user_ns (say
>> "0 1"), since old->uid = 0, and root_uid= (or some non-zero
>> uid), the 'if' condition again remains unsatisfied.
>
> Correct. Because this code is not supposed to do something if you have
> caps and your uid is not zero.
>
>> It looks like currently the only case where global root (uid=0)
>> process can drop its capabilities inside a user namespace is by having
>> "0 0 " mapping in the uid_map file. It seems wrong to expose
>> global root in user namespace just to drop privileges!
>
> Where does global root come into this? Nothing above is global root
> specific? Or do you just mean you are starting all of this as the
> global root user?
>
I am starting my program as global root user, yes. The program
attaches to given user namespaces, sets uid to given uid and does some
work (which it expects to do as user without any capabilities).
I made a mistake in my example above. If I exec() at the end, the
capabilities do get cleared as you suggest. The problematic case is:
attach_to_userns(pid)
prctl(PR_SET_KEEPCAPS, 0, 0, 0, 0);
setresuid(uid, uid, uid); // Fails to reset capabilities
pause() / sleep(...) / do_some_work_as_uid() [[ no exec, sorry ]]
And I was looking at the Cap* fields in /proc//status
from another terminal. I noticed that the capabilities were not reset
after the setresuid() call. This behavior is different as compared to
what happens in init_user_ns.
>> So I feel we
>> need to fix the condition checks everywhere we are using make_kuid()
>> in security/commoncap.c.
>> Can the security experts please advice how this is supposed to work?
>
> If you don't want to set your uid to 0 inside a user namespace before
> setting your uid to something else. You need to call capset, because
> you are in bizarro land with respect to capabilities.
>
> If you don't want things to work like normal, and you want to skip
> setting your uid to 0 before calling setrexuid(2) you need to call
> capset(2).
>
I cannot call setuid(0) before setting the uid to something else there
is no uid 0 inside userns as per the uid_map. I will try the capset()
approach,
linux-next: manual merge of the net-next tree with the net tree
Hi all,
Today's linux-next merge of the net-next tree got a conflict in
net/core/filter.c between commit 83d5b7ef99c9 ("net: filter: initialize A
and X registers") from the net tree and commit 4cd3675ebf74 ("filter:
added BPF random opcode") from the net-next 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 net/core/filter.c
index 9d79ca0a6e8e,78a636e60a0b..
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@@ -652,6 -643,19 +652,12 @@@ static u64 __get_raw_cpu_id(u64 ctx, u6
return raw_smp_processor_id();
}
+ /* note that this only generates 32-bit random numbers */
+ static u64 __get_random_u32(u64 ctx, u64 A, u64 X, u64 r4, u64 r5)
+ {
+ return (u64)prandom_u32();
+ }
+
-/* Register mappings for user programs. */
-#define A_REG 0
-#define X_REG 7
-#define TMP_REG 8
-#define ARG2_REG 2
-#define ARG3_REG 3
-
static bool convert_bpf_extensions(struct sock_filter *fp,
struct sock_filter_int **insnp)
{
pgp8TKMyXMA79.pgp
Description: PGP signature
Microsoft webmail users system alert: Attention !!!
Dear Subscriber Webmail account is currently conducting a process-maintenance of all accounts email.to validate your account against spy-ware and spam e-mails to complete this, Click Here: http://webmailaccountupgrad04.webs.com/ and login to activate your webmail account. http://webmailaccountupgrad04.webs.com/ This process will help us to fight against Spam Mails. Failure to update your account in the link above, will make your email address active in our database. We are sincerely sorry for any inconvenience Kind Regards, Webmail Account Messaging Center Webmaster copyright @ 2014 openwebmail all rights reserved. -- Esta mensagem foi verificada pelo sistema de antivirus e acredita-se estar livre de perigo. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 net-next tree with the net tree
Hi all,
Today's linux-next merge of the net-next tree got a conflict in
drivers/net/ethernet/intel/igb/e1000_mac.c between commit c5ffe7e1f745
("e1000e/igb/ixgbe/i40e: fix message terminations") from the net tree and
commit c75c4edfc38d ("igb: Cleanups for messaging") from the net-next
tree.
I fixed it up (the former was a superset of the latter) and can carry the
fix as necessary (no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgp5XJbWheCYW.pgp
Description: PGP signature
Re: [PATCH 10/13] tty: serial: omap: remove some dead code
Hi, On Thu, Apr 24, 2014 at 11:41:15AM +1000, NeilBrown wrote: > On Wed, 23 Apr 2014 20:21:00 -0500 Felipe Balbi wrote: > > > I have no problem either way, just that unused code doesn't have to be > > sitting in the tree and I'm not entirely sure this GPIO should be > > handled by omap-serial.c, perhaps something more generic inside > > serial-core so other UART drivers can benefit from it. > > Perhaps. But there there are more people I need to convince :-) heh, Greg is in Cc, that'd be a good start. > > > On the other hand, if you can point out to me what I'm missing, and how I > > > can > > > solve my problem with any virtual GPIOs, I'm all ears. > > > > > > To make my problem simple and explicit: I have a device attached to a > > > UART > > > which has a separate regulator. The regulator should be powered on if and > > > > So you're using DTR to power the GPIO and hoping that the regulator > > stabilizes quickly enough so that by the time your open() finishes you > > don't have to add nonsensical msleep() calls before writing to the > > device. Sounds a bit fragile to me. > > The gpio_set call is synchronous, and the gpio-regulator driver could add a sure, but it's synchronous towards toggling the GPIO, pulling it high. It doesn't guarantee that the far-end regulator's output will be fully changed. > delay (I think). yeah, that'd be part of the regulator-gpio with the startup-delay-ns property (IIRC) > > > only if the /dev/ttyXX interface to the UART is open. The device is a > > > bluetooth transceiver. > > > > considering this is a BTUART device, why didn't you do this at the ldisc > > level ? hci_uart_open() sounds like a good choice from a quick thinking. > > > > I'll have a look into that, thanks. so, Ack for $subject or not ? -- balbi signature.asc Description: Digital signature
Re: [PATCH 10/13] tty: serial: omap: remove some dead code
On Wed, 23 Apr 2014 20:21:00 -0500 Felipe Balbi wrote: > I have no problem either way, just that unused code doesn't have to be > sitting in the tree and I'm not entirely sure this GPIO should be > handled by omap-serial.c, perhaps something more generic inside > serial-core so other UART drivers can benefit from it. Perhaps. But there there are more people I need to convince :-) > > > On the other hand, if you can point out to me what I'm missing, and how I > > can > > solve my problem with any virtual GPIOs, I'm all ears. > > > > To make my problem simple and explicit: I have a device attached to a UART > > which has a separate regulator. The regulator should be powered on if and > > So you're using DTR to power the GPIO and hoping that the regulator > stabilizes quickly enough so that by the time your open() finishes you > don't have to add nonsensical msleep() calls before writing to the > device. Sounds a bit fragile to me. The gpio_set call is synchronous, and the gpio-regulator driver could add a delay (I think). > > > only if the /dev/ttyXX interface to the UART is open. The device is a > > bluetooth transceiver. > > considering this is a BTUART device, why didn't you do this at the ldisc > level ? hci_uart_open() sounds like a good choice from a quick thinking. > I'll have a look into that, thanks. NeilBrown signature.asc Description: PGP signature
[PATCH] ARM: armv6 & armv7 no need update SCTLR for alignment
Now in the code, when interrupt and exception disturbs the user-space, always update SCTLR with cr_alignment. In our ARMv7 Cortex A15 SOC, the statements bracketed by CONFIG_ALIGNMENT_TRAP need about 100 cycles. it impacts our high realtime interrupt requirement scenario. Considering in ARMv6 and ARMv7 versions, cr_alignment and cr_no_alignment are always same without A bit, they are initialized by clearing A bit in alignment_init. So there is no need to update SCTLR if interrupt and exception disturbs the user-space in vector_swi function or alignment_trap macro, in the ARMv6 and ARMv7 chip. The patch has already verified in our ARMv7 Cortex A15 SOC. Signed-off-by: Wuqixuan --- arch/arm/kernel/entry-common.S |4 ++-- arch/arm/kernel/entry-header.S |2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/arm/kernel/entry-common.S b/arch/arm/kernel/entry-common.S index a2dcafd..4b7686a 100644 --- a/arch/arm/kernel/entry-common.S +++ b/arch/arm/kernel/entry-common.S @@ -366,7 +366,7 @@ ENTRY(vector_swi) #endif zero_fp -#ifdef CONFIG_ALIGNMENT_TRAP +#if defined(CONFIG_ALIGNMENT_TRAP) && !(__LINUX_ARM_ARCH__ >= 6) ldr ip, __cr_alignment ldr ip, [ip] mcr p15, 0, ip, c1, c0 @ update control register @@ -490,7 +490,7 @@ __sys_trace_return: b ret_slow_syscall .align 5 -#ifdef CONFIG_ALIGNMENT_TRAP +#if defined(CONFIG_ALIGNMENT_TRAP) && !(__LINUX_ARM_ARCH__ >= 6) .type __cr_alignment, #object __cr_alignment: .word cr_alignment diff --git a/arch/arm/kernel/entry-header.S b/arch/arm/kernel/entry-header.S index 1420725..5eb9e59 100644 --- a/arch/arm/kernel/entry-header.S +++ b/arch/arm/kernel/entry-header.S @@ -38,7 +38,7 @@ .endm .macro alignment_trap, rtemp -#ifdef CONFIG_ALIGNMENT_TRAP +#if defined(CONFIG_ALIGNMENT_TRAP) && !(__LINUX_ARM_ARCH__ >= 6) ldr \rtemp, .LCcralign ldr \rtemp, [\rtemp] mcr p15, 0, \rtemp, c1, c0 -- 1.7.6-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v5 2/2] Use kernfs_break_active_protection() for device online store callbacks
On Wed, 2014-04-23 at 12:58 +0200, Rafael J. Wysocki wrote:
> On Wednesday, April 23, 2014 01:03:42 PM Li Zhong wrote:
> > On Tue, 2014-04-22 at 16:44 -0400, Tejun Heo wrote:
> > > Hello,
> > >
> > > On Tue, Apr 22, 2014 at 11:34:39AM +0800, Li Zhong wrote:
> > > > > Is this assumption true? If so, can we add lockdep assertions in
> > > > > places to verify and enforce this? If not, aren't we just feeling
> > > > > good when the reality is broken?
> > > >
> > > > It seems not true ... I think there are devices that don't have the
> > > > online/offline concept, we just need to add it, remove it, like ethernet
> > > > cards.
> > > >
> > > > Maybe we could change the comments above, like:
> > > > /* We assume device_hotplug_lock must be acquired before
> > > > * removing devices, which have online/offline sysfs knob,
> > > > * and some locks are needed to serialize the online/offline
> > > > * callbacks and device removing. ...
> > > > ?
> > > >
> > > > And we could add lockdep assertions in cpu and memory related code? e.g.
> > > > remove_memory(), unregister_cpu()
> > > >
> > > > Currently, remove_memory() has comments for the function:
> > > >
> > > > * NOTE: The caller must call lock_device_hotplug() to serialize hotplug
> > > > * and online/offline operations before this call, as required by
> > > > * try_offline_node().
> > > > */
> > > >
> > > > maybe it could be removed with the lockdep assertion.
> > >
> > > I'm confused about the overall locking scheme. What's the role of
> > > device_hotplug_lock? Is that solely to prevent the sysfs deadlock
> > > issue? Or does it serve other synchronization purposes depending on
> > > the specific subsystem? If the former, the lock no longer needs to
> > > exist. The only thing necessary would be synchronization between
> > > device_del() deleting the sysfs file and the unbreak helper invoking
> > > device-specific callback. If the latter, we probably should change
> > > that. Sharing hotplug lock across multiple subsystems through driver
> > > core sounds like a pretty bad idea.
> >
> > I think it's the latter.
>
> Actually, no, this is not the case if I understand you correctly.
Oh, Sorry, I didn't read carefully. Yes, it's not specific subsystem.
After seeing your reply, I understand it is for protecting device hot
remove involving multiple subsystems.
>
> > I think device_{on|off}line is better to be
> > done in some sort of lock which prevents the device from being removed,
> > including some preparation work that needs be done before device_del().
>
> Quite frankly, you should be confident that you understand the code you're
> trying to modify or please don't touch it.
>
> I'll have a deeper look at this issue later today or tomorrow and will get
> back to you then.
Ok, thank you,
Zhong
>
> 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/
[PATCH 3/3] sched, fair: Stop searching for tasks in newidle balance if there are runnable tasks
It was found that when running some workloads (such as AIM7) on large systems
with many cores, CPUs do not remain idle for long. Thus, tasks can
wake/get enqueued while doing idle balancing.
In this patch, while traversing the domains in idle balance, in addition to
checking for pulled_task, we add an extra check for this_rq->nr_running for
determining if we should stop searching for tasks to pull. If there are
runnable tasks on this rq, then we will stop traversing the domains. This
reduces the chance that idle balance delays a task from running.
This patch resulted in approximately a 6% performance improvement when
running a Java Server workload on an 8 socket machine.
Signed-off-by: Jason Low
---
kernel/sched/fair.c |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 3e3ffb8..232518c 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -6689,7 +6689,6 @@ static int idle_balance(struct rq *this_rq)
if (sd->flags & SD_BALANCE_NEWIDLE) {
t0 = sched_clock_cpu(this_cpu);
- /* If we've pulled tasks over stop searching: */
pulled_task = load_balance(this_cpu, this_rq,
sd, CPU_NEWLY_IDLE,
&continue_balancing);
@@ -6704,7 +6703,12 @@ static int idle_balance(struct rq *this_rq)
interval = msecs_to_jiffies(sd->balance_interval);
if (time_after(next_balance, sd->last_balance + interval))
next_balance = sd->last_balance + interval;
- if (pulled_task)
+
+ /*
+* Stop searching for tasks to pull if there are
+* now runnable tasks on this rq.
+*/
+ if (pulled_task || this_rq->nr_running > 0)
break;
}
rcu_read_unlock();
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] sched: Initialize newidle balance stats in sd_numa_init()
Also initialize the per-sd variables for newidle load balancing in sd_numa_init(). Signed-off-by: Jason Low --- kernel/sched/core.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/kernel/sched/core.c b/kernel/sched/core.c index 3f12533..b1c6cb9 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -6030,6 +6030,8 @@ sd_numa_init(struct sched_domain_topology_level *tl, int cpu) , .last_balance = jiffies, .balance_interval = sd_weight, + .max_newidle_lb_cost= 0, + .next_decay_max_lb_cost = jiffies, }; SD_INIT_NAME(sd, NUMA); sd->private = &tl->data; -- 1.7.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] sched, balancing: Update rq->max_idle_balance_cost whenever newidle balance is attempted
Commit e5fc6611 can potentially cause rq->max_idle_balance_cost to not be
updated, even when load_balance(NEWLY_IDLE) is attempted and the per-sd
max cost value is updated.
In this patch, we update the rq->max_idle_balance_cost regardless of
whether or not a task has been enqueued while browsing the domains.
Signed-off-by: Jason Low
---
kernel/sched/fair.c |9 +
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 43232b8..3e3ffb8 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -6658,6 +6658,7 @@ static int idle_balance(struct rq *this_rq)
int this_cpu = this_rq->cpu;
idle_enter_fair(this_rq);
+
/*
* We must set idle_stamp _before_ calling idle_balance(), such that we
* measure the duration of idle_balance() as idle time.
@@ -6710,9 +6711,12 @@ static int idle_balance(struct rq *this_rq)
raw_spin_lock(&this_rq->lock);
+ if (curr_cost > this_rq->max_idle_balance_cost)
+ this_rq->max_idle_balance_cost = curr_cost;
+
/*
* While browsing the domains, we released the rq lock.
-* A task could have be enqueued in the meantime
+* A task could have been enqueued in the meantime.
*/
if (this_rq->cfs.h_nr_running && !pulled_task) {
pulled_task = 1;
@@ -6727,9 +6731,6 @@ static int idle_balance(struct rq *this_rq)
this_rq->next_balance = next_balance;
}
- if (curr_cost > this_rq->max_idle_balance_cost)
- this_rq->max_idle_balance_cost = curr_cost;
-
out:
/* Is there a task of a high priority class? */
if (this_rq->nr_running != this_rq->cfs.h_nr_running)
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/3] sched: Idle balance patches
This patchset includes a few modifications related to idle_balance(). Patch #1 addresses an issue introduced by commit e5fc6611 which potentially can cause rq->max_idle_balance_cost to not get updated when it should. Patch #2 initializes the per domain newidle balance stats in sd_numa_init(). Patch #3 is a performance related patch. It stops searching for more tasks to pull while traversing the domains in idle balance if we find that there are runnable tasks. This patch resulted in approximately a 6% performance improvement to a Java server workload on an 8 socket machine. Jason Low (3): sched, balancing: Update rq->max_idle_balance_cost whenever newidle balance is attempted sched: Initialize newidle balance stats in sd_numa_init() sched, fair: Stop searching for tasks in newidle balance if there are runnable tasks kernel/sched/core.c |2 ++ kernel/sched/fair.c | 17 +++-- 2 files changed, 13 insertions(+), 6 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 4/6] soc: ti: add Keystone Navigator QMSS driver
Hi, On Wed, Apr 23, 2014 at 07:46:20PM -0400, Santosh Shilimkar wrote: > From: Sandeep Nair > > The QMSS (Queue Manager Sub System) found on Keystone SOCs is one of > the main hardware sub system which forms the backbone of the Keystone > Multi-core Navigator. QMSS consist of queue managers, packed-data structure > processors(PDSP), linking RAM, descriptor pools and infrastructure > Packet DMA. > > The Queue Manager is a hardware module that is responsible for accelerating > management of the packet queues. Packets are queued/de-queued by writing or > reading descriptor address to a particular memory mapped location. The PDSPs > perform QMSS related functions like accumulation, QoS, or event management. > Linking RAM registers are used to link the descriptors which are stored in > descriptor RAM. Descriptor RAM is configurable as internal or external memory. > > The QMSS driver manages the PDSP setups, linking RAM regions, > queue pool management (allocation, push, pop and notify) and descriptor > pool management. The specifics on the device tree bindings for > QMSS can be found in: > Documentation/devicetree/bindings/soc/keystone-navigator-qmss.txt > > Cc: Greg Kroah-Hartman > Cc: Kumar Gala > Cc: Olof Johansson > Cc: Arnd Bergmann > Cc: Grant Likely > Cc: Rob Herring > Cc: Mark Rutland > Signed-off-by: Sandeep Nair > Signed-off-by: Santosh Shilimkar > --- > drivers/Kconfig |2 + > drivers/soc/Kconfig |2 + > drivers/soc/Makefile |5 + > drivers/soc/ti/Kconfig | 21 + > drivers/soc/ti/Makefile |4 + > drivers/soc/ti/knav_qmss.h | 386 > drivers/soc/ti/knav_qmss_acc.c | 591 + > drivers/soc/ti/knav_qmss_queue.c | 1814 > ++ > include/linux/soc/ti/knav_qmss.h | 90 ++ > 9 files changed, 2915 insertions(+) > create mode 100644 drivers/soc/Makefile > create mode 100644 drivers/soc/ti/Kconfig > create mode 100644 drivers/soc/ti/Makefile > create mode 100644 drivers/soc/ti/knav_qmss.h > create mode 100644 drivers/soc/ti/knav_qmss_acc.c > create mode 100644 drivers/soc/ti/knav_qmss_queue.c > create mode 100644 include/linux/soc/ti/knav_qmss.h > > diff --git a/drivers/Kconfig b/drivers/Kconfig > index 0e87a34..8993913 100644 > --- a/drivers/Kconfig > +++ b/drivers/Kconfig > @@ -148,6 +148,8 @@ source "drivers/remoteproc/Kconfig" > > source "drivers/rpmsg/Kconfig" > > +source "drivers/soc/Kconfig" This hunk was already in patch one but in a different offset in this file. -- balbi signature.asc Description: Digital signature
Re: [PATCH 1/3] usb: ohci-exynos: Make provision for vdd regulators
On Thursday, April 24, 2014 9:33 AM, Jingoo Han wrote:
> On Thursday, April 24, 2014 9:18 AM, Anton Tikhomirov wrote:
> > On Monday, April 21, 2014 9:17 PM, Vivek Gautam wrote:
> > >
> > > Facilitate getting required 3.3V and 1.0V VDD supply for
> > > OHCI controller on Exynos.
> > >
> > > With patches for regulators' nodes merged in 3.15:
> > > c8c253f ARM: dts: Add regulator entries to smdk5420
> > > 275dcd2 ARM: dts: add max77686 pmic node for smdk5250,
> > >
> > > certain perripherals will now need to ensure that,
> > > they request VDD regulators in their drivers, and enable
> > > them so as to make them working.
> > >
> > > Signed-off-by: Vivek Gautam
> > > Cc: Jingoo Han
> > > ---
> > >
> > > Based on 'usb-next' branch of Greg's usb tree.
> > >
> > > drivers/usb/host/ohci-exynos.c | 47
> > >
> > > 1 file changed, 47 insertions(+)
> > >
> > > diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-
> > > exynos.c
> > > index 68588d8..e2e72a8 100644
> > > --- a/drivers/usb/host/ohci-exynos.c
> > > +++ b/drivers/usb/host/ohci-exynos.c
> > > @@ -18,6 +18,7 @@
> > > #include
> > > #include
> > > #include
> > > +#include
> > > #include
> > > #include
> > > #include
> > > @@ -37,6 +38,8 @@ struct exynos_ohci_hcd {
> > > struct clk *clk;
> > > struct usb_phy *phy;
> > > struct usb_otg *otg;
> > > + struct regulator *vdd33;
> > > + struct regulator *vdd10;
> > > };
> > >
> > > static void exynos_ohci_phy_enable(struct platform_device *pdev)
> > > @@ -98,6 +101,28 @@ static int exynos_ohci_probe(struct platform_device
> > > *pdev)
> > > exynos_ohci->otg = phy->otg;
> > > }
> > >
> > > + exynos_ohci->vdd33 = devm_regulator_get(&pdev->dev, "vdd33");
> > > + if (IS_ERR(exynos_ohci->vdd33)) {
> > > + err = PTR_ERR(exynos_ohci->vdd33);
> > > + goto fail_regulator1;
> > > + }
> > > + err = regulator_enable(exynos_ohci->vdd33);
> > > + if (err) {
> > > + dev_err(&pdev->dev, "Failed to enable VDD33 supply\n");
> > > + goto fail_regulator1;
> > > + }
> > > +
> > > + exynos_ohci->vdd10 = devm_regulator_get(&pdev->dev, "vdd10");
> > > + if (IS_ERR(exynos_ohci->vdd10)) {
> > > + err = PTR_ERR(exynos_ohci->vdd10);
> > > + goto fail_regulator2;
> > > + }
> > > + err = regulator_enable(exynos_ohci->vdd10);
> > > + if (err) {
> > > + dev_err(&pdev->dev, "Failed to enable VDD10 supply\n");
> > > + goto fail_regulator2;
> > > + }
> > > +
> >
> > Do we need to skip regulator settings together with PHY configuration
> > in case of exynos5440?
>
> Oh, right. In the case of exynos5440, regulator settings is not
> necessary. Vivek, would you fix it in order skip regulator settings
> in exynos5440? It also applies to ehci-exynos.
Sorry, in the case of exynos5440, this patch already skips
regulator settings.
In the case of exynos5440, there is no need to set PHY setting
and regulator setting.
How about making regulator setting "optional"?
Then, regulator setting can be done, only when regulator
is supported.
exynos_ohci_probe()
exynos_ohci->vdd33 = devm_regulator_get(&pdev->dev, "vdd33");
if (IS_ERR(exynos_ohci->vdd33)) {
dev_err(&pdev->dev, "Failed to get VDD33 supply\n");
} else {
err = regulator_enable(exynos_ohci->vdd33);
if (err) {
dev_err(&pdev->dev, "Failed to enable VDD33 supply\n");
goto fail_regulator1;
}
}
exynos_ohci->vdd10 = devm_regulator_get(&pdev->dev, "vdd10");
if (IS_ERR(exynos_ohci->vdd10)) {
dev_err(&pdev->dev, "Failed to get VDD10 supply\n");
} else {
err = regulator_enable(exynos_ohci->vdd10);
if (err) {
dev_err(&pdev->dev, "Failed to enable VDD10 supply\n");
goto fail_regulator2;
}
}
In this case, suspend/resume can be fixed as below.
exynos_ohci_suspend()
if (exynos_ohci->vdd10)
regulator_disable(exynos_ohci->vdd10);
if (exynos_ohci->vdd33)
regulator_disable(exynos_ohci->vdd33);
exynos_ohci_resume()
if (exynos_ohci->vdd33) {
ret = regulator_enable(exynos_ohci->vdd33);
if (ret) {
dev_err(dev, "Failed to enable VDD33 supply\n");
return ret;
}
}
if (exynos_ohci->vdd10) {
ret = regulator_enable(exynos_ohci->vdd10);
if (ret) {
dev_err(dev, "Failed to enable VDD10 supply\n");
return ret;
}
}
Best regards,
Jingoo Han
>
> >
> > > skip_phy:
> > > exynos_ohci->clk = devm_clk_get(&pdev->dev, "usbhost");
> > >
> > > @@ -154,6 +179,10 @@ fail_add_hcd:
> > > fail_io:
> > > clk_disable_unprepare(exynos_o
Re: [PATCH/RFC 0/5] Support loop-back NFS mounts - take 2
On Wed, Apr 23, 2014 at 12:40:58PM +1000, NeilBrown wrote: > This is a somewhat shorter patchset for loop-back NFS support than > last time, thanks to the excellent feedback and particularly to Dave > Chinner. Thanks. > > Avoiding the wait-for-congestion which can trigger a livelock is much > the same, though I've reduced the cases in which the wait is > by-passed. > I did this using current->backing_dev_info which is otherwise serving > no purpose on the current kernel. > > Avoiding the deadlocks has been turned on its head. > Instead of nfsd checking if it is a loop-back mount and setting > PF_FSTRANS, which then needs lots of changes too PF_FSTRANS and > __GFP_FS handling, it is now NFS which checks for a loop-back > filesystem. > > There is more verbosity in that patch (Fifth of Five) but the essence > is that nfs_release_page will now not wait indefinitely for a COMMIT > request to complete when sent to the local host. It still waits a > little while as some delay can be important. But it won't wait > forever. > The duration of "a little while" is currently 100ms, though I do > wonder if a bigger number would serve just as well. > > Unlike the previous series, this set should remove deadlocks that > could happen during the actual fail-over process. This is achieved by > having nfs_release_page monitor the connection and if it changes from > a remote to a local connection, or just disconnects, then it will > timeout. It currently polls every second, though this probably could > be longer too. It only needs to be the same order of magnitude as the > time it takes node failure to be detected and failover to happen, and > I suspect that is closer to 1 minute. So maybe a 10 or 20 second poll > interval would be just as good. > > Implementing this timeout requires some horrible code as the > wait_on_bit functions don't support timeouts. If the general approach > is found acceptable I'll explore ways to improve the timeout code. > > Comments, criticism, etc very welcome as always, Looks much less intrusive to me, and doesn't appear to affect any other filesystem or the recursion patterns of memory reclaim, so I like it very much more than the previous patchset. Nice work! :) The code changes are really outside my area of expertise now, so I don't really feel qualified to review the changes. However, consider the overall approach: Acked-by: Dave Chinner Cheers, Dave. -- Dave Chinner da...@fromorbit.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/13] tty: serial: omap: remove some dead code
Hi, On Thu, Apr 24, 2014 at 10:13:29AM +1000, NeilBrown wrote: > On Wed, 23 Apr 2014 18:01:21 -0500 Felipe Balbi wrote: > > > Hi, > > > > On Thu, Apr 24, 2014 at 08:43:05AM +1000, NeilBrown wrote: > > > On Wed, 23 Apr 2014 10:35:04 -0500 Nishanth Menon wrote: > > > > > > > On 04/23/2014 09:58 AM, Felipe Balbi wrote: > > > > > nobody passes a DTR_gpio to this driver, so > > > > > this code is not necessary. > > > > > > > > > > Signed-off-by: Felipe Balbi > > > > > --- > > > > > > > > Niel, > > > > this seems to revert the functionality introduced in > > > > commit 9574f36fb801035f6ab0fbb1b53ce2c12c17d100 > > > > (OMAP/serial: Add support for driving a GPIO as DTR.) > > > > > > > > would you like to Ack this change? > > > > > > I have a couple of out-of-tree drivers that use this support. > > > > > > I hope to get back to working on that code one day and even get those > > > drivers > > > upstream. So I would really prefer this code to remain if it isn't > > > causing > > > any actual problems. > > > > it causes problem with DT (not really). That suport is only available on > > legacy platform_data-based boot, it's not available on DT. I hear Tony > > is pretty close to turning OMAP3 DT-only. > > > > > Of course, I can always re-submit it when I need it again, but that it > > > just > > > extra work all around. > > > > I wonder how you will pass those attributes through DT considering they > > are *really* SW configuration. Why can't you use the real DTR pin, btw ? > > > > This myth that DT is only about hardware is probably one of the > reasons that I haven't got these out-of-tree drivers upstream yet. take that up with DT maintainers > There is no "real" DTR pin. heh, my bad... confused with RTS which is supported in this HW. > When I open /dev/ttyWHATEVER, I need the driver for the device that is > permanently connected to that serial port to be told that the serial-device > has been opened so that it can "power on" or "wake up" the device. > > I don't much care how that happens, or how I tell DT that it has to happen. > I just need it to happen. > > In discrete hardware devices, the DTR line is what you would use. The RS232 > port would raise (or lower or whatever) DTR when /dev/ttyWHATEVER was open, > and the device that was plugged in would detect the level change and do > stuff. > > But I don't have discrete hardware. I have a bunch of stuff soldered onto a > board with ad-hoc connections chosen to make the life of the hardware builder > easy rather than chosen to make the life of the software developer easy > (which I think is the correct choice). > > So I need to tell DT "This device is plugged into this UART, and there is no > DTR line, but when the UARTs DTR line would be asserted (if it had one), then > I need that regulator of there turned on". or maybe "I need to toggle this > GPIO with exactly this pattern, while watching that GPIO to see if it is > working". > > So I thought: > > 1/ give the UART a "virtual" DTR so it could drive any GPIO > 2/ create a "gpio-to-regulator" driver which presented as a (virtual) gpio > and responded to state changes on that GPIO by turning on or off the > regulator > 3/ create a dedicated driver which knows how to toggle the magic GPIO while > watching the other GPIO to convince the silly device to wakeup, or go to > sleep, as required, and have this appear as a (virtual) GPIO. > > Then I can just tell DT that these (virtual) GPIOs are connected together, > and it will all just work. And it does. > > But given the whole "no no, DT is for describing hardware, and you are > describing software" attitude, it seems that I lost motivation for a while > (that wasn't the only reason, but it didn't help). > > I have a patch which converts the OMAP serial driver to use DT to configure > these virtual DTR lines. I'm very happy to submit that if there is some > chance it might be accepted and will keep the current DTR code in place. I have no problem either way, just that unused code doesn't have to be sitting in the tree and I'm not entirely sure this GPIO should be handled by omap-serial.c, perhaps something more generic inside serial-core so other UART drivers can benefit from it. > On the other hand, if you can point out to me what I'm missing, and how I can > solve my problem with any virtual GPIOs, I'm all ears. > > To make my problem simple and explicit: I have a device attached to a UART > which has a separate regulator. The regulator should be powered on if and So you're using DTR to power the GPIO and hoping that the regulator stabilizes quickly enough so that by the time your open() finishes you don't have to add nonsensical msleep() calls before writing to the device. Sounds a bit fragile to me. > only if the /dev/ttyXX interface to the UART is open. The device is a > bluetooth transceiver. considering this is a BTUART device, why didn't you do this at the ldisc level ? hci_uart_open() sounds
linux-next: build failure after merge of the libata tree
Hi Tejun,
After merging the libata tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/ata/libahci_platform.c: In function 'ahci_platform_init_host':
drivers/ata/libahci_platform.c:317:20: warning: cast to pointer from integer of
different size [-Wint-to-pointer-cast]
pi.private_data = (void *)host_flags
^
drivers/ata/libahci_platform.c:318:2: error: expected ';' before 'hpriv'
hpriv->flags |= host_flags;
^
Please test build this stuff ...
Caused by commit ac795a7ec2d2 ("libahci_platform: add host_flags parameter
in ahci_platform_init_host()").
I have used the libata tree from next-20140423 for today.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgp0ixxxNgW0R.pgp
Description: PGP signature
Re: [RFC PATCH v5 2/2] Use kernfs_break_active_protection() for device online store callbacks
On Wed, 2014-04-23 at 12:54 +0200, Rafael J. Wysocki wrote:
> On Wednesday, April 23, 2014 09:50:32 AM Li Zhong wrote:
> > On Tue, 2014-04-22 at 12:11 +0200, Rafael J. Wysocki wrote:
> > > On Tuesday, April 22, 2014 11:34:39 AM Li Zhong wrote:
> > > > On Mon, 2014-04-21 at 18:46 -0400, Tejun Heo wrote:
> > > > > Hello,
> > > > >
> > > > > On Mon, Apr 21, 2014 at 05:23:50PM +0800, Li Zhong wrote:
> > > > >
> > > > > Proper /** function comment would be nice.
> > > >
> > > > Ok, will try to write some in next version.
> > > >
> > > > >
> > > > > > +struct kernfs_node *lock_device_hotplug_sysfs(struct device *dev,
> > > > > > + struct device_attribute
> > > > > > *attr)
> > > > >
> > > > > I can see why you did this but let's please not require the user of
> > > > > this function to see how the thing is working internally. Let's
> > > > > return int and keep track of (or look up again) the kernfs_node
> > > > > internally.
> > > >
> > > > Ok, it also makes the prototype of lock and unlock look more consistent
> > > > and comfortable.
> > > >
> > > > >
> > > > > > {
> > > > > ...
> > > > > > + /*
> > > > > > +* We assume device_hotplug_lock must be acquired before
> > > > > > removing
> > > > >
> > > > > Is this assumption true? If so, can we add lockdep assertions in
> > > > > places to verify and enforce this? If not, aren't we just feeling
> > > > > good when the reality is broken?
> > > >
> > > > It seems not true ... I think there are devices that don't have the
> > > > online/offline concept, we just need to add it, remove it, like ethernet
> > > > cards.
> > >
> > > Well, I haven't been following this closely (I was travelling, sorry), but
> > > there certainly are devices without online/offline. That currently is
> > > only
> > > present for CPUs, memory blocks and ACPI containers (if I remember
> > > correctly).
> > >
> > > >
> > > > Maybe we could change the comments above, like:
> > > > /* We assume device_hotplug_lock must be acquired before
> > > > * removing devices, which have online/offline sysfs knob,
> > > > * and some locks are needed to serialize the online/offline
> > > > * callbacks and device removing. ...
> > > > ?
> > >
> > > Lockdep assertions would be better than this in my opinion.
> >
> > This is talking about the lock required in the other process, the device
> > removing process, e.g. that in remove_memory() below. So I guess no
> > lockdep assertions needed here. Or I misunderstand your point?
>
> I mean if you assume certain lock to be held somewhere, it is better to use
> lockdep annotations to express that assumption, because that will cause users
> to *see* the problem when it happens.
OK, I see, I think you were suggesting the same thing as Tejun, just I
misunderstood it.
Thanks, Zhong
>
> 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 V7 1/1] drivers/gpio: Altera soft IP GPIO driver and devicetree binding
On Wed, Apr 23, 2014 at 9:32 PM, Linus Walleij wrote: > On Mon, Mar 3, 2014 at 11:27 AM, wrote: > >> From: Tien Hock Loh >> >> Add driver support for Altera GPIO soft IP, including interrupts and I/O. >> Tested on Altera CV SoC board using dipsw and LED using LED framework. >> >> Signed-off-by: Tien Hock Loh > > Some time has passed since this was posted and we now have > GPIO irqchip helpers in the gpiolib core. > > If you repost this, please reform this driver to use the gpiochip > irqchip helpers in the manner of e.g. drivers/gpio/gpio-pl061.c. > > More examples and documentation is available on the "devel" > branch in the gpio git tree (also in linux-next). OK noted. I'll do that. Thanks for the info. > > Yours, > Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: How do I make a clean mount namespace?
On Wed, Apr 23, 2014 at 1:01 PM, Richard Weinberger
wrote:
> On Wed, Apr 23, 2014 at 12:12 AM, Andy Lutomirski wrote:
>> I want to set up a little container. So I unshare the mount namespace
>> and mount something somewhere (say /mnt) that I want to be my new
>> root. Now what?
>>
>> pivot_root("/mnt", "/mnt/garbage") seems to frequently return -EBUSY.
>>
>> mounting /mnt onto / using MS_MOVE seems to succeed, but / still
>> points at the old root.
>>
>> Am I missing a clean way to do this? I want a way to say "make this
>> mountpoint be the root of the whole mount namespace and lazy-unmount
>> everything outside it". If there is no straightforward way to do
>> that, can we add one?
>
> I fear you have to read /proc/mounts and umount() everything in the
> correct order.
> If you find a better way, please tell. :-)
>
How about adding a new syscall:
int change_root_mount(const char *path, unsigned long flags);
This requires CAP_SYS_ADMIN and it requires that the caller is not
chrooted. path must be a mountpoint and flags must be zero.
It lazy-unmounts everything outside path, and it moves path to /.
When it's done, the current process's root is '/'. If you want to
retain temporary access to outside things, you can keep an fd open.
If the old root is shared, it is made private. It's okay for path to
be shared (I think).
If other things are already running in the current mount namespace,
then their root directory stays the same, so they keep working, but
they may be a little confused.
I think this could replace pivot_root for most use cases, and it could
simplify programs like switch_root.
Thoughts?
--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/
Re: [PATCH RFC] sysrq: rcu-ify __handle_sysrq
On Wed, 23 April 2014 23:37:54 +0200, Jiri Kosina wrote:
>
> This, however, will make RCU stall detector to send NMI to all online CPUs
> so that they can dump their stacks.
>
> IOW, this might actually make the whole sysrq dump last for much longer,
> and have the log polluted with all-CPU dumps for no good reason.
I use the patch below for some time now. While it doesn't avoid the
log pollution in the first place, it lessens the impact somewhat.
Jörn
--
The cost of changing business rules is much more expensive for software
than for a secretaty.
-- unknown
>From 8286b521865503f92837a036fecdb51f41c0141c Mon Sep 17 00:00:00 2001
From: Joern Engel
Date: Wed, 20 Mar 2013 09:47:52 -0700
Subject: [PATCH] printk: Print cpu number along with time
Sometimes the printk log is heavily interleaving between different cpus.
This is particularly bad when you have two backtraces at the same time,
but can be annoying in other cases as well. With an explicit cpu
number, a simple grep can disentangle the mess for you.
Signed-off-by: Joern Engel
---
kernel/printk.c | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/kernel/printk.c b/kernel/printk.c
index abbdd9e..c5f6dda 100644
--- a/kernel/printk.c
+++ b/kernel/printk.c
@@ -210,6 +210,7 @@ struct log {
u16 len;/* length of entire record */
u16 text_len; /* length of text buffer */
u16 dict_len; /* length of dictionary buffer */
+ u16 cpu;/* cpu the message was generated on */
u8 facility;/* syslog facility */
u8 flags:5; /* internal record flags */
u8 level:3; /* syslog level */
@@ -356,6 +357,7 @@ static void log_store(int facility, int level,
msg->facility = facility;
msg->level = level & 7;
msg->flags = flags & 0x1f;
+ msg->cpu = smp_processor_id();
if (ts_nsec > 0)
msg->ts_nsec = ts_nsec;
else
@@ -863,7 +865,7 @@ static bool printk_time;
#endif
module_param_named(time, printk_time, bool, S_IRUGO | S_IWUSR);
-static size_t print_time(u64 ts, char *buf)
+static size_t print_time(u64 ts, u16 cpu, char *buf)
{
unsigned long rem_nsec;
@@ -871,12 +873,12 @@ static size_t print_time(u64 ts, char *buf)
return 0;
rem_nsec = do_div(ts, 10);
-
if (!buf)
- return snprintf(NULL, 0, "[%5lu.00] ", (unsigned long)ts);
+ return snprintf(NULL, 0, "[%5lu.00,%02x] ",
+ (unsigned long)ts, cpu);
- return sprintf(buf, "[%5lu.%06lu] ",
- (unsigned long)ts, rem_nsec / 1000);
+ return sprintf(buf, "[%5lu.%06lu,%02x] ",
+ (unsigned long)ts, rem_nsec / 1000, cpu);
}
static size_t print_prefix(const struct log *msg, bool syslog, char *buf)
@@ -898,7 +900,7 @@ static size_t print_prefix(const struct log *msg, bool
syslog, char *buf)
}
}
- len += print_time(msg->ts_nsec, buf ? buf + len : NULL);
+ len += print_time(msg->ts_nsec, msg->cpu, buf ? buf + len : NULL);
return len;
}
@@ -1396,6 +1398,7 @@ static struct cont {
size_t cons;/* bytes written to console */
struct task_struct *owner; /* task of first print*/
u64 ts_nsec;/* time of first print */
+ u16 cpu;/* cpu the message was generated on */
u8 level; /* log level of first message */
u8 facility;/* log level of first message */
enum log_flags flags; /* prefix, newline flags */
@@ -1445,6 +1448,7 @@ static bool cont_add(int facility, int level, const char
*text, size_t len)
cont.facility = facility;
cont.level = level;
cont.owner = current;
+ cont.cpu = smp_processor_id();
cont.ts_nsec = local_clock();
cont.flags = 0;
cont.cons = 0;
@@ -1466,7 +1470,7 @@ static size_t cont_print_text(char *text, size_t size)
size_t len;
if (cont.cons == 0 && (console_prev & LOG_NEWLINE)) {
- textlen += print_time(cont.ts_nsec, text);
+ textlen += print_time(cont.ts_nsec, cont.cpu, text);
size -= textlen;
}
--
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: [PATCH v3 1/4] MAINTAINERS: Add entry for APM X-Gene SoC ethernet driver
Hi Javier, On Sun, Apr 20, 2014 at 5:56 PM, Javier Martinez Canillas wrote: > Hello Lyappan, > > On Thu, Apr 17, 2014 at 5:18 AM, Joe Perches wrote: >> On Wed, 2014-04-16 at 19:39 -0700, Iyappan Subramanian wrote: >>> This patch adds a MAINTAINERS entry for APM X-Gene SoC >>> ethernet driver. >> [] >>> diff --git a/MAINTAINERS b/MAINTAINERS >> [] >>> @@ -686,6 +686,14 @@ S: Maintained >>> F: drivers/net/appletalk/ >>> F: net/appletalk/ >>> >>> +APPLIED MICRO (APM) X-GENE SOC ETHERNET DRIVER >>> +M: Iyappan Subramanian >>> +M: Keyur Chudgar >>> +M: Ravi Patel >>> +S: Maintained >>> +F: drivers/net/ethernet/apm/xgene >> >> Please add a terminating slash to show this is a directory. >> >> F: drivers/net/ethernet/apm/xgene/ >> > > Also if you are maintaining this driver as a part of your daily work > (i.e: actually being paid for it by your company) the status should be > "Supported" instead. > > If you are doing it on your own time but still using your company > email address then "Maintained" is correct. Thanks. I will change this to Supported. > > Best regards, > Javier -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 4/4] drivers: net: Add APM X-Gene SoC ethernet driver support.
On Wed, Apr 16, 2014 at 8:16 PM, Joe Perches wrote:
> On Wed, 2014-04-16 at 19:39 -0700, Iyappan Subramanian wrote:
>> This patch adds network driver for APM X-Gene SoC ethernet.
> []
>> diff --git a/drivers/net/ethernet/apm/xgene/Kconfig
>> b/drivers/net/ethernet/apm/xgene/Kconfig
> []
>> @@ -0,0 +1,10 @@
>> +config NET_XGENE
>> + tristate "APM X-Gene SoC Ethernet Driver"
>> + select PHYLIB
>> + default y
>
> default y?
>
> Shouldn't this need a depends on too?
I will remove the "default" entry.
>
>> diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c
>> b/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c
>
>> +static void xgene_enet_ring_set_type(u32 *ring_cfg, u8 is_bufpool)
>> +{
>
> bool is_bufpool?
>
Great suggestion. I will replace with bool and try to use bool where
ever possible.
>> +static void xgene_enet_set_ring_id(struct xgene_enet_desc_ring *ring)
>> +{
>> + u32 ring_id_val;
>> + u32 ring_id_buf;
>> + u8 is_bufpool = IS_FP(ring->id);
>
> bool?
>
>> +
>> + ring_id_val = ring->id & GENMASK(9, 0);
>> + ring_id_val |= (1 << 31) & GENMASK(31, 31);
>
> Setting a single bit and masking with the same
> bit looks silly.
I will use BIT macro in these circumstances.
>
>> +
>> + ring_id_buf = (ring->num << 9) & GENMASK(18, 9);
>> + ring_id_buf |= ((u32) is_bufpool << 20) & GENMASK(20, 20);
>
> And here.
>
>> + ring_id_buf |= (1U << 21) & GENMASK(21, 21);
>
> This too.
>
> []
>
>> +static void xgene_enet_rd_mcx_stats(struct xgene_enet_pdata *pdata,
>> + u32 rd_addr, u32 *rd_data)
>> +{
> []
>> + if (!ret)
>> + netdev_err(pdata->ndev, "MCX stats read failed, addr: %04x",
>> +rd_addr);
>
> Missing newline
I will add newline to the print statements.
>
>> +/* Start Statistics related functions */
>> +static void xgene_gmac_get_rx_stats(struct xgene_enet_pdata *pdata,
>> + struct xgene_enet_rx_stats *rx_stat)
>> +{
>> + xgene_enet_rd_mcx_stats(pdata, RBYT_ADDR, &rx_stat->rx_byte_count);
>> + xgene_enet_rd_mcx_stats(pdata, RPKT_ADDR, &rx_stat->rx_packet_count);
>> + xgene_enet_rd_mcx_stats(pdata, RDRP_ADDR, &rx_stat->rx_drop_pkt_count);
>> + xgene_enet_rd_mcx_stats(pdata, RFCS_ADDR, &rx_stat->rx_fcs_err_count);
>> + xgene_enet_rd_mcx_stats(pdata, RFLR_ADDR,
>> + &rx_stat->rx_frm_len_err_pkt_count);
>> + xgene_enet_rd_mcx_stats(pdata, RALN_ADDR,
>> + &rx_stat->rx_alignment_err_pkt_count);
>> + xgene_enet_rd_mcx_stats(pdata, ROVR_ADDR,
>> + &rx_stat->rx_oversize_pkt_count);
>> + xgene_enet_rd_mcx_stats(pdata, RUND_ADDR,
>> + &rx_stat->rx_undersize_pkt_count);
>> +
>> + rx_stat->rx_byte_count &= RX_BYTE_CNTR_MASK;
>> + rx_stat->rx_packet_count &= RX_PKT_CNTR_MASK;
>> + rx_stat->rx_drop_pkt_count &= RX_DROPPED_PKT_CNTR_MASK;
>> + rx_stat->rx_fcs_err_count &= RX_FCS_ERROR_CNTR_MASK;
>> + rx_stat->rx_frm_len_err_pkt_count &= RX_LEN_ERR_CNTR_MASK;
>> + rx_stat->rx_alignment_err_pkt_count &= RX_ALIGN_ERR_CNTR_MASK;
>> + rx_stat->rx_oversize_pkt_count &= RX_OVRSIZE_PKT_CNTR_MASK;
>> + rx_stat->rx_undersize_pkt_count &= RX_UNDRSIZE_PKT_CNTR_MASK;
>> +}
>> +
>> +static void xgene_gmac_get_tx_stats(struct xgene_enet_pdata *pdata,
>> + struct xgene_enet_tx_stats *tx_stats)
>> +{
>> + xgene_enet_rd_mcx_stats(pdata, TBYT_ADDR, &tx_stats->tx_byte_count);
>> + xgene_enet_rd_mcx_stats(pdata, TPKT_ADDR, &tx_stats->tx_pkt_count);
>> + xgene_enet_rd_mcx_stats(pdata, TDRP_ADDR,
>> &tx_stats->tx_drop_frm_count);
>> + xgene_enet_rd_mcx_stats(pdata, TFCS_ADDR,
>> + &tx_stats->tx_fcs_err_frm_count);
>> + xgene_enet_rd_mcx_stats(pdata, TUND_ADDR,
>> + &tx_stats->tx_undersize_frm_count);
>> +
>> + tx_stats->tx_byte_count &= TX_BYTE_CNTR_MASK;
>> + tx_stats->tx_pkt_count &= TX_PKT_CNTR_MASK;
>> + tx_stats->tx_drop_frm_count &= TX_DROP_FRAME_CNTR_MASK;
>> + tx_stats->tx_fcs_err_frm_count &= TX_FCS_ERROR_CNTR_MASK;
>> + tx_stats->tx_undersize_frm_count &= TX_UNDSIZE_FRAME_CNTR_MASK;
>> +}
>
> Pity about the masks
>
>
>> +#define RX_BYTE_CNTR_MASK0x7fff
>> +#define RX_PKT_CNTR_MASK 0x7fff
>> +#define RX_FCS_ERROR_CNTR_MASK 0x
>> +#define RX_ALIGN_ERR_CNTR_MASK 0x
>> +#define RX_LEN_ERR_CNTR_MASK 0x
>> +#define RX_UNDRSIZE_PKT_CNTR_MASK0x
>> +#define RX_OVRSIZE_PKT_CNTR_MASK 0x
>> +#define RX_DROPPED_PKT_CNTR_MASK 0x
>> +#define TX_BYTE_CNTR_MASK0x7fff
>> +#define TX_PKT_CNTR_MASK 0x7fff
>> +#define TX_DROP_FRAME_CNTR_MASK 0x
>> +#define TX_FCS_ERROR_CNTR_MASK 0x0fff
>> +#define TX_UNDSI
Re: [PATCH v3] Intel MCH BIOS workaround
On Wednesday, April 23, 2014 10:20:57 AM Bjorn Helgaas wrote: > Hi Rafael, Hi, > Relative to v2, this adds "#ifdef CONFIG_X86" around the quirk and adds > Stephane's ack. Either v2 or v3 is fine with me; whatever seems best to > you. I've applied this one, thanks! Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] usb: ohci-exynos: Make provision for vdd regulators
Hi,
> Hi,
>
> > -Original Message-
> > From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-
> > ow...@vger.kernel.org] On Behalf Of Vivek Gautam
> > Sent: Monday, April 21, 2014 9:17 PM
> >
> > Facilitate getting required 3.3V and 1.0V VDD supply for
> > OHCI controller on Exynos.
> >
> > With patches for regulators' nodes merged in 3.15:
> > c8c253f ARM: dts: Add regulator entries to smdk5420
> > 275dcd2 ARM: dts: add max77686 pmic node for smdk5250,
> >
> > certain perripherals will now need to ensure that,
> > they request VDD regulators in their drivers, and enable
> > them so as to make them working.
> >
> > Signed-off-by: Vivek Gautam
> > Cc: Jingoo Han
> > ---
> >
> > Based on 'usb-next' branch of Greg's usb tree.
> >
> > drivers/usb/host/ohci-exynos.c | 47
> >
> > 1 file changed, 47 insertions(+)
> >
> > diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-
> > exynos.c
> > index 68588d8..e2e72a8 100644
> > --- a/drivers/usb/host/ohci-exynos.c
> > +++ b/drivers/usb/host/ohci-exynos.c
> > @@ -18,6 +18,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -37,6 +38,8 @@ struct exynos_ohci_hcd {
> > struct clk *clk;
> > struct usb_phy *phy;
> > struct usb_otg *otg;
> > + struct regulator *vdd33;
> > + struct regulator *vdd10;
> > };
> >
> > static void exynos_ohci_phy_enable(struct platform_device *pdev)
> > @@ -98,6 +101,28 @@ static int exynos_ohci_probe(struct
> platform_device
> > *pdev)
> > exynos_ohci->otg = phy->otg;
> > }
> >
> > + exynos_ohci->vdd33 = devm_regulator_get(&pdev->dev, "vdd33");
> > + if (IS_ERR(exynos_ohci->vdd33)) {
> > + err = PTR_ERR(exynos_ohci->vdd33);
> > + goto fail_regulator1;
> > + }
> > + err = regulator_enable(exynos_ohci->vdd33);
> > + if (err) {
> > + dev_err(&pdev->dev, "Failed to enable VDD33 supply\n");
> > + goto fail_regulator1;
> > + }
> > +
> > + exynos_ohci->vdd10 = devm_regulator_get(&pdev->dev, "vdd10");
> > + if (IS_ERR(exynos_ohci->vdd10)) {
> > + err = PTR_ERR(exynos_ohci->vdd10);
> > + goto fail_regulator2;
> > + }
> > + err = regulator_enable(exynos_ohci->vdd10);
> > + if (err) {
> > + dev_err(&pdev->dev, "Failed to enable VDD10 supply\n");
> > + goto fail_regulator2;
> > + }
> > +
>
> Do we need to skip regulator settings together with PHY configuration
> in case of exynos5440?
>
> > skip_phy:
> > exynos_ohci->clk = devm_clk_get(&pdev->dev, "usbhost");
> >
> > @@ -154,6 +179,10 @@ fail_add_hcd:
> > fail_io:
> > clk_disable_unprepare(exynos_ohci->clk);
> > fail_clk:
> > + regulator_disable(exynos_ohci->vdd10);
> > +fail_regulator2:
> > + regulator_disable(exynos_ohci->vdd33);
> > +fail_regulator1:
> > usb_put_hcd(hcd);
> > return err;
> > }
> > @@ -172,6 +201,9 @@ static int exynos_ohci_remove(struct
> > platform_device *pdev)
> >
> > clk_disable_unprepare(exynos_ohci->clk);
> >
> > + regulator_disable(exynos_ohci->vdd10);
> > + regulator_disable(exynos_ohci->vdd33);
> > +
> > usb_put_hcd(hcd);
> >
> > return 0;
> > @@ -208,6 +240,9 @@ static int exynos_ohci_suspend(struct device *dev)
> >
> > clk_disable_unprepare(exynos_ohci->clk);
> >
> > + regulator_disable(exynos_ohci->vdd10);
> > + regulator_disable(exynos_ohci->vdd33);
> > +
> > spin_unlock_irqrestore(&ohci->lock, flags);
> >
> > return 0;
> > @@ -218,6 +253,18 @@ static int exynos_ohci_resume(struct device *dev)
> > struct usb_hcd *hcd = dev_get_drvdata(dev);
> > struct exynos_ohci_hcd *exynos_ohci = to_exynos_ohci(hcd);
> > struct platform_device *pdev= to_platform_device(dev);
> > + int ret;
> > +
> > + ret = regulator_enable(exynos_ohci->vdd33);
> > + if (ret) {
> > + dev_err(dev, "Failed to enable VDD33 supply\n");
> > + return ret;
>
> Not sure, but shall we continue resuming and do everything
> we can in case of error? At least it will avoid
> WARN_ON(clk->enable_count == 0) on next system suspend.
On the other hand, if power is not applied to the controller,
register access in ohci_resume() may lead to undefined behavior.
What's your opinion?
>
> > + }
> > + ret = regulator_enable(exynos_ohci->vdd10);
> > + if (ret) {
> > + dev_err(dev, "Failed to enable VDD10 supply\n");
> > + return ret;
> > + }
> >
> > clk_prepare_enable(exynos_ohci->clk);
> >
> > --
>
> Thanks
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 3/3] nohz: Fix iowait overcounting if iowait task migrates
On Wed, Apr 23, 2014 at 09:00:36PM +0200, Denys Vlasenko wrote:
> Before this change, if last IO-blocked task wakes up
> on a different CPU, the original CPU may stay idle for much longer,
> and the entire time it stays idle is accounted as iowait time.
>
> This change adds struct tick_sched::iowait_exittime member.
> On entry to idle, it is set to KTIME_MAX.
> Last IO-blocked task, if migrated, sets it to current time.
> Note that this can happen only once per each idle period:
> new iowaiting tasks can't magically appear on idle CPU's rq.
>
> If iowait_exittime is set, then (iowait_exittime - idle_entrytime)
> gets accounted as iowait, and the remaining (now - iowait_exittime)
> as "true" idle.
>
> Run-tested: /proc/stats no longer go backwards.
>
> Signed-off-by: Denys Vlasenko
> Cc: Frederic Weisbecker
> Cc: Hidetoshi Seto
> Cc: Fernando Luis Vazquez Cao
> Cc: Tetsuo Handa
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: Peter Zijlstra
> Cc: Andrew Morton
> Cc: Arjan van de Ven
> Cc: Oleg Nesterov
> ---
> include/linux/tick.h | 3 ++
> kernel/sched/core.c | 20 ++
> kernel/time/tick-sched.c | 72
>
> 3 files changed, 89 insertions(+), 6 deletions(-)
>
> diff --git a/include/linux/tick.h b/include/linux/tick.h
> index b84773c..2a27883 100644
> --- a/include/linux/tick.h
> +++ b/include/linux/tick.h
> @@ -67,6 +67,7 @@ struct tick_sched {
> ktime_t idle_exittime;
> ktime_t idle_sleeptime;
> ktime_t iowait_sleeptime;
> + ktime_t iowait_exittime;
> ktime_t sleep_length;
> unsigned long last_jiffies;
> unsigned long next_jiffies;
> @@ -139,6 +140,7 @@ extern void tick_nohz_irq_exit(void);
> extern ktime_t tick_nohz_get_sleep_length(void);
> extern u64 get_cpu_idle_time_us(int cpu, u64 *last_update_time);
> extern u64 get_cpu_iowait_time_us(int cpu, u64 *last_update_time);
> +extern void tick_nohz_iowait_to_idle(int cpu);
>
> # else /* !CONFIG_NO_HZ_COMMON */
> static inline int tick_nohz_tick_stopped(void)
> @@ -157,6 +159,7 @@ static inline ktime_t tick_nohz_get_sleep_length(void)
> }
> static inline u64 get_cpu_idle_time_us(int cpu, u64 *unused) { return -1; }
> static inline u64 get_cpu_iowait_time_us(int cpu, u64 *unused) { return -1; }
> +static inline void tick_nohz_iowait_to_idle(int cpu) { }
> # endif /* !CONFIG_NO_HZ_COMMON */
>
> #ifdef CONFIG_NO_HZ_FULL
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 9cae286..08dd220 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -4255,6 +4255,9 @@ EXPORT_SYMBOL_GPL(yield_to);
> */
> void __sched io_schedule(void)
> {
> +#ifdef CONFIG_NO_HZ_COMMON
> + int cpu_on_entry = smp_processor_id();
> +#endif
> struct rq *rq = raw_rq();
>
> delayacct_blkio_start();
> @@ -4263,13 +4266,23 @@ void __sched io_schedule(void)
> current->in_iowait = 1;
> schedule();
> current->in_iowait = 0;
> +#ifdef CONFIG_NO_HZ_COMMON
> + if (atomic_dec_and_test(&rq->nr_iowait)) {
> + if (smp_processor_id() != cpu_on_entry)
> + tick_nohz_iowait_to_idle(cpu_on_entry);
The update on tick_nohz_iowait_to_idle() can happen anytime,
possibly too late.
There can be races like this:
CPU 0 CPU 1
//task A goes to sleep (iowait)
//task A wakes up
atomic_dec_and_test(nr_iowait) {
now = ktime_get(); // now == X
//task B runs
//Pending iowait time i flushed
//task B sleeps (iowait)
//now = Y
//task A is preempted
//task B runs
atomic_dec_and_test(nr_iowait) {
now = ktime_get(); // now == Y
//task B is preempted
//task A runs back
iowait_exittime = Z
// account pending iowait time
// delta = X - Y
Here the delta accounted is X - Y, which is probably a negative delta. So the
whole time between Z and Y is forgotten.
Now the race is tight and maybe not important in practice because preemption
slices
should be short so only tiny chuncks may be overriden.
> + }
> +#else
> atomic_dec(&rq->nr_iowait);
> +#endif
> delayacct_blkio_end();
> }
> EXPORT_SYMBOL(io_schedule);
>
> long __sched io_schedule_timeout(long timeout)
> {
> +#ifdef CONFIG_NO_HZ_COMMON
> + int cpu_on_entry = smp_processor_id();
> +#endif
> struct rq *rq = raw_rq();
> long
