On Wed, 25 Apr 2018 14:29:31 +0200,
Paul Menzel wrote:
>
> Dear Takashi,
>
>
> On 04/25/18 13:58, Takashi Iwai wrote:
> > On Wed, 25 Apr 2018 13:48:27 +0200, Paul Menzel wrote:
>
> >> With the attached debug patch, `azx_probe()` seems to have been called
> >> twice on the ASRock E350M1. Is that
Dear Bart,
On 04/25/18 14:26, Bart Van Assche wrote:
On Wed, 2018-04-25 at 07:37 +0200, Paul Menzel wrote:
Am 24.04.2018 um 23:17 schrieb Bart Van Assche:
On Tue, 2018-04-24 at 23:04 +0200, Paul Menzel wrote:
I applied your change, and rebuilt the Linux kernel. Unfortunately, it
looks like,
Dear Takashi,
On 04/25/18 14:34, Takashi Iwai wrote:
On Wed, 25 Apr 2018 14:29:31 +0200, Paul Menzel wrote:
On 04/25/18 13:58, Takashi Iwai wrote:
On Wed, 25 Apr 2018 13:48:27 +0200, Paul Menzel wrote:
With the attached debug patch, `azx_probe()` seems to have been called
twice on the AS
On Wed, Apr 25, 2018 at 11:19:20AM +0800, Chen-Yu Tsai wrote:
> On Wed, Apr 25, 2018 at 3:37 AM, Maxime Ripard
> wrote:
> > On Tue, Apr 24, 2018 at 08:17:11PM +0800, Chen-Yu Tsai wrote:
> >> On Tue, Apr 24, 2018 at 8:13 PM, Maxime Ripard
> >> wrote:
> >> > On Tue, Apr 24, 2018 at 07:34:19PM +0800
On Wed, Apr 25, 2018 at 01:52:55PM +0300, Vladimir Davydov wrote:
> On Tue, Apr 24, 2018 at 02:54:15PM +0100, Roman Gushchin wrote:
> >
> > But what we can do here, is to ignore memory.min of empty cgroups
> > (patch below), it will resolve some edge cases like this.
>
> Makes sense to me.
Ok, l
This patch adds the correct platform data information for the Caroline
Chromebook, so that the mouse button does not get stuck in pressed state
after the first click.
The Samus button keymap and platform data definition are the correct
ones for Caroline, so they have been reused here.
v2: updated
On 2018-04-25 13:12, Petr Mladek wrote:
>
> diff --git a/lib/test_printf.c b/lib/test_printf.c
> index 45c33143fb4a..74dff6c44ec6 100644
> --- a/lib/test_printf.c
> +++ b/lib/test_printf.c
> @@ -285,12 +285,19 @@ null_pointer(void)
>
> #define PTR_INVALID ((void *)0x00ab)
>
> +extern in
On Tue, 24 Apr 2018, Michal Hocko wrote:
> On Tue 24-04-18 19:17:12, Mikulas Patocka wrote:
> >
> >
> > On Tue, 24 Apr 2018, Michal Hocko wrote:
> >
> > > On Wed 25-04-18 00:18:40, Richard Weinberger wrote:
> > > > Am Dienstag, 24. April 2018, 21:28:03 CEST schrieb Michal Hocko:
> > > > > > A
Cc: Jingoo Han
On 04/24/2018 10:32 PM, Krzysztof Kozlowski wrote:
> The Exynos5440 is not actively developed, there are no development
> boards available and probably there are no real products with it.
> Remove wide-tree support for Exynos5440.
>
> Signed-off-by: Krzysztof Kozlowski
Thanks Krz
On 04/24/2018 10:32 PM, Krzysztof Kozlowski wrote:
> The Exynos5440 is not actively developed, there are no development
> boards available and probably there are no real products with it.
> Remove wide-tree support for Exynos5440.
>
> Signed-off-by: Krzysztof Kozlowski
It's good you didn't remov
Store user space frame-pointer value (BP register) into Perf trace
on a sample for a process so the value becomes available when
unwinding call stacks for functions gaining event samples.
Test executable for the example below was compiled with frame pointer
support enabled:
g++ -o futex-fp -f
On 04/19/2018 04:05 PM, Wolfram Sang wrote:
> We should get drvdata from struct device directly. Going via
> platform_device is an unneeded step back and forth.
>
> Signed-off-by: Wolfram Sang
Patch applied, thanks!
On Wed, Apr 25, 2018 at 05:50:41AM -0400, Chunyu Hu wrote:
> - Original Message -
> > From: "Catalin Marinas"
> > On Tue, Apr 24, 2018 at 07:20:57AM -0600, Michal Hocko wrote:
> > > On Mon 23-04-18 12:17:32, Chunyu Hu wrote:
> > > [...]
> > > > So if there is a new flag, it would be the 25
On Mon, Apr 23, 2018 at 11:18:11AM +0200, Michal Simek wrote:
> device->baud is always non zero value because it is checked already in
> early_serial8250_setup() before init_port is called.
>
> Fixes: 0ff3ab701963 ("serial: 8250_early: Only set divisor if valid clk &
> baud")
> Cc: stable
This
On Thu, Apr 19, 2018 at 09:25:08PM +0900, DaeRyong Jeong wrote:
> The patch is attached at the end of this email and can be downloaded from
> here.
> https://kiwi.cs.purdue.edu/static/race-fuzzer/tty_insert_flip_string_fixed_flag.patch
>
> We applied the patch to v4.16 and tested our reproducer.
On 25/04/18 12:08, Petr Tesarik wrote:
> Xen PV domains cannot shut down and start a crash kernel. Instead,
> the crashing kernel makes a SCHEDOP_shutdown hypercall with the
> reason code SHUTDOWN_crash, cf. xen_crash_shutdown() machine op in
> arch/x86/xen/enlighten_pv.c.
>
> A crash kernel reser
On Wed, Apr 25, 2018 at 09:19:29AM +0530, Vijayanand Jitta wrote:
> Idk, I don't like the idea of adding a counter outside of the vm counters
> infrastructure, and I definitely wouldn't touch the exposed
> nr_slab_reclaimable and nr_slab_unreclaimable fields.
> >>>
> >>> We would be
On Wed, Apr 25, 2018 at 2:49 PM, Sylwester Nawrocki
wrote:
> On 04/24/2018 10:32 PM, Krzysztof Kozlowski wrote:
>> The Exynos5440 is not actively developed, there are no development
>> boards available and probably there are no real products with it.
>> Remove wide-tree support for Exynos5440.
>>
Previous version of the patch series was sent here
https://lkml.org/lkml/2018/2/6/250
Most of the patches sent for v2 was merged. Remaining unmerged patches
from v2 and a few additional patches are sent here.
This series should be merged only after [1].
[1] -> https://marc.info/?l=linux-kernel&m=
During a short period when the bus voltage is switched from 3.3v to 1.8v,
(to enumerate UHS mode), the mmc module is disabled and the mmc IO lines
are kept in a state according to the programmed pad mux pull type.
According to 4.2.4.2 Timing to Switch Signal Voltage in "SD Specifications
Part 1 Ph
commit 0e43884cca77218d2eccc331396e8 ("ARM: dts: dra71-evm: Select pull
down for mmc1_clk line in default mode") modified mmc1_pins_default
pinctrl group in dra71-evm.dts to change the CLK line to
PIN_INPUT_PULLDOWN. However instead of changing the pinctrl group,
use the new pinctrl group "mmc1_pin
From: Hari Nagalla
Wilink8 module is a combo wireless connectivity card based
on Texas Instrument's wl18xx solution.
Add support for the wlan capabilities of this module by muxing
the relevant mmc lines, and setting the required device-tree
data.
Signed-off-by: Eyal Reizer
Signed-off-by: Hari
From: Vishal Mahaveer
Add support for WLAN using wilink8 module. On dra76-evm, MMC4 is
used for connecting to wilink8 module.
Signed-off-by: Vishal Mahaveer
Signed-off-by: Kishon Vijay Abraham I
---
arch/arm/boot/dts/dra76-evm.dts | 31 +++
1 file changed, 31 inser
>From 4.18 kernel, all the MMC controller instances in DRA7
are programmed using sdhci based driver (sdhci-omap.c). Document
this new requirement here. Both omap2plus_defconfig and
multi_v7_defconfig has CONFIG_MMC_SDHCI_OMAP enabled.
Signed-off-by: Kishon Vijay Abraham I
---
Documentation/arm/O
While the supported UHS mode can be obtained from CAPA2
register, SD Host Controller Standard Specification
doesn't define bits for MMC's HS200 and DDR mode capability.
Add properties to indicate MMC HS200 and DDR speed mode capability in
dt node.
Signed-off-by: Kishon Vijay Abraham I
---
arch/a
From: Hari Nagalla
The wilink module is a combo wireless connectivity sdio
card based on Texas Instrument's wl18xx solution. It is a
4-wire, 1.8V, embedded sdio wlan device with an external
irq line and is power-controlled by a gpio-based fixed
regulator.
Add pinmux configuration and IODelay val
On TI's DRA74x EVM, EVM_3V6 is connected is connected to the VBAT line
of the wilink card. Model it here so that it can be used while adding
wilink8 WLAN support.
Signed-off-by: Kishon Vijay Abraham I
---
arch/arm/boot/dts/dra7-evm.dts | 42 ++
1 file changed, 42
On 2018/4/25 13:46, Jaegeuk Kim wrote:
> syzbot hit the following crash on upstream commit
> 83beed7b2b26f232d782127792dd0cd4362fdc41 (Fri Apr 20 17:56:32 2018 +)
> Merge branch 'fixes' of
> git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal
> syzbot dashboard link:
> ht
During a short period when the bus voltage is switched from 3.3v to 1.8v,
(to enumerate UHS mode), the mmc module is disabled and the mmc IO lines
are kept in a state according to the programmed pad mux pull type.
According to 4.2.4.2 Timing to Switch Signal Voltage in "SD Specifications
Part 1 Ph
Use sdhci-omap programming model based on the generic sdhci
library for programming the eMMC/SD/SDIO controller.
Signed-off-by: Kishon Vijay Abraham I
---
.../boot/dts/am57xx-beagle-x15-common.dtsi| 4 +--
arch/arm/boot/dts/am57xx-beagle-x15.dts | 1 +
arch/arm/boot/dts/am57xx-idk-co
On 04/24/2018 10:32 PM, Krzysztof Kozlowski wrote:
> The Exynos5440 is not actively developed, there are no development
> boards available and probably there are no real products with it.
> Remove wide-tree support for Exynos5440.
>
> Signed-off-by: Krzysztof Kozlowski
Reviewed-by: Sylwester Naw
On Tue, Apr 24, 2018 at 7:38 PM, Maxime Ripard
wrote:
> On Tue, Apr 24, 2018 at 07:04:12PM +0530, Jagan Teki wrote:
>> Allwinner A64 has display engine pipeline like other Allwinner SOC's
>> A83T/H3/H5.
>>
>> A64 DE2 behaviour similar to Allwinner A83T where mixer0, connected to tcon0
>> with
>>
From: Sekhar Nori
Include dra76x-mmc-iodelay.dtsi which has pinmux and IODelay
configuration values for the various MMC modes for am574x SoC
and use it in the pinctrl properties of MMC devicetree
nodes present in am574x-idk.dts.
Signed-off-by: Sekhar Nori
Signed-off-by: Kishon Vijay Abraham I
Hi Abhishek,
On Wed, 25 Apr 2018 12:02:29 +0530, Abhishek Sahu
wrote:
> On 2018-04-23 12:28, Miquel Raynal wrote:
> > Hi Abhishek,
> > > On Mon, 23 Apr 2018 11:58:42 +0530, Abhishek Sahu
> > wrote:
> > >> On 2018-04-22 21:49, Miquel Raynal wrote:
> >> > Hi Abhishek,
> >> > > On Thu, 12
Em Wed, Apr 25, 2018 at 08:27:31AM -0400, Liang, Kan escreveu:
>
>
> On 4/24/2018 3:29 PM, Arnaldo Carvalho de Melo wrote:
> > Em Tue, Apr 24, 2018 at 03:23:06PM -0400, Liang, Kan escreveu:
> > > On 4/24/2018 3:17 PM, Arnaldo Carvalho de Melo wrote:
> > > > Em Tue, Apr 24, 2018 at 11:20:13AM -070
commit 18aa0f4bca701cb078a6 ("ARM: dts: am57xx-idk: Select pull down
for mmc1_clk line in default mode") modified mmc1_pins_default
pinctrl group in am57xx-idk-common.dtsi in order to change the CLK
line to PIN_INPUT_PULLDOWN. However instead of modifying the pinctrl
group, use the new pinctrl grou
mmc specific pinmux is selected from dra72x-mmc-iodelay.dtsi, so remove
it from dra72-evm-common.dtsi.
Signed-off-by: Kishon Vijay Abraham I
---
arch/arm/boot/dts/dra72-evm-common.dtsi | 27 -
1 file changed, 27 deletions(-)
diff --git a/arch/arm/boot/dts/dra72-evm-commo
During a short period when the bus voltage is switched from 3.3v to 1.8v,
(to enumerate UHS mode), the mmc module is disabled and the mmc IO lines
are kept in a state according to the programmed pad mux pull type.
According to 4.2.4.2 Timing to Switch Signal Voltage in "SD Specifications
Part 1 Ph
On Wed, Apr 25, 2018 at 08:12:31PM +0900, Tetsuo Handa wrote:
> From: Tetsuo Handa
>
> syzbot is reporting crashes triggered by memory allocation fault injection
> at tty_ldisc_get() [1]. As an attempt to handle OOM in a graceful way, we
> have tried commit 5362544bebe85071 ("tty: don't panic on
Add "vqmmc-supply" property for mmc2 to indicate the supply connected
to the IO lines.
Signed-off-by: Kishon Vijay Abraham I
---
arch/arm/boot/dts/dra71-evm.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/dra71-evm.dts b/arch/arm/boot/dts/dra71-evm.dts
index ebc4bbae981
On 04/24/2018 11:28 PM, Christoph Hellwig wrote:
> On Tue, Apr 24, 2018 at 10:27:21PM -0700, Eric Dumazet wrote:
>> When adding tcp mmap() implementation, I forgot that socket lock
>> had to be taken before current->mm->mmap_sem. syzbot eventually caught
>> the bug.
>>
>> Since we can not lock th
On 2018/4/25 13:46, Jaegeuk Kim wrote:
> syzbot has tested the proposed patch but the reproducer still triggered crash:
> kernel BUG at fs/f2fs/inode.c:LINE!
>
> F2FS-fs (loop1): invalid crc value
> F2FS-fs (loop5): Magic Mismatch, valid(0xf2f52010) - read(0x0)
> F2FS-fs (loop5): Can't find valid
I'm really sorry for you to wait.
Since I made a few mistakes previously, I really don't want to make a
mistake again.
Therefore I have been reading documents more carefully and learning
the approved email client (i.e., mutt).
It is almost done. I will send a patch very soon.
Again, I'm really sor
On 2018/4/25 13:46, Jaegeuk Kim wrote:
> syzbot hit the following crash on upstream commit
> 87ef12027b9b1dd0e0b12cf311fbcb19f9d92539 (Wed Apr 18 19:48:17 2018 +)
> Merge tag 'ceph-for-4.17-rc2' of git://github.com/ceph/ceph-client
> syzbot dashboard link:
> https://syzkaller.appspot.com/bug?e
On Wed, 25 Apr 2018, Rafael J. Wysocki wrote:
> On Wednesday, April 25, 2018 10:52:18 AM CEST Rafael J. Wysocki wrote:
> > On Tuesday, April 24, 2018 10:09:28 AM CEST Thomas Gleixner wrote:
> > > On Mon, 23 Apr 2018, John Stultz wrote:
> > >
> > > > On Mon, Apr 23, 2018 at 7:45 PM, Genki Sky wrot
Hi Jaegeuk,
This patch makes generic/008 failed, because for fallocate case, total valid
block count can not be calculated by gathering valid_blocks of all sit entries.
Thanks,
On 2018/4/25 13:46, Jaegeuk Kim wrote:
> This patch enhances sanity check for SIT entries.
>
> syzbot hit the followin
On 2018/4/25 13:46, Jaegeuk Kim wrote:
> This is to give a option for user to be able to recover B/foo in the below
> case.
>
> mkdir A
> sync()
> rename(A, B)
> creat (B/foo)
> fsync (B/foo)
> ---crash---
That makes sense, IMO, it will be better to cover cross rename case as well?
Thanks,
>
>
On Thu, 2018-04-19 at 21:54 +0800, Yixun Lan wrote:
> This patch try to add AO clock and Reset driver for Amlogic's
> Meson-AXG SoC.
> Please note that patch 7 need to wait for the DTS changes[3] merged
> into mainline first, otherwise it will break the serial console.
>
> patch 2: factor the
On 04/24, Andrey Grodzovsky wrote:
>
> --- a/drivers/gpu/drm/scheduler/gpu_scheduler.c
> +++ b/drivers/gpu/drm/scheduler/gpu_scheduler.c
> @@ -227,9 +227,10 @@ void drm_sched_entity_do_release(struct
> drm_gpu_scheduler *sched,
> return;
> /**
>* The client will not que
On Wed, 2018-04-25 at 13:12 +0200, Petr Mladek wrote:
> There are few printk formats that make sense only with two or more
> specifiers. Also some specifiers make sense only when a kernel feature
> is enabled.
>
> The handling of unknown specifiers is strange, inconsistent, and
> even leaking the
On 04/25/2018 03:14 AM, Daniel Vetter wrote:
On Tue, Apr 24, 2018 at 05:37:08PM -0400, Andrey Grodzovsky wrote:
On 04/24/2018 05:21 PM, Eric W. Biederman wrote:
Andrey Grodzovsky writes:
On 04/24/2018 03:44 PM, Daniel Vetter wrote:
On Tue, Apr 24, 2018 at 05:46:52PM +0200, Michel Dänzer
On Wed, 2018-04-25 at 13:12 +0200, Petr Mladek wrote:
> Move the non-trivial code from the long pointer() function. We are
> going
> to add a check for the access to the address that will make it even
> more
> complicated.
>
> Also it is better to warn about unknown specifier instead of falling
>
On 25 April 2018 13:31, Greg Kroah-Hartman wrote:
> On Wed, Apr 25, 2018 at 01:26:33AM +0200, Sebastian Reichel wrote:
> > Hi Greg,
> >
> > On Tue, Apr 24, 2018 at 03:57:49PM +0200, Greg Kroah-Hartman wrote:
> > > On Mon, Apr 23, 2018 at 03:10:55PM +0100, Adam Thomson wrote:
> > > > This patch set
On 04/24, Andrey Grodzovsky wrote:
>
> Currently calling wait_event_killable as part of exiting process
> will stall forever since SIGKILL generation is suppresed by PF_EXITING.
See my reply to 2/3,
> In our partilaur case AMDGPU driver wants to flush all GPU jobs in
> flight before shutting down
Hi Philippe,
On Wednesday, 25 April 2018 15:20:04 EEST Philippe CORNU wrote:
> On 04/25/2018 11:01 AM, Laurent Pinchart wrote:
> > On Wednesday, 25 April 2018 10:53:13 EEST Philippe Cornu wrote:
> >> Add optional power supplies using the description found in
> >> "SiI9022A/SiI9024A HDMI Transmitte
On Wed, Apr 25, 2018 at 05:48:42PM +0800, Qu Wenruo wrote:
> Hi,
>
> When testing IO heavy work on my VM backed by Ryzen 1700 CPU, I turned
> to brd modules, but surprisingly, the speed is even slower than some HDD:
>
> ---
> $ sudo modprobe brd rd_nr=1 rd_size=1048576
> $ dd if=/dev/zero of=/dev
On Tuesday, April 24, 2018 10:32:35 PM Krzysztof Kozlowski wrote:
> The Exynos5440 is not actively developed, there are no development
> boards available and probably there are no real products with it.
> Remove wide-tree support for Exynos5440.
Thanks for doing this.
> Signed-off-by: Krzysztof K
Hi Dan,
On Thu, Apr 19, 2018 at 08:15:10AM +0300, Dan Carpenter wrote:
> Several people have asked me to write this and I think one person was
> maybe working on writing it themselves...
>
> The point of this check is to find place which might be vulnerable to
> the Spectre vulnerability. In the
tty_insert_flip_string_fixed_flag() copies chars to the buffer indicated
by th->used and updates tb->used.
But tty_insert_flip_string_fixed_flag() can be executed concurrently and
tb->used can be updated improperly.
It leads slab-out-of-bound write in tty_insert_flip_string_fixed_flag or
slab-out-o
Hi, Robin,
Thanks for the patch. It was some time since I put together that code,
but I remember hitting something similar to
https://www.linuxquestions.org/questions/linux-kernel-70/%27nents%27-argument-of-dma_unmap_sg-4175621964/
Even if it's clear from the documentation that orig_nents sho
On 04/24, Daniel Vetter wrote:
>
> wait_event_killabel doesn't check for fatal_signal_pending before calling
> schedule, so definitely has a nice race there.
This is fine. See the signal_pending_state() check in __schedule().
And this doesn't differ from wait_event_interruptible(), it too doesn't
On Tue, Apr 24, 2018 at 09:22:18PM +0200, Thomas Gleixner wrote:
> Kaike reported that in tests rdma hrtimers occasionaly stopped working. He
> did great debugging, which provided enough context to decode the problem.
>
> CPU 3 CPU 2
>
> idle
> start sched_tim
In some places, we still used get_seconds() instead of
ktime_get_real_seconds(), and I'm changing the remaining ones now to
all use ktime_get_real_seconds() so we use the full available range for
timestamps instead of overflowing the 'unsigned long' return value in
year 2106 on 32-bit kernels.
Sig
The shmid64_ds/semid64_ds/msqid64_ds data structures have been extended
to contain extra fields for storing the upper bits of the time stamps,
this patch does the other half of the job and and fills the new fields on
32-bit architectures as well as 32-bit tasks running on a 64-bit kernel
in compat
Three ipc syscalls (mq_timedsend, mq_timedreceive and and semtimedop)
take a timespec argument. After we move 32-bit architectures over to
useing 64-bit time_t based syscalls, we need seperate entry points for
the old 32-bit based interfaces.
This changes the #ifdef guards for the existing 32-bit
This extends the x86 copy of the sysvipc data structures to deal with
32-bit user space that has 64-bit time_t and wants to see timestamps
beyond 2038.
Fortunately, x86 has padding for this purpose in all the data structures,
so we can just add extra fields. With msgid64_ds and shmid64_ds, the
dat
On Fri 2018-04-20 10:52:21, Sergey Senozhatsky wrote:
> On (04/19/18 12:02), Petr Mladek wrote:
> > On Thu 2018-04-19 10:42:50, Sergey Senozhatsky wrote:
> > > We wake up klogd very late - only when current console_sem owner
> > > is done pushing pending kernel messages to the serial/net consoles.
This is a preparatation for changing over __kernel_timespec to 64-bit
times, which involves assigning new system call numbers for mq_timedsend(),
mq_timedreceive() and semtimedop() for compatibility with future y2038
proof user space.
The existing ABIs will remain available through compat code.
S
Most architectures now use the asm-generic copy of the sysvipc data
structures (msqid64_ds, semid64_ds, shmid64_ds), which use 32-bit
__kernel_time_t on 32-bit architectures but have padding behind them to
allow extending the type to 64-bit.
Unfortunately, that fails on all big-endian architecture
32-bit architectures implementing 64BIT_TIME and COMPAT_32BIT_TIME
need to have the traditional semtimedop() behavior with 32-bit timestamps
for sys_ipc() by calling compat_ksys_semtimedop(), while those that
are not yet converted need to keep using ksys_semtimedop() like
64-bit architectures do.
sparc, uses a nonstandard variation of the generic sysvipc
data structures, intended to have the padding moved around
so it can deal with big-endian 32-bit user space that has
64-bit time_t.
Unlike most architectures, sparc actually succeeded in
defining this right for big-endian CPUs, but as ever
powerpc, uses a nonstandard variation of the generic sysvipc
data structures, intended to have the padding moved around
so it can deal with big-endian 32-bit user space that has
64-bit time_t.
powerpc has the same definition as parisc and sparc, but now also
supports little-endian mode, which is n
parisc, uses a nonstandard variation of the generic sysvipc
data structures, intended to have the padding moved around
so it can deal with big-endian 32-bit user space that has
64-bit time_t.
Unlike most architectures, parisc actually succeeded in
defining this right for big-endian CPUs, but as ev
Hi Thomas,
This is a small update to last week's patch series, I hope I
have worked out all the remaining issues now. If nothing else
comes up, please pull into tip for 4.18. The commits are
based on top of what you already pulled into timers/core, so
you can either add these to the same branch or
The s390 msgbuf/sembuf/shmbuf header files are all identical to the
version from asm-generic.
This patch removes the files and replaces them with 'generic-y'
statements, to avoid having to modify each copy when we extend sysvipc
to deal with 64-bit time_t in 32-bit user space.
Note that unlike al
The alpha ipcbuf/msgbuf/sembuf/shmbuf header files are all identical
to the version from asm-generic.
This patch removes the files and replaces them with 'generic-y'
statements as part of the y2038 series. Since there is no 32-bit
syscall support for alpha, we don't need the other changes, but
it'
MIPS is the weirdest case for sysvipc, because each of the
three data structures is done differently:
* msqid64_ds has padding in the right place so we could in theory
extend this one to just have 64-bit values instead of time_t.
As this does not work for most of the other combinations,
we j
xtensa, uses a nonstandard variation of the generic sysvipc
data structures, intended to have the padding moved around
so it can deal with big-endian 32-bit user space that has
64-bit time_t.
xtensa tries hard to define the structures so they work
in both big-endian and little-endian systems with
The ia64 ipcbuf/msgbuf/sembuf/shmbuf header files are all identical
to the version from asm-generic.
This patch removes the files and replaces them with 'generic-y'
statements as part of the y2038 changes. While ia64 no longer has
a compat mode and doesn't need the file any more, it seem nicer
to
Both 32-bit amd 64-bit ARM use the asm-generic header files for their
sysvipc data structures, so no special care is needed to make those
work beyond y2038, with the one exception of compat mode: Since there
is no asm-generic definition of the compat mode IPC structures, ARM64
provides its own copy
Signed-off-by: Thiebaud Weksteen
---
drivers/char/tpm/tpm_eventlog_of.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/char/tpm/tpm_eventlog_of.c
b/drivers/char/tpm/tpm_eventlog_of.c
index 96fd5646f866..ea0f16f19d73 100644
--- a/drivers/char/tpm/tpm_eventlog_of.c
Add "vqmmc-supply" property for mmc0/mmc1 to indicate the supply connected
to the IO lines. Also add dt node for ldo1 regulator required for mmc1
vqmmc-supply.
Signed-off-by: Kishon Vijay Abraham I
---
arch/arm/boot/dts/keystone-k2g-evm.dts | 10 ++
1 file changed, 10 insertions(+)
diff
Use sdhci-omap programming model based on the generic sdhci
library for programming the MMC/SD controller.
Signed-off-by: Kishon Vijay Abraham I
---
arch/arm/boot/dts/keystone-k2g.dtsi | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/arch/arm/boot/dts/keystone-k2g
Enable CONFIG_MMC_SDHCI_OMAP so that TI's K2G SoC
can use sdhci-omap driver for MMC/SD controller.
Signed-off-by: Kishon Vijay Abraham I
---
arch/arm/configs/keystone_defconfig | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/configs/keystone_defconfig
b/arch/arm/configs/keystone
Update mmc dt node to use sdhci-omap binding instead of omap_hsmmc
binding.
I've also updated keystone_defconfig to enable CONFIG_MMC_SDHCI_OMAP.
Everyone who use a custom .config should also enable
CONFIG_MMC_SDHCI_OMAP for MMC to work.
This series should be merged only after [1]
[1] -> https://
Hi Vaishali,
Thank you for the patch.
On Wednesday, 25 April 2018 15:10:36 EEST Vaishali Thakkar wrote:
> As specified in drm_drv.c, drm_dev_unref is a compatibility alias
> for drm_dev_put and shouldn't be used in new code. So, use
> drm_dev_put instead.
This looks good to me. However, how abou
>From 4.18 kernel, all the MMC controller instances in DRA7
are programmed using sdhci based driver (sdhci-omap.c). Document
this new requirement here. Both omap2plus_defconfig and
multi_v7_defconfig has CONFIG_MMC_SDHCI_OMAP enabled.
Signed-off-by: Kishon Vijay Abraham I
---
Changes from v3:
Add
* Kishon Vijay Abraham I [180425 12:57]:
> --- a/arch/arm/boot/dts/dra74x-mmc-iodelay.dtsi
> +++ b/arch/arm/boot/dts/dra74x-mmc-iodelay.dtsi
> @@ -49,6 +49,17 @@
> >;
> };
>
> + mmc1_pins_default_no_clk_pu: mmc1_pins_default_no_clk_pu {
> + pinctrl-single,pins
On Wed, Apr 25, 2018 at 3:22 PM, Oleg Nesterov wrote:
> On 04/24, Daniel Vetter wrote:
>>
>> wait_event_killabel doesn't check for fatal_signal_pending before calling
>> schedule, so definitely has a nice race there.
>
> This is fine. See the signal_pending_state() check in __schedule().
>
> And t
The last commit to "remoteproc_core.c":
880f5b388252 remoteproc: Pass type of shutdown to subdev remove
added a Boolean flag to the subdevice remove method, to distinguish
between graceful shutdown and a crash. Unfortunately, the names of
the parameters were inconsistent, and in fact have opposi
On 4/25/2018 8:59 AM, Arnaldo Carvalho de Melo wrote:
Em Wed, Apr 25, 2018 at 08:27:31AM -0400, Liang, Kan escreveu:
On 4/24/2018 3:29 PM, Arnaldo Carvalho de Melo wrote:
Em Tue, Apr 24, 2018 at 03:23:06PM -0400, Liang, Kan escreveu:
On 4/24/2018 3:17 PM, Arnaldo Carvalho de Melo wrote:
E
On Wed, Apr 25, 2018 at 10:20:50PM +0900, DaeRyong Jeong wrote:
> tty_insert_flip_string_fixed_flag() copies chars to the buffer indicated
> by th->used and updates tb->used.
> But tty_insert_flip_string_fixed_flag() can be executed concurrently and
> tb->used can be updated improperly.
> It leads
pm_runtime handles sdio power on and power off transitions.
An old workaround for trying to control the power explicitly from the
driver was in fact causing failures on suspend/resume as the mmc layer
already power the module on resume.
In case of resume pm_runtime_get sync returns a positive devi
On 04/24/2018 10:27 PM, Eric Dumazet wrote:
> When adding tcp mmap() implementation, I forgot that socket lock
> had to be taken before current->mm->mmap_sem. syzbot eventually caught
> the bug.
> +
...
> + down_read(¤t->mm->mmap_sem);
> +
> + ret = -EINVAL;
> + vma = find_vma(c
On Wed, 25 Apr 2018 14:38:36 +0200,
Paul Menzel wrote:
>
> Dear Takashi,
>
>
> On 04/25/18 14:34, Takashi Iwai wrote:
> > On Wed, 25 Apr 2018 14:29:31 +0200, Paul Menzel wrote:
>
> >> On 04/25/18 13:58, Takashi Iwai wrote:
> >>> On Wed, 25 Apr 2018 13:48:27 +0200, Paul Menzel wrote:
> >>
>
On Wed, Apr 25, 2018 at 7:02 PM, Laurent Pinchart
wrote:
> Hi Vaishali,
>
> Thank you for the patch.
>
> On Wednesday, 25 April 2018 15:10:36 EEST Vaishali Thakkar wrote:
>> As specified in drm_drv.c, drm_dev_unref is a compatibility alias
>> for drm_dev_put and shouldn't be used in new code. So,
On 04/24/2018 05:40 PM, Daniel Vetter wrote:
On Tue, Apr 24, 2018 at 05:02:40PM -0400, Andrey Grodzovsky wrote:
On 04/24/2018 03:44 PM, Daniel Vetter wrote:
On Tue, Apr 24, 2018 at 05:46:52PM +0200, Michel Dänzer wrote:
Adding the dri-devel list, since this is driver independent code.
On
On Fri, 06 Apr 2018, Heikki Krogerus wrote:
> Using reStructuredText literal-block element with ascii-art.
> That prevents the ascii art from being processed as
> reStructuredText.
>
> Reported-by: Masanari Iida
> Fixes: bdecb33af34f ("usb: typec: API for controlling USB Type-C
> Multiplexers")
Hi Vaishali,
On Wednesday, 25 April 2018 16:42:59 EEST Vaishali Thakkar wrote:
> On Wed, Apr 25, 2018 at 7:02 PM, Laurent Pinchart wrote:
> > On Wednesday, 25 April 2018 15:10:36 EEST Vaishali Thakkar wrote:
> >> As specified in drm_drv.c, drm_dev_unref is a compatibility alias
> >> for drm_dev_pu
Hi Anson,
On Wed, Apr 25, 2018 at 2:36 AM, Anson Huang wrote:
> Sorry, I made a mistake here, the MAX7320 IO0 is for adjusting FEC1's voltage,
In this case you need to pass the 'phy-supply' property inside the fec
node and add a regulator that is controlled via MAX7320 IO0 pin.
501 - 600 of 1348 matches
Mail list logo
