> On Sep 28, 2018, at 12:52 AM, Peter Zijlstra wrote:
>
> On Fri, Sep 28, 2018 at 07:23:20AM +, Song Liu wrote:
>> Hi Peter,
>>> #ifdef CONFIG_UPROBE_EVENTS
>>> +PMU_FORMAT_ATTR(ref_ctr_offset, "config:63-24");
>>
>> I guess you meant this part? This is for uprobe only, so I put
>> it
> On Sep 28, 2018, at 12:52 AM, Peter Zijlstra wrote:
>
> On Fri, Sep 28, 2018 at 07:23:20AM +, Song Liu wrote:
>> Hi Peter,
>>> #ifdef CONFIG_UPROBE_EVENTS
>>> +PMU_FORMAT_ATTR(ref_ctr_offset, "config:63-24");
>>
>> I guess you meant this part? This is for uprobe only, so I put
>> it
On Fri, Sep 28, 2018 at 10:04:29AM +0100, Dave Stevenson wrote:
> Hi Nate
>
> Thanks for the patch.
>
> On Fri, 28 Sep 2018 at 01:53, Nathan Chancellor
> wrote:
> >
> > Clang warns:
> >
> > drivers/staging/vc04_services/bcm2835-camera/controls.c:59:18: warning:
> > variable 'mains_freq_qmenu'
On Fri, Sep 28, 2018 at 10:04:29AM +0100, Dave Stevenson wrote:
> Hi Nate
>
> Thanks for the patch.
>
> On Fri, 28 Sep 2018 at 01:53, Nathan Chancellor
> wrote:
> >
> > Clang warns:
> >
> > drivers/staging/vc04_services/bcm2835-camera/controls.c:59:18: warning:
> > variable 'mains_freq_qmenu'
This patch removes #if 0 code blocks and usages of the
functions defined in the #if 0 code block. It removes
the macro msdc_irq_restore() and replaces its usage
with call to the function called in the macro definition.
Issue found by checkpatch.
Signed-off-by: Nishad Kamdar
---
Changes in v4:
This patch removes #if 0 code blocks and usages of the
functions defined in the #if 0 code block. It removes
the macro msdc_irq_restore() and replaces its usage
with call to the function called in the macro definition.
Issue found by checkpatch.
Signed-off-by: Nishad Kamdar
---
Changes in v4:
From: He Zhe
Add KBUILD_MODNAME to make prints more clear and correct wrong casting that
might cut off the normal output.
Signed-off-by: He Zhe
Cc: pmla...@suse.com
Cc: sergey.senozhat...@gmail.com
Cc: rost...@goodmis.org
---
v2:
Correct wrong cast in sprintf
kernel/printk/printk.c | 7
From: He Zhe
Add KBUILD_MODNAME to make prints more clear and correct wrong casting that
might cut off the normal output.
Signed-off-by: He Zhe
Cc: pmla...@suse.com
Cc: sergey.senozhat...@gmail.com
Cc: rost...@goodmis.org
---
v2:
Correct wrong cast in sprintf
kernel/printk/printk.c | 7
From: He Zhe
log_buf_len_setup does not check input argument before passing it to
simple_strtoull. The argument would be a NULL pointer if "log_buf_len",
without its value, is set in command line and thus causes the following
panic.
PANIC: early exception 0xe3 IP 10:aaeacd0d error 0 cr2
In order to introduce per-cpu cgroup storage, let's generalize
bpf cgroup core to support multiple cgroup storage types.
Potentially, per-node cgroup storage can be added later.
This commit is mostly a formal change that replaces
cgroup_storage pointer with a array of cgroup_storage pointers.
It
From: He Zhe
log_buf_len_setup does not check input argument before passing it to
simple_strtoull. The argument would be a NULL pointer if "log_buf_len",
without its value, is set in command line and thus causes the following
panic.
PANIC: early exception 0xe3 IP 10:aaeacd0d error 0 cr2
In order to introduce per-cpu cgroup storage, let's generalize
bpf cgroup core to support multiple cgroup storage types.
Potentially, per-node cgroup storage can be added later.
This commit is mostly a formal change that replaces
cgroup_storage pointer with a array of cgroup_storage pointers.
It
Em Fri, Sep 28, 2018 at 04:43:06PM +0530, Ravi Bangoria escreveu:
>
>
> On 09/28/2018 04:23 PM, Thomas Richter wrote:
> > S390 does not support the perf_event_open system call for
> > attribute type PERF_TYPE_BREAKPOINT. This results in test
> > failure for test 22:
> >
> > [root@s8360046
Em Fri, Sep 28, 2018 at 04:43:06PM +0530, Ravi Bangoria escreveu:
>
>
> On 09/28/2018 04:23 PM, Thomas Richter wrote:
> > S390 does not support the perf_event_open system call for
> > attribute type PERF_TYPE_BREAKPOINT. This results in test
> > failure for test 22:
> >
> > [root@s8360046
Hello,
syzbot found the following crash on:
HEAD commit:c127e59bee3e Merge tag 'for_v4.19-rc6' of git://git.kernel..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=13b2f32a40
kernel config: https://syzkaller.appspot.com/x/.config?x=dfb440e26f0a6f6f
Hello,
syzbot found the following crash on:
HEAD commit:c127e59bee3e Merge tag 'for_v4.19-rc6' of git://git.kernel..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=13b2f32a40
kernel config: https://syzkaller.appspot.com/x/.config?x=dfb440e26f0a6f6f
On Fri, 28 Sep 2018, Andy Lutomirski wrote:
> > On Sep 28, 2018, at 1:42 AM, Thomas Gleixner wrote:
> >
> >> On Fri, 28 Sep 2018, Martin Schwidefsky wrote:
> >> On Fri, 28 Sep 2018 09:12:10 +0200
> >> Geert Uytterhoeven wrote:
> >>> I don't know if that has happened, and whether it would work
On Fri, 28 Sep 2018, Andy Lutomirski wrote:
> > On Sep 28, 2018, at 1:42 AM, Thomas Gleixner wrote:
> >
> >> On Fri, 28 Sep 2018, Martin Schwidefsky wrote:
> >> On Fri, 28 Sep 2018 09:12:10 +0200
> >> Geert Uytterhoeven wrote:
> >>> I don't know if that has happened, and whether it would work
On Thu, Sep 27, 2018 at 04:10:29PM -0700, Kees Cook wrote:
> On Thu, Sep 27, 2018 at 3:48 PM, Tycho Andersen wrote:
> > On Thu, Sep 27, 2018 at 02:31:24PM -0700, Kees Cook wrote:
> >> On Thu, Sep 27, 2018 at 8:11 AM, Tycho Andersen wrote:
> >> struct seccomp_notif {
> >> __u16
On Thu, Sep 27, 2018 at 04:10:29PM -0700, Kees Cook wrote:
> On Thu, Sep 27, 2018 at 3:48 PM, Tycho Andersen wrote:
> > On Thu, Sep 27, 2018 at 02:31:24PM -0700, Kees Cook wrote:
> >> On Thu, Sep 27, 2018 at 8:11 AM, Tycho Andersen wrote:
> >> struct seccomp_notif {
> >> __u16
Yeah... :( All the remaining patches are similar and risky.
regards,
dan carpenter
Yeah... :( All the remaining patches are similar and risky.
regards,
dan carpenter
On Wed, Sep 26, 2018 at 08:16:57PM +0100, John Whitmore wrote:
> Remove the member variables TxSTBC and RxSTBC as neither is used in
> code.
>
> This is a coding style change which should not impact runtime code
> execution.
>
> Signed-off-by: John Whitmore
> ---
>
On Wed, Sep 26, 2018 at 08:16:57PM +0100, John Whitmore wrote:
> Remove the member variables TxSTBC and RxSTBC as neither is used in
> code.
>
> This is a coding style change which should not impact runtime code
> execution.
>
> Signed-off-by: John Whitmore
> ---
>
On Wed, Sep 26, 2018 at 08:16:56PM +0100, John Whitmore wrote:
> The member variables AdvCoding and GreenField are unused in code so
> have been removed from the structure and associated initialisation
> function.
>
> This is a coding style change which should have no impact on runtime
> code
On Wed, Sep 26, 2018 at 08:16:56PM +0100, John Whitmore wrote:
> The member variables AdvCoding and GreenField are unused in code so
> have been removed from the structure and associated initialisation
> function.
>
> This is a coding style change which should have no impact on runtime
> code
Hello all,
I've submitted a V3 following a KBuild warning.
You can thus drop this V2.
Thanks and sorry for the spamming.
Have a nice weekend.
Regards
On 09/28/2018 10:36 AM, Pierre-Yves MORDRET wrote:
> This serie adds support for M2M transfer triggered by STM32 DMA in order to
> transfer data
Hello all,
I've submitted a V3 following a KBuild warning.
You can thus drop this V2.
Thanks and sorry for the spamming.
Have a nice weekend.
Regards
On 09/28/2018 10:36 AM, Pierre-Yves MORDRET wrote:
> This serie adds support for M2M transfer triggered by STM32 DMA in order to
> transfer data
The following changes since commit 5223c9c1cbfc0cd4d0a1b50758e0949af3290fa1:
spi: spi-fsl-dspi: fix broken DSPI_EOQ_MODE (2018-08-28 20:55:23 +0100)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git
tags/spi-fix-v4.19-rc5
for you to
The following changes since commit 5223c9c1cbfc0cd4d0a1b50758e0949af3290fa1:
spi: spi-fsl-dspi: fix broken DSPI_EOQ_MODE (2018-08-28 20:55:23 +0100)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git
tags/spi-fix-v4.19-rc5
for you to
On Fri, Sep 28, 2018 at 10:48:57AM +0800, Baoquan He wrote:
> On 09/27/18 at 04:31pm, Masayoshi Mizuma wrote:
> > From: Masayoshi Mizuma
> >
> > Add warning message if the padding size for KASLR,
> > rand_mem_physical_padding, is not enough. The message also
> > says the suitable padding size.
>
On Fri, Sep 28, 2018 at 10:48:57AM +0800, Baoquan He wrote:
> On 09/27/18 at 04:31pm, Masayoshi Mizuma wrote:
> > From: Masayoshi Mizuma
> >
> > Add warning message if the padding size for KASLR,
> > rand_mem_physical_padding, is not enough. The message also
> > says the suitable padding size.
>
On 9/28/18 12:43 AM, Omar Sandoval wrote:
> On Fri, Sep 28, 2018 at 11:11:24AM +1000, Stephen Rothwell wrote:
>> Hi Jens,
>>
>> After merging the block tree, today's linux-next build (arm
>> multi_v7_defconfig) produced this warning:
>>
>> block/kyber-iosched.c:84:22: warning: integer overflow in
On 9/28/18 12:43 AM, Omar Sandoval wrote:
> On Fri, Sep 28, 2018 at 11:11:24AM +1000, Stephen Rothwell wrote:
>> Hi Jens,
>>
>> After merging the block tree, today's linux-next build (arm
>> multi_v7_defconfig) produced this warning:
>>
>> block/kyber-iosched.c:84:22: warning: integer overflow in
On Fri, 28 Sep 2018, Aaron Tomlin wrote:
> Extend the slub_debug syntax to "slub_debug=[,]*", where
> may contain an asterisk at the end. For example, the following would poison
> all kmalloc slabs:
Acked-by: Christoph Lameter
On Fri, 28 Sep 2018, Aaron Tomlin wrote:
> Extend the slub_debug syntax to "slub_debug=[,]*", where
> may contain an asterisk at the end. For example, the following would poison
> all kmalloc slabs:
Acked-by: Christoph Lameter
Currently the XUSB power domains used by the Tegra xHCI controller are
never powered off on the removal of the driver, however, they will be
powered off on probe failure. Update the removal code to be consistent
with the probe failure path to power off the XUSB power domains.
Signed-off-by: Jon
Currently the XUSB power domains used by the Tegra xHCI controller are
never powered off on the removal of the driver, however, they will be
powered off on probe failure. Update the removal code to be consistent
with the probe failure path to power off the XUSB power domains.
Signed-off-by: Jon
The generic power-domain framework has been updated to allow devices
that require more than one power-domain to create a new device for
each power-domain required and then link these new power-domain
devices to the consumer device.
Update the Tegra xHCI driver to use the new APIs provided by the
Populate the power-domain properties for the xHCI device for Tegra210.
Signed-off-by: Jon Hunter
---
arch/arm64/boot/dts/nvidia/tegra210.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/boot/dts/nvidia/tegra210.dtsi
b/arch/arm64/boot/dts/nvidia/tegra210.dtsi
index
The generic power-domain framework has been updated to allow devices
that require more than one power-domain to create a new device for
each power-domain required and then link these new power-domain
devices to the consumer device.
Update the Tegra xHCI driver to use the new APIs provided by the
Populate the power-domain properties for the xHCI device for Tegra210.
Signed-off-by: Jon Hunter
---
arch/arm64/boot/dts/nvidia/tegra210.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/boot/dts/nvidia/tegra210.dtsi
b/arch/arm64/boot/dts/nvidia/tegra210.dtsi
index
Now that the Tegra xHCI driver manages the XUSB power-domains itself,
remove the code to power-up the power-domains used by the xHCI device
from the PMC driver on boot.
Signed-off-by: Jon Hunter
---
drivers/soc/tegra/pmc.c | 16
1 file changed, 16 deletions(-)
diff --git
Now that the Tegra xHCI driver manages the XUSB power-domains itself,
remove the code to power-up the power-domains used by the xHCI device
from the PMC driver on boot.
Signed-off-by: Jon Hunter
---
drivers/soc/tegra/pmc.c | 16
1 file changed, 16 deletions(-)
diff --git
Add details for power-domains to the Tegra xHCI bindings so that
generic power-domains can be used for inconjunction with the xHCI
driver.
Signed-off-by: Jon Hunter
---
Documentation/devicetree/bindings/usb/nvidia,tegra124-xusb.txt | 8
1 file changed, 8 insertions(+)
diff --git
This series add genpd support for the Tegra xHCI device that requires
more than one power-domain to operate.
This series is making changes to more than one subsystem and at first
glance may look like a maintainers nightmare. However, my proposal is
this, once reviewed and people are happy ...
1.
Add details for power-domains to the Tegra xHCI bindings so that
generic power-domains can be used for inconjunction with the xHCI
driver.
Signed-off-by: Jon Hunter
---
Documentation/devicetree/bindings/usb/nvidia,tegra124-xusb.txt | 8
1 file changed, 8 insertions(+)
diff --git
This series add genpd support for the Tegra xHCI device that requires
more than one power-domain to operate.
This series is making changes to more than one subsystem and at first
glance may look like a maintainers nightmare. However, my proposal is
this, once reviewed and people are happy ...
1.
> On Sep 28, 2018, at 1:42 AM, Thomas Gleixner wrote:
>
>> On Fri, 28 Sep 2018, Martin Schwidefsky wrote:
>> On Fri, 28 Sep 2018 09:12:10 +0200
>> Geert Uytterhoeven wrote:
>>> I don't know if that has happened, and whether it would work on s390 now.
>>
>> commit
> On Sep 28, 2018, at 1:42 AM, Thomas Gleixner wrote:
>
>> On Fri, 28 Sep 2018, Martin Schwidefsky wrote:
>> On Fri, 28 Sep 2018 09:12:10 +0200
>> Geert Uytterhoeven wrote:
>>> I don't know if that has happened, and whether it would work on s390 now.
>>
>> commit
The patch
spi: mediatek: add bindings for Mediatek MT2712 soc platform
has been applied to the spi tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24
The patch
spi: mediatek: add bindings for Mediatek MT2712 soc platform
has been applied to the spi tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24
The patch
regulator: Support regulators where voltage ranges are selectable
has been applied to the regulator tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in
The patch
regulator/mfd: bd718xx: rename bd71837/bd71847 common instances
has been applied to the regulator tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in
The patch
regulator: Support regulators where voltage ranges are selectable
has been applied to the regulator tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in
The patch
regulator/mfd: bd718xx: rename bd71837/bd71847 common instances
has been applied to the regulator tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in
The patch
regulator/mfd: Support ROHM BD71847 power management IC
has been applied to the regulator tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next
The patch
regulator/mfd: Support ROHM BD71847 power management IC
has been applied to the regulator tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next
The patch
regulator: dt bindings: add BD71847 device-tree binding documentation
has been applied to the regulator tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime
The patch
mfd: dt bindings: add BD71847 device-tree binding documentation
has been applied to the regulator tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in
The patch
regulator: dt bindings: add BD71847 device-tree binding documentation
has been applied to the regulator tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime
The patch
mfd: dt bindings: add BD71847 device-tree binding documentation
has been applied to the regulator tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in
The patch
regulator: bd718XX use pickable ranges
has been applied to the regulator tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent
The patch
regulator: bd718XX use pickable ranges
has been applied to the regulator tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent
The patch
regulator: bd718xx: rename bd71837 to 718xx
has been applied to the regulator tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and
The patch
regulator: bd718xx: rename bd71837 to 718xx
has been applied to the regulator tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and
Tvrtko,
On Fri, 28 Sep 2018, Tvrtko Ursulin wrote:
> On 28/09/2018 11:26, Thomas Gleixner wrote:
> > On Wed, 19 Sep 2018, Tvrtko Ursulin wrote:
> >
> > It would be very helpful if you cc all involved people on the cover letter
> > instead of just cc'ing your own pile of email addresses. CC'ed
Tvrtko,
On Fri, 28 Sep 2018, Tvrtko Ursulin wrote:
> On 28/09/2018 11:26, Thomas Gleixner wrote:
> > On Wed, 19 Sep 2018, Tvrtko Ursulin wrote:
> >
> > It would be very helpful if you cc all involved people on the cover letter
> > instead of just cc'ing your own pile of email addresses. CC'ed
On Fri, Sep 21, 2018 at 11:52:58AM -0700, Lee Jones wrote:
> > Great, thanks. There's also the MFD DT bindings and another patch later
> > on with Acked-for-MFD tags on them, should I convert the tags to acks,
> > apply those as well and include them in the pull request?
> Please.
The
On Fri, Sep 21, 2018 at 11:52:58AM -0700, Lee Jones wrote:
> > Great, thanks. There's also the MFD DT bindings and another patch later
> > on with Acked-for-MFD tags on them, should I convert the tags to acks,
> > apply those as well and include them in the pull request?
> Please.
The
On Fri, Sep 28, 2018 at 08:23:03AM -0500, Alex Elder wrote:
> On 09/28/2018 07:26 AM, Niklas Cassel wrote:
> > On Fri, Sep 28, 2018 at 06:41:11AM -0500, Alex Elder wrote:
> >> Was there something wrong with this patch? I sent it a long time
> >> ago but it still applies cleanly. I can re-send if
On Fri, Sep 28, 2018 at 08:23:03AM -0500, Alex Elder wrote:
> On 09/28/2018 07:26 AM, Niklas Cassel wrote:
> > On Fri, Sep 28, 2018 at 06:41:11AM -0500, Alex Elder wrote:
> >> Was there something wrong with this patch? I sent it a long time
> >> ago but it still applies cleanly. I can re-send if
On 9/28/2018 6:24 AM, p...@codeaurora.org wrote:
1) Does that seem like the right place?
IMO, I think best is to call after driver callback in PCI core.
A driver specific action can cause some of these errors.
We don't want to return with outstanding errors.
2) I guess all we need now would
On 9/28/2018 6:24 AM, p...@codeaurora.org wrote:
1) Does that seem like the right place?
IMO, I think best is to call after driver callback in PCI core.
A driver specific action can cause some of these errors.
We don't want to return with outstanding errors.
2) I guess all we need now would
On Fri, 28 Sep 2018 at 15:37, Bartlomiej Zolnierkiewicz
wrote:
>
> "Samsung PM Suspend debug" feature (controlled by SAMSUNG_PM_DEBUG
> config option) is not working properly (debug messages are not
> displayed after resume) on Exynos platforms because GPIOs restore
> code is not implemented.
On Fri, 28 Sep 2018 at 15:37, Bartlomiej Zolnierkiewicz
wrote:
>
> "Samsung PM Suspend debug" feature (controlled by SAMSUNG_PM_DEBUG
> config option) is not working properly (debug messages are not
> displayed after resume) on Exynos platforms because GPIOs restore
> code is not implemented.
On Thu, Sep 27, 2018 at 12:27:10PM -0700, Florian Fainelli wrote:
> When THUMB2_KERNEL is enabled, we would be setting the secondary core's
> entry point to secondary_startup() which is already Thumb2 code, utilize
> secondary_startup_arm() which takes care of doing the mode switching for
> us.
On Thu, Sep 27, 2018 at 12:27:10PM -0700, Florian Fainelli wrote:
> When THUMB2_KERNEL is enabled, we would be setting the secondary core's
> entry point to secondary_startup() which is already Thumb2 code, utilize
> secondary_startup_arm() which takes care of doing the mode switching for
> us.
On Thu, Sep 27, 2018 at 12:27:09PM -0700, Florian Fainelli wrote:
> When THUMB2_KERNEL is enabled, we would be failing to resume from an
> idle or system suspend call where the reentry point is set to
> cpu_resume() because that function is in Thumb2. Utilize
> cpu_resume_arm() for ARM 32-bit
On Thu, Sep 27, 2018 at 12:27:09PM -0700, Florian Fainelli wrote:
> When THUMB2_KERNEL is enabled, we would be failing to resume from an
> idle or system suspend call where the reentry point is set to
> cpu_resume() because that function is in Thumb2. Utilize
> cpu_resume_arm() for ARM 32-bit
On Fri, 28 Sep 2018 15:42:35 +0200
Christian Borntraeger wrote:
> On 09/28/2018 03:41 PM, Halil Pasic wrote:
> >
> >
> > On 09/28/2018 03:35 PM, Cornelia Huck wrote:
> >> On Fri, 28 Sep 2018 09:33:21 -0400
> >> Tony Krowiak wrote:
> >>
> >>> From: Tony Krowiak
> >>>
> >>> Fixes case
On Fri, 28 Sep 2018 15:42:35 +0200
Christian Borntraeger wrote:
> On 09/28/2018 03:41 PM, Halil Pasic wrote:
> >
> >
> > On 09/28/2018 03:35 PM, Cornelia Huck wrote:
> >> On Fri, 28 Sep 2018 09:33:21 -0400
> >> Tony Krowiak wrote:
> >>
> >>> From: Tony Krowiak
> >>>
> >>> Fixes case
On 09/28/2018 03:43 PM, Tony Krowiak wrote:
> From: Tony Krowiak
>
> Removes extraneous text from third line below:
>
> +05 CEX5A Accelerator
> +05.0047 CEX5A Accelerator
> +05.00ff CEX5A Accelerator (5,4), (5,171), (6,4), (6,171),
>
On 09/28/2018 03:43 PM, Tony Krowiak wrote:
> From: Tony Krowiak
>
> Removes extraneous text from third line below:
>
> +05 CEX5A Accelerator
> +05.0047 CEX5A Accelerator
> +05.00ff CEX5A Accelerator (5,4), (5,171), (6,4), (6,171),
>
From: Tony Krowiak
Removes extraneous text from third line below:
+05 CEX5A Accelerator
+05.0047 CEX5A Accelerator
+05.00ff CEX5A Accelerator (5,4), (5,171), (6,4), (6,171),
^^^
---
Documentation/s390/vfio-ap.txt | 2
From: Tony Krowiak
Removes extraneous text from third line below:
+05 CEX5A Accelerator
+05.0047 CEX5A Accelerator
+05.00ff CEX5A Accelerator (5,4), (5,171), (6,4), (6,171),
^^^
---
Documentation/s390/vfio-ap.txt | 2
The following changes since commit 5b394b2ddf0347bef56e50c69a58773c94343ff3:
Linux 4.19-rc1 (2018-08-26 14:11:59 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
tags/regulator-v4.19-rc5
for you to fetch changes up to
The following changes since commit 5b394b2ddf0347bef56e50c69a58773c94343ff3:
Linux 4.19-rc1 (2018-08-26 14:11:59 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
tags/regulator-v4.19-rc5
for you to fetch changes up to
On 09/28/2018 03:41 PM, Halil Pasic wrote:
>
>
> On 09/28/2018 03:35 PM, Cornelia Huck wrote:
>> On Fri, 28 Sep 2018 09:33:21 -0400
>> Tony Krowiak wrote:
>>
>>> From: Tony Krowiak
>>>
>>> Fixes case statement in vfio_ap_mdev_copy_masks() function in
>>> vfio-ap-ops.c.
>>> ---
>>>
On 09/28/2018 03:41 PM, Halil Pasic wrote:
>
>
> On 09/28/2018 03:35 PM, Cornelia Huck wrote:
>> On Fri, 28 Sep 2018 09:33:21 -0400
>> Tony Krowiak wrote:
>>
>>> From: Tony Krowiak
>>>
>>> Fixes case statement in vfio_ap_mdev_copy_masks() function in
>>> vfio-ap-ops.c.
>>> ---
>>>
On 09/28/2018 03:35 PM, Cornelia Huck wrote:
> On Fri, 28 Sep 2018 09:33:21 -0400
> Tony Krowiak wrote:
>
>> From: Tony Krowiak
>>
>> Fixes case statement in vfio_ap_mdev_copy_masks() function in
>> vfio-ap-ops.c.
>> ---
>> drivers/s390/crypto/vfio_ap_ops.c | 3 ++-
>> 1 file changed, 2
On 09/28/2018 03:35 PM, Cornelia Huck wrote:
> On Fri, 28 Sep 2018 09:33:21 -0400
> Tony Krowiak wrote:
>
>> From: Tony Krowiak
>>
>> Fixes case statement in vfio_ap_mdev_copy_masks() function in
>> vfio-ap-ops.c.
>> ---
>> drivers/s390/crypto/vfio_ap_ops.c | 3 ++-
>> 1 file changed, 2
On 09/28/2018 03:35 PM, Cornelia Huck wrote:
> On Fri, 28 Sep 2018 09:33:21 -0400
> Tony Krowiak wrote:
>
>> From: Tony Krowiak
>>
>> Fixes case statement in vfio_ap_mdev_copy_masks() function in
>> vfio-ap-ops.c.
>> ---
>> drivers/s390/crypto/vfio_ap_ops.c | 3 ++-
>> 1 file changed, 2
On 09/28/2018 03:35 PM, Cornelia Huck wrote:
> On Fri, 28 Sep 2018 09:33:21 -0400
> Tony Krowiak wrote:
>
>> From: Tony Krowiak
>>
>> Fixes case statement in vfio_ap_mdev_copy_masks() function in
>> vfio-ap-ops.c.
>> ---
>> drivers/s390/crypto/vfio_ap_ops.c | 3 ++-
>> 1 file changed, 2
[ Re-sending without the corporate footer garbage... ]
On Wed, Sep 05, 2018 at 03:34:41PM +0100, Will Deacon wrote:
>Hi all,
>
>This is a resend of:
>
> http://lists.infradead.org/pipermail/linux-arm-kernel/2018-July/593559.html
>
>now based on 4.19-rc2.
>
>The Debian folks have observed a
[ Re-sending without the corporate footer garbage... ]
On Wed, Sep 05, 2018 at 03:34:41PM +0100, Will Deacon wrote:
>Hi all,
>
>This is a resend of:
>
> http://lists.infradead.org/pipermail/linux-arm-kernel/2018-July/593559.html
>
>now based on 4.19-rc2.
>
>The Debian folks have observed a
I will fold in.
On 09/28/2018 03:33 PM, Tony Krowiak wrote:
> From: Tony Krowiak
>
> Fixes case statement in vfio_ap_mdev_copy_masks() function in
> vfio-ap-ops.c.
> ---
> drivers/s390/crypto/vfio_ap_ops.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git
I will fold in.
On 09/28/2018 03:33 PM, Tony Krowiak wrote:
> From: Tony Krowiak
>
> Fixes case statement in vfio_ap_mdev_copy_masks() function in
> vfio-ap-ops.c.
> ---
> drivers/s390/crypto/vfio_ap_ops.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git
"Samsung PM Suspend debug" feature (controlled by SAMSUNG_PM_DEBUG
config option) is not working properly (debug messages are not
displayed after resume) on Exynos platforms because GPIOs restore
code is not implemented.
Add PLAT_S3C24XX, ARCH_S3C64XX and ARCH_S5PV210 dependencies to
"Samsung PM Suspend debug" feature (controlled by SAMSUNG_PM_DEBUG
config option) is not working properly (debug messages are not
displayed after resume) on Exynos platforms because GPIOs restore
code is not implemented.
Add PLAT_S3C24XX, ARCH_S3C64XX and ARCH_S5PV210 dependencies to
701 - 800 of 1218 matches
Mail list logo
