Two new events, VFIO_CCW_EVENT_ONLINE and VFIO_CCW_EVENT_OFFLINE
allow to handle the enabling and disabling of a Sub Channel and
the shutdown, quiesce and reset operations are changed accordingly.
Signed-off-by: Pierre Morel
---
drivers/s390/cio/vfio_ccw_drv.c |
Two new events, VFIO_CCW_EVENT_ONLINE and VFIO_CCW_EVENT_OFFLINE
allow to handle the enabling and disabling of a Sub Channel and
the shutdown, quiesce and reset operations are changed accordingly.
Signed-off-by: Pierre Morel
---
drivers/s390/cio/vfio_ccw_drv.c | 47
This patch simplifies the IO request handling to handle the only
implemented request: SSCH.
Other request are invalid and get a return value of -EINVAL.
This patch change the event name to VFIO_CCW_EVENT_SSCH_REQ to reflect
what is done and prepare for future implementation of other requests.
This patch simplifies the IO request handling to handle the only
implemented request: SSCH.
Other request are invalid and get a return value of -EINVAL.
This patch change the event name to VFIO_CCW_EVENT_SSCH_REQ to reflect
what is done and prepare for future implementation of other requests.
The VFIO_CCW_EVENT_INIT event allows to export the initial state
into the FSM.
Signed-off-by: Pierre Morel
---
drivers/s390/cio/vfio_ccw_drv.c | 26 +++---
drivers/s390/cio/vfio_ccw_fsm.c | 21 +
The VFIO_CCW_EVENT_INIT event allows to export the initial state
into the FSM.
Signed-off-by: Pierre Morel
---
drivers/s390/cio/vfio_ccw_drv.c | 26 +++---
drivers/s390/cio/vfio_ccw_fsm.c | 21 +
drivers/s390/cio/vfio_ccw_ops.c | 11
The fsm_func_t function type definition does not need the event
parameter since all functions are in a state/event table.
Signed-off-by: Pierre Morel
---
drivers/s390/cio/vfio_ccw_fsm.c | 34 +++---
drivers/s390/cio/vfio_ccw_private.h |
The fsm_func_t function type definition does not need the event
parameter since all functions are in a state/event table.
Signed-off-by: Pierre Morel
---
drivers/s390/cio/vfio_ccw_fsm.c | 34 +++---
drivers/s390/cio/vfio_ccw_private.h | 5 ++---
2 files changed,
The Sub channel event callback is threaded using workqueues.
The work uses the FSM introducing the VFIO_CCW_EVENT_SCH_EVENT
event.
The update of the SCHIB is now done inside the FSM function.
Signed-off-by: Pierre Morel
---
drivers/s390/cio/vfio_ccw_drv.c | 33
We use mutex around the FSM function call to make the FSM
event handling and state change atomic.
Signed-off-by: Pierre Morel
---
drivers/s390/cio/vfio_ccw_drv.c | 3 +--
drivers/s390/cio/vfio_ccw_fsm.c | 2 --
drivers/s390/cio/vfio_ccw_ops.c | 4 +---
The Sub channel event callback is threaded using workqueues.
The work uses the FSM introducing the VFIO_CCW_EVENT_SCH_EVENT
event.
The update of the SCHIB is now done inside the FSM function.
Signed-off-by: Pierre Morel
---
drivers/s390/cio/vfio_ccw_drv.c | 33
We use mutex around the FSM function call to make the FSM
event handling and state change atomic.
Signed-off-by: Pierre Morel
---
drivers/s390/cio/vfio_ccw_drv.c | 3 +--
drivers/s390/cio/vfio_ccw_fsm.c | 2 --
drivers/s390/cio/vfio_ccw_ops.c | 4 +---
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
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
On Thu, Apr 19, 2018 at 10:58 AM, Miklos Szeredi wrote:
> On Wed, Apr 18, 2018 at 7:40 PM, Song Liu wrote:
>> As Miklos reported and suggested:
>>
>> This pattern repeats two times in trace_uprobe.c and in
>> kernel/events/core.c as well:
>>
>>
On Thu, Apr 19, 2018 at 10:58 AM, Miklos Szeredi wrote:
> On Wed, Apr 18, 2018 at 7:40 PM, Song Liu wrote:
>> As Miklos reported and suggested:
>>
>> This pattern repeats two times in trace_uprobe.c and in
>> kernel/events/core.c as well:
>>
>> ret = kern_path(filename, LOOKUP_FOLLOW,
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
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
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
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
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.
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.
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
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
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
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
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
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
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
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
Dave Martin writes:
> On Sun, Apr 15, 2018 at 11:16:04AM -0700, Linus Torvalds wrote:
>
> [...]
>
>> The other thing we should do is to get rid of the stupid padding.
>> Right now "struct siginfo" is pointlessly padded to 128 bytes. That is
>> completely insane, when it's
Dave Martin writes:
> On Sun, Apr 15, 2018 at 11:16:04AM -0700, Linus Torvalds wrote:
>
> [...]
>
>> The other thing we should do is to get rid of the stupid padding.
>> Right now "struct siginfo" is pointlessly padded to 128 bytes. That is
>> completely insane, when it's always just zero in the
Pavel Machek wrote:
> > There is currently no way to verify the resume image when returning
> > from hibernate. This might compromise the signed modules trust model,
> > so until we can work with signed hibernate images we disable it when the
> > kernel is locked down.
>
> I'd
The architectures that support 32-bit compat mode define a number
of simple types for use in compat handlers. About half of those
are identical between architectures, and some of those are also
required now by handlers shared with CONFIG_COMPAT_32BIT_TIME
functions on 32-bit architectures.
Let's
Pavel Machek wrote:
> > There is currently no way to verify the resume image when returning
> > from hibernate. This might compromise the signed modules trust model,
> > so until we can work with signed hibernate images we disable it when the
> > kernel is locked down.
>
> I'd rather see
The architectures that support 32-bit compat mode define a number
of simple types for use in compat handlers. About half of those
are identical between architectures, and some of those are also
required now by handlers shared with CONFIG_COMPAT_32BIT_TIME
functions on 32-bit architectures.
Let's
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.
On 13/04/2018 16:05, Cornelia Huck wrote:
When we call ssch, an interrupt might already be pending once we
return from the START SUBCHANNEL instruction. Therefore we need to
make sure interrupts are disabled until after we're done with our
processing.
Note that the subchannel lock is the same
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.
On 13/04/2018 16:05, Cornelia Huck wrote:
When we call ssch, an interrupt might already be pending once we
return from the START SUBCHANNEL instruction. Therefore we need to
make sure interrupts are disabled until after we're done with our
processing.
Note that the subchannel lock is the same
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
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
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
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
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
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
Op 19-04-18 om 13:05 schreef Fengguang Wu:
> Hi Maarten,
>
>> What extra dmesg output do you get when you boot with drm.debug=0x1f ?
>
> Attached is the dmesg with drm.debug=0x1f.
>
> Thanks,
> Fengguang
Ah so we're inheriting the FB 2x, once with 1280x1024, other with 1366x768:
kern :debug : [
Op 19-04-18 om 13:05 schreef Fengguang Wu:
> Hi Maarten,
>
>> What extra dmesg output do you get when you boot with drm.debug=0x1f ?
>
> Attached is the dmesg with drm.debug=0x1f.
>
> Thanks,
> Fengguang
Ah so we're inheriting the FB 2x, once with 1280x1024, other with 1366x768:
kern :debug : [
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.
Currently, the code block inside the for loop will never execute
more than once, because the function returns inmediately after
the first iteration, hence the execution of the code at the second
iteration is structurally dead and, code at line 281: return 0; is
never reached.
Based on the code
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
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.
Currently, the code block inside the for loop will never execute
more than once, because the function returns inmediately after
the first iteration, hence the execution of the code at the second
iteration is structurally dead and, code at line 281: return 0; is
never reached.
Based on the code
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
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
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
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
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
This is an update of a series I posted a long time ago [1], updating
the IPC subsystem to pass down 64-bit time stamps to user space.
In particular, for sys_msgctl, sys_semctl and sys_shmctl, I do not
introduce a completely new set of replacement system calls, but instead
extend the existing ones
This is an update of a series I posted a long time ago [1], updating
the IPC subsystem to pass down 64-bit time stamps to user space.
In particular, for sys_msgctl, sys_semctl and sys_shmctl, I do not
introduce a completely new set of replacement system calls, but instead
extend the existing ones
Pavel Machek wrote:
> > (1) chmod and chown are disallowed on debugfs objects (though the root dir
> > can be modified by mount and remount, but I'm not worried about that).
>
> This has nothing to do with the lockdown goals, right? I find chown of
> such files quite nice,
Pavel Machek wrote:
> > (1) chmod and chown are disallowed on debugfs objects (though the root dir
> > can be modified by mount and remount, but I'm not worried about that).
>
> This has nothing to do with the lockdown goals, right? I find chown of
> such files quite nice, to allow
On Thu, 19 Apr 2018 09:40:33 +0900
Namhyung Kim wrote:
> > I totally agree. I just want to make sure that whatever we come up with
> > will be well thought out. Perhaps we can wait till November to talk
> > about it.
>
> I'm not sure I can go to LPC this year, but
On Thu, 19 Apr 2018 09:40:33 +0900
Namhyung Kim wrote:
> > I totally agree. I just want to make sure that whatever we come up with
> > will be well thought out. Perhaps we can wait till November to talk
> > about it.
>
> I'm not sure I can go to LPC this year, but definitely interested in
>
Add support for RTC (Real Time Clock) to STM32MP157C SoC.
Signed-off-by: Amelie Delaunay
---
arch/arm/boot/dts/stm32mp157c.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/stm32mp157c.dtsi
b/arch/arm/boot/dts/stm32mp157c.dtsi
index
Add support for RTC (Real Time Clock) to STM32MP157C SoC.
Signed-off-by: Amelie Delaunay
---
arch/arm/boot/dts/stm32mp157c.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/stm32mp157c.dtsi
b/arch/arm/boot/dts/stm32mp157c.dtsi
index bc3eddc..954 100644
---
This series adds support for STM32 RTC to stm32mp157c SoC and enable it
on stm32mp157c-ed1 board.
Amelie Delaunay (2):
ARM: dts: stm32: add RTC support to stm32mp157c
ARM: dts: stm32: enable RTC on stm32mp157c-ed1
arch/arm/boot/dts/stm32mp157c-ed1.dts | 4
This series adds support for STM32 RTC to stm32mp157c SoC and enable it
on stm32mp157c-ed1 board.
Amelie Delaunay (2):
ARM: dts: stm32: add RTC support to stm32mp157c
ARM: dts: stm32: enable RTC on stm32mp157c-ed1
arch/arm/boot/dts/stm32mp157c-ed1.dts | 4
Enable RTC (Real Time Clock) on stm32mp157c-ed1 board.
Signed-off-by: Amelie Delaunay
---
arch/arm/boot/dts/stm32mp157c-ed1.dts | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/stm32mp157c-ed1.dts
b/arch/arm/boot/dts/stm32mp157c-ed1.dts
index
Enable RTC (Real Time Clock) on stm32mp157c-ed1 board.
Signed-off-by: Amelie Delaunay
---
arch/arm/boot/dts/stm32mp157c-ed1.dts | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/stm32mp157c-ed1.dts
b/arch/arm/boot/dts/stm32mp157c-ed1.dts
index 9f90337a..f9c4f8f 100644
[CC'ing Linus W.]
On Thu, Apr 19, 2018 at 4: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
Seems
[CC'ing Linus W.]
On Thu, Apr 19, 2018 at 4: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
Seems fine and other drivers in platform/ also call dev_get_drvdata
From: Colin Ian King
Currently logical and is being used instead of bitwise and. Fix this.
Detected by CoverityScan, CID#1468008 ("Logical vs bitwise operator")
Fixes: d59fb2856223 ("ASoC: rt5668: add rt5668B codec driver")
Signed-off-by: Colin Ian King
From: Colin Ian King
Currently logical and is being used instead of bitwise and. Fix this.
Detected by CoverityScan, CID#1468008 ("Logical vs bitwise operator")
Fixes: d59fb2856223 ("ASoC: rt5668: add rt5668B codec driver")
Signed-off-by: Colin Ian King
---
sound/soc/codecs/rt5668.c | 2 +-
The Microchip LAN78XX family of devices are Ethernet controllers with
a USB interface. Despite being discoverable devices it can be useful to
be able to configure them from Device Tree, particularly in low-cost
applications without an EEPROM or programmed OTP.
This patch set adds support for
There is a standard mechanism for locating and using a MAC address from
the Device Tree. Use this facility in the lan78xx driver to support
applications without programmed EEPROM or OTP. At the same time,
regularise the handling of the different address sources.
Signed-off-by: Phil Elwell
The Microchip LAN78XX family of devices are Ethernet controllers with
a USB interface. Despite being discoverable devices it can be useful to
be able to configure them from Device Tree, particularly in low-cost
applications without an EEPROM or programmed OTP.
This patch set adds support for
There is a standard mechanism for locating and using a MAC address from
the Device Tree. Use this facility in the lan78xx driver to support
applications without programmed EEPROM or OTP. At the same time,
regularise the handling of the different address sources.
Signed-off-by: Phil Elwell
---
Add support for DT property "microchip,led-modes", a vector of zero
to four cells (u32s) in the range 0-15, each of which sets the mode
for one of the LEDs. Some possible values are:
0=link/activity 1=link1000/activity
2=link100/activity 3=link10/activity
Add support for DT property "microchip,led-modes", a vector of zero
to four cells (u32s) in the range 0-15, each of which sets the mode
for one of the LEDs. Some possible values are:
0=link/activity 1=link1000/activity
2=link100/activity 3=link10/activity
This commit adds device tree description of Kieback & Peter GmbH
iMX6Q TPC board.
Signed-off-by: Lukasz Majewski
Reviewed-by: Fabio Estevam
---
Changes for v6:
- Add space between // and SPDX
- Replace 'disp0' with 'display'
- Replace 'rtc: ds1307@32' with
This commit adds device tree description of Kieback & Peter GmbH
iMX6Q TPC board.
Signed-off-by: Lukasz Majewski
Reviewed-by: Fabio Estevam
---
Changes for v6:
- Add space between // and SPDX
- Replace 'disp0' with 'display'
- Replace 'rtc: ds1307@32' with 'ds1307: rtc@32'
- Replace 'codec:
The Microchip LAN78XX family of devices are Ethernet controllers with
a USB interface. Despite being discoverable devices it can be useful to
be able to configure them from Device Tree, particularly in low-cost
applications without an EEPROM or programmed OTP.
This patch set adds support for
The Microchip LAN78XX family of devices are Ethernet controllers with
a USB interface. Despite being discoverable devices it can be useful to
be able to configure them from Device Tree, particularly in low-cost
applications without an EEPROM or programmed OTP.
Document the supported properties in
The Microchip LAN78XX family of devices are Ethernet controllers with
a USB interface. Despite being discoverable devices it can be useful to
be able to configure them from Device Tree, particularly in low-cost
applications without an EEPROM or programmed OTP.
This patch set adds support for
The Microchip LAN78XX family of devices are Ethernet controllers with
a USB interface. Despite being discoverable devices it can be useful to
be able to configure them from Device Tree, particularly in low-cost
applications without an EEPROM or programmed OTP.
Document the supported properties in
On Thu, Apr 19, 2018 at 09:19:03AM -0500, Alex G. wrote:
> On the other side, you lose readability as soon as you get a few more
> handlers and the function becomes too long.
No you don't - you split it properly.
> And more importantly, you lose generality: it's not obvious that
> there's
On Thu, Apr 19, 2018 at 09:19:03AM -0500, Alex G. wrote:
> On the other side, you lose readability as soon as you get a few more
> handlers and the function becomes too long.
No you don't - you split it properly.
> And more importantly, you lose generality: it's not obvious that
> there's
On 19/04/18 15:13, Jerome Brunet wrote:
On Fri, 2018-03-16 at 16:01 +0100, Jerome Brunet wrote:
This changeset adds write support to meson efuse driver.
The first patch just changes the way the nvmem data are allocated w/o
any functional changes. The second patches actually adds write
On 19/04/18 15:13, Jerome Brunet wrote:
On Fri, 2018-03-16 at 16:01 +0100, Jerome Brunet wrote:
This changeset adds write support to meson efuse driver.
The first patch just changes the way the nvmem data are allocated w/o
any functional changes. The second patches actually adds write
On Thursday, April 04/19/18, 2018 at 07:10:30 +0530, Dave Young wrote:
> On 04/18/18 at 06:01pm, Rahul Lakkireddy wrote:
> > On Wednesday, April 04/18/18, 2018 at 11:45:46 +0530, Dave Young wrote:
> > > Hi Rahul,
> > > On 04/17/18 at 01:14pm, Rahul Lakkireddy wrote:
> > > > On production servers
On Thursday, April 04/19/18, 2018 at 07:10:30 +0530, Dave Young wrote:
> On 04/18/18 at 06:01pm, Rahul Lakkireddy wrote:
> > On Wednesday, April 04/18/18, 2018 at 11:45:46 +0530, Dave Young wrote:
> > > Hi Rahul,
> > > On 04/17/18 at 01:14pm, Rahul Lakkireddy wrote:
> > > > On production servers
On 04/18/2018 04:31 AM, Pierre Morel wrote:
On 17/04/2018 20:11, Tony Krowiak wrote:
On 04/17/2018 12:55 PM, Pierre Morel wrote:
On 17/04/2018 18:22, Tony Krowiak wrote:
On 04/17/2018 12:13 PM, Pierre Morel wrote:
On 17/04/2018 17:02, Tony Krowiak wrote:
On 04/16/2018 06:51 AM, Pierre Morel
On 04/18/2018 04:31 AM, Pierre Morel wrote:
On 17/04/2018 20:11, Tony Krowiak wrote:
On 04/17/2018 12:55 PM, Pierre Morel wrote:
On 17/04/2018 18:22, Tony Krowiak wrote:
On 04/17/2018 12:13 PM, Pierre Morel wrote:
On 17/04/2018 17:02, Tony Krowiak wrote:
On 04/16/2018 06:51 AM, Pierre Morel
We should get drvdata from struct device directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang
---
Build tested only. buildbot is happy. Please apply individually.
drivers/clk/samsung/clk-s3c2410-dclk.c | 6 ++
We should get drvdata from struct device directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang
---
Build tested only. buildbot is happy. Please apply individually.
drivers/clk/samsung/clk-s3c2410-dclk.c | 6 ++
1 file changed, 2 insertions(+),
We should get drvdata from struct device directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang
---
Build tested only. buildbot is happy. Please apply individually.
drivers/dma/dw/platform.c | 6 ++
1 file
We should get drvdata from struct device directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang
---
Build tested only. buildbot is happy. Please apply individually.
drivers/dma/dw/platform.c | 6 ++
1 file changed, 2 insertions(+), 4
We should get drvdata from struct device directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang
---
Build tested only. buildbot is happy. Please apply individually.
drivers/crypto/exynos-rng.c | 6 ++
We should get drvdata from struct device directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang
---
Build tested only. buildbot is happy. Please apply individually.
drivers/crypto/exynos-rng.c | 6 ++
drivers/crypto/picoxcell_crypto.c | 6
901 - 1000 of 2008 matches
Mail list logo