[PATCH] arm: pxa: create a unified defconfig for PXA27X-DT
Instead of one defconfig file per board, pxa27x-dt_defconfig is expected to provide a configuration for kernel which can test any PXA27X-DT compatible board Signed-off-by: Sergei Ianovich CC: Robert Jarzmik CC: Arnd Bergmann --- Documentation/arm/pxa/pxa27x_defconfig.txt | 7 ++ arch/arm/configs/pxa27x-dt_defconfig | 102 + 2 files changed, 109 insertions(+) create mode 100644 Documentation/arm/pxa/pxa27x_defconfig.txt create mode 100644 arch/arm/configs/pxa27x-dt_defconfig diff --git a/Documentation/arm/pxa/pxa27x_defconfig.txt b/Documentation/arm/pxa/pxa27x_defconfig.txt new file mode 100644 index 000..fc4e164 --- /dev/null +++ b/Documentation/arm/pxa/pxa27x_defconfig.txt @@ -0,0 +1,7 @@ +If you are reading this, because you are adding support for a new +PXA27X board, please note that you should not create an additional +defconfig in arch/arm/configs. + +Instead, please update arch/arm/configs/pxa27x-dt_defconfig so that +a kernel built with this config after `make olddefconfig` boots your +board. diff --git a/arch/arm/configs/pxa27x-dt_defconfig b/arch/arm/configs/pxa27x-dt_defconfig new file mode 100644 index 000..003be48 --- /dev/null +++ b/arch/arm/configs/pxa27x-dt_defconfig @@ -0,0 +1,102 @@ +## Kernel built with this config should boot any supported PXA27X-DT board +## Please see Documentation/arm/pxa/pxa27x_defconfig.txt for details +## +CONFIG_ARM=y +CONFIG_HIGH_RES_TIMERS=y +CONFIG_CC_OPTIMIZE_FOR_SIZE=y +CONFIG_EMBEDDED=y +CONFIG_MODULES=y +CONFIG_MODULE_UNLOAD=y +CONFIG_MODVERSIONS=y +CONFIG_BLK_CMDLINE_PARSER=y +CONFIG_PARTITION_ADVANCED=y +CONFIG_ARCH_PXA=y +CONFIG_MACH_PXA27X_DT=y +CONFIG_PXA_SYSTEMS_CPLDS=y +CONFIG_PXA_SSP=y +CONFIG_CPU_FREQ=y +CONFIG_ARM_PXA2xx_CPUFREQ=y +CONFIG_NET=y +CONFIG_IRDA=y +CONFIG_PXA_FICP=y +CONFIG_MTD=y +CONFIG_MTD_OF_PARTS=y +CONFIG_MTD_BLOCK=y +CONFIG_MTD_CFI=y +CONFIG_MTD_CFI_ADV_OPTIONS=y +CONFIG_MTD_CFI_GEOMETRY=y +CONFIG_MTD_CFI_INTELEXT=y +CONFIG_MTD_PHYSMAP_OF=y +CONFIG_MTD_PXA2XX=y +CONFIG_OF=y +CONFIG_OF_FLATTREE=y +CONFIG_SCSI=y +CONFIG_BLK_DEV_SD=y +CONFIG_ATA=y +CONFIG_SATA_PMP=y +CONFIG_ATA_SFF=y +CONFIG_ATA_BMDMA=y +CONFIG_PATA_PXA=y +CONFIG_NETDEVICES=y +CONFIG_DM9000=y +CONFIG_INPUT=y +CONFIG_INPUT_MOUSEDEV=y +CONFIG_INPUT_KEYBOARD=y +CONFIG_KEYBOARD_PXA27x=y +CONFIG_INPUT_MOUSE=y +CONFIG_MOUSE_NAVPOINT_PXA27x=y +CONFIG_TTY=y +CONFIG_SERIAL_8250=y +CONFIG_SERIAL_8250_CONSOLE=y +CONFIG_SERIAL_8250_NR_UARTS=40 +CONFIG_SERIAL_8250_RUNTIME_UARTS=40 +CONFIG_SERIAL_8250_EXTENDED=y +CONFIG_SERIAL_8250_MANY_PORTS=y +CONFIG_SERIAL_8250_SHARE_IRQ=y +CONFIG_SERIAL_8250_PXA=y +CONFIG_I2C=y +CONFIG_I2C_GPIO=y +CONFIG_I2C_PXA=y +CONFIG_SPI=y +CONFIG_SPI_PXA2XX=y +CONFIG_WATCHDOG=y +CONFIG_SA1100_WATCHDOG=y +CONFIG_REGULATOR=y +CONFIG_REGULATOR_FIXED_VOLTAGE=y +CONFIG_MEDIA_SUPPORT=y +CONFIG_MEDIA_CAMERA_SUPPORT=y +CONFIG_VIDEO_DEV=y +CONFIG_V4L_PLATFORM_DRIVERS=y +CONFIG_SOC_CAMERA=y +CONFIG_VIDEO_PXA27x=y +CONFIG_FB=y +CONFIG_FB_PXA=y +CONFIG_FB_PXA_OVERLAY=y +CONFIG_FB_PXA_SMARTPANEL=y +CONFIG_FB_PXA_PARAMETERS=y +CONFIG_FRAMEBUFFER_CONSOLE=y +CONFIG_SOUND=y +CONFIG_SND=y +CONFIG_SND_ARM=y +CONFIG_SND_PXA2XX_AC97=y +CONFIG_SND_SOC=y +CONFIG_SND_PXA2XX_SOC=y +CONFIG_USB_SUPPORT=y +CONFIG_USB=y +CONFIG_USB_OHCI_HCD=y +CONFIG_USB_OHCI_HCD_PXA27X=y +CONFIG_USB_STORAGE=y +CONFIG_USB_SERIAL=y +CONFIG_MMC=y +CONFIG_MMC_BLOCK=y +CONFIG_MMC_PXA=y +CONFIG_RTC_CLASS=y +CONFIG_RTC_DRV_PXA=y +CONFIG_DMADEVICES=y +CONFIG_DMA_OF=y +CONFIG_PXA_DMA=y +CONFIG_PWM=y +CONFIG_PWM_PXA=y +CONFIG_EXT4_FS=y +CONFIG_JFFS2_FS=y +CONFIG_JFFS2_COMPRESSION_OPTIONS=y -- 2.6.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V10 7/7] dma: qcom_hidma: add support for object hierarchy
Hi Sinan, [auto build test ERROR on v4.4-rc5] [also build test ERROR on next-20151218] url: https://github.com/0day-ci/linux/commits/Sinan-Kaya/dma-add-Qualcomm-Technologies-HIDMA-driver/20151218-010637 config: sparc64-allmodconfig (attached as .config) reproduce: wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree make.cross ARCH=sparc64 All errors (new ones prefixed by >>): >> ERROR: "of_irq_parse_one" [drivers/dma/qcom/hdma_mgmt.ko] undefined! --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: Binary data
[git pull] Input updates for 4.4-rc5
Hi Linus, Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus to receive updates for the input subsystem. Just a few assorted driver fixes. Changelog: - Charles Keepax (1): Input: arizona-haptic - fix disabling of haptics device Charlie Mooney (1): Input: elan_i2c - set input device's vendor and product IDs Dmitry Torokhov (1): Input: atmel_mxt_ts - add generic platform data for Chromebooks James Chen (1): Input: elants_i2c - fix wake-on-touch Javier Martinez Canillas (1): Input: atmel_mxt_ts - add maxtouch to I2C table for module autoload Karsten Merker (1): Input: sun4i-lradc-keys - fix typo in binding documentation Sudip Mukherjee (5): Input: db9 - clear unused function pointers Input: gamecon - clear unused function pointers Input: turbografx - clear unused function pointers Input: walkera0701 - clear unused function pointers Input: parkbd - clear unused function pointers Vladis Dronov (1): Input: aiptek - fix crash on detecting device without endpoints Diffstat: .../devicetree/bindings/input/sun4i-lradc-keys.txt | 2 +- drivers/input/joystick/db9.c | 1 + drivers/input/joystick/gamecon.c | 1 + drivers/input/joystick/turbografx.c| 1 + drivers/input/joystick/walkera0701.c | 1 + drivers/input/misc/arizona-haptics.c | 3 +- drivers/input/mouse/elan_i2c_core.c| 3 ++ drivers/input/serio/parkbd.c | 1 + drivers/input/tablet/aiptek.c | 9 ++ drivers/input/touchscreen/atmel_mxt_ts.c | 34 ++ drivers/input/touchscreen/elants_i2c.c | 21 +++-- 11 files changed, 65 insertions(+), 12 deletions(-) -- 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 V10 7/7] dma: qcom_hidma: add support for object hierarchy
Hi Sinan, [auto build test ERROR on v4.4-rc5] [also build test ERROR on next-20151218] url: https://github.com/0day-ci/linux/commits/Sinan-Kaya/dma-add-Qualcomm-Technologies-HIDMA-driver/20151218-010637 config: sparc-allyesconfig (attached as .config) reproduce: wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree make.cross ARCH=sparc All errors (new ones prefixed by >>): drivers/built-in.o: In function `hidma_mgmt_of_populate_channels': >> hidma_mgmt.c:(.init.text+0x5cc8): undefined reference to `of_irq_parse_one' --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: Binary data
Re: [PATCH v5] arm: pxa: support ICP DAS LP-8x4x FPGA irq
On Fri, 2015-12-18 at 21:58 -0600, Rob Herring wrote:
> On Tue, Dec 15, 2015 at 10:26:21PM +0300, Sergei Ianovich wrote:
> > +Example:
> > +
> > + fpga: fpga@1706 {
>
> Nothing else in the fpga? In any case, this node should be named
> interrupt-controller@1706.
>
> > + compatible = "icpdas,irq-lp8x4x";
>
> As pointed out in the uart binding, don't use wildcards here.
>
> > + reg = <0x1706 0x16>;
> > + interrupt-parent = <>;
> > + interrupts = <3 IRQ_TYPE_EDGE_RISING>;
> > + #interrupt-cells = <1>;
> > + interrupt-controller;
> > + status = "okay";
> > + };
> > +
> > + uart@17009050 {
> > + compatible = "icpdas,uart-lp8x4x";
> > + reg = <0x17009050 0x10
> > + 0x17009030 0x02>;
> > + interrupt-parent = <>;
> > + interrupts = <13>;
> > + status = "okay";
> > + };
That was just an example. The actual binding in LP-8x4x is bigger:
fpga@5 {
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 5 0x300 0x1>;
interrupt-parent = <>;
rtc@901c {
compatible = "dallas,rtc-ds1302";
reg = <0x901c 0x1>;
status = "okay";
};
sram@a000 {
compatible = "icpdas,sram-lp8x4x";
reg = <0xa000 0x1000
0x901e 0x1>;
partitions {
#address-cells = <1>;
#size-cells = <1>;
};
};
fpgairq: irq@9006 {
compatible = "icpdas,irq-lp8x4x";
reg = <0x9006 0x16>;
interrupt-parent = <>;
interrupts = <3 IRQ_TYPE_EDGE_FALLING>;
#interrupt-cells = <1>;
interrupt-controller;
status = "okay";
};
uart@9050 {
compatible = "icpdas,uart-lp8x4x";
reg = <0x9050 0x10
0x9030 0x02>;
interrupts = <13>;
status = "okay";
};
uart@9060 {
compatible = "icpdas,uart-lp8x4x";
reg = <0x9060 0x10
0x9032 0x02>;
interrupts = <14>;
status = "okay";
};
uart@9070 {
compatible = "icpdas,uart-lp8x4x";
reg = <0x9070 0x10
0x9034 0x02>;
interrupts = <15>;
status = "okay";
};
backplane {
compatible = "icpdas,backplane-lp8x4x";
reg = <0x0 0x2
0x1000 0x10
0x2000 0x10
0x3000 0x10
0x4000 0x10
0x5000 0x10
0x6000 0x10
0x7000 0x10
0x8000 0x10
0x9002 0x2
0x9004 0x2
0x9046 0x2>;
eeprom-gpios = < 4 0>;
};
};
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] staging: coding style cleanups for staging/panel driver
On Sat, Dec 19, 2015 at 11:55:13AM +0530, Sudip Mukherjee wrote: > On Fri, Dec 18, 2015 at 08:01:58AM -0800, Greg KH wrote: > > On Fri, Dec 18, 2015 at 02:48:58PM +0530, Bijosh T wrote: > > > From: Bijosh T > > > > > > This patch fixes coding style errors for staging/panel driver. > > > > > > Signed-off-by: Bijosh T > > > > I need a "full" name here, not just "T" as a last name, as odds are it's > > a bit longer than just that one character... > > > > Please fix up and resend. > > While you are resending please also mention which coding style error you > have fixed. Well, they are so minor (mostly spaces) that anyone interested should read the patch. 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: futex(3) man page, final draft for pre-release review
On 12/18/2015 12:21 PM, Torvald Riegel wrote:
> On Tue, 2015-12-15 at 13:18 -0800, Darren Hart wrote:
>> On Tue, Dec 15, 2015 at 02:43:50PM +0100, Michael Kerrisk (man-pages) wrote:
>>>
>>>When executing a futex operation that requests to block a thread,
>>>the kernel will block only if the futex word has the value that
>>>the calling thread supplied (as one of the arguments of the
>>>futex() call) as the expected value of the futex word. The load‐
>>>ing of the futex word's value, the comparison of that value with
>>>the expected value, and the actual blocking will happen atomi‐
>>>
>>> FIXME: for next line, it would be good to have an explanation of
>>> "totally ordered" somewhere around here.
>>>
>>>cally and totally ordered with respect to concurrently executing
>>
>> Totally ordered with respect futex operations refers to semantics of the
>> ACQUIRE/RELEASE operations and how they impact ordering of memory reads and
>> writes. The kernel futex operations are protected by spinlocks, which ensure
>> that that all operations are serialized with respect to one another.
>>
>> This is a lot to attempt to define in this document. Perhaps a reference to
>> linux/Documentation/memory-barriers.txt as a footnote would be sufficient? Or
>> perhaps for this manual, "serialized" would be sufficient, with a footnote
>> regarding "totally ordered" and a pointer to the memory-barrier
>> documentation?
>
> I'd strongly prefer to document the semantics for users here.
Yes, please.
> And I
> don't think users use the kernel's memory model -- instead, if we assume
> that most users will call futex ops from C or C++, then the best we have
> is the C11 / C++11 memory model.
Agreed.
> Therefore, if we want to expand that,
I think we should. And by we, I mean you ;-)
> we should specify semantics in terms of as-if equivalence to C11 pseudo
> code. I had proposed that in the past but, IIRC, Michael didn't want to
> add a C11 "dependency" in the semantics back then, at least for the
> initial release.
I'd like to avoid it if possible, since many of us don't understand
all the details of those C11 semantics--and by us, I mean
me :-/. But maybe I'll be forced to educate myself better.
> Here's what I wrote back then (atomic_*_relaxed() is like C11
> atomic_*(..., memory_order_relaxed), lock/unlock have normal C11 mutex
> semantics):
>
>
>
> For example, we could say that futex_wait is, in terms of
> synchronization semantics, *as if* we'd execute a piece of C11 code.
> Here's a part of the docs for a glibc-internal futex wrapper that I'm
> working on; this is futex_wait ... :
>
> /* Atomically wrt other futex operations, this blocks iff the value at
>*FUTEX matches the expected value. This is semantically equivalent to:
> l = (FUTEX);
> wait_flag = (FUTEX);
> lock (l);
> val = atomic_load_relaxed (FUTEX);
> if (val != expected) { unlock (l); return EAGAIN; }
> atomic_store_relaxed (wait_flag, 1);
> unlock (l);
> // Now block; can time out in futex_time_wait (see below)
> while (atomic_load_relaxed(wait_flag));
>
>Note that no guarantee of a happens-before relation between a woken
>futex_wait and a futex_wake is documented; however, this does not matter
>in practice because we have to consider spurious wake-ups (see below),
>and thus would not be able to reason which futex_wake woke us anyway.
>
>
> ... and this is futex_wake:
>
> /* Atomically wrt other futex operations, this unblocks the specified
>number of processes, or all processes blocked on this futex if there are
>fewer than the specified number. Semantically, this is equivalent to:
> l = (futex);
> lock (l);
> for (res = 0; processes_to_wake > 0; processes_to_wake--, res++) {
>if () break;
>wf = (futex);
>// No happens-before guarantee with woken futex_wait (see above)
>atomic_store_relaxed (wf, 0);
> }
> return res;
>
> This allows a programmer to really infer the guarantees he/she can get
> from a futex in terms of synchronization, without the docs having to use
> prose to describe that. This should also not constrain the kernel in
> terms of how to implement it, because it is a conceptual as-if relation
> (e.g., the kernel won't spin-wait the whole time, and we might want to
> make this clear for the PI case).
>
> Of course, there are several as-if representations we could use, and we
> might want to be a bit more pseudo-code-ish to make this also easy to
> understand for people not familiar with C11 (e.g., using mutex + condvar
> with some relaxation of condvar guaranteees).
Okay -- I'm open to all of the above.
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
Re: futex(3) man page, final draft for pre-release review
On 12/18/2015 12:11 PM, Torvald Riegel wrote: > On Wed, 2015-12-16 at 16:54 +0100, Michael Kerrisk (man-pages) wrote: >> Hello Darren, >> >> On 12/15/2015 10:18 PM, Darren Hart wrote: >>> On Tue, Dec 15, 2015 at 02:43:50PM +0100, Michael Kerrisk (man-pages) wrote: >> >> [...] >> When executing a futex operation that requests to block a thread, the kernel will block only if the futex word has the value that the calling thread supplied (as one of the arguments of the futex() call) as the expected value of the futex word. The load‐ ing of the futex word's value, the comparison of that value with the expected value, and the actual blocking will happen atomi‐ FIXME: for next line, it would be good to have an explanation of "totally ordered" somewhere around here. cally and totally ordered with respect to concurrently executing >>> >>> Totally ordered with respect futex operations refers to semantics of the >>> ACQUIRE/RELEASE operations and how they impact ordering of memory reads and >>> writes. The kernel futex operations are protected by spinlocks, which ensure >>> that that all operations are serialized with respect to one another. >>> >>> This is a lot to attempt to define in this document. Perhaps a reference to >>> linux/Documentation/memory-barriers.txt as a footnote would be sufficient? >>> Or >>> perhaps for this manual, "serialized" would be sufficient, with a footnote >>> regarding "totally ordered" and a pointer to the memory-barrier >>> documentation? >> >> I think I'll just settle for writing serialized in the man page, and be >> done with it :-). > > I'd prefer if you'd not just use "serialized" :) Sigh :-). Okay--removed. > Eventually, I'd prefer > if we can explain the semantics for the user in terms of the terminology > and semantics of the memory model of the programming language that users > will likely use to call futex ops (ie, C11 / C++11). And I'd be really happy to see such an explanation land in the page. 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: [PATCH v4] of: fix declaration of of_io_request_and_map
On Thu, Dec 17, 2015 at 11:55:28AM -0600, Rob Herring wrote:
> On Tue, Dec 8, 2015 at 2:47 AM, Sudip Mukherjee
> wrote:
> > We are having build failure with linux-next for sparc allmodconfig with
> > the error messages:
> >
> > drivers/built-in.o: In function `meson6_timer_init':
> > meson6_timer.c:(.init.text+0x5fe8): undefined reference to
> > `of_io_request_and_map'
> > drivers/built-in.o: In function `mtk_timer_init':
> > mtk_timer.c:(.init.text+0x6af0): undefined reference to
> > `of_io_request_and_map'
> > drivers/built-in.o: In function `asm9260_timer_init':
> > asm9260_timer.c:(.init.text+0x6c48): undefined reference to
> > `of_io_request_and_map'
> >
> > CONFIG_OF is defined for sparc so it is expected that we have a
> > definition of of_io_request_and_map() but of/address.c is only compiled
> > if it is !SPARC. In other words, CONFIG_OF_ADDRESS is not defined for
> > sparc so we get the build failure.
> >
> > Fixes: e572f844ca66 ("clocksource/drivers/meson6: Add the COMPILE_TEST
> > option")
> > Fixes: bec8c4617611 ("clocksource/drivers/mediatek: Add the COMPILE_TEST
> > option")
> > Fixes: 4a373b45f94a ("clocksource/drivers/asm9260: Add the COMPILE_TEST
> > option")
> > Cc: Daniel Lezcano
> > Signed-off-by: Sudip Mukherjee
>
> Moved the include out of the ifdefs and applied, thanks.
Thanks, I was wondering if the include should be within the ifdefs or
outside. But since the original code had it inside ifdefs, i thought its
better to have it inside.
regards
sudip
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/signal: Cleanup get_nr_restart_syscall
On 12/18/15 15:37, Dmitry V. Levin wrote:
Check for TS_COMPAT instead of TIF_IA32 to distinguish ia32 tasks
from 64-bit tasks.
Check for __X32_SYSCALL_BIT only if CONFIG_X86_X32_ABI is defined.
Signed-off-by: Dmitry V. Levin
Cc: Elvira Khabirova
Cc: Andy Lutomirski
---
arch/x86/kernel/signal.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/arch/x86/kernel/signal.c b/arch/x86/kernel/signal.c
index cb6282c..ff7dedc 100644
--- a/arch/x86/kernel/signal.c
+++ b/arch/x86/kernel/signal.c
@@ -692,12 +692,15 @@ handle_signal(struct ksignal *ksig, struct pt_regs *regs)
static inline unsigned long get_nr_restart_syscall(const struct pt_regs *regs)
{
-#if defined(CONFIG_X86_32) || !defined(CONFIG_X86_64)
+#ifdef CONFIG_X86_64
+ if (is_ia32_task())
+ return __NR_ia32_restart_syscall;
+# ifdef CONFIG_X86_X32_ABI
+ if (regs->orig_ax & __X32_SYSCALL_BIT)
+ return __NR_restart_syscall | __X32_SYSCALL_BIT;
+# endif
+#endif
return __NR_restart_syscall;
-#else /* !CONFIG_X86_32 && CONFIG_X86_64 */
- return test_thread_flag(TIF_IA32) ? __NR_ia32_restart_syscall :
- __NR_restart_syscall | (regs->orig_ax & __X32_SYSCALL_BIT);
-#endif /* CONFIG_X86_32 || !CONFIG_X86_64 */
}
/*
I bet you actually made the code slower.
-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] staging: coding style cleanups for staging/panel driver
On Fri, Dec 18, 2015 at 08:01:58AM -0800, Greg KH wrote: > On Fri, Dec 18, 2015 at 02:48:58PM +0530, Bijosh T wrote: > > From: Bijosh T > > > > This patch fixes coding style errors for staging/panel driver. > > > > Signed-off-by: Bijosh T > > I need a "full" name here, not just "T" as a last name, as odds are it's > a bit longer than just that one character... > > Please fix up and resend. While you are resending please also mention which coding style error you have fixed. regards sudip -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: Indent issus in kernel module development
On Sat, 2015-12-19 at 13:50 +0800, chunguang qu wrote: > Yes, I just tried `scripts/Lindent` and it has the same problem. > > I had compared the source of `Lindent` with `-linux` option of > `indent` long time ago, there's seems no major difference. > So i used `indent -linux ` above. > > Thanks for your advice about `emace`, but `vi` is my only editor for > dozens of years. Try: $ ./scripts/checkpatch.pl --fix --types=spacing -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [RFCv6 PATCH 03/10] sched: scheduler-driven cpu frequency selection
Hi Steve,
On Fri, Dec 18, 2015 at 11:15:01AM -0800, Steve Muckle wrote:
> On 12/16/2015 11:17 PM, Leo Yan wrote:
> > Could you check if below corner case will introduce logic error?
> > The task still will be removed from rq if timer tick is triggered
> > between two time's set_current_state().
> >
> > set_current_state(TASK_INTERRUPTIBLE);
> >`---> timer_tick and
> > schedule();
> > do_something...
> > set_current_state(TASK_RUNNING);
> >
> > It will be safe for combination for set_current_state()/schedule()
> > with waken_up_process():
> >
> > Thread_A: Thread_B:
> >
> > set_current_state(TASK_INTERRUPTIBLE);
> > `---> timer_tick and
> >schedule();
> >
> > wake_up_process(Thread_A);
> ><-/
> > schedule();
> >
> > The first time's schedule() will remove task from rq which is caused
> > by timer tick and call schedule(), and the second time schdule() will
> > be equal yeild().
>
> I was initially concerned about preemption while task state =
> TASK_INTERRUPTIBLE as well, but a task with state TASK_INTERRUPTIBLE is
> not dequeued if it is preempted. See core.c:__schedule():
>
> if (!preempt && prev->state) {
> if (unlikely(signal_pending_state(prev->state, prev))) {
> prev->state = TASK_RUNNING;
> } else {
> deactivate_task(rq, prev, DEQUEUE_SLEEP);
> prev->on_rq = 0;
>
> I knew this had to be the case, because this design pattern is used in
> many other places in the kernel, so many things would be very broken if
> this were a problem.
You are right, I went through the code again and sched tick irq will
call preempt_schedule_irq() and __schedule(true); so finally set the
parameter "preempt" = true. Sorry for noise :p
---8<---
arch/arm64/kernel/entry.S:
#ifdef CONFIG_PREEMPT
el1_preempt:
mov x24, lr
1: bl preempt_schedule_irq// irq en/disable is done inside
ldr x0, [tsk, #TI_FLAGS]// get new tasks TI_FLAGS
tbnzx0, #TIF_NEED_RESCHED, 1b // needs rescheduling?
ret x24
#endif
Thanks,
Leo Yan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Indent issus in kernel module development
Yes, I just tried `scripts/Lindent` and it has the same problem. I had compared the source of `Lindent` with `-linux` option of `indent` long time ago, there's seems no major difference. So i used `indent -linux ` above. Thanks for your advice about `emace`, but `vi` is my only editor for dozens of years. 2015-12-19 10:26 GMT+08:00 Randy Dunlap : > On 12/18/15 18:07, chunguang qu wrote: >> `indent -linux` sometimes made my code totally a mess. >> I know it most likely a bug of GNU INDENT. And this is not a bug report. >> I only want to know other kernel developers how to deal with this problem. >> Since GUN INDENT is recommend in kernel's CodingStyle, I think surely >> someone here encounter this problem either. > > Huh? > > CodingStyle says: > > Now, again, GNU indent has the same brain-dead settings that GNU emacs > has, which is why you need to give it a few command line options. > > It also says try using scripts/Lindent. Have you tried it? > It won't be perfect either, AFAI recall, but it might help. > > or you could try emacs (as indicated in CodingStyle). Good luck with that. > > > >> CMD >> LANG=C indent -linux >> >> FROM >> http://paste.ubuntu.com/14093393/ >> >> TO >> http://paste.ubuntu.com/14093405/ >> >> Thanks. > > > > > -- > ~Randy -- [Kevin Q (ChunGuang Qu)](mailto:quchungu...@gmail.com) [public key](http://pgp.mit.edu:11371/pks/lookup?op=get=0x5B06DCA77BEF043B) @sdu.edu.cn @gnu.org @mit.edu @grazestar.com @jolijolie.cn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 3/7] mm: add find_get_entries_tag()
Add find_get_entries_tag() to the family of functions that include
find_get_entries(), find_get_pages() and find_get_pages_tag(). This is
needed for DAX dirty page handling because we need a list of both page
offsets and radix tree entries ('indices' and 'entries' in this function)
that are marked with the PAGECACHE_TAG_TOWRITE tag.
Signed-off-by: Ross Zwisler
Reviewed-by: Jan Kara
---
include/linux/pagemap.h | 3 +++
mm/filemap.c| 68 +
2 files changed, 71 insertions(+)
diff --git a/include/linux/pagemap.h b/include/linux/pagemap.h
index 26eabf5..4db0425 100644
--- a/include/linux/pagemap.h
+++ b/include/linux/pagemap.h
@@ -361,6 +361,9 @@ unsigned find_get_pages_contig(struct address_space
*mapping, pgoff_t start,
unsigned int nr_pages, struct page **pages);
unsigned find_get_pages_tag(struct address_space *mapping, pgoff_t *index,
int tag, unsigned int nr_pages, struct page **pages);
+unsigned find_get_entries_tag(struct address_space *mapping, pgoff_t start,
+ int tag, unsigned int nr_entries,
+ struct page **entries, pgoff_t *indices);
struct page *grab_cache_page_write_begin(struct address_space *mapping,
pgoff_t index, unsigned flags);
diff --git a/mm/filemap.c b/mm/filemap.c
index 167a4d9..99dfbc9 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -1498,6 +1498,74 @@ repeat:
}
EXPORT_SYMBOL(find_get_pages_tag);
+/**
+ * find_get_entries_tag - find and return entries that match @tag
+ * @mapping: the address_space to search
+ * @start: the starting page cache index
+ * @tag: the tag index
+ * @nr_entries:the maximum number of entries
+ * @entries: where the resulting entries are placed
+ * @indices: the cache indices corresponding to the entries in @entries
+ *
+ * Like find_get_entries, except we only return entries which are tagged with
+ * @tag.
+ */
+unsigned find_get_entries_tag(struct address_space *mapping, pgoff_t start,
+ int tag, unsigned int nr_entries,
+ struct page **entries, pgoff_t *indices)
+{
+ void **slot;
+ unsigned int ret = 0;
+ struct radix_tree_iter iter;
+
+ if (!nr_entries)
+ return 0;
+
+ rcu_read_lock();
+restart:
+ radix_tree_for_each_tagged(slot, >page_tree,
+ , start, tag) {
+ struct page *page;
+repeat:
+ page = radix_tree_deref_slot(slot);
+ if (unlikely(!page))
+ continue;
+ if (radix_tree_exception(page)) {
+ if (radix_tree_deref_retry(page)) {
+ /*
+* Transient condition which can only trigger
+* when entry at index 0 moves out of or back
+* to root: none yet gotten, safe to restart.
+*/
+ goto restart;
+ }
+
+ /*
+* A shadow entry of a recently evicted page, a swap
+* entry from shmem/tmpfs or a DAX entry. Return it
+* without attempting to raise page count.
+*/
+ goto export;
+ }
+ if (!page_cache_get_speculative(page))
+ goto repeat;
+
+ /* Has the page moved? */
+ if (unlikely(page != *slot)) {
+ page_cache_release(page);
+ goto repeat;
+ }
+export:
+ indices[ret] = iter.index;
+ entries[ret] = page;
+ if (++ret == nr_entries)
+ break;
+ }
+ rcu_read_unlock();
+ return ret;
+}
+EXPORT_SYMBOL(find_get_entries_tag);
+
/*
* CD/DVDs are error prone. When a medium error occurs, the driver may fail
* a _large_ part of the i/o request. Imagine the worst scenario:
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 2/7] dax: support dirty DAX entries in radix tree
Add support for tracking dirty DAX entries in the struct address_space
radix tree. This tree is already used for dirty page writeback, and it
already supports the use of exceptional (non struct page*) entries.
In order to properly track dirty DAX pages we will insert new exceptional
entries into the radix tree that represent dirty DAX PTE or PMD pages.
These exceptional entries will also contain the writeback addresses for the
PTE or PMD faults that we can use at fsync/msync time.
There are currently two types of exceptional entries (shmem and shadow)
that can be placed into the radix tree, and this adds a third. We rely on
the fact that only one type of exceptional entry can be found in a given
radix tree based on its usage. This happens for free with DAX vs shmem but
we explicitly prevent shadow entries from being added to radix trees for
DAX mappings.
The only shadow entries that would be generated for DAX radix trees would
be to track zero page mappings that were created for holes. These pages
would receive minimal benefit from having shadow entries, and the choice
to have only one type of exceptional entry in a given radix tree makes the
logic simpler both in clear_exceptional_entry() and in the rest of DAX.
Signed-off-by: Ross Zwisler
---
fs/block_dev.c | 3 ++-
fs/inode.c | 1 +
include/linux/dax.h| 5
include/linux/fs.h | 1 +
include/linux/radix-tree.h | 9 +++
mm/filemap.c | 13 +++---
mm/truncate.c | 64 +++---
mm/vmscan.c| 9 ++-
8 files changed, 73 insertions(+), 32 deletions(-)
diff --git a/fs/block_dev.c b/fs/block_dev.c
index c25639e..226dacc 100644
--- a/fs/block_dev.c
+++ b/fs/block_dev.c
@@ -75,7 +75,8 @@ void kill_bdev(struct block_device *bdev)
{
struct address_space *mapping = bdev->bd_inode->i_mapping;
- if (mapping->nrpages == 0 && mapping->nrshadows == 0)
+ if (mapping->nrpages == 0 && mapping->nrshadows == 0 &&
+ mapping->nrdax == 0)
return;
invalidate_bh_lrus();
diff --git a/fs/inode.c b/fs/inode.c
index 1be5f90..79d828f 100644
--- a/fs/inode.c
+++ b/fs/inode.c
@@ -496,6 +496,7 @@ void clear_inode(struct inode *inode)
spin_lock_irq(>i_data.tree_lock);
BUG_ON(inode->i_data.nrpages);
BUG_ON(inode->i_data.nrshadows);
+ BUG_ON(inode->i_data.nrdax);
spin_unlock_irq(>i_data.tree_lock);
BUG_ON(!list_empty(>i_data.private_list));
BUG_ON(!(inode->i_state & I_FREEING));
diff --git a/include/linux/dax.h b/include/linux/dax.h
index b415e52..e9d57f68 100644
--- a/include/linux/dax.h
+++ b/include/linux/dax.h
@@ -36,4 +36,9 @@ static inline bool vma_is_dax(struct vm_area_struct *vma)
{
return vma->vm_file && IS_DAX(vma->vm_file->f_mapping->host);
}
+
+static inline bool dax_mapping(struct address_space *mapping)
+{
+ return mapping->host && IS_DAX(mapping->host);
+}
#endif
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 3aa5142..b9ac534 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -433,6 +433,7 @@ struct address_space {
/* Protected by tree_lock together with the radix tree */
unsigned long nrpages;/* number of total pages */
unsigned long nrshadows; /* number of shadow entries */
+ unsigned long nrdax; /* number of DAX entries */
pgoff_t writeback_index;/* writeback starts here */
const struct address_space_operations *a_ops; /* methods */
unsigned long flags; /* error bits/gfp mask */
diff --git a/include/linux/radix-tree.h b/include/linux/radix-tree.h
index 33170db..f793c99 100644
--- a/include/linux/radix-tree.h
+++ b/include/linux/radix-tree.h
@@ -51,6 +51,15 @@
#define RADIX_TREE_EXCEPTIONAL_ENTRY 2
#define RADIX_TREE_EXCEPTIONAL_SHIFT 2
+#define RADIX_DAX_MASK 0xf
+#define RADIX_DAX_PTE (0x4 | RADIX_TREE_EXCEPTIONAL_ENTRY)
+#define RADIX_DAX_PMD (0x8 | RADIX_TREE_EXCEPTIONAL_ENTRY)
+#define RADIX_DAX_TYPE(entry) ((__force unsigned long)entry & RADIX_DAX_MASK)
+#define RADIX_DAX_ADDR(entry) ((void __pmem *)((unsigned long)entry & \
+ ~RADIX_DAX_MASK))
+#define RADIX_DAX_ENTRY(addr, pmd) ((void *)((__force unsigned long)addr | \
+ (pmd ? RADIX_DAX_PMD : RADIX_DAX_PTE)))
+
static inline int radix_tree_is_indirect_ptr(void *ptr)
{
return (int)((unsigned long)ptr & RADIX_TREE_INDIRECT_PTR);
diff --git a/mm/filemap.c b/mm/filemap.c
index 1bb0076..167a4d9 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -11,6 +11,7 @@
*/
#include
#include
+#include
#include
#include
#include
@@ -579,6 +580,12 @@ static int page_cache_tree_insert(struct address_space
*mapping,
p = radix_tree_deref_slot_protected(slot, >tree_lock);
if
[PATCH v5 4/7] dax: add support for fsync/sync
To properly handle fsync/msync in an efficient way DAX needs to track dirty
pages so it is able to flush them durably to media on demand.
The tracking of dirty pages is done via the radix tree in struct
address_space. This radix tree is already used by the page writeback
infrastructure for tracking dirty pages associated with an open file, and
it already has support for exceptional (non struct page*) entries. We
build upon these features to add exceptional entries to the radix tree for
DAX dirty PMD or PTE pages at fault time.
Signed-off-by: Ross Zwisler
---
fs/dax.c| 159 ++--
include/linux/dax.h | 2 +
mm/filemap.c| 3 +
3 files changed, 158 insertions(+), 6 deletions(-)
diff --git a/fs/dax.c b/fs/dax.c
index 43671b6..19347cf 100644
--- a/fs/dax.c
+++ b/fs/dax.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -289,6 +290,143 @@ static int copy_user_bh(struct page *to, struct
buffer_head *bh,
return 0;
}
+static int dax_radix_entry(struct address_space *mapping, pgoff_t index,
+ void __pmem *addr, bool pmd_entry, bool dirty)
+{
+ struct radix_tree_root *page_tree = >page_tree;
+ int error = 0;
+ void *entry;
+
+ __mark_inode_dirty(mapping->host, I_DIRTY_PAGES);
+
+ spin_lock_irq(>tree_lock);
+ entry = radix_tree_lookup(page_tree, index);
+
+ if (entry) {
+ if (!pmd_entry || RADIX_DAX_TYPE(entry) == RADIX_DAX_PMD)
+ goto dirty;
+ radix_tree_delete(>page_tree, index);
+ mapping->nrdax--;
+ }
+
+ if (!addr) {
+ /*
+* This can happen during correct operation if our pfn_mkwrite
+* fault raced against a hole punch operation. If this
+* happens the pte that was hole punched will have been
+* unmapped and the radix tree entry will have been removed by
+* the time we are called, but the call will still happen. We
+* will return all the way up to wp_pfn_shared(), where the
+* pte_same() check will fail, eventually causing page fault
+* to be retried by the CPU.
+*/
+ goto unlock;
+ } else if (RADIX_DAX_TYPE(addr)) {
+ WARN_ONCE(1, "%s: invalid address %p\n", __func__, addr);
+ goto unlock;
+ }
+
+ error = radix_tree_insert(page_tree, index,
+ RADIX_DAX_ENTRY(addr, pmd_entry));
+ if (error)
+ goto unlock;
+
+ mapping->nrdax++;
+ dirty:
+ if (dirty)
+ radix_tree_tag_set(page_tree, index, PAGECACHE_TAG_DIRTY);
+ unlock:
+ spin_unlock_irq(>tree_lock);
+ return error;
+}
+
+static void dax_writeback_one(struct address_space *mapping, pgoff_t index,
+ void *entry)
+{
+ struct radix_tree_root *page_tree = >page_tree;
+ int type = RADIX_DAX_TYPE(entry);
+ struct radix_tree_node *node;
+ void **slot;
+
+ if (type != RADIX_DAX_PTE && type != RADIX_DAX_PMD) {
+ WARN_ON_ONCE(1);
+ return;
+ }
+
+ spin_lock_irq(>tree_lock);
+ /*
+* Regular page slots are stabilized by the page lock even
+* without the tree itself locked. These unlocked entries
+* need verification under the tree lock.
+*/
+ if (!__radix_tree_lookup(page_tree, index, , ))
+ goto unlock;
+ if (*slot != entry)
+ goto unlock;
+
+ /* another fsync thread may have already written back this entry */
+ if (!radix_tree_tag_get(page_tree, index, PAGECACHE_TAG_TOWRITE))
+ goto unlock;
+
+ radix_tree_tag_clear(page_tree, index, PAGECACHE_TAG_TOWRITE);
+
+ if (type == RADIX_DAX_PMD)
+ wb_cache_pmem(RADIX_DAX_ADDR(entry), PMD_SIZE);
+ else
+ wb_cache_pmem(RADIX_DAX_ADDR(entry), PAGE_SIZE);
+ unlock:
+ spin_unlock_irq(>tree_lock);
+}
+
+/*
+ * Flush the mapping to the persistent domain within the byte range of [start,
+ * end]. This is required by data integrity operations to ensure file data is
+ * on persistent storage prior to completion of the operation.
+ */
+void dax_writeback_mapping_range(struct address_space *mapping, loff_t start,
+ loff_t end)
+{
+ struct inode *inode = mapping->host;
+ pgoff_t indices[PAGEVEC_SIZE];
+ pgoff_t start_page, end_page;
+ struct pagevec pvec;
+ void *entry;
+ int i;
+
+ if (inode->i_blkbits != PAGE_SHIFT) {
+ WARN_ON_ONCE(1);
+ return;
+ }
+
+ rcu_read_lock();
+ entry = radix_tree_lookup(>page_tree, start & PMD_MASK);
+ rcu_read_unlock();
+
+ /* see if the start of our range is covered by a PMD entry */
+ if (entry &&
[PATCH v5 5/7] ext2: call dax_pfn_mkwrite() for DAX fsync/msync
To properly support the new DAX fsync/msync infrastructure filesystems
need to call dax_pfn_mkwrite() so that DAX can track when user pages are
dirtied.
Signed-off-by: Ross Zwisler
---
fs/ext2/file.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/fs/ext2/file.c b/fs/ext2/file.c
index 11a42c5..2c88d68 100644
--- a/fs/ext2/file.c
+++ b/fs/ext2/file.c
@@ -102,8 +102,8 @@ static int ext2_dax_pfn_mkwrite(struct vm_area_struct *vma,
{
struct inode *inode = file_inode(vma->vm_file);
struct ext2_inode_info *ei = EXT2_I(inode);
- int ret = VM_FAULT_NOPAGE;
loff_t size;
+ int ret;
sb_start_pagefault(inode->i_sb);
file_update_time(vma->vm_file);
@@ -113,6 +113,8 @@ static int ext2_dax_pfn_mkwrite(struct vm_area_struct *vma,
size = (i_size_read(inode) + PAGE_SIZE - 1) >> PAGE_SHIFT;
if (vmf->pgoff >= size)
ret = VM_FAULT_SIGBUS;
+ else
+ ret = dax_pfn_mkwrite(vma, vmf);
up_read(>dax_sem);
sb_end_pagefault(inode->i_sb);
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 7/7] xfs: call dax_pfn_mkwrite() for DAX fsync/msync
To properly support the new DAX fsync/msync infrastructure filesystems need to call dax_pfn_mkwrite() so that DAX can track when user pages are dirtied. Signed-off-by: Ross Zwisler --- fs/xfs/xfs_file.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/fs/xfs/xfs_file.c b/fs/xfs/xfs_file.c index f5392ab..40ffbb1 100644 --- a/fs/xfs/xfs_file.c +++ b/fs/xfs/xfs_file.c @@ -1603,9 +1603,8 @@ xfs_filemap_pmd_fault( /* * pfn_mkwrite was originally inteneded to ensure we capture time stamp * updates on write faults. In reality, it's need to serialise against - * truncate similar to page_mkwrite. Hence we open-code dax_pfn_mkwrite() - * here and cycle the XFS_MMAPLOCK_SHARED to ensure we serialise the fault - * barrier in place. + * truncate similar to page_mkwrite. Hence we cycle the XFS_MMAPLOCK_SHARED + * to ensure we serialise the fault barrier in place. */ static int xfs_filemap_pfn_mkwrite( @@ -1628,6 +1627,8 @@ xfs_filemap_pfn_mkwrite( size = (i_size_read(inode) + PAGE_SIZE - 1) >> PAGE_SHIFT; if (vmf->pgoff >= size) ret = VM_FAULT_SIGBUS; + else if (IS_DAX(inode)) + ret = dax_pfn_mkwrite(vma, vmf); xfs_iunlock(ip, XFS_MMAPLOCK_SHARED); sb_end_pagefault(inode->i_sb); return ret; -- 2.5.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 2/7] dax: support dirty DAX entries in radix tree
On Fri, Dec 18, 2015 at 10:01:10AM +0100, Jan Kara wrote: > On Tue 08-12-15 12:18:40, Ross Zwisler wrote: > > Add support for tracking dirty DAX entries in the struct address_space > > radix tree. This tree is already used for dirty page writeback, and it > > already supports the use of exceptional (non struct page*) entries. > > > > In order to properly track dirty DAX pages we will insert new exceptional > > entries into the radix tree that represent dirty DAX PTE or PMD pages. > > These exceptional entries will also contain the writeback addresses for the > > PTE or PMD faults that we can use at fsync/msync time. > > > > There are currently two types of exceptional entries (shmem and shadow) > > that can be placed into the radix tree, and this adds a third. There > > shouldn't be any collisions between these various exceptional entries > > because only one type of exceptional entry should be able to be found in a > > radix tree at a time depending on how it is being used. > > I was thinking about this and I'm not sure the use of exceptional entries > cannot collide. DAX uses page cache for read mapping of holes. When memory > pressure happens, page can get evicted again and entry in the radix tree > will get replaced with a shadow entry. So shadow entries *can* exist in DAX > mappings. Thus at least your change to clear_exceptional_entry() looks > wrong to me. > > Also when we'd like to insert DAX radix tree entry, we have to count with > the fact that there can be shadow entry in place and we have to tear it > down properly. You are right, thank you for catching this. I think the correct thing to do is to just explicitly disallow having shadow entries in trees for DAX mappings. As you say the only usage is to track zero page mappings for reading holes which will get minimal benefit from shadow entries, and this choice makes the logic both in clear_exceptional_entry() and in the rest of the DAX code simpler. I've sent out a v5 that fixes this 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/
[PATCH v5 6/7] ext4: call dax_pfn_mkwrite() for DAX fsync/msync
To properly support the new DAX fsync/msync infrastructure filesystems
need to call dax_pfn_mkwrite() so that DAX can track when user pages are
dirtied.
Signed-off-by: Ross Zwisler
---
fs/ext4/file.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/fs/ext4/file.c b/fs/ext4/file.c
index 749b222..8c8965c 100644
--- a/fs/ext4/file.c
+++ b/fs/ext4/file.c
@@ -291,8 +291,8 @@ static int ext4_dax_pfn_mkwrite(struct vm_area_struct *vma,
{
struct inode *inode = file_inode(vma->vm_file);
struct super_block *sb = inode->i_sb;
- int ret = VM_FAULT_NOPAGE;
loff_t size;
+ int ret;
sb_start_pagefault(sb);
file_update_time(vma->vm_file);
@@ -300,6 +300,8 @@ static int ext4_dax_pfn_mkwrite(struct vm_area_struct *vma,
size = (i_size_read(inode) + PAGE_SIZE - 1) >> PAGE_SHIFT;
if (vmf->pgoff >= size)
ret = VM_FAULT_SIGBUS;
+ else
+ ret = dax_pfn_mkwrite(vma, vmf);
up_read(_I(inode)->i_mmap_sem);
sb_end_pagefault(sb);
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 1/7] pmem: add wb_cache_pmem() to the PMEM API
The function __arch_wb_cache_pmem() was already an internal implementation
detail of the x86 PMEM API, but this functionality needs to be exported as
part of the general PMEM API to handle the fsync/msync case for DAX mmaps.
One thing worth noting is that we really do want this to be part of the
PMEM API as opposed to a stand-alone function like clflush_cache_range()
because of ordering restrictions. By having wb_cache_pmem() as part of the
PMEM API we can leave it unordered, call it multiple times to write back
large amounts of memory, and then order the multiple calls with a single
wmb_pmem().
Signed-off-by: Ross Zwisler
---
arch/x86/include/asm/pmem.h | 11 ++-
include/linux/pmem.h| 22 +-
2 files changed, 27 insertions(+), 6 deletions(-)
diff --git a/arch/x86/include/asm/pmem.h b/arch/x86/include/asm/pmem.h
index d8ce3ec..6c7ade0 100644
--- a/arch/x86/include/asm/pmem.h
+++ b/arch/x86/include/asm/pmem.h
@@ -67,18 +67,19 @@ static inline void arch_wmb_pmem(void)
}
/**
- * __arch_wb_cache_pmem - write back a cache range with CLWB
+ * arch_wb_cache_pmem - write back a cache range with CLWB
* @vaddr: virtual start address
* @size: number of bytes to write back
*
* Write back a cache range using the CLWB (cache line write back)
* instruction. This function requires explicit ordering with an
- * arch_wmb_pmem() call. This API is internal to the x86 PMEM implementation.
+ * arch_wmb_pmem() call.
*/
-static inline void __arch_wb_cache_pmem(void *vaddr, size_t size)
+static inline void arch_wb_cache_pmem(void __pmem *addr, size_t size)
{
u16 x86_clflush_size = boot_cpu_data.x86_clflush_size;
unsigned long clflush_mask = x86_clflush_size - 1;
+ void *vaddr = (void __force *)addr;
void *vend = vaddr + size;
void *p;
@@ -115,7 +116,7 @@ static inline size_t arch_copy_from_iter_pmem(void __pmem
*addr, size_t bytes,
len = copy_from_iter_nocache(vaddr, bytes, i);
if (__iter_needs_pmem_wb(i))
- __arch_wb_cache_pmem(vaddr, bytes);
+ arch_wb_cache_pmem(addr, bytes);
return len;
}
@@ -138,7 +139,7 @@ static inline void arch_clear_pmem(void __pmem *addr,
size_t size)
else
memset(vaddr, 0, size);
- __arch_wb_cache_pmem(vaddr, size);
+ arch_wb_cache_pmem(addr, size);
}
static inline bool __arch_has_wmb_pmem(void)
diff --git a/include/linux/pmem.h b/include/linux/pmem.h
index acfea8c..7c3d11a 100644
--- a/include/linux/pmem.h
+++ b/include/linux/pmem.h
@@ -53,12 +53,18 @@ static inline void arch_clear_pmem(void __pmem *addr,
size_t size)
{
BUG();
}
+
+static inline void arch_wb_cache_pmem(void __pmem *addr, size_t size)
+{
+ BUG();
+}
#endif
/*
* Architectures that define ARCH_HAS_PMEM_API must provide
* implementations for arch_memcpy_to_pmem(), arch_wmb_pmem(),
- * arch_copy_from_iter_pmem(), arch_clear_pmem() and arch_has_wmb_pmem().
+ * arch_copy_from_iter_pmem(), arch_clear_pmem(), arch_wb_cache_pmem()
+ * and arch_has_wmb_pmem().
*/
static inline void memcpy_from_pmem(void *dst, void __pmem const *src, size_t
size)
{
@@ -178,4 +184,18 @@ static inline void clear_pmem(void __pmem *addr, size_t
size)
else
default_clear_pmem(addr, size);
}
+
+/**
+ * wb_cache_pmem - write back processor cache for PMEM memory range
+ * @addr: virtual start address
+ * @size: number of bytes to write back
+ *
+ * Write back the processor cache range starting at 'addr' for 'size' bytes.
+ * This function requires explicit ordering with a wmb_pmem() call.
+ */
+static inline void wb_cache_pmem(void __pmem *addr, size_t size)
+{
+ if (arch_has_pmem_api())
+ arch_wb_cache_pmem(addr, size);
+}
#endif /* __PMEM_H__ */
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 0/7] DAX fsync/msync support
Changes from v4: - Explicity prevent shadow entries from being added to radix trees for DAX mappings in patch 2. The only shadow entries that would be generated for DAX radix trees would be to track zero page mappings that were created for holes. These pages would receive minimal benefit from having shadow entries, and the choice to have only one type of exceptional entry in a given radix tree makes the logic simpler both in clear_exceptional_entry() and in the rest of DAX. (Jan) - Added Reviewed-by from Jan to patch 3. This series is built upon ext4/master. A working tree with this series applied can be found here: https://git.kernel.org/cgit/linux/kernel/git/zwisler/linux.git/log/?h=fsync_v5 Ross Zwisler (7): pmem: add wb_cache_pmem() to the PMEM API dax: support dirty DAX entries in radix tree mm: add find_get_entries_tag() dax: add support for fsync/sync ext2: call dax_pfn_mkwrite() for DAX fsync/msync ext4: call dax_pfn_mkwrite() for DAX fsync/msync xfs: call dax_pfn_mkwrite() for DAX fsync/msync arch/x86/include/asm/pmem.h | 11 +-- fs/block_dev.c | 3 +- fs/dax.c| 159 ++-- fs/ext2/file.c | 4 +- fs/ext4/file.c | 4 +- fs/inode.c | 1 + fs/xfs/xfs_file.c | 7 +- include/linux/dax.h | 7 ++ include/linux/fs.h | 1 + include/linux/pagemap.h | 3 + include/linux/pmem.h| 22 +- include/linux/radix-tree.h | 9 +++ mm/filemap.c| 84 ++- mm/truncate.c | 64 ++ mm/vmscan.c | 9 ++- 15 files changed, 339 insertions(+), 49 deletions(-) -- 2.5.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] netcp: fix regression in receive processing
From: Arnd Bergmann
Date: Fri, 18 Dec 2015 15:18:08 +0100
> A cleanup patch I did was unfortunately wrong and introduced
> multiple serious bugs in the netcp rx processing, as indicated
> by these correct gcc warnings:
>
> drivers/net/ethernet/ti/netcp_core.c:776:14: warning: 'buf_ptr' may be used
> uninitialized in this function [-Wuninitialized]
> drivers/net/ethernet/ti/netcp_core.c:687:14: warning: 'ptr' may be used
> uninitialized in this function [-Wuninitialized]
>
> I have checked the patch once more and found that a call to
> get_pkt_info() accidentally got removed in netcp_free_rx_desc_chain,
> and netcp_process_one_rx_packet no longer retrieved the correct
> buffer length. This patch should fix all the known problems,
> but I did not test on real hardware.
>
> Signed-off-by: Arnd Bergmann
> Fixes: 899077791403 ("netcp: try to reduce type confusion in descriptors")
Applied.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [LKP] [PATCH v2] rhashtable: Kill harmless RCU warning in rhashtable_walk_init
On Fri, Dec 18, 2015 at 11:42:59PM -0500, David Miller wrote:
> From: Herbert Xu
> Date: Sat, 19 Dec 2015 10:45:28 +0800
>
> > On Fri, Dec 18, 2015 at 04:27:31PM -0500, David Miller wrote:
> >> From: Herbert Xu
> >> Date: Fri, 18 Dec 2015 21:14:08 +0800
> >>
> >> > On Fri, Dec 18, 2015 at 04:54:14AM -0800, Eric Dumazet wrote:
> >> >>
> >> >> You can avoid the comment by using the self documented and lockdep
> >> >> enabled primitive
> >> >>
> >> >> iter->walker->tbl = rcu_dereference_protected(ht->tbl,
> >> >>
> >> >> lockdep_is_held(>lock));
> >> >
> >> > That is just gross. I think a comment is much better in this case.
> >>
> >> Herbert, this macro was created exactly to handle this situation,
> >> and this is what we do everywhere else in the tree.
> >
> > OK.
> >
> > ---8<---
> > The commit f9f51b8070be3e829100614a7372b219723b864f ("rhashtable:
> > Fix walker list corruption") causes a suspicious RCU usage warning
> > because we no longer hold ht->mutex when we dereference ht->tbl.
> >
> > However, this is a false positive because we now hold ht->lock
> > which also guarantees that ht->tbl won't disppear from under us.
> >
> > This patch kills the warning by using rcu_dereference_protected.
> >
> > Reported-by: kernel test robot
> > Signed-off-by: Herbert Xu
>
> The correct commti SHA1 is c6ff5268293ef98e48a99597e765ffc417e39fa5.
>
> Or at least, when I run:
>
> git show f9f51b8070be3e829100614a7372b219723b864f
>
> I get:
>
> fatal: bad object f9f51b8070be3e829100614a7372b219723b864f
>
> :-)
Oops, that commit comes from 0day robot :-)
> https://github.com/0day-ci/linux
> Herbert-Xu/rhashtable-Fix-walker-list-corruption/20151216-164833
> commit f9f51b8070be3e829100614a7372b219723b864f ("rhashtable: Fix walker list
> corruption")
commit f9f51b8070be3e829100614a7372b219723b864f
Author: Herbert Xu
AuthorDate: Wed Dec 16 16:45:54 2015 +0800
Commit: 0day robot
CommitDate: Wed Dec 16 16:48:36 2015 +0800
rhashtable: Fix walker list corruption
Thanks,
Fengguang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] rhashtable: Kill harmless RCU warning in rhashtable_walk_init
From: Herbert Xu
Date: Sat, 19 Dec 2015 10:45:28 +0800
> On Fri, Dec 18, 2015 at 04:27:31PM -0500, David Miller wrote:
>> From: Herbert Xu
>> Date: Fri, 18 Dec 2015 21:14:08 +0800
>>
>> > On Fri, Dec 18, 2015 at 04:54:14AM -0800, Eric Dumazet wrote:
>> >>
>> >> You can avoid the comment by using the self documented and lockdep
>> >> enabled primitive
>> >>
>> >> iter->walker->tbl = rcu_dereference_protected(ht->tbl,
>> >> lockdep_is_held(>lock));
>> >
>> > That is just gross. I think a comment is much better in this case.
>>
>> Herbert, this macro was created exactly to handle this situation,
>> and this is what we do everywhere else in the tree.
>
> OK.
>
> ---8<---
> The commit f9f51b8070be3e829100614a7372b219723b864f ("rhashtable:
> Fix walker list corruption") causes a suspicious RCU usage warning
> because we no longer hold ht->mutex when we dereference ht->tbl.
>
> However, this is a false positive because we now hold ht->lock
> which also guarantees that ht->tbl won't disppear from under us.
>
> This patch kills the warning by using rcu_dereference_protected.
>
> Reported-by: kernel test robot
> Signed-off-by: Herbert Xu
The correct commti SHA1 is c6ff5268293ef98e48a99597e765ffc417e39fa5.
Or at least, when I run:
git show f9f51b8070be3e829100614a7372b219723b864f
I get:
fatal: bad object f9f51b8070be3e829100614a7372b219723b864f
:-)
I fixed this up and applied this, 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 V5 1/2] watchdog: Use static struct class watchdog_class in stead of pointer
On 17/12/2015:06:56:27 AM, Guenter Roeck wrote: > On 12/17/2015 04:23 AM, Pratyush Anand wrote: > >We need few sysfs attributes to know different status of a watchdog device. > >To do that, we need to associate .dev_groups with watchdog_class. So > >convert it from pointer to static. > >Putting this static struct in watchdog_dev.c, so that static device > >attributes defined in that file can be attached to it. > > > >Signed-off-by: Pratyush Anand > >Suggested-by: Guenter Roeck > >Reviewed-by: Guenter Roeck > > As things evolve, I'd by now prefer to move the call to device_create() > into watchdog_dev.c, but that can wait for a follow-up patch if Wim > is ok with this series. Thanks for your quick review. OK. I will wait for Wim's comment and then may be I will send another version with your comment for patch 1/1 incorporated. ~Pratyush -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 1/3] dt-binding: power: Add otg regulator binding
On Tue, Dec 15, 2015 at 11:52:10AM -0800, Tim Bird wrote: > Add a binding for the regulator which controls the OTG chargepath switch. > The OTG switch gets its power from pm8941_5vs1, and that should be > expressed as a usb_otg_in-supply property in the DT node for the > charger driver. The regulator name is "otg-vbus". > > Signed-off-by: Tim Bird > --- > Changes since v3 > - switch supply name to have underscores instead of dashes >- (switched back to match the name used in data sheets) > - switch regulator node name to otg-vbus > Changes since v1 > - switch supply name to have dashes instead of underscores > - remove superfluous DT explanations in the otg node description > --- > .../devicetree/bindings/power_supply/qcom_smbb.txt| 19 > +++ > 1 file changed, 19 insertions(+) Acked-by: Rob Herring -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5] arm: pxa: support ICP DAS LP-8x4x FPGA irq
On Tue, Dec 15, 2015 at 10:26:21PM +0300, Sergei Ianovich wrote:
> ICP DAS LP-8x4x contains FPGA chip. The chip functions as an interrupt
> source providing 16 additional interrupts among other things. The
> interrupt lines are muxed to a GPIO pin of a 2nd level PXA-GPIO
> interrupt controller. GPIO pins of the 2nd level controller are in turn
> muxed to a CPU interrupt line.
>
> Until pxa is completely converted to device tree, it is impossible
> to use IRQCHIP_DECLARE() and the irqdomain needs to added manually.
> Drivers for the on-CPU IRQs and GPIO-IRQs are loaded using
> postcore_initcall(). We need to have all irq domain drivers loaded prior
> to DT parsing in order to allow normal initialization of IRQ resources
> with DT.
>
> Signed-off-by: Sergei Ianovich
> Reviewed-by: Linus Walleij
> CC: Arnd Bergmann
> ---
>v4..v5
>* constify struct of_device_id
>* drop irq number from handler signature
>
>v3.2..v4
>* move DTS binding to a different patch (8/21)
>
>v3.1..v3.2
>fixes to apply Linus Walleij's "Reviewed-by":
>* add kerneldoc comment for state container struct
>* rename irq -> hwirq for clarity
>* drop overzealous error checks from the hotpaths
>
>v3..v3.1
>fixes according to Linus Walleij review comments:
>* update commit message
>* use state container instead of global variables
>* get hardware irq nums from irq_data, don't calculate them
>* use BIT() macro
>* add defines for system irq register masks
>* replace cycle control variable with break
>* use better names for resource variables
>* add a linear domain instead of a legacy one
>* use irq_create_mapping() instead of irq_alloc_desc()
>
>v2..v3
>* no changes (except number 09/16 -> 11/21)
>
>v0..v2
>* extract irqchip and move to drivers/irqchip/
>* use device tree
>* use devm helpers where possible
>
> .../bindings/interrupt-controller/irq-lp8x4x.txt | 49 +
> drivers/irqchip/Kconfig| 5 +
> drivers/irqchip/Makefile | 1 +
> drivers/irqchip/irq-lp8x4x.c | 227
> +
> 4 files changed, 282 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/interrupt-controller/irq-lp8x4x.txt
> create mode 100644 drivers/irqchip/irq-lp8x4x.c
>
> diff --git
> a/Documentation/devicetree/bindings/interrupt-controller/irq-lp8x4x.txt
> b/Documentation/devicetree/bindings/interrupt-controller/irq-lp8x4x.txt
> new file mode 100644
> index 000..c8940d2
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/interrupt-controller/irq-lp8x4x.txt
> @@ -0,0 +1,49 @@
> +ICP DAS LP-8x4x FPGA Interrupt Controller
> +
> +ICP DAS LP-8x4x contains FPGA chip. The chip functions as a interrupt
> +source providing 16 additional interrupts among other things.
> +
> +Required properties:
> +- compatible : should be "icpdas,irq-lp8x4x"
> +
> +- reg: physical base address of the controller and length of memory mapped
> + region.
> +
> +- interrupt-controller : identifies the node as an interrupt controller
> +
> +- #interrupt-cells : should be 1
> +
> +- interrupts : should provide interrupt
> +
> +- interrupt-parent : should provide a link to interrupt controller either
> + explicitly and implicitly from a parent node
> +
> +Example:
> +
> + fpga: fpga@1706 {
Nothing else in the fpga? In any case, this node should be named
interrupt-controller@1706.
> + compatible = "icpdas,irq-lp8x4x";
As pointed out in the uart binding, don't use wildcards here.
> + reg = <0x1706 0x16>;
> + interrupt-parent = <>;
> + interrupts = <3 IRQ_TYPE_EDGE_RISING>;
> + #interrupt-cells = <1>;
> + interrupt-controller;
> + status = "okay";
> + };
> +
> + uart@17009050 {
> + compatible = "icpdas,uart-lp8x4x";
> + reg = <0x17009050 0x10
> +0x17009030 0x02>;
> + interrupt-parent = <>;
> + interrupts = <13>;
> + status = "okay";
> + };
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] gpio: sx150x: Add support for sx1502
On Tue, Dec 15, 2015 at 11:01:34PM +0100, Peter Rosin wrote: > From: Peter Rosin > > Signed-off-by: Peter Rosin > --- > .../devicetree/bindings/gpio/gpio-sx150x.txt | 3 +- For the binding: Acked-by: Rob Herring > drivers/gpio/gpio-sx150x.c | 53 > -- > 2 files changed, 51 insertions(+), 5 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 1/3] clk: bcm2835: Add bindings for the auxiliary peripheral clock gates.
On Tue, Dec 15, 2015 at 03:35:57PM -0800, Eric Anholt wrote: > These will be used for enabling UART1, SPI1, and SPI2. > > Signed-off-by: Eric Anholt > --- > > v2: Make the binding cover both the IRQ and clock enable registers. > > .../bindings/clock/brcm,bcm2835-aux-clock.txt | 31 > ++ > include/dt-bindings/clock/bcm2835-aux.h| 17 > 2 files changed, 48 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/clock/brcm,bcm2835-aux-clock.txt > create mode 100644 include/dt-bindings/clock/bcm2835-aux.h Acked-by: Rob Herring -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] devicetree: sound: add binding for WM8974 codec
On Wed, Dec 16, 2015 at 01:55:13PM +, Mans Rullgard wrote: > This adds a binding for the Wolfson WM8974 mono audio codec. > > Signed-off-by: Mans Rullgard > --- > Sending this patch again, this time including Mark Brown. > --- > Documentation/devicetree/bindings/sound/wlf,wm8974.txt | 15 +++ > 1 file changed, 15 insertions(+) > create mode 100644 Documentation/devicetree/bindings/sound/wlf,wm8974.txt This could go in i2c/trivial-devices.txt if this is it, but standalone is fine too. Acked-by: Rob Herring -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] devicetree: sound: add binding for WM8974 codec
On Wed, Dec 16, 2015 at 01:31:30PM +, Måns Rullgård wrote: > Mark, > > This is the 1/1 you were missing. > > Am I the only one who is annoyed by scripts/get_maintainer.pl not > returning all the addresses it should in cases like this? Is there some > trick I'm missing? Documentation/devicetree/bindings/sound/ should probably be listed with the ALSA maintainer entry. 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/
[PATCH] ARM64: Fix compiling with GCC 6 and Atomics enabled
The problem here is that GCC 6 and above emits .arch now
for each function so now the global .arch_extension has
no effect. This fixes the problem by putting
.arch_extension inside ARM64_LSE_ATOMIC_INSN so
it is enabled for each place where LSE is used.
Signed-off-by: Andrew Pinski
---
arch/arm64/include/asm/lse.h |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/include/asm/lse.h b/arch/arm64/include/asm/lse.h
index 3de42d6..625601f 100644
--- a/arch/arm64/include/asm/lse.h
+++ b/arch/arm64/include/asm/lse.h
@@ -17,8 +17,6 @@
#else /* __ASSEMBLER__ */
-__asm__(".arch_extension lse");
-
/* Move the ll/sc atomics out-of-line */
#define __LL_SC_INLINE
#define __LL_SC_PREFIX(x) __ll_sc_##x
@@ -29,7 +27,7 @@ __asm__(".arch_extension lse");
/* In-line patching at runtime */
#define ARM64_LSE_ATOMIC_INSN(llsc, lse) \
- ALTERNATIVE(llsc, lse, ARM64_HAS_LSE_ATOMICS)
+ ALTERNATIVE(".arch_extensionlse\n" llsc, lse,
ARM64_HAS_LSE_ATOMICS)
#endif /* __ASSEMBLER__ */
#else /* CONFIG_AS_LSE && CONFIG_ARM64_LSE_ATOMICS */
--
1.7.2.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RESEND PATCH v2 2/2] ASoC: atmel-classd: DT binding for PDMIC driver
On Thu, Dec 17, 2015 at 05:50:00PM +0800, Songjun Wu wrote:
> DT binding documentation for this new ASoC driver.
>
> Signed-off-by: Songjun Wu
> ---
>
> Changes in v2: None
>
> .../devicetree/bindings/sound/atmel-pdmic.txt | 55
>
> 1 file changed, 55 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/sound/atmel-pdmic.txt
>
> diff --git a/Documentation/devicetree/bindings/sound/atmel-pdmic.txt
> b/Documentation/devicetree/bindings/sound/atmel-pdmic.txt
> new file mode 100644
> index 000..e0875f1
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sound/atmel-pdmic.txt
> @@ -0,0 +1,55 @@
> +* Atmel PDMIC driver under ALSA SoC architecture
> +
> +Required properties:
> +- compatible
> + Should be "atmel,sama5d2-pdmic".
> +- reg
> + Should contain PDMIC registers location and length.
> +- interrupts
> + Should contain the IRQ line for the PDMIC.
> +- dmas
> + One DMA specifiers as described in atmel-dma.txt and dma.txt files.
> +- dma-names
> + Must be "rx".
> +- clock-names
> + Required elements:
> + - "pclk"peripheral clock
> + - "gclk"generated clock
> +- clocks
> + Must contain an entry for each required entry in clock-names.
> + Please refer to clock-bindings.txt.
> +- atmel,mic-min-freq
> + The minimal frequency that the micphone supports.
> +- atmel,mic-max-freq
> + The maximal frequency that the micphone supports.
Please append units to these 2 (-hz).
> +Optional properties:
> +- pinctrl-names, pinctrl-0
> + Please refer to pinctrl-bindings.txt.
> +- atmel,model
> + The user-visible name of this sound card.
> + The default value is "PDMIC".
When and why would this be different than the default?
"label" can be used here if this is really needed.
> +- atmel,mic-offset
> + The offset that should be added.
> + The range is from -32768 to 32767.
> + The default value is 0.
> +
> +Example:
> + pdmic@f8018000 {
> + compatible = "atmel,sama5d2-pdmic";
> + reg = <0xf8018000 0x124>;
> + interrupts = <48 IRQ_TYPE_LEVEL_HIGH 7>;
> + dmas = <
> + (AT91_XDMAC_DT_MEM_IF(0) |
> AT91_XDMAC_DT_PER_IF(1)
> + | AT91_XDMAC_DT_PERID(50))>;
> + dma-names = "rx";
> + clocks = <_clk>, <_gclk>;
> + clock-names = "pclk", "gclk";
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <_pdmic_default>;
> + atmel,model = "PDMIC @ sama5d2_xplained";
> + atmel,mic-min-freq = <100>;
> + atmel,mic-max-freq = <3246000>;
> + atmel,mic-offset = <0x0>;
> + };
> --
> 1.7.9.5
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 3/8] dt-bindings: Add root properties for Raspberry Pi 2
On Wed, Dec 16, 2015 at 03:55:10PM -0800, Eric Anholt wrote: > Signed-off-by: Eric Anholt > --- > Documentation/devicetree/bindings/arm/bcm/brcm,bcm2835.txt | 4 > 1 file changed, 4 insertions(+) Acked-by: Rob Herring -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/6] dt-bindings: add document for rk3036-vop
On Thu, Dec 17, 2015 at 11:45:19AM +0800, Mark Yao wrote: > Cc: Rob Herring > Cc: Pawel Moll > Cc: Mark Rutland > Cc: Ian Campbell > Cc: Kumar Gala > Cc: devicet...@vger.kernel.org > > Signed-off-by: Mark Yao Acked-by: Rob Herring -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v1 4/6] ARM: dts: rockchip: add the kylin board for rk3036
On Thu, Dec 17, 2015 at 10:21:50PM +0800, Caesar Wang wrote: > This patchset is the initiation version to try work > for kylin board. > > Signed-off-by: Caesar Wang > --- > > Documentation/devicetree/bindings/arm/rockchip.txt | 4 + > arch/arm/boot/dts/Makefile | 1 + > arch/arm/boot/dts/rk3036-kylin.dts | 298 > + > 3 files changed, 303 insertions(+) > create mode 100644 arch/arm/boot/dts/rk3036-kylin.dts Acked-by: Rob Herring -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 1/2] spi: dts: Add new device property to specifcy a wait time between word transmissions
On Thu, Dec 17, 2015 at 12:40:26PM +0100, Marcus Weseloh wrote: > Adds a new property "spi-word-wait-ns" to the spi-bus binding that allows > SPI slave devices to set a wait time between the transmission of words. > > Signed-off-by: Marcus Weseloh > --- > Documentation/devicetree/bindings/spi/spi-bus.txt | 2 ++ > drivers/spi/spi.c | 2 ++ > include/linux/spi/spi.h | 2 ++ > 3 files changed, 6 insertions(+) Acked-by: Rob Herring -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 5/8 v6] thermal: rcar: enable to use thermal-zone on DT
On Fri, Dec 18, 2015 at 12:25:51AM +, Kuninori Morimoto wrote:
>
> From: Kuninori Morimoto
>
> This patch enables to use thermal-zone on DT if it was calles as
> "renesas,rcar-thermal-gen2".
> Previous style (= non thermal-zone) is still supported by
> "renesas,rcar-thermal" to keep compatibility for "git bisect".
>
> Signed-off-by: Kuninori Morimoto
> ---
> v5 -> v6
>
> - "was call" -> "was called"
Except there is a typo...
> - add reason why it keeps previous style
>
> .../devicetree/bindings/thermal/rcar-thermal.txt | 37 +-
> drivers/thermal/rcar_thermal.c | 45
> +++---
> 2 files changed, 75 insertions(+), 7 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/thermal/rcar-thermal.txt
> b/Documentation/devicetree/bindings/thermal/rcar-thermal.txt
> index 332e625..e5ee3f1 100644
> --- a/Documentation/devicetree/bindings/thermal/rcar-thermal.txt
> +++ b/Documentation/devicetree/bindings/thermal/rcar-thermal.txt
> @@ -1,8 +1,9 @@
> * Renesas R-Car Thermal
>
> Required properties:
> -- compatible : "renesas,thermal-", "renesas,rcar-thermal"
> - as fallback.
> +- compatible : "renesas,thermal-",
> +"renesas,rcar-gen2-thermal" (with thermal-zone) or
> +"renesas,rcar-thermal" (without thermal-zone) as
> fallback.
> Examples with soctypes are:
> - "renesas,thermal-r8a73a4" (R-Mobile APE6)
> - "renesas,thermal-r8a7779" (R-Car H1)
> +thermal: thermal@e61f {
> + compatible ="renesas,thermal-r8a7790",
> + "renesas,rcar-gen2-thermal",
> + "renesas,rcar-thermal";
Isn't having both mutually exclusive?
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: [PATCH V10 2/7] dma: hidma: Add Device Tree support
On Thu, Dec 17, 2015 at 12:01:17PM -0500, Sinan Kaya wrote: > Add documentation for the Qualcomm Technologies HIDMA driver. > > Signed-off-by: Sinan Kaya > --- > .../devicetree/bindings/dma/qcom_hidma_mgmt.txt| 79 > ++ > 1 file changed, 79 insertions(+) > create mode 100644 Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt Acked-by: Rob Herring -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] extcon: add Maxim MAX3355 driver
On Fri, Dec 18, 2015 at 01:47:14AM +0300, Sergei Shtylyov wrote: > Maxim Integrated MAX3355E chip integrates a charge pump and comparators to > enable a system with an integrated USB OTG dual-role transceiver to > function as an USB OTG dual-role device. In addition to sensing/controlling > Vbus, the chip also passes thru the ID signal from the USB OTG connector. > On some Renesas boards, this signal is just fed into the SoC thru a GPIO > pin -- there's no real OTG controller, only host and gadget USB controllers > sharing the same USB bus; however, we'd like to allow host or gadget > drivers to be loaded depending on the cable type, hence the need for the > MAX3355 extcon driver. The Vbus status signals are also wired to GPIOs > (however, we aren't currently interested in them), the OFFVBUS# signal is > controlled by the host controllers, there's also the SHDN# signal wired to > a GPIO, it should be driven high for the normal operation. > > Signed-off-by: Sergei Shtylyov > > --- > The patch is against the 'extcon-next' branch of the 'extcon.git' repo. > > Changes in version 4: > - stopped calling kstrdup() for the device name; > - removed unneeded 'owner' field initializer; > - moved devm_extcon_allocate() call further down in the probe() method; > - extended the driver copyright; > - indented the continuation lines in the binding document. > > Changes in version 3: > - reformatted the change log. > > Changes in version 2: > - added the USB gadget cable support; > - added the remove() driver method which drives SHDN# GPIO low to save power; > - dropped vendor prefix from the ID GPIO property name; > - changed the GPIO property name suffix to "-gpios"; > - switched to usign extcon_set_cable_state_() API; > - switched to using the gpiod/sleeping 'gpiolib' APIs; > - addded error messages to max3355_probe(); > - added IRQF_NO_SUSPEND flasg to the devm_request_threaded_irq() call; > - renamed 'ret' variable to 'err' in max3355_probe(); > - expanded the Kconfig entry help text; > - added vendor name to the patch summary, the bindings document, the Kconfig > entry, the driver heading comment, the module description, and the change > log; > - fixed up and reformatted the change log. > > Documentation/devicetree/bindings/extcon/extcon-max3355.txt | 21 + Acked-by: Rob Herring > drivers/extcon/Kconfig |8 > drivers/extcon/Makefile |1 > drivers/extcon/extcon-max3355.c | 151 > > 4 files changed, 181 insertions(+) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/5] dt-bindings: iommu: Add binding for mediatek IOMMU
On Fri, Dec 18, 2015 at 04:09:39PM +0800, Yong Wu wrote: > This patch add mediatek iommu dts binding document. > > Signed-off-by: Yong Wu Acked-by: Rob Herring -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RESEND][PATCH v2] block: partition: Add partition specific uevent callbacks for partition info
On Thu, Dec 10, 2015 at 12:00 PM, John Stultz wrote: > From: San Mehat > > This patch has been carried in the Android tree for quite some > time and is one of the few patches required to get a mainline > kernel up and running with an exsiting Android userspace. So I > wanted to submit it for review and consideration if it should > be merged. > > For partitions, add new uevent parameters 'PARTN' which > specifies the partitions index in the table, and 'PARTNAME', > which specifies PARTNAME specifices the partition name of a > partition device. > > Android's userspace uses this for creating device node links from the > partition name and number: ie: > /dev/block/platform/soc/by-name/system > or > /dev/block/platform/soc/by-num/p1 > > One can see its usage here: > https://android.googlesource.com/platform/system/core/+/master/init/devices.cpp#355 > and > https://android.googlesource.com/platform/system/core/+/master/init/devices.cpp#494 > > Cc: Jens Axboe > Cc: Rom Lemarchand > Cc: Android Kernel Team > Cc: Jeff Moyer > Cc: har...@redhat.com > Cc: k...@redhat.com > Signed-off-by: Dima Zavin > [Dropped NPARTS and reworded commit message for context] > Signed-off-by: John Stultz Ping? Any thoughts on this? Am I missing someone on the CC list I should be including? thanks -john -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 1/3] ARM: sunxi: Introduce Allwinner for A83T support
On Fri, Dec 18, 2015 at 09:30:49PM +0800, Vishnu Patekar wrote:
> Allwinner A83T is octa-core cortex-a7 based SoC.
> It's clock control unit and prcm, pinmux are different from previous sun8i
> series.
> Its processor cores are arragned in two clusters 4 cores each,
> similar to A80.
>
> Signed-off-by: Vishnu Patekar
Acked-by: Rob Herring
> ---
> Documentation/arm/sunxi/README | 1 -
> Documentation/devicetree/bindings/arm/sunxi.txt | 1 +
> arch/arm/mach-sunxi/sunxi.c | 1 +
> drivers/clk/sunxi/clk-sunxi.c | 6 ++
> 4 files changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/arm/sunxi/README b/Documentation/arm/sunxi/README
> index 430d279..e5a115f 100644
> --- a/Documentation/arm/sunxi/README
> +++ b/Documentation/arm/sunxi/README
> @@ -72,6 +72,5 @@ SunXi family
>
> * Octa ARM Cortex-A7 based SoCs
>- Allwinner A83T
> -+ Not Supported
> + Datasheet
>http://dl.linux-sunxi.org/A83T/A83T_datasheet_Revision_1.1.pdf
> diff --git a/Documentation/devicetree/bindings/arm/sunxi.txt
> b/Documentation/devicetree/bindings/arm/sunxi.txt
> index bb9b0faa..7e79fcc 100644
> --- a/Documentation/devicetree/bindings/arm/sunxi.txt
> +++ b/Documentation/devicetree/bindings/arm/sunxi.txt
> @@ -11,5 +11,6 @@ using one of the following compatible strings:
>allwinner,sun7i-a20
>allwinner,sun8i-a23
>allwinner,sun8i-a33
> + allwinner,sun8i-a83t
>allwinner,sun8i-h3
>allwinner,sun9i-a80
> diff --git a/arch/arm/mach-sunxi/sunxi.c b/arch/arm/mach-sunxi/sunxi.c
> index c2be98f..3c15619 100644
> --- a/arch/arm/mach-sunxi/sunxi.c
> +++ b/arch/arm/mach-sunxi/sunxi.c
> @@ -69,6 +69,7 @@ MACHINE_END
> static const char * const sun8i_board_dt_compat[] = {
> "allwinner,sun8i-a23",
> "allwinner,sun8i-a33",
> + "allwinner,sun8i-a83t",
> "allwinner,sun8i-h3",
> NULL,
> };
> diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
> index 5ba2188..0d45253 100644
> --- a/drivers/clk/sunxi/clk-sunxi.c
> +++ b/drivers/clk/sunxi/clk-sunxi.c
> @@ -1219,6 +1219,12 @@ CLK_OF_DECLARE(sun8i_a23_clk_init,
> "allwinner,sun8i-a23", sun6i_init_clocks);
> CLK_OF_DECLARE(sun8i_a33_clk_init, "allwinner,sun8i-a33", sun6i_init_clocks);
> CLK_OF_DECLARE(sun8i_h3_clk_init, "allwinner,sun8i-h3", sun6i_init_clocks);
>
> +static void __init sun8i_a83t_init_clocks(struct device_node *node)
> +{
> + sunxi_init_clocks(NULL, 0);
> +}
> +CLK_OF_DECLARE(sun8i_a83t_clk_init, "allwinner,sun8i-a83t",
> sun8i_a83t_init_clocks);
> +
> static void __init sun9i_init_clocks(struct device_node *node)
> {
> sunxi_init_clocks(NULL, 0);
> --
> 1.9.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/
[GIT PULL] Power management fixes for v4.4-rc6
Hi Linus, Please pull from git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \ pm+acpi-4.4-rc6 to receive power management fixes for v4.4-rc6 with top-most commit f1b9fc591e437ec07626ba84e1d81be19cb00eb6 Merge branches 'powercap', 'pm-cpufreq' and 'pm-domains' on top of commit 9f9499ae8e6415cefc4fe0a96ad0e27864353c89 Linux 4.4-rc5 These fix a potential regression introduced during the 4.3 cycle (generic power domains framework), a nasty bug that has been present forever (power capping RAPL driver), a build issue (Tegra cpufreq driver) and a minor ugliness introduced recently (intel_pstate). Specifics: - Fix a potential regression in the generic power domains framework introduced during the 4.3 development cycle that may lead to spurious failures of system suspend in certain situations (Ulf Hansson). - Fix a problem in the power capping RAPL (Running Average Power Limits) driver that causes it to initialize successfully on some systems where it is not supposed to do that which is due to an incorrect check in an initialization routine (Prarit Bhargava). - Fix a build problem in the cpufreq Tegra driver that depends on the regulator framework, but that dependency is not reflected in Kconfig (Arnd Bergmann). - Fix a recent mistake in the intel_pstate driver where a numeric constant is used directly instead of a symbol defined specifically for the case in question (Prarit Bhargava). Thanks! --- Arnd Bergmann (1): cpufreq: tegra: add regulator dependency for T124 Prarit Bhargava (2): cpufreq: intel_pstate: Minor cleanup for FRAC_BITS powercap / RAPL: fix BIOS lock check Ulf Hansson (1): PM / Domains: Allow runtime PM callbacks to be re-used during system PM --- drivers/base/power/domain.c| 33 ++--- drivers/cpufreq/Kconfig.arm| 2 +- drivers/cpufreq/intel_pstate.c | 2 +- drivers/powercap/intel_rapl.c | 7 +-- 4 files changed, 29 insertions(+), 15 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: [BUG] perf test 21("Test object code reading") failure on ARM64
>>>... > > Hi, > > What is your objdump version? Hi, Sorry for the late reply. # objdump --version GNU objdump (GNU Binutils) 2.25. I am sure that the system is Little endian. > >>> >>> So the following patch is needed. >>> diff --git a/tools/perf/tests/code-reading.c >>> b/tools/perf/tests/code-reading.c >>> index a767a64..1b55fa0 100644 >>> --- a/tools/perf/tests/code-reading.c >>> +++ b/tools/perf/tests/code-reading.c >>> @@ -61,9 +61,6 @@ static size_t read_objdump_line(const char *line, size_t >>> line_len, void *buf, >>> if (i >= line_len || !isxdigit(line[i])) >>> break; >>> c2 = line[i++]; >>> - /* Followed by a space */ >>> - if (i < line_len && line[i] && !isspace(line[i])) >>> - break; >>> /* Store byte */ >>> *(unsigned char *)buf = (hex(c1) << 4) | hex(c2); >>>buf += 1; >>> >>> After applying this patch, the test still failed. >>> ## >>> ... >>> Objdump command is: objdump -z -d --start-address=0x7c4c4 >>> --stop-address=0x7c544 /tmp/oxygen_root-root/lib64/libc-2.19-2014.08.so >>> Bytes read differ from those read by objdump >>> buf1 (dso): >>> 0x00 0x00 0x80 0xd2 0xd5 0xff 0xff 0x17 0xe0 0x03 0x19 0xaa 0xd3 0xff >>> 0xff 0x17 >>> 0xe1 0x03 0x14 0xaa 0xa2 0x63 0x02 0x91 0xe0 0x03 0x13 0xaa 0x66 0xfe >>> 0xff 0x97 >>> 0xfc 0x03 0x00 0xaa 0xa0 0x4f 0x40 0xf9 0xe2 0x03 0x1c 0xaa 0xe1 0x03 >>> 0x00 0xaa >>> 0x08 0x00 0x67 0x9e 0x61 0x02 0x01 0x8b 0xe0 0x03 0x13 0xaa 0x60 0x01 >>> 0x00 0x94 >>> 0xe0 0xf9 0xff 0x35 0x95 0x07 0x00 0xd1 0x1b 0x00 0x80 0xd2 0x01 0x01 >>> 0x66 0x9e >>> 0x60 0x02 0x15 0x8b 0x17 0x00 0x1c 0xcb 0xf8 0x03 0x1b 0xaa 0x0a 0x00 >>> 0x67 0x9e >>> 0x20 0x00 0x80 0xd2 0x00 0x00 0x1c 0xcb 0x81 0x02 0x01 0xcb 0x09 0x00 >>> 0x67 0x9e >>> 0x2b 0x00 0x67 0x9e 0x16 0x03 0x14 0x8b 0x20 0x03 0x1a 0x8b 0x01 0x00 >>> 0x80 0x52 >>> >>> buf2 (objdump): >>> 0xd2 0x80 0x00 0x00 0x17 0xff 0xff 0xd5 0xaa 0x19 0x03 0xe0 0x17 0xff >>> 0xff 0xd3 >>> 0xaa 0x14 0x03 0xe1 0x91 0x02 0x63 0xa2 0xaa 0x13 0x03 0xe0 0x97 0xff >>> 0xfe 0x66 >>> 0xaa 0x00 0x03 0xfc 0xf9 0x40 0x4f 0xa0 0xaa 0x1c 0x03 0xe2 0xaa 0x00 >>> 0x03 0xe1 >>> 0x9e 0x67 0x00 0x08 0x8b 0x01 0x02 0x61 0xaa 0x13 0x03 0xe0 0x94 0x00 >>> 0x01 0x60 >>> 0x35 0xff 0xf9 0xe0 0xd1 0x00 0x07 0x95 0xd2 0x80 0x00 0x1b 0x9e 0x66 >>> 0x01 0x01 >>> 0x8b 0x15 0x02 0x60 0xcb 0x1c 0x00 0x17 0xaa 0x1b 0x03 0xf8 0x9e 0x67 >>> 0x00 0x0a >>> 0xd2 0x80 0x00 0x20 0xcb 0x1c 0x00 0x00 0xcb 0x01 0x02 0x81 0x9e 0x67 >>> 0x00 0x09 >>> 0x9e 0x67 0x00 0x2b 0x8b 0x14 0x03 0x16 0x8b 0x1a 0x03 0x20 0x52 0x80 >>> 0x00 0x01 > > The data appears to match, but the endian is different. > > Regards, > Jan > >>> >>> test child finished with -1 >>> end >>> Test object code reading: FAILED! >>> ## >>> >>> Seems the dso file format is different between x86 and ARM64. >>> Maybe this test case only works fine on x86. >>> -- >>> Regards >>> Kaixu Xia >>> >> > > . > -- Regards Kaixu Xia -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 55/58] mtd: nand: add helpers to access ->priv
Hi Brian,
On Fri, 18 Dec 2015 14:17:58 -0800
Brian Norris wrote:
> Hi Boris,
>
> On Thu, Dec 10, 2015 at 09:00:39AM +0100, Boris Brezillon wrote:
> > Add two helpers to access the field reserved for private controller data.
> > This makes it clearer what this field is reserved for and ease future
> > refactoring.
>
> I agree with the refactoring part, but I'm not sure about the name. Is
> it really "controller" data? That sounds like something that has 1
> instance per controller. But the way this is sometimes used, we get 1
> instance per NAND chip, and there may be more than one NAND chip per
> controller.
>
> So at the moment, this is more like opaque "driver data", like
> dev_{get,set}_drvdata(), which doesn't really have a prescribed use --
> it's up to the driver.
>
> Notably, we already have a (sort of) 1-per-controler-instance field:
> struct nand_hw_control (I notice we have both the 'controller' and
> 'hwcontrol' fields in nand_chip; that's pretty ugly too...).
Will be addressed soon ;-).
> Those don't
> have private data fields, but we could of course extend that if we
> really want "controller" data.
Actually the nand_{get,set}_controller_data() helpers are not about
assigning NAND controller private data (as you pointed those can
already be retrieved thanks to the ->controller field using the
container_of() trick), but per-chip private data instantiated by the
NAND controller and attached to a specific chip. For example, some
controllers pre-compute some register values or a clk rate to set when
a specific chip is selected. This is what per-chip controller data is
meant for.
Now, the reason I explicitly specified the data usage instead of using
a generic name like nand_{get,set}_data() is because I plan to define
other helpers to allow NAND manufacturer code to manipulate its own
private data. This is required if we want to support read-retry on some
chips who are requiring a read OTP area step to retrieve some register
values which will later be used to change from one read-retry mode to
another.
The plan was to define the nand_{set,get}_manufacturer_data() helpers,
and create or reuse an existing priv field (mtd->priv?) to store this
private data.
Also note that the spi framework provides the same kind of helpers [1].
This being said, I'm perfectly fine changing the function names, but
I'd like to replace it by something explicitly telling the user that
this field should only be set by NAND controller drivers.
[1]http://lxr.free-electrons.com/source/include/linux/spi/spi.h#L189
Best Regards,
Boris
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.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/
[linux-sunxi] [PATCH v7 2/2] sun4i-codec: Add FM, Line and Mic inputs
This is the second part, actually adding FM, Line and Mic inputs.
Signed-off-by: Danny Milosavljevic
---
b/sound/soc/sunxi/sun4i-codec.c | 182 +++-
1 file changed, 178 insertions(+), 4 deletions(-)
diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i-codec.c
index 6628e6e..9a9ad62 100644
--- a/sound/soc/sunxi/sun4i-codec.c
+++ b/sound/soc/sunxi/sun4i-codec.c
@@ -59,9 +59,20 @@
#define SUN4I_CODEC_DAC_ACTL_DACAENR (31)
#define SUN4I_CODEC_DAC_ACTL_DACAENL (30)
#define SUN4I_CODEC_DAC_ACTL_MIXEN (29)
+#define SUN4I_CODEC_DAC_ACTL_LNG (26)
+#define SUN4I_CODEC_DAC_ACTL_FMG (23)
+#define SUN4I_CODEC_DAC_ACTL_MICG (20)
+#define SUN4I_CODEC_DAC_ACTL_LLNS (19)
+#define SUN4I_CODEC_DAC_ACTL_RLNS (18)
+#define SUN4I_CODEC_DAC_ACTL_LFMS (17)
+#define SUN4I_CODEC_DAC_ACTL_RFMS (16)
#define SUN4I_CODEC_DAC_ACTL_LDACLMIXS (15)
#define SUN4I_CODEC_DAC_ACTL_RDACRMIXS (14)
#define SUN4I_CODEC_DAC_ACTL_LDACRMIXS (13)
+#define SUN4I_CODEC_DAC_ACTL_MIC1LS(12)
+#define SUN4I_CODEC_DAC_ACTL_MIC1RS(11)
+#define SUN4I_CODEC_DAC_ACTL_MIC2LS(10)
+#define SUN4I_CODEC_DAC_ACTL_MIC2RS(9)
#define SUN4I_CODEC_DAC_ACTL_DACPAS(8)
#define SUN4I_CODEC_DAC_ACTL_MIXPAS(7)
#define SUN4I_CODEC_DAC_ACTL_PA_MUTE (6)
@@ -87,8 +98,11 @@
#define SUN4I_CODEC_ADC_ACTL_PREG1EN (29)
#define SUN4I_CODEC_ADC_ACTL_PREG2EN (28)
#define SUN4I_CODEC_ADC_ACTL_VMICEN(27)
-#define SUN4I_CODEC_ADC_ACTL_VADCG (20)
+#define SUN4I_CODEC_ADC_ACTL_PREG1_A10 (25)
+#define SUN4I_CODEC_ADC_ACTL_PREG2_A10 (23)
+#define SUN4I_CODEC_ADC_ACTL_ADCG (20)
#define SUN4I_CODEC_ADC_ACTL_ADCIS (17)
+#define SUN4I_CODEC_ADC_ACTL_LNRDF (16)
#define SUN4I_CODEC_ADC_ACTL_PA_EN (4)
#define SUN4I_CODEC_ADC_ACTL_DDE (3)
#define SUN4I_CODEC_ADC_DEBUG (0x2c)
@@ -100,6 +114,16 @@
#define SUN7I_CODEC_AC_DAC_CAL (0x38)
#define SUN7I_CODEC_AC_MIC_PHONE_CAL (0x3c)
+#define SUN7I_CODEC_AC_MIC_PHONE_CAL_PREG1 (29)
+#define SUN7I_CODEC_AC_MIC_PHONE_CAL_PREG2 (26)
+/* note: no idea where the output pins for the following are. */
+#define SUN7I_CODEC_AC_MIC_PHONE_CAL_PHONEOUTG (5)
+#define SUN7I_CODEC_AC_MIC_PHONE_CAL_PHONEOUTEN (4)
+#define SUN7I_CODEC_AC_MIC_PHONE_CAL_PHONEOUTS3 (3)
+#define SUN7I_CODEC_AC_MIC_PHONE_CAL_PHONEOUTS2 (2)
+#define SUN7I_CODEC_AC_MIC_PHONE_CAL_PHONEOUTS1 (1)
+#define SUN7I_CODEC_AC_MIC_PHONE_CAL_PHONEOUTS0 (0)
+
struct sun4i_codec {
struct device *dev;
struct regmap *regmap;
@@ -509,19 +533,102 @@ static const struct snd_kcontrol_new sun4i_codec_pa_mute
=
SUN4I_CODEC_DAC_ACTL_PA_MUTE, 1, 0);
static DECLARE_TLV_DB_SCALE(sun4i_codec_pa_volume_scale, -6300, 100, 1);
+static DECLARE_TLV_DB_SCALE(sun4i_codec_linein_loopback_gain_scale,
+ -150,
+ 150,
+ 0);
+static DECLARE_TLV_DB_SCALE(sun4i_codec_fmin_loopback_gain_scale,
+ -450,
+ 150,
+ 0);
+static DECLARE_TLV_DB_SCALE(sun4i_codec_micin_loopback_gain_scale,
+ -450,
+ 150,
+ 0);
+static DECLARE_TLV_DB_RANGE(sun4i_codec_micin_preamp_gain_scale_a10,
+ 0, 0, TLV_DB_SCALE_ITEM(0, 0, 0),
+ 1, 7, TLV_DB_SCALE_ITEM(3500, 300, 0));
+static DECLARE_TLV_DB_SCALE(sun4i_codec_adc_gain_scale, -450, 150, 0);
+/* Sources:
+ * A10 User Manual v1.5 20130820
+ * A20 User Manual v1.4 20150510
+ */
+static const char * const sun4i_codec_capture_source[] = {
+ "Line-In",
+ "FM",
+ "Mic1",
+ "Mic2",
+ "Mic1,Mic2",
+ "Mic1+Mic2",
+ "Output Mixer",
+ "Line-In,Mic1",
+};
+static SOC_ENUM_SINGLE_DECL(sun4i_codec_enum_capture_source,
+ SUN4I_CODEC_ADC_ACTL,
+ SUN4I_CODEC_ADC_ACTL_ADCIS,
+ sun4i_codec_capture_source);
+
+static const struct snd_kcontrol_new sun4i_codec_capture_source_controls =
+ SOC_DAPM_ENUM("Route", sun4i_codec_enum_capture_source);
#define SUN4I_COMMON_CODEC_WIDGETS \
- SOC_SINGLE_TLV("Power Amplifier Volume", SUN4I_CODEC_DAC_ACTL,\
- SUN4I_CODEC_DAC_ACTL_PA_VOL, 0x3F, 0,\
-
[linux-sunxi] [PATCH v7 1/2] sun4i-codec: Add FM, Line and Mic inputs
This is the first part:
sun4i-codec: make it possible to use different codec_widgets for A10 and A20.
Signed-off-by: Danny Milosavljevic
---
b/sound/soc/sunxi/sun4i-codec.c | 45
++--
1 file changed, 34 insertions(+), 11 deletions(-)
diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i-codec.c
index e6cc6a1..6628e6e 100644
--- a/sound/soc/sunxi/sun4i-codec.c
+++ b/sound/soc/sunxi/sun4i-codec.c
@@ -96,8 +96,9 @@
/* Other various ADC registers */
#define SUN4I_CODEC_DAC_TXCNT (0x30)
#define SUN4I_CODEC_ADC_RXCNT (0x34)
-#define SUN4I_CODEC_AC_SYS_VERI(0x38)
-#define SUN4I_CODEC_AC_MIC_PHONE_CAL (0x3c)
+
+#define SUN7I_CODEC_AC_DAC_CAL (0x38)
+#define SUN7I_CODEC_AC_MIC_PHONE_CAL (0x3c)
struct sun4i_codec {
struct device *dev;
@@ -509,10 +510,13 @@ static const struct snd_kcontrol_new sun4i_codec_pa_mute =
static DECLARE_TLV_DB_SCALE(sun4i_codec_pa_volume_scale, -6300, 100, 1);
-static const struct snd_kcontrol_new sun4i_codec_widgets[] = {
- SOC_SINGLE_TLV("Power Amplifier Volume", SUN4I_CODEC_DAC_ACTL,
- SUN4I_CODEC_DAC_ACTL_PA_VOL, 0x3F, 0,
- sun4i_codec_pa_volume_scale),
+#define SUN4I_COMMON_CODEC_WIDGETS \
+ SOC_SINGLE_TLV("Power Amplifier Volume", SUN4I_CODEC_DAC_ACTL,\
+ SUN4I_CODEC_DAC_ACTL_PA_VOL, 0x3F, 0,\
+ sun4i_codec_pa_volume_scale)
+
+static const struct snd_kcontrol_new sun4i_codec_widgets_a10[] = {
+ SUN4I_COMMON_CODEC_WIDGETS,
};
static const struct snd_kcontrol_new sun4i_codec_left_mixer_controls[] = {
@@ -627,9 +631,9 @@ static const struct snd_soc_dapm_route
sun4i_codec_codec_dapm_routes[] = {
{ "Mic1", NULL, "VMIC" },
};
-static struct snd_soc_codec_driver sun4i_codec_codec = {
- .controls = sun4i_codec_widgets,
- .num_controls = ARRAY_SIZE(sun4i_codec_widgets),
+static struct snd_soc_codec_driver sun4i_codec_codec_a10 = {
+ .controls = sun4i_codec_widgets_a10,
+ .num_controls = ARRAY_SIZE(sun4i_codec_widgets_a10),
.dapm_widgets = sun4i_codec_codec_dapm_widgets,
.num_dapm_widgets = ARRAY_SIZE(sun4i_codec_codec_dapm_widgets),
.dapm_routes= sun4i_codec_codec_dapm_routes,
@@ -680,7 +684,7 @@ static const struct regmap_config sun4i_codec_regmap_config
= {
.reg_bits = 32,
.reg_stride = 4,
.val_bits = 32,
- .max_register = SUN4I_CODEC_AC_MIC_PHONE_CAL,
+ .max_register = SUN7I_CODEC_AC_MIC_PHONE_CAL,
};
static const struct of_device_id sun4i_codec_of_match[] = {
@@ -753,10 +757,24 @@ static struct snd_soc_card
*sun4i_codec_create_card(struct device *dev)
return card;
};
+static const struct snd_kcontrol_new sun7i_codec_widgets[] = {
+ SUN4I_COMMON_CODEC_WIDGETS,
+};
+
+static struct snd_soc_codec_driver sun7i_codec_codec = {
+ .controls = sun7i_codec_widgets,
+ .num_controls = ARRAY_SIZE(sun7i_codec_widgets),
+ .dapm_widgets = sun4i_codec_codec_dapm_widgets,
+ .num_dapm_widgets = ARRAY_SIZE(sun4i_codec_codec_dapm_widgets),
+ .dapm_routes= sun4i_codec_codec_dapm_routes,
+ .num_dapm_routes= ARRAY_SIZE(sun4i_codec_codec_dapm_routes),
+};
+
static int sun4i_codec_probe(struct platform_device *pdev)
{
struct snd_soc_card *card;
struct sun4i_codec *scodec;
+ struct snd_soc_codec_driver *codec;
struct resource *res;
void __iomem *base;
int ret;
@@ -819,7 +837,12 @@ static int sun4i_codec_probe(struct platform_device *pdev)
scodec->capture_dma_data.maxburst = 4;
scodec->capture_dma_data.addr_width = DMA_SLAVE_BUSWIDTH_2_BYTES;
- ret = snd_soc_register_codec(>dev, _codec_codec,
+ if (of_device_is_compatible(pdev->dev.of_node,
+ "allwinner,sun7i-a20-codec"))
+ codec = _codec_codec;
+ else
+ codec = _codec_codec_a10;
+ ret = snd_soc_register_codec(>dev, codec,
_codec_dai, 1);
if (ret) {
dev_err(>dev, "Failed to register our codec\n");
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ceph: Avoid to propagate the invalid page point
The variant pagep will still get the invalid page point, although ceph
fails in function ceph_update_writeable_page.
To fix this issue, Assigne the page to pagep until there is no failure
in function ceph_update_writeable_page.
Signed-off-by: Minfei Huang
---
fs/ceph/addr.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/fs/ceph/addr.c b/fs/ceph/addr.c
index b7d218a..6491079 100644
--- a/fs/ceph/addr.c
+++ b/fs/ceph/addr.c
@@ -1149,7 +1149,6 @@ static int ceph_write_begin(struct file *file, struct
address_space *mapping,
page = grab_cache_page_write_begin(mapping, index, 0);
if (!page)
return -ENOMEM;
- *pagep = page;
dout("write_begin file %p inode %p page %p %d~%d\n", file,
inode, page, (int)pos, (int)len);
--
2.6.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v7 0/2] sun4i-codec: Add FM, Line and Mic inputs
Hi, this is the seventh version of the patch set that adds inputs to sun4i-codec. Changes compared to v6 are: - preparation for different A20, A10 controls is now in an extra patch. - all register definitions are now at the top - sun7i-specific things (A20-specific things) are now less grouped-together. The patches are on top of the branch "sunxi-next" in . Regards, Danny --- Danny Milosavljevic (2): sun4i-codec: Add FM, Line and Mic inputs sun4i-codec: make it possible to use different codec_widgets for A10 and A20. sound/soc/sunxi/sun4i-codec.c | 223 +--- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] rhashtable: Kill harmless RCU warning in rhashtable_walk_init
On Fri, Dec 18, 2015 at 04:27:31PM -0500, David Miller wrote:
> From: Herbert Xu
> Date: Fri, 18 Dec 2015 21:14:08 +0800
>
> > On Fri, Dec 18, 2015 at 04:54:14AM -0800, Eric Dumazet wrote:
> >>
> >> You can avoid the comment by using the self documented and lockdep
> >> enabled primitive
> >>
> >> iter->walker->tbl = rcu_dereference_protected(ht->tbl,
> >> lockdep_is_held(>lock));
> >
> > That is just gross. I think a comment is much better in this case.
>
> Herbert, this macro was created exactly to handle this situation,
> and this is what we do everywhere else in the tree.
OK.
---8<---
The commit f9f51b8070be3e829100614a7372b219723b864f ("rhashtable:
Fix walker list corruption") causes a suspicious RCU usage warning
because we no longer hold ht->mutex when we dereference ht->tbl.
However, this is a false positive because we now hold ht->lock
which also guarantees that ht->tbl won't disppear from under us.
This patch kills the warning by using rcu_dereference_protected.
Reported-by: kernel test robot
Signed-off-by: Herbert Xu
diff --git a/lib/rhashtable.c b/lib/rhashtable.c
index eb9240c..51282f5 100644
--- a/lib/rhashtable.c
+++ b/lib/rhashtable.c
@@ -519,7 +519,8 @@ int rhashtable_walk_init(struct rhashtable *ht, struct
rhashtable_iter *iter)
return -ENOMEM;
spin_lock(>lock);
- iter->walker->tbl = rht_dereference(ht->tbl, ht);
+ iter->walker->tbl =
+ rcu_dereference_protected(ht->tbl, lockdep_is_held(>lock));
list_add(>walker->list, >walker->tbl->walkers);
spin_unlock(>lock);
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] natsemi: add checks for dma mapping errors
From: Alexey Khoroshilov
Date: Sat, 19 Dec 2015 00:55:37 +0300
> @@ -2093,6 +2099,10 @@ static netdev_tx_t start_tx(struct sk_buff *skb,
> struct net_device *dev)
> np->tx_skbuff[entry] = skb;
> np->tx_dma[entry] = pci_map_single(np->pci_dev,
> skb->data,skb->len, PCI_DMA_TODEVICE);
> + if (pci_dma_mapping_error(np->pci_dev, np->tx_dma[entry])) {
> + np->tx_skbuff[entry] = NULL;
> + return NETDEV_TX_BUSY;
> + }
>
> np->tx_ring[entry].addr = cpu_to_le32(np->tx_dma[entry]);
>
Returning NETDEV_TX_BUSY and freeing the SKB will crash the system.
NETDEV_TX_BUSY is only for buggy drivers that do not manage their
TX ring busy condition correctly, and thus need retries.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
On Sat, Dec 19, 2015 at 1:16 AM, Måns Rullgård wrote: > Julian Margetson writes: > >> On 12/18/2015 6:33 PM, Måns Rullgård wrote: >>> Julian Margetson writes: >>> On 12/18/2015 1:18 PM, Måns Rullgård wrote: > Julian Margetson writes: > >> On 12/18/2015 8:49 AM, Måns Rullgård wrote: >>> Andy Shevchenko writes: >>> >> [5.206125] Unable to handle kernel paging request for data at >> address 0x >> [5.228546] Faulting instruction address: 0xc043a2c8 >> [5.248577] Vector: 300 (Data Access) at [eddafae0] >> [5.268658] pc: c043a2c8: sata_dwc_qc_issue+0xb8/0x204 > Well, that's not good. Can you translate that address to a line of > code? Besides that, can you enable DYNAMIC_DEBUG in the config and append 'dw_dmac_core.dyndbg dw_dmac.dyndbg' to the kernel cmdline? >>> Enabling debug messages in the sata_dwc driver might also be >>> informative. >>> >> Changed the sata-dwc to a module . >> >> [ 18.475140] sata-dwc 4bffd1000.sata: sata_dwc_qc_prep_by_tag: >> dma_dwc_xfer_setup returns NULL >> [ 18.535698] sata-dwc 4bffd1000.sata: sata_dwc_qc_prep_by_tag: >> dma_dwc_xfer_setup returns NULL > That's strange. The only way that can happen is if > dmaengine_prep_slave_sg() return NULL, and that really shouldn't be > happening. Did you turn on debug messages in dw_dma? You can enable > some extra debug messages by adding "#define VERBOSE_DEBUG" at the top > of drivers/dma/dw/core.c > [ 17.526173] sata-dwc 4bffd1000.sata: sata_dwc_qc_prep_by_tag: dma_dwc_xfer_setup returns NULL [ 17.600124] sata-dwc 4bffd1000.sata: sata_dwc_qc_prep_by_tag: dma_dwc_xfer_setup returns NULL [ 17.662978] sata-dwc 4bffd1000.sata: sata_dwc_qc_prep_by_tag: dma_dwc_xfer_setup returns NULL >>> Could you post the entire kernel log? There might be important >>> information before the errors start. >>> >> >> >> =~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2015.12.18 15:01:48 =~=~=~=~=~=~=~=~=~=~=~= >> [0.00] Using Canyonlands machine description >> [0.00] Initializing cgroup subsys cpu >> [0.00] Linux version 4.4.0-rc5-Sam460ex (root@julian-VirtualBox) >> (gcc version 4.8.2 (Ubuntu 4.8.2-16ubuntu3) ) #8 PREEMPT Fri Dec 18 13:36:34 >> AST 2015 >> [0.00] Zone ranges: >> [0.00] DMA [mem 0x-0x2fff] >> [0.00] Normal empty >> [0.00] HighMem [mem 0x3000-0x7fff] >> [0.00] Movable zone start for each node >> [0.00] Early memory node ranges >> [0.00] node 0: [mem 0x-0x7fff] >> [0.00] Initmem setup node 0 [mem >> 0x-0x7fff] >> [0.00] MMU: Allocated 1088 bytes of context maps for 255 contexts >> [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total >> pages: 522752 >> [0.00] Kernel command line: root=/dev/sda8 console=ttyS0,115200 >> console=tty0 dw_dmac_core.dyndbg dw_dmac.dyndbg I would suggest to use console=tty1 instead of console=tty0. > > [...] > >> [ 13.643415] systemd[1]: Mounted Configuration File System. >> [ 17.526173] sata-dwc 4bffd1000.sata: sata_dwc_qc_prep_by_tag: >> dma_dwc_xfer_setup returns NULL >> [ 17.600124] sata-dwc 4bffd1000.sata: sata_dwc_qc_prep_by_tag: >> dma_dwc_xfer_setup returns NULL >> [ 17.662978] sata-dwc 4bffd1000.sata: sata_dwc_qc_prep_by_tag: >> dma_dwc_xfer_setup returns NULL > > This log is weird. The sata_dwc_probe() function prints several things > (one using dev_notice()), for instance this: > > /* Read the ID and Version Registers */ > idr = in_le32(>sata_dwc_regs->idr); > versionr = in_le32(>sata_dwc_regs->versionr); > dev_notice(>dev, "id %d, controller version %c.%c%c\n", >idr, ver[0], ver[1], ver[2]); > > The dw_dma_probe() function also prints a line: > > dev_info(chip->dev, "DesignWare DMA Controller, %d channels\n", > pdata->nr_channels); > > These messages are nowhere to be seen in your log, nor are numerous > others that really must appear before before sata_dwc_qc_prep_by_tag() > can be called. > It would be better to add 'ignore_loglevel' to the cmdline as well. > I'd like to note that the driver works on my Sigma Designs based system > using a different DMA controller, so it's not completely broken. The > DMA driver could still be faulty, but that still doesn't explain the > missing kernel messages. > > -- > Måns Rullgård > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- With Best Regards, Andy Shevchenko -- To unsubscribe from
Re: ahash alg that does not implement import/export failed to register
On Fri, Dec 18, 2015 at 05:31:34PM -0800, Tim Chen wrote: > Herbert, > > There are some ahash algorithms like x86's sha1-mb and > ghash that failed to register because of the newly added > check of non-zero statesize from commit 8996eafd. But > since there are algorithms that do not implement an import or > export, there is no state required for them. Wonder if the check > should be modified to something like: No import and export are required by algif_hash so they must be implemented. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] scsi: storvsc: Tighten up the interrupt path
> -Original Message-
> From: James Bottomley [mailto:james.bottom...@hansenpartnership.com]
> Sent: Friday, December 18, 2015 8:48 AM
> To: KY Srinivasan ; Hannes Reinecke ;
> gre...@linuxfoundation.org; linux-kernel@vger.kernel.org;
> de...@linuxdriverproject.org; oher...@suse.com;
> jbottom...@parallels.com; h...@infradead.org; linux-s...@vger.kernel.org;
> a...@canonical.com; vkuzn...@redhat.com; jasow...@redhat.com;
> martin.peter...@oracle.com
> Subject: Re: [PATCH V3 4/4] scsi: storvsc: Tighten up the interrupt path
>
> On Fri, 2015-12-18 at 16:20 +, KY Srinivasan wrote:
> >
> > > -Original Message-
> > > From: Hannes Reinecke [mailto:h...@suse.de]
> > > Sent: Friday, December 18, 2015 12:52 AM
> > > To: KY Srinivasan ; gre...@linuxfoundation.org;
> > > linux-
> > > ker...@vger.kernel.org; de...@linuxdriverproject.org;
> > > oher...@suse.com;
> > > jbottom...@parallels.com; h...@infradead.org;
> > > linux-s...@vger.kernel.org;
> > > a...@canonical.com; vkuzn...@redhat.com; jasow...@redhat.com;
> > > martin.peter...@oracle.com
> > > Subject: Re: [PATCH V3 4/4] scsi: storvsc: Tighten up the interrupt
> > > path
> > >
> > > On 12/13/2015 09:28 PM, K. Y. Srinivasan wrote:
> > > > On the interrupt path, we repeatedly establish the pointer to the
> > > > storvsc_device. Fix this.
> > > >
> > > > Signed-off-by: K. Y. Srinivasan
> > > > Reviewed-by: Long Li
> > > > Reviewed-by: Johannes Thumshirn
> > > > Tested-by: Alex Ng
> > > > ---
> > > > drivers/scsi/storvsc_drv.c | 23 ---
> > > > 1 files changed, 8 insertions(+), 15 deletions(-)
> > > >
> > > > diff --git a/drivers/scsi/storvsc_drv.c
> > > > b/drivers/scsi/storvsc_drv.c
> > > > index d6ca4f2..b68aebe 100644
> > > > --- a/drivers/scsi/storvsc_drv.c
> > > > +++ b/drivers/scsi/storvsc_drv.c
> > > > @@ -945,19 +945,16 @@ static void storvsc_handle_error(struct
> > > vmscsi_request *vm_srb,
> > > > }
> > > >
> > > >
> > > > -static void storvsc_command_completion(struct
> > > > storvsc_cmd_request
> > > *cmd_request)
> > > > +static void storvsc_command_completion(struct
> > > > storvsc_cmd_request
> > > *cmd_request,
> > > > + struct storvsc_device
> > > > *stor_dev)
> > > > {
> > > > struct scsi_cmnd *scmnd = cmd_request->cmd;
> > > > - struct hv_host_device *host_dev = shost_priv(scmnd
> > > > ->device-
> > > > host);
> > > > struct scsi_sense_hdr sense_hdr;
> > > > struct vmscsi_request *vm_srb;
> > > > struct Scsi_Host *host;
> > > > - struct storvsc_device *stor_dev;
> > > > - struct hv_device *dev = host_dev->dev;
> > > > u32 payload_sz = cmd_request->payload_sz;
> > > > void *payload = cmd_request->payload;
> > > >
> > > > - stor_dev = get_in_stor_device(dev);
> > > > host = stor_dev->host;
> > > >
> > > > vm_srb = _request->vstor_packet.vm_srb;
> > > > @@ -987,14 +984,13 @@ static void
> > > > storvsc_command_completion(struct
> > > storvsc_cmd_request *cmd_request)
> > > > kfree(payload);
> > > > }
> > > >
> > > > -static void storvsc_on_io_completion(struct hv_device *device,
> > > > +static void storvsc_on_io_completion(struct storvsc_device
> > > > *stor_device,
> > > > struct vstor_packet
> > > > *vstor_packet,
> > > > struct storvsc_cmd_request
> > > > *request)
> > > > {
> > > > - struct storvsc_device *stor_device;
> > > > struct vstor_packet *stor_pkt;
> > > > + struct hv_device *device = stor_device->device;
> > > >
> > > > - stor_device = hv_get_drvdata(device);
> > > > stor_pkt = >vstor_packet;
> > > >
> > > > /*
> > > > @@ -1049,7 +1045,7 @@ static void storvsc_on_io_completion(struct
> > > hv_device *device,
> > > > stor_pkt->vm_srb.data_transfer_length =
> > > > vstor_packet->vm_srb.data_transfer_length;
> > > >
> > > > - storvsc_command_completion(request);
> > > > + storvsc_command_completion(request, stor_device);
> > > >
> > > > if (atomic_dec_and_test(_device
> > > > ->num_outstanding_req) &&
> > > > stor_device->drain_notify)
> > > > @@ -1058,21 +1054,19 @@ static void
> > > > storvsc_on_io_completion(struct
> > > hv_device *device,
> > > >
> > > > }
> > > >
> > > > -static void storvsc_on_receive(struct hv_device *device,
> > > > +static void storvsc_on_receive(struct storvsc_device
> > > > *stor_device,
> > > > struct vstor_packet *vstor_packet,
> > > > struct storvsc_cmd_request
> > > > *request)
> > > > {
> > > > struct storvsc_scan_work *work;
> > > > - struct storvsc_device *stor_device;
> > > >
> > > > switch (vstor_packet->operation) {
> > > > case VSTOR_OPERATION_COMPLETE_IO:
> > > > - storvsc_on_io_completion(device, vstor_packet,
> > > > request);
> > > >
Re: Indent issus in kernel module development
On 12/18/15 18:07, chunguang qu wrote: > `indent -linux` sometimes made my code totally a mess. > I know it most likely a bug of GNU INDENT. And this is not a bug report. > I only want to know other kernel developers how to deal with this problem. > Since GUN INDENT is recommend in kernel's CodingStyle, I think surely > someone here encounter this problem either. Huh? CodingStyle says: Now, again, GNU indent has the same brain-dead settings that GNU emacs has, which is why you need to give it a few command line options. It also says try using scripts/Lindent. Have you tried it? It won't be perfect either, AFAI recall, but it might help. or you could try emacs (as indicated in CodingStyle). Good luck with that. > CMD > LANG=C indent -linux > > FROM > http://paste.ubuntu.com/14093393/ > > TO > http://paste.ubuntu.com/14093405/ > > Thanks. -- ~Randy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] mtd: sh_flctl: pass FIFO as physical address
On Tue, Dec 08, 2015 at 04:38:12PM +0100, Arnd Bergmann wrote: > By convention, the FIFO address we pass using dmaengine_slave_config > is a physical address in the form that is understood by the DMA > engine, as a dma_addr_t, phys_addr_t or resource_size_t. > > The sh_flctl driver however passes a virtual __iomem address that > gets cast to dma_addr_t in the slave driver. This happens to work > on shmobile because that platform sets up an identity mapping for > its MMIO regions, but such code is not portable to other platforms, > and prevents us from ever changing the platform mapping or reusing > the driver on other architectures like ARM64 that might not have the > mapping. > > We also get a warning about a type mismatch for the case that > dma_addr_t is wider than a pointer, i.e. when CONFIG_LPAE is set: > > drivers/mtd/nand/sh_flctl.c: In function 'flctl_setup_dma': > drivers/mtd/nand/sh_flctl.c:163:17: warning: cast from pointer to integer of > different size [-Wpointer-to-int-cast] > cfg.dst_addr = (dma_addr_t)FLDTFIFO(flctl); > > This changes the driver to instead pass the physical address of > the FIFO that is extracted from the MMIO resource, making the > code more portable and avoiding the warning. > > Signed-off-by: Arnd Bergmann Applied -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] mtd: denali: make MTD_NAND_DENALI_DT dependent on OF
On Wed, Dec 16, 2015 at 02:00:09PM +0900, Masahiro Yamada wrote: > The build passes even if CONFIG_OF is undefined, but it makes sense > to let it depend on OF. > > Signed-off-by: Masahiro Yamada Applied to l2-mtd.git -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 20/43] MAINTAINERS: add git URL for KVM/s390
On Fri, Dec 18, 2015 at 01:42:09PM +0100, Cornelia Huck wrote: > On Fri, 18 Dec 2015 20:32:15 +0800 > Fengguang Wu wrote: > > > Thanks! The background is, the 0day patch test script relies on the > > information in MAINTAINERS to decide which tree it can apply the LKML > > patches to. So I need to add some missing git URLs to the MAINTAINERS > > file. > > Don't you also need the branch the patches should apply against, or am > I misunderstanding what you're trying to do? Yes one option is to append the branch name in MAINTAINERS like this: +T: git git://git.kernel.org/pub/scm/linux/kernel/git/kvms390/linux.git next The other option is to get the branch name from linux-next, whose Next/Trees file contains this line: kvms390 git git://git.kernel.org/pub/scm/linux/kernel/git/kvms390/linux.git#next Then the robot knows patches should be applied to the 'next' branch. So for most trees, there is no need to specify the branch name in the MAINTAINERS file. Not only it's not necessary, but also helps avoid double configuration. Thanks, Fengguang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 18/43] MAINTAINERS: add kdbus
On Fri, Dec 18, 2015 at 07:33:36AM -0800, Greg KH wrote: > On Fri, Dec 18, 2015 at 03:51:41PM +0800, Fengguang Wu wrote: > > CC: Greg Kroah-Hartman > > Signed-off-by: Fengguang Wu > > --- > > MAINTAINERS | 10 ++ > > 1 file changed, 10 insertions(+) > > > > --- linux.orig/MAINTAINERS 2015-12-18 15:43:28.229016896 +0800 > > +++ linux/MAINTAINERS 2015-12-18 15:43:28.229016896 +0800 > > @@ -6005,6 +6005,16 @@ S: Maintained > > F: Documentation/kbuild/kconfig-language.txt > > F: scripts/kconfig/ > > > > +KDBUS > > +M: Greg Kroah-Hartman > > +T: git git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git > > kdbus > > +S: Supported > > +F: ipc/kdbus/ > > +F: Documentation/kdbus/ > > +F: samples/kdbus/ > > +F: tools/testing/selftests/kdbus/ > > +F: include/uapi/linux/kdbus.h > > What is this patch for? I didn't send this or create this entry, why > did you? Greg, that is necessary for the 0day email testing feature. After adding the above information, when someone posted patch modifying the listed kdbus files, the robot will know to apply the patch to your char-misc/kdbus branch for testing. Thanks, Fengguang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] SCSI fixes for 4.4-rc5
Three fixes this time, two in SES picked up by KASAN for various types
of buffer overrun. The first is a USB array which returns page 8
whatever is asked for and causes us to overrun with incorrect data
format assumptions and the second is an invalid iteration of page 10
(the additional information page). The final one is a reversion of a
NULL deref fix which caused suspend/resume not to be called in pairs
leading to incorrect device operation (Jens has queued a more proper
fix for the problem in block).
The patch is available here:
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-fixes
The short changelog is:
James Bottomley (2):
ses: fix additional element traversal bug
ses: Fix problems with simple enclosures
Ken Xue (1):
Revert "SCSI: Fix NULL pointer dereference in runtime PM"
With the diffstat:
drivers/scsi/scsi_pm.c| 20 ++--
drivers/scsi/ses.c| 30 --
include/linux/enclosure.h | 4
3 files changed, 42 insertions(+), 12 deletions(-)
And full diffs below.
James
---
diff --git a/drivers/scsi/ses.c b/drivers/scsi/ses.c
index dcb0d76..044d064 100644
--- a/drivers/scsi/ses.c
+++ b/drivers/scsi/ses.c
@@ -84,6 +84,7 @@ static void init_device_slot_control(unsigned char *dest_desc,
static int ses_recv_diag(struct scsi_device *sdev, int page_code,
void *buf, int bufflen)
{
+ int ret;
unsigned char cmd[] = {
RECEIVE_DIAGNOSTIC,
1, /* Set PCV bit */
@@ -92,9 +93,26 @@ static int ses_recv_diag(struct scsi_device *sdev, int
page_code,
bufflen & 0xff,
0
};
+ unsigned char recv_page_code;
- return scsi_execute_req(sdev, cmd, DMA_FROM_DEVICE, buf, bufflen,
+ ret = scsi_execute_req(sdev, cmd, DMA_FROM_DEVICE, buf, bufflen,
NULL, SES_TIMEOUT, SES_RETRIES, NULL);
+ if (unlikely(!ret))
+ return ret;
+
+ recv_page_code = ((unsigned char *)buf)[0];
+
+ if (likely(recv_page_code == page_code))
+ return ret;
+
+ /* successful diagnostic but wrong page code. This happens to some
+* USB devices, just print a message and pretend there was an error */
+
+ sdev_printk(KERN_ERR, sdev,
+ "Wrong diagnostic page; asked for %d got %u\n",
+ page_code, recv_page_code);
+
+ return -EINVAL;
}
static int ses_send_diag(struct scsi_device *sdev, int page_code,
@@ -541,7 +559,15 @@ static void ses_enclosure_data_process(struct
enclosure_device *edev,
if (desc_ptr)
desc_ptr += len;
- if (addl_desc_ptr)
+ if (addl_desc_ptr &&
+ /* only find additional descriptions for specific
devices */
+ (type_ptr[0] == ENCLOSURE_COMPONENT_DEVICE ||
+type_ptr[0] == ENCLOSURE_COMPONENT_ARRAY_DEVICE ||
+type_ptr[0] == ENCLOSURE_COMPONENT_SAS_EXPANDER ||
+/* these elements are optional */
+type_ptr[0] ==
ENCLOSURE_COMPONENT_SCSI_TARGET_PORT ||
+type_ptr[0] ==
ENCLOSURE_COMPONENT_SCSI_INITIATOR_PORT ||
+type_ptr[0] ==
ENCLOSURE_COMPONENT_CONTROLLER_ELECTRONICS))
addl_desc_ptr += addl_desc_ptr[1] + 2;
}
diff --git a/include/linux/enclosure.h b/include/linux/enclosure.h
index 7be22da..a4cf57c 100644
--- a/include/linux/enclosure.h
+++ b/include/linux/enclosure.h
@@ -29,7 +29,11 @@
/* A few generic types ... taken from ses-2 */
enum enclosure_component_type {
ENCLOSURE_COMPONENT_DEVICE = 0x01,
+ ENCLOSURE_COMPONENT_CONTROLLER_ELECTRONICS = 0x07,
+ ENCLOSURE_COMPONENT_SCSI_TARGET_PORT = 0x14,
+ ENCLOSURE_COMPONENT_SCSI_INITIATOR_PORT = 0x15,
ENCLOSURE_COMPONENT_ARRAY_DEVICE = 0x17,
+ ENCLOSURE_COMPONENT_SAS_EXPANDER = 0x18,
};
/* ses-2 common element status */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Indent issus in kernel module development
`indent -linux` sometimes made my code totally a mess. I know it most likely a bug of GNU INDENT. And this is not a bug report. I only want to know other kernel developers how to deal with this problem. Since GUN INDENT is recommend in kernel's CodingStyle, I think surely someone here encounter this problem either. CMD LANG=C indent -linux FROM http://paste.ubuntu.com/14093393/ TO http://paste.ubuntu.com/14093405/ Thanks. -- [Kevin Q (ChunGuang Qu)](mailto:quchungu...@gmail.com) [public key](http://pgp.mit.edu:11371/pks/lookup?op=get=0x5B06DCA77BEF043B) @sdu.edu.cn @gnu.org @mit.edu -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] blackfin-cpufreq: Change return type of cpu_set_cclk() to that of clk_set_rate()
On 18-12-15, 20:07, SF Markus Elfring wrote:
> From: Markus Elfring
> Date: Fri, 18 Dec 2015 19:43:27 +0100
>
> The return type "unsigned long" was used by the cpu_set_cclk() function
> while the type "int" is provided by the clk_set_rate() function.
> Let us make this usage consistent.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus Elfring
> ---
> drivers/cpufreq/blackfin-cpufreq.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/cpufreq/blackfin-cpufreq.c
> b/drivers/cpufreq/blackfin-cpufreq.c
> index a9f8e5b..2a6f3ac 100644
> --- a/drivers/cpufreq/blackfin-cpufreq.c
> +++ b/drivers/cpufreq/blackfin-cpufreq.c
> @@ -112,7 +112,7 @@ static unsigned int bfin_getfreq_khz(unsigned int cpu)
> }
>
> #ifdef CONFIG_BF60x
> -unsigned long cpu_set_cclk(int cpu, unsigned long new)
> +int cpu_set_cclk(int cpu, unsigned long new)
> {
> struct clk *clk;
Acked-by: Viresh Kumar
--
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/2] Input: uinput: Sanity check on ff_effects_max and EV_FF
On Sun, Nov 08, 2015 at 06:37:34PM +0100, Elias Vanderstuyft wrote:
> Currently the user can set ff_effects_max to zero with the EV_FF bit
> (and the FF_GAIN and/or FF_AUTOCENTER bits) set,
> in this case the uninitialized methods
> ff->set_gain and/or ff->set_autocenter can be dereferenced,
> resulting in a kernel oops.
>
> Check in uinput_create_device() and
> print a helpful message and return -EINVAL in case the check fails.
>
> Signed-off-by: Elias Vanderstuyft
Applied, thank you.
> ---
> Changes in v2:
> - Rebase on pending patches from David Herrmann and Benjamin Tissoires:
> - v3 Input: uinput - add new UINPUT_DEV_SETUP and UI_ABS_SETUP ioctl
> - Input: uinput - rework ABS validation
> - Don't require EV_FF bit to be set when ff_effects_max is non-zero
> - Move check from uinput_setup_device() to uinput_create_device()
> - Update commit description
>
> At the same time, the new UINPUT_DEV_SETUP and UI_ABS_SETUP ioctls were
> tested as well (in both orders).
> The legacy write() (instead of UINPUT_DEV_SETUP) was also tested.
>
> drivers/input/misc/uinput.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/input/misc/uinput.c b/drivers/input/misc/uinput.c
> index 1d93037..b9d0713 100644
> --- a/drivers/input/misc/uinput.c
> +++ b/drivers/input/misc/uinput.c
> @@ -272,6 +272,13 @@ static int uinput_create_device(struct uinput_device
> *udev)
> input_set_events_per_packet(dev, 60);
> }
>
> + if (test_bit(EV_FF, dev->evbit) && !udev->ff_effects_max) {
> + printk(KERN_DEBUG "%s: ff_effects_max should be non-zero when
> FF_BIT is set\n",
> + UINPUT_NAME);
> + error = -EINVAL;
> + goto fail1;
> + }
> +
> if (udev->ff_effects_max) {
> error = input_ff_create(dev, udev->ff_effects_max);
> if (error)
> --
> 1.9.3
>
--
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 v3] Input: uinput - add new UINPUT_DEV_SETUP and UI_ABS_SETUP ioctl
On Wed, Oct 28, 2015 at 11:10:06AM -0400, Benjamin Tissoires wrote:
> Hi,
>
> On Oct 25 2015 or thereabouts, David Herrmann wrote:
> > Hi
> >
> > On Sun, Oct 25, 2015 at 12:53 AM, Dmitry Torokhov
> > wrote:
> > > Hi Benjamin,
> > >
> > > On Tue, Aug 25, 2015 at 11:12:59AM -0400, Benjamin Tissoires wrote:
> > >> +static int uinput_abs_setup(struct uinput_device *udev,
> > >> + struct uinput_setup __user *arg, size_t size)
> > >> +{
> > >> + struct uinput_abs_setup setup = {};
> > >> + struct input_dev *dev;
> > >> +
> > >> + if (size > sizeof(setup))
> > >> + return -E2BIG;
> > >> + if (udev->state == UIST_CREATED)
> > >> + return -EINVAL;
> > >> + if (copy_from_user(, arg, size))
> > >> + return -EFAULT;
> > >> + if (setup.code > ABS_MAX)
> > >> + return -ERANGE;
> > >> +
> > >> + dev = udev->dev;
> > >> +
> > >> + input_alloc_absinfo(dev);
> > >> + if (!dev->absinfo)
> > >> + return -ENOMEM;
> > >> +
> > >> + set_bit(setup.code, dev->absbit);
> > >> + dev->absinfo[setup.code] = setup.absinfo;
> > >> +
> > >> + /*
> > >> + * We restore the state to UIST_NEW_DEVICE because the user has to
> > >> call
> > >> + * UI_DEV_SETUP in the last place before UI_DEV_CREATE to check the
> > >> + * validity of the absbits.
> > >> + */
> > >
> > > Do we have to be this strict? It seems to me that with the new IOCTLs
> > > you naturally want to use the new ioctl to setup the device, then adjust
> > > various axes and bits and then validate everything.
> >
> > Indeed, we now force the order to be abs-setup first, then
> > device-setup as last step. Appended is a follow-up patch to cleanup
> > ABS handling in uinput. It is untested. Benjamin, care to give it a
> > spin?
> >
>
> Sorry it took so long for the tests/review.
>
> So the test part is fine. It works as expected. (Tested-by: BT
> )
>
> For the review part, everything looks good except that now the doc for
> UI_ABS_SETUP in uapi/linux/uinput.h should be changed to reflect the
> fact that UI_DEV_SETUP is not a pre-requirement before calling
> UI_ABS_SETUP.
>
> With the doc change, the patch is also Reviewed-by: me.
OK, I applied the original and also adjusted the docs and applied this
one as a separate patch.
Thanks.
--
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] HID: Use multitouch driver for Type Covers
No, it doesn't work. On 12/19/2015 12:06 AM, Bastien Nocera wrote: > On Mon, 2015-12-14 at 21:50 +0900, Akihiko Odaki wrote: >> Use multitouch driver instead of microsoft one for Microsoft Surface >> Type Covers. >> >> By using MT_CLS_EXPORT_ALL_INPUTS, the keyboards function as well as >> the multitouch pads do. >> >> Signed-off-by: Akihiko Odaki > > All the multimedia keys work, and MT support also works, on my Surface > 3 cover (045e:07de). > > *But* the Caps-Lock key's LED doesn't light up anymore. Can you verify > it does on yours as well? > > Cheers > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
ahash alg that does not implement import/export failed to register
Herbert, There are some ahash algorithms like x86's sha1-mb and ghash that failed to register because of the newly added check of non-zero statesize from commit 8996eafd. But since there are algorithms that do not implement an import or export, there is no state required for them. Wonder if the check should be modified to something like: diff --git a/crypto/ahash.c b/crypto/ahash.c index 9c1dc8d..f512183 100644 --- a/crypto/ahash.c +++ b/crypto/ahash.c @@ -544,7 +544,10 @@ static int ahash_prepare_alg(struct ahash_alg *alg) struct crypto_alg *base = >halg.base; if (alg->halg.digestsize > PAGE_SIZE / 8 || - alg->halg.statesize > PAGE_SIZE / 8 || + alg->halg.statesize > PAGE_SIZE / 8) + return -EINVAL; + + if ((alg->import || alg->export) && alg->halg.statesize == 0) return -EINVAL; Thanks. Tim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
net, ipv6: out of bounds access in secret_stable
Hi Hannes,
I've hit the following out of bounds access while fuzzing on the latest -next
kernel.
This code was added in 3d1bec9932 ("ipv6: introduce secret_stable to
ipv6_devconf").
[ 459.553655] BUG: KASAN: stack-out-of-bounds in strlen+0x58/0x90 at addr
8802ab0efb0e
[ 459.554953] Read of size 1 by task trinity-c91/22576
[ 459.555805] page:ea000aac3bc0 count:0 mapcount:0 mapping:
(null) index:0x0
[ 459.556899] flags: 0x26f8000()
[ 459.557521] page dumped because: kasan: bad access detected
[ 459.558320] CPU: 7 PID: 22576 Comm: trinity-c91 Not tainted
4.4.0-rc5-next-20151218-sasha-00021-gaba8d84-dirty #2750
[ 459.559809] 549d0aa3 8802ab0ef860
a1042384
[ 459.561036] 41b58ab3 ac667cdb a10422d9
8802ab0ef848
[ 459.562245] 9f6a417e 549d0aa3 8802ab0efb0e
8802ab0efb0e
[ 459.563429] Call Trace:
[ 459.563831] dump_stack (lib/dump_stack.c:52)
[ 459.564623] ? _atomic_dec_and_lock (lib/dump_stack.c:27)
[ 459.565628] ? __dump_page (mm/debug.c:126)
[ 459.566538] kasan_report_error (include/linux/kasan.h:28
mm/kasan/report.c:170 mm/kasan/report.c:237)
[ 459.570997] __asan_report_load1_noabort (mm/kasan/report.c:277)
[ 459.572119] ? check_preemption_disabled (lib/smp_processor_id.c:39)
[ 459.573731] ? strlen (lib/string.c:481 (discriminator 1))
[ 459.574646] strlen (lib/string.c:481 (discriminator 1))
[ 459.575485] proc_dostring (kernel/sysctl.c:1825 kernel/sysctl.c:1906)
[ 459.576445] ? alloc_debug_processing (mm/slub.c:1054)
[ 459.577523] addrconf_sysctl_stable_secret (net/ipv6/addrconf.c:5395)
[ 459.583431] proc_sys_call_handler (fs/proc/proc_sysctl.c:543)
[ 459.587326] proc_sys_write (fs/proc/proc_sysctl.c:562)
[ 459.588378] do_loop_readv_writev (fs/read_write.c:725)
[ 459.589374] do_readv_writev (fs/read_write.c:853)
[ 459.601113] vfs_writev (fs/read_write.c:891)
[ 459.601895] ? __fdget_pos (fs/file.c:781)
[ 459.602918] SyS_writev (fs/read_write.c:924 fs/read_write.c:915)
[ 459.604122] ? SyS_readv (fs/read_write.c:915)
[ 459.605163] entry_SYSCALL_64_fastpath (arch/x86/entry/entry_64.S:186)
[ 459.606131] Memory state around the buggy address:
[ 459.607020] 8802ab0efa00: 00 00 00 00 f1 f1 f1 f1 00 00 00 00 00 00 00
00
[ 459.608442] 8802ab0efa80: f2 f2 f2 f2 00 00 f4 f4 f2 f2 f2 f2 00 00 00
00
[ 459.610252] >8802ab0efb00: 00 06 f4 f4 f3 f3 f3 f3 00 00 00 00 00 00 00
00
[ 459.612306] ^
[ 459.613233] 8802ab0efb80: 00 00 f1 f1 f1 f1 00 f4 f4 f4 f3 f3 f3 f3 00
00
[ 459.615076] 8802ab0efc00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00
Thanks,
Sasha
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] mm, oom: initiallize all new zap_details fields before use
Commit "mm, oom: introduce oom reaper" forgot to initialize the two new fields of struct zap_details in unmap_mapping_range(). This caused using stack garbage on the call to unmap_mapping_range_tree(). Signed-off-by: Sasha Levin --- mm/memory.c |1 + 1 file changed, 1 insertion(+) diff --git a/mm/memory.c b/mm/memory.c index 206c8cd..0e32993 100644 --- a/mm/memory.c +++ b/mm/memory.c @@ -2431,6 +2431,7 @@ void unmap_mapping_range(struct address_space *mapping, details.last_index = hba + hlen - 1; if (details.last_index < details.first_index) details.last_index = ULONG_MAX; + details.check_swap_entries = details.ignore_dirty = false; /* DAX uses i_mmap_lock to serialise file truncate vs page fault */ -- 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 1/1 linux-next] mtd: cfi_cmdset_0002: use swap() in cfi_cmdset_0002()
Garbage collecting old patches... On Wed, Jun 10, 2015 at 06:31:32PM +0200, Fabian Frederick wrote: > Use kernel.h macro definition. > > Thanks to Julia Lawall for Coccinelle scripting support. > > Signed-off-by: Fabian Frederick Applied to l2-mtd.git -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 linux-next] mtd/ftl: use swap() in copy_erase_unit()
Garbage collecting old patches... On Wed, Jun 10, 2015 at 06:31:06PM +0200, Fabian Frederick wrote: > Use kernel.h macro definition. > > Thanks to Julia Lawall for Coccinelle scripting support. > > Signed-off-by: Fabian Frederick Applied to l2-mtd.git -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] futex: Allow FUTEX_CLOCK_REALTIME with FUTEX_WAIT op
On Fri, 18 Dec 2015, Darren Hart wrote: While reviewing Michael Kerrisk's recent futex manpage update, I noticed that we allow the FUTEX_CLOCK_REALTIME flag for FUTEX_WAIT_BITSET but not for FUTEX_WAIT. FUTEX_WAIT is treated as a simple version for FUTEX_WAIT_BITSET internally (with a bitmask of FUTEX_BITSET_MATCH_ANY). As such, I cannot come up with a reason for this exclusion for FUTEX_WAIT. This change does modify the behavior of the futex syscall, changing a call with FUTEX_WAIT | FUTEX_CLOCK_REALTIME from returning -ENOSYS, to be equivalent to FUTEX_WAIT_BITSET | FUTEX_CLOCK_REALTIME with a bitset of FUTEX_BITSET_MATCH_ANY. Cc: Thomas Gleixner Cc: Peter Zijlstra Cc: Davidlohr Bueso Reported-by: Michael Kerrisk Signed-off-by: Darren Hart Acked-by: Davidlohr Bueso -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] mtd: nand: pxa3xx_nand: add register access debug
Garbage collecting some old patches before vacation...
On Mon, Aug 24, 2015 at 10:46:18AM -0300, Ezequiel Garcia wrote:
> I agree that the hack is useful for debugging purposes, it's just that I don't
> see why we want it in mainline - where we usually avoid clutter.
I'm not sure this is really that important of clutter. It's in a nicely
hidden abstraction (the local nand_{read,write}l() helpers), and it
doesn't add any compile time cost for most users.
> Also, your argument applies to all the other drivers, but that doesn't mean
> we will patch them all.
>
> Anyway, this is just my opinion. If Brian thinks differently, I have no
> problem
> with it.
I don't have very strong opinions on this. It's kind of annoying to have
this sort of stuff duplicated for every driver, if it's really needed.
But I'll admit this kind of infrastructure is sometimes useful.
Anecdote: I recently found the regmap trace event infrastructure pretty
nice for debugging some other drivers. This would only require you to
have tracing enabled, and then no recompiles are necessary at all. Just
cmdline changes.
So, I could go with this patch, if Robert still desires it. Or you could
convert to using regmap for MMIO :)
Brian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Staging: comedi: pcmcia: fixed a line with over 80 chars
On Sun, Dec 13, 2015 at 05:40:34PM +0100, Philippe Loctaux wrote: > This patch fixes the checkpatch.pl warning: > > WARNING: line over 80 characters > > Signed-off-by: Philippe Loctaux > --- > drivers/staging/comedi/comedi_pcmcia.h | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/drivers/staging/comedi/comedi_pcmcia.h > b/drivers/staging/comedi/comedi_pcmcia.h > index 5d3db2b..245e6bd 100644 > --- a/drivers/staging/comedi/comedi_pcmcia.h > +++ b/drivers/staging/comedi/comedi_pcmcia.h > @@ -38,8 +38,10 @@ int comedi_pcmcia_driver_register(struct comedi_driver *, > void comedi_pcmcia_driver_unregister(struct comedi_driver *, >struct pcmcia_driver *); > > -/** > - * module_comedi_pcmcia_driver() - Helper macro for registering a comedi > PCMCIA driver > +/* > + * module_comedi_pcmcia_driver() > + * Helper macro for registering a comedi PCMCIA driver No, you just broke the kernel-doc formatting here :( -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] staging: wilc1000: fix double mutex_unlock on failure path in wilc_wlan_cleanup()
On Sat, Dec 05, 2015 at 01:04:34AM +0300, Alexey Khoroshilov wrote: > If hif_read_reg() or hif_write_reg() fail in wilc_wlan_cleanup(), > it calls release_bus() and continues execution. But it leads to double > release_bus() call that means double unlock of g_linux_wlan->hif_cs mutex. > > The patch adds return in case of failure. > > Found by Linux Driver Verification project (linuxtesting.org). > > Signed-off-by: Alexey Khoroshilov > --- > drivers/staging/wilc1000/wilc_wlan.c | 2 ++ > 1 file changed, 2 insertions(+) No longer applies to my tree, can you rebase it against staging-testing and resend? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/10] bpf samples: Add utils.[ch] for using BPF
On Fri, Dec 18, 2015 at 03:04:00PM +0800, Wangnan (F) wrote:
>
> >>However, linux/err.h is not a part of uapi. To make libbpf work, one has to
> >>create its
> >>own err.h.
> >Why tools/include/linux/err.h is not suitable for everyone?
> >
> >>Now I'm thinking provide LIBBPF_{IS_ERR,PTR_ERR}(), in libbpf itself.
> >seems odd. we already have user space err.h in tools/include.
>
> Currently samples/bpf doesn't have an -I$(srctree)/tools/include.
>
> I tried to add it into CFLAGS of samples/bpf. It causes other problems,
let's fix those problem then.
> What I want to do in this patchset is not only removing original libbpf.c
> and bpf_load.c. In fact I want libbpf in tools/lib/bpf becomes a public
> available library for other userspace tools (tc for example). Switching
> samples/bpf into libbpf is the first step of this goal. From doing this
> I found and fixed some limitation, like those missed BPF map operations.
> Making libbpf.h and bpf.h available for normal userspace programs is also
> important.
>
> Having the above goal, I think you can understand why improving
> tools/include
> is not a good idea. You don't want to force a normal userspace program setup
> a similar header environment for using libbpf. It is relatively a small
> library. So it would be good if bpf.h and libbpf.h only depend on what can
> be found in uapi.
completely agree on the goal of making libbpf to be a standalone library,
but disagree on tools/include dependency.
If you copy-paste err.h into libbpf either as-is or as LIBBPF_IS_ERR,
it's not going to be enough. Soon you'll need another macro from tools/include
and so on. imo it's much easier to include tools/include/ as part of
standalone libbpf.
Also at the time of creation of tools/lib/bpf we agreed that it's LGPL
just like tools/lib/traceevent, but I don't see any mention of it in
the libbpf source.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
mm, vmstat: kernel BUG at mm/vmstat.c:1408!
Hi all, I've started seeing the following in the latest -next kernel. [ 531.127489] kernel BUG at mm/vmstat.c:1408! [ 531.128157] invalid opcode: [#1] PREEMPT SMP KASAN [ 531.128872] Modules linked in: [ 531.129324] CPU: 6 PID: 407 Comm: kworker/6:1 Not tainted 4.4.0-rc5-next-20151218-sasha-00021-gaba8d84-dirty #2750 [ 531.130939] Workqueue: vmstat vmstat_update [ 531.131741] task: 88020407 ti: 880204078000 task.ti: 880204078000 [ 531.133189] RIP: vmstat_update (mm/vmstat.c:1408) [ 531.134466] RSP: 0018:88020407fbf8 EFLAGS: 00010293 [ 531.135132] RAX: 0006 RBX: 8800418e2fd8 RCX: [ 531.135995] RDX: 0007 RSI: 8c0982a0 RDI: 9b8bd6e4 [ 531.137475] RBP: 88020407fc18 R08: R09: 880204070230 [ 531.138304] R10: 8c0982a0 R11: e272b4f2 R12: 880204c1bf60 [ 531.139329] R13: 880204ab09c8 R14: 880204ab09b8 R15: 880204ab09b0 [ 531.140261] FS: () GS:880204c0() knlGS: [ 531.141218] CS: 0010 DS: ES: CR0: 8005003b [ 531.142036] CR2: 7f039a8c1944 CR3: 0ea28000 CR4: 06a0 [ 531.142752] Stack: [ 531.142963] 880204c21000 880204c21000 880204c1bf60 880204ab09c8 [ 531.144095] 88020407fd40 813a8fea 41b58ab3 8e667cdb [ 531.145258] 880204ab09f8 880204c1bf68 880204ab09c0 8802 [ 531.146475] Call Trace: [ 531.147037] process_one_work (./arch/x86/include/asm/preempt.h:22 kernel/workqueue.c:2045) [ 531.150790] worker_thread (include/linux/compiler.h:218 include/linux/list.h:206 kernel/workqueue.c:2171) [ 531.155176] kthread (kernel/kthread.c:209) [ 531.158941] ret_from_fork (arch/x86/entry/entry_64.S:469) [ 531.160654] Code: 75 1e be 79 00 00 00 48 c7 c7 80 0f 10 8c 89 45 e4 e8 cd 92 cd ff 8b 45 e4 c6 05 e1 c4 13 1a 01 89 c0 f0 48 0f ab 03 72 02 eb 0e <0f> 0b 48 c7 c7 c0 f1 47 90 e8 3d 03 ae 01 48 83 c4 08 5b 41 5c All code 0: 75 1e jne0x20 2: be 79 00 00 00 mov$0x79,%esi 7: 48 c7 c7 80 0f 10 8cmov$0x8c100f80,%rdi e: 89 45 e4mov%eax,-0x1c(%rbp) 11: e8 cd 92 cd ff callq 0xffcd92e3 16: 8b 45 e4mov-0x1c(%rbp),%eax 19: c6 05 e1 c4 13 1a 01movb $0x1,0x1a13c4e1(%rip)# 0x1a13c501 20: 89 c0 mov%eax,%eax 22: f0 48 0f ab 03 lock bts %rax,(%rbx) 27: 72 02 jb 0x2b 29: eb 0e jmp0x39 2b:* 0f 0b ud2 <-- trapping instruction 2d: 48 c7 c7 c0 f1 47 90mov$0x9047f1c0,%rdi 34: e8 3d 03 ae 01 callq 0x1ae0376 39: 48 83 c4 08 add$0x8,%rsp 3d: 5b pop%rbx 3e: 41 5c pop%r12 ... Code starting with the faulting instruction === 0: 0f 0b ud2 2: 48 c7 c7 c0 f1 47 90mov$0x9047f1c0,%rdi 9: e8 3d 03 ae 01 callq 0x1ae034b e: 48 83 c4 08 add$0x8,%rsp 12: 5b pop%rbx 13: 41 5c pop%r12 ... [ 531.164630] RIP vmstat_update (mm/vmstat.c:1408) [ 531.165523] RSP Thanks, Sasha -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [PATCHv3] RTC: RK808: Compensate for Rockchip calendar deviation on November 31st
> There's actually a real world case that's pretty common where we want > to work with dates before 2016. When I power cycle my device and it > totally loses battery, I notice that the firmware seems to start as: > > 2013-01-21 00:50:02 > > It's possible we could need to run for a while in this state and we > possibly could even need alarms to fire. ...but that's nowhere near > the problematic dates and presumably someone wouldn't have a system in > the "clock set totally wrong" state for a really long time. Yeah... I don't think it really makes much sense to worry about that. At that point it's much more likely that you will loose an alarm because the user finally fixes the clock at some point (either manually or by connecting to a network and having some automated sync service jump in), and we never worry about something like that either. I mean, fixing it wouldn't be a big deal (another 5 lines or so maybe), but I just don't think it's worth adding any complexity. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [PATCHv3] RTC: RK808: Compensate for Rockchip calendar deviation on November 31st
Julius, On Tue, Dec 15, 2015 at 3:02 PM, Julius Werner wrote: > In A.D. 1582 Pope Gregory XIII found that the existing Julian calendar > insufficiently represented reality, and changed the rules about > calculating leap years to account for this. Similarly, in A.D. 2013 > Rockchip hardware engineers found that the new Gregorian calendar still > contained flaws, and that the month of November should be counted up to > 31 days instead. Unfortunately it takes a long time for calendar changes > to gain widespread adoption, and just like more than 300 years went by > before the last Protestant nation implemented Greg's proposal, we will > have to wait a while until all religions and operating system kernels > acknowledge the inherent advantages of the Rockchip system. Until then > we need to translate dates read from (and written to) Rockchip hardware > back to the Gregorian format. > > This patch works by defining Jan 1st, 2016 as the arbitrary anchor date > on which Rockchip and Gregorian calendars are in sync. From that we can > translate arbitrary later dates back and forth by counting the number > of November/December transitons since the anchor date to determine the > offset between the calendars. We choose this method (rather than trying > to regularly "correct" the date stored in hardware) since it's the only > way to ensure perfect time-keeping even if the system may be shut down > for an unknown number of years. The drawback is that other software > reading the same hardware (e.g. mainboard firmware) must use the same > translation convention (including the same anchor date) to be able to > read and write correct timestamps from/to the RTC. > > Signed-off-by: Julius Werner > --- > drivers/rtc/rtc-rk808.c | 48 > 1 file changed, 44 insertions(+), 4 deletions(-) I'm not terribly worried about the date in the past problem that you brought up in your own response. So: Reviewed-by: Douglas Anderson -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [PATCHv3] RTC: RK808: Compensate for Rockchip calendar deviation on November 31st
Julius, On Tue, Dec 15, 2015 at 3:14 PM, Julius Werner wrote: > Okay, wrote up and tested the anchor date version. I think once you > get over the initial weirdness of the approach this one is really much > cleaner and safer. > > I tested this with the older rtc_tm_to_time() API and only ported it > over to rtc_tm_to_time64() for submission, since my 3.14 kernel didn't > have that yet... but it still compiles fine and the change was very > trivial so I'm confident that it should work. > > I also did a big manual test for my conversion functions where I just > threw a whole bunch of dates at them, results below for reference: > > [1.431216] jwerner: Testing translation functions: > [1.431221] 2015-01-01 to_rockchip: 2015-01-02 to_gregorian: 2014-12-31 > [1.431224] 2015-10-30 to_rockchip: 2015-10-31 to_gregorian: 2015-10-29 > [1.431228] 2015-10-31 to_rockchip: 2015-11-01 to_gregorian: 2015-10-30 > [1.431231] 2015-11-01 to_rockchip: 2015-11-02 to_gregorian: 2015-10-31 > [1.431235] 2015-11-27 to_rockchip: 2015-11-28 to_gregorian: 2015-11-26 > [1.431238] 2015-11-28 to_rockchip: 2015-11-29 to_gregorian: 2015-11-27 > [1.431242] 2015-11-29 to_rockchip: 2015-11-30 to_gregorian: 2015-11-28 > [1.431245] 2015-11-30 to_rockchip: 2015-12-01 to_gregorian: 2015-11-29 > > This one is actually a bug... to_rockchip should be 2015-11-31 here. > It happens because the "compensate if we went back over" part of > gregorian_to_rockchip() only checks whether we went over *backwards*, > which happens if the date is after the anchor date. If it was before > we can go back over forwards and I didn't bother to handle that case. > I think this is fine since all affected dates lie in the past and > there's no real-world use case where you'd ever need them to work > again. Thanks for the testing. Ah, I see, so the problem with your patch is only right around 11/31 in years past. That seems OK to me. There's actually a real world case that's pretty common where we want to work with dates before 2016. When I power cycle my device and it totally loses battery, I notice that the firmware seems to start as: 2013-01-21 00:50:02 It's possible we could need to run for a while in this state and we possibly could even need alarms to fire. ...but that's nowhere near the problematic dates and presumably someone wouldn't have a system in the "clock set totally wrong" state for a really long time. -Doug -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] CHROMIUM: Input: elants_i2c: fixed wake-on-touch issue
Hi James,
On Fri, Dec 18, 2015 at 10:48:48AM +0800, james.chen wrote:
> From: "james.chen"
>
> Something wrong in suspend/resume of kernel v3.14 for the function of
> wake-on-touch. The function of device_may_wakeup will return true if
> the device supports wake-on-touch (for example, kitty and buddy).
> So, modify the code from "if (device_may_wakeup(dev))" to
> "if (!device_may_wakeup(dev))". And adjust the condition check of
> keep_power_in_suspend (designed for minnie).
>
> Signed-off-by: James Chen
Adjusted commit message and dropped rename retry_cnt -> retry and
applied.
Thank you.
> ---
> drivers/input/touchscreen/elants_i2c.c | 37
> +-
> 1 file changed, 19 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/input/touchscreen/elants_i2c.c
> b/drivers/input/touchscreen/elants_i2c.c
> index 17cc20e..06ee814 100644
> --- a/drivers/input/touchscreen/elants_i2c.c
> +++ b/drivers/input/touchscreen/elants_i2c.c
> @@ -1307,7 +1307,7 @@ static int __maybe_unused elants_i2c_suspend(struct
> device *dev)
> struct i2c_client *client = to_i2c_client(dev);
> struct elants_data *ts = i2c_get_clientdata(client);
> const u8 set_sleep_cmd[] = { 0x54, 0x50, 0x00, 0x01 };
> - int retry_cnt;
> + int retry;
> int error;
>
> /* Command not support in IAP recovery mode */
> @@ -1316,24 +1316,25 @@ static int __maybe_unused elants_i2c_suspend(struct
> device *dev)
>
> disable_irq(client->irq);
>
> - if (device_may_wakeup(dev) || ts->keep_power_in_suspend) {
> - for (retry_cnt = 0; retry_cnt < MAX_RETRIES; retry_cnt++) {
> + if (device_may_wakeup(dev)) {
> + /*
> + * The device will automatically enter idle mode
> + * that has reduced power consumption.
> + */
> + ts->wake_irq_enabled = (enable_irq_wake(client->irq) == 0);
> + } else if (ts->keep_power_in_suspend) {
> + for (retry = 0; retry < MAX_RETRIES; retry++) {
> error = elants_i2c_send(client, set_sleep_cmd,
> - sizeof(set_sleep_cmd));
> + sizeof(set_sleep_cmd));
> if (!error)
> break;
>
> dev_err(>dev,
> "suspend command failed: %d\n", error);
> }
> -
> - if (device_may_wakeup(dev))
> - ts->wake_irq_enabled =
> - (enable_irq_wake(client->irq) == 0);
> } else {
> - elants_i2c_power_off(ts);
> + elants_i2c_power_off(ts);
> }
> -
> return 0;
> }
>
> @@ -1342,16 +1343,17 @@ static int __maybe_unused elants_i2c_resume(struct
> device *dev)
> struct i2c_client *client = to_i2c_client(dev);
> struct elants_data *ts = i2c_get_clientdata(client);
> const u8 set_active_cmd[] = { 0x54, 0x58, 0x00, 0x01 };
> - int retry_cnt;
> + int retry;
> int error;
>
> - if (device_may_wakeup(dev) && ts->wake_irq_enabled)
> - disable_irq_wake(client->irq);
> -
> - if (ts->keep_power_in_suspend) {
> - for (retry_cnt = 0; retry_cnt < MAX_RETRIES; retry_cnt++) {
> + if (device_may_wakeup(dev)) {
> + if (ts->wake_irq_enabled)
> + disable_irq_wake(client->irq);
> + elants_i2c_sw_reset(client);
> + } else if (ts->keep_power_in_suspend) {
> + for (retry = 0; retry < MAX_RETRIES; retry++) {
> error = elants_i2c_send(client, set_active_cmd,
> - sizeof(set_active_cmd));
> + sizeof(set_active_cmd));
> if (!error)
> break;
>
> @@ -1362,7 +1364,6 @@ static int __maybe_unused elants_i2c_resume(struct
> device *dev)
> elants_i2c_power_on(ts);
> elants_i2c_initialize(ts);
> }
> -
> ts->state = ELAN_STATE_NORMAL;
> enable_irq(client->irq);
>
> --
> 1.8.3.2
>
--
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] x86/signal: Cleanup get_nr_restart_syscall
Check for TS_COMPAT instead of TIF_IA32 to distinguish ia32 tasks
from 64-bit tasks.
Check for __X32_SYSCALL_BIT only if CONFIG_X86_X32_ABI is defined.
Signed-off-by: Dmitry V. Levin
Cc: Elvira Khabirova
Cc: Andy Lutomirski
---
arch/x86/kernel/signal.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/arch/x86/kernel/signal.c b/arch/x86/kernel/signal.c
index cb6282c..ff7dedc 100644
--- a/arch/x86/kernel/signal.c
+++ b/arch/x86/kernel/signal.c
@@ -692,12 +692,15 @@ handle_signal(struct ksignal *ksig, struct pt_regs *regs)
static inline unsigned long get_nr_restart_syscall(const struct pt_regs *regs)
{
-#if defined(CONFIG_X86_32) || !defined(CONFIG_X86_64)
+#ifdef CONFIG_X86_64
+ if (is_ia32_task())
+ return __NR_ia32_restart_syscall;
+# ifdef CONFIG_X86_X32_ABI
+ if (regs->orig_ax & __X32_SYSCALL_BIT)
+ return __NR_restart_syscall | __X32_SYSCALL_BIT;
+# endif
+#endif
return __NR_restart_syscall;
-#else /* !CONFIG_X86_32 && CONFIG_X86_64 */
- return test_thread_flag(TIF_IA32) ? __NR_ia32_restart_syscall :
- __NR_restart_syscall | (regs->orig_ax & __X32_SYSCALL_BIT);
-#endif /* CONFIG_X86_32 || !CONFIG_X86_64 */
}
/*
--
ldv
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Rethinking sigcontext's xfeatures slightly for PKRU's benefit?
On Fri, Dec 18, 2015 at 3:16 PM, Andy Lutomirski wrote: > > Yes, I think. If I'm using protection keys to protect some critical > data structure (important stuff in shared memory, important memory > mapped files, pmem, etc), then I'll allocate a protection key and set > PKRU to deny writes. The problem is that I really, really want writes > denied except when explicitly enabled in narrow regions of code that > use wrpkru to enable them, and I don't want an asynchronous signal > delivered in those narrow regions of code or newly cloned threads to > pick up the write-allow value. So I want baseline_pkru to have the > deny writes entry. Hmm. Ok, that does sound like a valid and interesting usage case. Fair enough. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5] extcon: add Maxim MAX3355 driver
Maxim Integrated MAX3355E chip integrates a charge pump and comparators to
enable a system with an integrated USB OTG dual-role transceiver to
function as an USB OTG dual-role device. In addition to sensing/controlling
Vbus, the chip also passes thru the ID signal from the USB OTG connector.
On some Renesas boards, this signal is just fed into the SoC thru a GPIO
pin -- there's no real OTG controller, only host and gadget USB controllers
sharing the same USB bus; however, we'd like to allow host or gadget
drivers to be loaded depending on the cable type, hence the need for the
MAX3355 extcon driver. The Vbus status signals are also wired to GPIOs
(however, we aren't currently interested in them), the OFFVBUS# signal is
controlled by the host controllers, there's also the SHDN# signal wired to
a GPIO, it should be driven high for the normal operation.
Signed-off-by: Sergei Shtylyov
Acked-by: Chanwoo Choi
---
Changes in version 5:
- removed unused variable in the probe() method;
- removed reference to the Koelsch board from the binding document;
- added Chanwoo Choi's ACK.
Changes in version 4:
- stopped calling kstrdup() for the device name;
- removed unneeded 'owner' field initializer;
- moved devm_extcon_allocate() call further down in the probe() method;
- extended the driver copyright;
- indented the continuation lines in the binding document.
Changes in version 3:
- reformatted the change log.
Changes in version 2:
- added the USB gadget cable support;
- added the remove() driver method which drives SHDN# GPIO low to save power;
- dropped vendor prefix from the ID GPIO property name;
- changed the GPIO property name suffix to "-gpios";
- switched to usign extcon_set_cable_state_() API;
- switched to using the gpiod/sleeping 'gpiolib' APIs;
- addded error messages to max3355_probe();
- added IRQF_NO_SUSPEND flasg to the devm_request_threaded_irq() call;
- renamed 'ret' variable to 'err' in max3355_probe();
- expanded the Kconfig entry help text;
- added vendor name to the patch summary, the bindings document, the Kconfig
entry, the driver heading comment, the module description, and the change log;
- fixed up and reformatted the change log.
Documentation/devicetree/bindings/extcon/extcon-max3355.txt | 21 +
drivers/extcon/Kconfig |8
drivers/extcon/Makefile |1
drivers/extcon/extcon-max3355.c | 150
4 files changed, 180 insertions(+)
Index: extcon/Documentation/devicetree/bindings/extcon/extcon-max3355.txt
===
--- /dev/null
+++ extcon/Documentation/devicetree/bindings/extcon/extcon-max3355.txt
@@ -0,0 +1,21 @@
+Maxim Integrated MAX3355 USB OTG chip
+-
+
+MAX3355 integrates a charge pump and comparators to enable a system with an
+integrated USB OTG dual-role transceiver to function as a USB OTG dual-role
+device.
+
+Required properties:
+- compatible: should be "maxim,max3355";
+- maxim,shdn-gpios: should contain a phandle and GPIO specifier for the GPIO
pin
+ connected to the MAX3355's SHDN# pin;
+- id-gpios: should contain a phandle and GPIO specifier for the GPIO pin
+ connected to the MAX3355's ID_OUT pin.
+
+Example:
+
+ usb-otg {
+ compatible = "maxim,max3355";
+ maxim,shdn-gpios = < 4 GPIO_ACTIVE_LOW>;
+ id-gpios = < 31 GPIO_ACTIVE_HIGH>;
+ };
Index: extcon/drivers/extcon/Kconfig
===
--- extcon.orig/drivers/extcon/Kconfig
+++ extcon/drivers/extcon/Kconfig
@@ -52,6 +52,14 @@ config EXTCON_MAX14577
Maxim MAX14577/77836. The MAX14577/77836 MUIC is a USB port accessory
detector and switch.
+config EXTCON_MAX3355
+ tristate "Maxim MAX3355 USB OTG EXTCON Support"
+ help
+ If you say yes here you get support for the USB OTG role detection by
+ MAX3355. The MAX3355 chip integrates a charge pump and comparators to
+ enable a system with an integrated USB OTG dual-role transceiver to
+ function as an USB OTG dual-role device.
+
config EXTCON_MAX77693
tristate "Maxim MAX77693 EXTCON Support"
depends on MFD_MAX77693 && INPUT
Index: extcon/drivers/extcon/Makefile
===
--- extcon.orig/drivers/extcon/Makefile
+++ extcon/drivers/extcon/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_EXTCON_ARIZONA)+= extcon-a
obj-$(CONFIG_EXTCON_AXP288)+= extcon-axp288.o
obj-$(CONFIG_EXTCON_GPIO) += extcon-gpio.o
obj-$(CONFIG_EXTCON_MAX14577) += extcon-max14577.o
+obj-$(CONFIG_EXTCON_MAX3355) += extcon-max3355.o
obj-$(CONFIG_EXTCON_MAX77693) += extcon-max77693.o
obj-$(CONFIG_EXTCON_MAX77843) += extcon-max77843.o
obj-$(CONFIG_EXTCON_MAX8997) += extcon-max8997.o
Index:
Re: Rethinking sigcontext's xfeatures slightly for PKRU's benefit?
On Fri, Dec 18, 2015 at 3:08 PM, Linus Torvalds wrote: > On Fri, Dec 18, 2015 at 2:28 PM, Andy Lutomirski wrote: >> >> Apps that don't want to use the baseline_pkru mechanism could use >> syscalls to claim ownership of protection keys but then manage them >> purely with WRPKRU directly. We could optionally disallow >> mprotect_key on keys that weren't allocated in advance. >> >> Does that seem sane? > > So everything seems sane except for the need for that baseline_pkru. > > I'm not seeing why it couldn't just be a fixed value. Is there any > real downside to it? Yes, I think. If I'm using protection keys to protect some critical data structure (important stuff in shared memory, important memory mapped files, pmem, etc), then I'll allocate a protection key and set PKRU to deny writes. The problem is that I really, really want writes denied except when explicitly enabled in narrow regions of code that use wrpkru to enable them, and I don't want an asynchronous signal delivered in those narrow regions of code or newly cloned threads to pick up the write-allow value. So I want baseline_pkru to have the deny writes entry. I think I would do exactly this in my production code here if my server supported it. Some day... Hrm. We might also want an option to change pkru and/or baseline_pkru in all threads in the current mm. That's optional but it could be handy. Maybe it would be as simple as having the allocate-a-pkey call have an option to set an initial baseline value and an option to propagate that initial value to pre-existing threads. --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 1/3] ata: sata_dwc_460ex: use "dmas" DT property to find dma channel
Julian Margetson writes: > On 12/18/2015 6:33 PM, Måns Rullgård wrote: >> Julian Margetson writes: >> >>> On 12/18/2015 1:18 PM, Måns Rullgård wrote: Julian Margetson writes: > On 12/18/2015 8:49 AM, Måns Rullgård wrote: >> Andy Shevchenko writes: >> > [5.206125] Unable to handle kernel paging request for data at > address 0x > [5.228546] Faulting instruction address: 0xc043a2c8 > [5.248577] Vector: 300 (Data Access) at [eddafae0] > [5.268658] pc: c043a2c8: sata_dwc_qc_issue+0xb8/0x204 Well, that's not good. Can you translate that address to a line of code? >>> Besides that, can you enable DYNAMIC_DEBUG in the config and append >>> 'dw_dmac_core.dyndbg dw_dmac.dyndbg' to the kernel cmdline? >> Enabling debug messages in the sata_dwc driver might also be informative. >> > Changed the sata-dwc to a module . > > [ 18.475140] sata-dwc 4bffd1000.sata: sata_dwc_qc_prep_by_tag: > dma_dwc_xfer_setup returns NULL > [ 18.535698] sata-dwc 4bffd1000.sata: sata_dwc_qc_prep_by_tag: > dma_dwc_xfer_setup returns NULL That's strange. The only way that can happen is if dmaengine_prep_slave_sg() return NULL, and that really shouldn't be happening. Did you turn on debug messages in dw_dma? You can enable some extra debug messages by adding "#define VERBOSE_DEBUG" at the top of drivers/dma/dw/core.c >>> [ 17.526173] sata-dwc 4bffd1000.sata: sata_dwc_qc_prep_by_tag: >>> dma_dwc_xfer_setup returns NULL >>> [ 17.600124] sata-dwc 4bffd1000.sata: sata_dwc_qc_prep_by_tag: >>> dma_dwc_xfer_setup returns NULL >>> [ 17.662978] sata-dwc 4bffd1000.sata: sata_dwc_qc_prep_by_tag: >>> dma_dwc_xfer_setup returns NULL >> Could you post the entire kernel log? There might be important >> information before the errors start. >> > > > =~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2015.12.18 15:01:48 =~=~=~=~=~=~=~=~=~=~=~= > [0.00] Using Canyonlands machine description > [0.00] Initializing cgroup subsys cpu > [0.00] Linux version 4.4.0-rc5-Sam460ex (root@julian-VirtualBox) (gcc > version 4.8.2 (Ubuntu 4.8.2-16ubuntu3) ) #8 PREEMPT Fri Dec 18 13:36:34 AST > 2015 > [0.00] Zone ranges: > [0.00] DMA [mem 0x-0x2fff] > [0.00] Normal empty > [0.00] HighMem [mem 0x3000-0x7fff] > [0.00] Movable zone start for each node > [0.00] Early memory node ranges > [0.00] node 0: [mem 0x-0x7fff] > [0.00] Initmem setup node 0 [mem > 0x-0x7fff] > [0.00] MMU: Allocated 1088 bytes of context maps for 255 contexts > [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total > pages: 522752 > [0.00] Kernel command line: root=/dev/sda8 console=ttyS0,115200 > console=tty0 dw_dmac_core.dyndbg dw_dmac.dyndbg [...] > [ 13.643415] systemd[1]: Mounted Configuration File System. > [ 17.526173] sata-dwc 4bffd1000.sata: sata_dwc_qc_prep_by_tag: > dma_dwc_xfer_setup returns NULL > [ 17.600124] sata-dwc 4bffd1000.sata: sata_dwc_qc_prep_by_tag: > dma_dwc_xfer_setup returns NULL > [ 17.662978] sata-dwc 4bffd1000.sata: sata_dwc_qc_prep_by_tag: > dma_dwc_xfer_setup returns NULL This log is weird. The sata_dwc_probe() function prints several things (one using dev_notice()), for instance this: /* Read the ID and Version Registers */ idr = in_le32(>sata_dwc_regs->idr); versionr = in_le32(>sata_dwc_regs->versionr); dev_notice(>dev, "id %d, controller version %c.%c%c\n", idr, ver[0], ver[1], ver[2]); The dw_dma_probe() function also prints a line: dev_info(chip->dev, "DesignWare DMA Controller, %d channels\n", pdata->nr_channels); These messages are nowhere to be seen in your log, nor are numerous others that really must appear before before sata_dwc_qc_prep_by_tag() can be called. I'd like to note that the driver works on my Sigma Designs based system using a different DMA controller, so it's not completely broken. The DMA driver could still be faulty, but that still doesn't explain the missing kernel messages. -- Måns Rullgård -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: Rethinking sigcontext's xfeatures slightly for PKRU's benefit?
On Fri, Dec 18, 2015 at 2:28 PM, Andy Lutomirski wrote: > > Apps that don't want to use the baseline_pkru mechanism could use > syscalls to claim ownership of protection keys but then manage them > purely with WRPKRU directly. We could optionally disallow > mprotect_key on keys that weren't allocated in advance. > > Does that seem sane? So everything seems sane except for the need for that baseline_pkru. I'm not seeing why it couldn't just be a fixed value. Is there any real downside to it? Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] futex: Prevent pi_state from double freeing in case of error
On Fri, Dec 18, 2015 at 02:13:43PM +0530, bhuvanesh_surach...@mentor.com wrote:
> From: Bhuvanesh Surachari
>
> In case of error from rt_mutex_start_proxy_lock pi_state is freed
> twice in futex_requeue function. Hence removing free_pi_state in
> else branch and branching to the location where pi_state is freed.
>
> Signed-off-by: Bhuvanesh Surachari
> Signed-off-by: Andy Lowe
Apparently inadvertently introduced by:
commit 30a6b8031fe14031ab27c1fa3483cb9780e7f63c
futex: Fix a race condition between REQUEUE_PI and task death
Reviewed-by: Darren Hart
> ---
> kernel/futex.c |1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/kernel/futex.c b/kernel/futex.c
> index 684d754..264b3f2 100644
> --- a/kernel/futex.c
> +++ b/kernel/futex.c
> @@ -1815,7 +1815,6 @@ retry_private:
> } else if (ret) {
> /* -EDEADLK */
> this->pi_state = NULL;
> - free_pi_state(pi_state);
> goto out_unlock;
> }
> }
> --
> 1.7.9.5
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
Darren Hart
Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Revert "kernel/stop_machine.c: remove CONFIG_SMP dependencies"
On Fri, 18 Dec 2015 15:35:55 +0530 Sudip Mukherjee
wrote:
> This reverts commit 64dab25b058c12f935794cb239089303bda7dbc1.
>
> CONFIG_SMP dependency is needed for some arch like tile, tilegx and
> m32r. They use stop_machine() but they donot have HOTPLUG_CPU and as a
> result their builds are failing with "undefined symbol 'stop_machine'".
Thanks. I had my &&'s and ||'s mixed up. I did this:
---
a/kernel/stop_machine.c~kernel-stop_machinec-remove-config_smp-dependencies-fix
+++ a/kernel/stop_machine.c
@@ -531,8 +531,6 @@ static int __init cpu_stop_init(void)
}
early_initcall(cpu_stop_init);
-#ifdef CONFIG_HOTPLUG_CPU
-
static int __stop_machine(cpu_stop_fn_t fn, void *data, const struct cpumask
*cpus)
{
struct multi_stop_data msdata = {
@@ -630,5 +628,3 @@ int stop_machine_from_inactive_cpu(cpu_s
mutex_unlock(_cpus_mutex);
return ret ?: done.ret;
}
-
-#endif /* CONFIG_HOTPLUG_CPU */
_
Rationale:
stop_machine.o is only built when CONFIG_SMP=y so
#if defined(CONFIG_SMP) || defined(CONFIG_HOTPLUG_CPU)
always evaluates to true, so remove it.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RESEND PATCH] mtd: mtk-nor: adjust sequence of trigger function and assignment function
On Fri, Dec 18, 2015 at 11:02:40AM +0800, Bayi Cheng wrote: > Move write data register before excute command to avoid > missing first byte write to nor flash > > Signed-off-by: Bayi Cheng > --- > the previous patch didn't drop the Change-Id Applied to l2-mtd.git -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] printk/nmi: Increase the size of NMI buffer and make it configurable
On Fri, 18 Dec 2015 13:11:41 +0100 Peter Zijlstra wrote: > On Fri, Dec 18, 2015 at 12:29:02PM +0100, Peter Zijlstra wrote: > > On Fri, Dec 18, 2015 at 10:18:08AM +, Daniel Thompson wrote: > > > I'm not entirely sure that this is an improvement. > > > > What I do these days is delete everything in vprintk_emit() and simply > > call early_printk(). > > On that, whoever made the device model use vprintk_emit() broke the > debugger (KGDB/KDB) printk intercept, and the whole vprintk_func > redirection scheme. crap, we have a whole set of interfaces which are broken this way. printk_emit(), vprintk(), vprintk_emit(). commit 7ff9554bb578ba02166071d2d487b7fc7d860d62 Author: Kay Sievers AuthorDate: Thu May 3 02:29:13 2012 +0200 Commit: Greg Kroah-Hartman CommitDate: Mon May 7 16:53:02 2012 -0700 printk: convert byte-buffer to variable-length record buffer -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] mtd: nand: support JEDEC additional redundant parameter pages
On Fri, Dec 11, 2015 at 09:16:20AM +0100, Antoine Tenart wrote: > On Thu, Dec 10, 2015 at 12:20:52PM -0800, Brian Norris wrote: > > On Fri, Dec 04, 2015 at 11:35:28PM +0100, Antoine Tenart wrote: > > > The JEDEC standard defines the JEDEC parameter page data structure. > > > One page plus two redundant pages are always there, in bits 0-1535. > > > Additionnal redundant parameter pages can be stored at bits 1536+. > > > Add support to read these pages. > > > > > > The first 3 JEDEC parameter pages are always checked, and if none > > > is valid we try to read additional redundant pages following the > > > standard definition: we continue while at least two of the four bytes > > > of the parameter page signature match (stored in the first dword). > > > > > > There is no limit to the number of additional redundant parameter > > > page. > > > > Hmm, do we really want this to be unbounded? What if (for example) a > > driver is buggy and has some kind of wraparound, so that it keeps > > returning the same parameter page (or a sequence of a few pages)? > > I would say buggy drivers need to be fixed. It's complicated to handle > all possible bugs a driver may have in the common code. Well, that's a fair statement to some extent. But generally, it is *much* preferred to code to real practice, rather than theoretical standards. And it's also much preferred not to code in potentially infinite loops. That's why we have timeouts, for instance, on most I/O. > If you prefer we can put a limit to the tries the code make, but this > can also impact working drivers by not trying enough. I'm open to > suggestions. Yes, please put some kind of limit. Probably a low one (after some number of damaged parameter pages, what's the likelihood that there will be any more correct ones?). If you make it a macro with a reasonable name, then it'll be more obvious what it does, in case someone needs to increase it. > > Also, is this actually solving any real problem? Have you seen flash > > that have more than the first 3 parameter pages? Have you tested > > this beyond the first 3? > > This does not solve any real world problem I had. I had to look at the > JEDEC standard and I made this in order to test something. So I thought > this could be useful to others, as the current code does not fully > implement the standard. OK. Well, I guess having the code might be better than nothing. I assume you at least faked the parameter pages so you could exercise all the code paths? Brian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] ideapad: Report hard block off if it is never on
On Wed, Dec 16, 2015 at 11:49:33AM +0800, Ike Panhc wrote:
Hi Ike,
+David Woodhouse (MODULE_AUTHOR)
> Hardware radio switch is rare on recently ideapad and some of them
> reported radio hardware blocked by error. With more and more ideapads
> available in market to maintain the dmi table becomes a
> never-finished job.
Indeed, inverting this logic or eliminating it would be an improvement.
To be clear, the only platforms which need to be listed in the DMI table are
those without a hw radio switch AND which will report hw_blocked when the ACPI
VPCCMD_R_RF call is made (instead of always returning 0 as they should)?
As such, the DMI list is a list of laptops with buggy firmware - correct?
> Therefore I am thinking an easy way to detect by response from
> hardware. This patch will make driver says hardware switch is not
> blocked if the response from ACPI is always radio blocked.
>
> For an ideapad without radio switch, no matter what ACPI says, driver
> will report false on hardware blocked.
>
> For an ideapad with radio switch, if driver loaded with radio on, no
> behavior is changed.
>
> For an ideapad with radio switch and driver loaded with radio off,
> driver will report unblocked falsely and network manager might not
> scan if wireless driver reports blocked. Once the switch is on,
> driver will report correct information.
This would be a regression for existing platforms though.
Do we have the ASL for some of the offending models compared with the good ones
so we can inspect and look for a deterministic detection mechanism?
>
> Signed-off-by: Ike Panhc
> ---
> drivers/platform/x86/ideapad-laptop.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/platform/x86/ideapad-laptop.c
> b/drivers/platform/x86/ideapad-laptop.c
> index a313dfc..91ccb4e 100644
> --- a/drivers/platform/x86/ideapad-laptop.c
> +++ b/drivers/platform/x86/ideapad-laptop.c
> @@ -482,11 +482,16 @@ static void ideapad_sync_rfk_state(struct
> ideapad_private *priv)
> {
> unsigned long hw_blocked = 0;
> int i;
> + static int hw_unblock_once;
>
> if (priv->has_hw_rfkill_switch) {
> if (read_ec_data(priv->adev->handle, VPCCMD_R_RF, _blocked))
> return;
> + if (hw_blocked)
> + hw_unblock_once = 1;
> hw_blocked = !hw_blocked;
> + if (!hw_unblock_once)
> + hw_blocked = 0;
> }
>
> for (i = 0; i < IDEAPAD_RFKILL_DEV_NUM; i++)
> --
> 1.9.1
>
>
--
Darren Hart
Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] mtd: spi-nor: fsl-quadspi: add big-endian support
On Fri, Dec 18, 2015 at 09:12:13AM +, Yao Yuan wrote: > Hi Woodhouse, Norris, > > Do you have any comments for this patch? No, it looks fine. But the driver maintainer (Han) already asked you for DT binding documentation already. This is a requirement before I can merge your patch. See Documentation/devicetree/bindings/submitting-patches.txt. > Thanks for your review. > > Best Regards, > Yuan Yao > > > -Original Message- > > From: Han Xu [mailto:han...@freescale.com] > > > + q->big_endian = of_property_read_bool(np, "big-endian"); > > > > I am fine with this patch, but need document the new property with another > > patch ^^^ See here Brian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] memory-hotplug: don't BUG() in register_memory_resource()
On Fri, 18 Dec 2015 15:50:24 +0100 Vitaly Kuznetsov wrote:
> Out of memory condition is not a bug and while we can't add new memory in
> such case crashing the system seems wrong. Propagating the return value
> from register_memory_resource() requires interface change.
>
> --- a/mm/memory_hotplug.c
> +++ b/mm/memory_hotplug.c
> +static int register_memory_resource(u64 start, u64 size,
> + struct resource **resource)
> {
> struct resource *res;
> res = kzalloc(sizeof(struct resource), GFP_KERNEL);
> - BUG_ON(!res);
> + if (!res)
> + return -ENOMEM;
>
> res->name = "System RAM";
> res->start = start;
> @@ -140,9 +142,10 @@ static struct resource *register_memory_resource(u64
> start, u64 size)
> if (request_resource(_resource, res) < 0) {
> pr_debug("System RAM resource %pR cannot be added\n", res);
> kfree(res);
> - res = NULL;
> + return -EEXIST;
> }
> - return res;
> + *resource = res;
> + return 0;
> }
Was there a reason for overwriting the request_resource() return value?
Ordinarily it should be propagated back to callers.
Please review.
---
a/mm/memory_hotplug.c~memory-hotplug-dont-bug-in-register_memory_resource-fix
+++ a/mm/memory_hotplug.c
@@ -131,7 +131,9 @@ static int register_memory_resource(u64
struct resource **resource)
{
struct resource *res;
+ int ret = 0;
res = kzalloc(sizeof(struct resource), GFP_KERNEL);
+
if (!res)
return -ENOMEM;
@@ -139,13 +141,14 @@ static int register_memory_resource(u64
res->start = start;
res->end = start + size - 1;
res->flags = IORESOURCE_MEM | IORESOURCE_BUSY;
- if (request_resource(_resource, res) < 0) {
+ ret = request_resource(_resource, res);
+ if (ret < 0) {
pr_debug("System RAM resource %pR cannot be added\n", res);
kfree(res);
- return -EEXIST;
+ } else {
+ *resource = res;
}
- *resource = res;
- return 0;
+ return ret;
}
static void release_memory_resource(struct resource *res)
_
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Problems with x86/x86_64 qemu tests in linux-next due to 'Enhance __assign_irq_vector() to rollback ...'
On Fri, Dec 18, 2015 at 11:14 AM, Jiang Liu wrote: > On 2015/12/18 7:59, Guenter Roeck wrote: Ah, again spend few hours to get the same. I found this on today's linux-next on some HP PC. Does the fix available anywhere on public? -- With Best Regards, Andy Shevchenko -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] mm: memcontrol: fix possible memcg leak due to interrupted reclaim
On Fri, 18 Dec 2015 19:24:05 +0300 Vladimir Davydov
wrote:
>
> OK, got it, thanks. Here goes the incremental patch (it should also fix
> the warning regarding unused cmpxchg returned value):
> ---
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index fc25dc211eaf..908c075e04eb 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -864,7 +864,7 @@ struct mem_cgroup *mem_cgroup_iter(struct mem_cgroup
> *root,
>* might block it. So we clear iter->position right
>* away.
>*/
> - cmpxchg(>position, pos, NULL);
> + (void)cmpxchg(>position, pos, NULL);
No, this doesn't actually squish the __must_check warning.
Can anyone think of anything smarter than this?
---
a/mm/memcontrol.c~mm-memcontrol-fix-possible-memcg-leak-due-to-interrupted-reclaim-fix-fix
+++ a/mm/memcontrol.c
@@ -851,6 +851,9 @@ static struct mem_cgroup *get_mem_cgroup
return memcg;
}
+/* Move this to compiler.h if it proves worthy */
+#define defeat_must_check(expr) do { if (expr) ; } while (0)
+
/**
* mem_cgroup_iter - iterate over memory cgroup hierarchy
* @root: hierarchy root
@@ -915,7 +918,7 @@ struct mem_cgroup *mem_cgroup_iter(struc
* might block it. So we clear iter->position right
* away.
*/
- (void)cmpxchg(>position, pos, NULL);
+ defeat_must_check(cmpxchg(>position, pos, NULL));
}
}
@@ -967,7 +970,7 @@ struct mem_cgroup *mem_cgroup_iter(struc
* thread, so check that the value hasn't changed since we read
* it to avoid reclaiming from the same cgroup twice.
*/
- (void)cmpxchg(>position, pos, memcg);
+ defeat_must_check(cmpxchg(>position, pos, memcg));
/*
* pairs with css_tryget when dereferencing iter->position
_
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] mtd: onenand: omap2: Simplify the DMA setup for various paths
On Fri, Dec 18, 2015 at 09:48:09PM +0200, Peter Ujfalusi wrote: > On 12/18/2015 08:11 PM, Brian Norris wrote: > > Peter, are you actually using this, or are you just refactoring for the > > fun of it? > > Not really for fun, but I want to get rid of all legacy/direct sDMA use so at > the end we will have omap_start_dma() visible in two files: > arch/arm/plat-omap/dma.c > drivers/dma/omap-dma.c > > from there it will be possible to get rid of the plat-omap code. This onenand > driver was the first in the 'git grep omap_start_dma' result ;) OK, well killing broken DMA support altogether might make more sense, and deleting an entire driver would be even better. Of course, having a real tester would be nice too. I'll wait on Tony/Aaro. Brian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
