Am Mittwoch, 4. Juli 2018, 14:41:22 CEST schrieb Sascha Hauer:
> This patch adds the various helper functions needed for authentication
> support. We need functions to hash nodes, to embed HMACs into a node and
> to compare hashes and HMACs. Most functions first check if this
> filesystem is
Am Mittwoch, 4. Juli 2018, 14:41:22 CEST schrieb Sascha Hauer:
> This patch adds the various helper functions needed for authentication
> support. We need functions to hash nodes, to embed HMACs into a node and
> to compare hashes and HMACs. Most functions first check if this
> filesystem is
Am Mittwoch, 4. Juli 2018, 14:41:19 CEST schrieb Sascha Hauer:
> The superblock node is read/modified/written several times throughout
> the UBIFS code. Instead of reading it from the device each time just
> keep a copy in memory and write back the modified copy when necessary.
> This patch helps
Am Mittwoch, 4. Juli 2018, 14:41:19 CEST schrieb Sascha Hauer:
> The superblock node is read/modified/written several times throughout
> the UBIFS code. Instead of reading it from the device each time just
> keep a copy in memory and write back the modified copy when necessary.
> This patch helps
Hi Bartosz,
I love your patch! Perhaps something to improve:
[auto build test WARNING on clk/clk-next]
[also build test WARNING on v4.19-rc1 next-20180827]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci
Hi Bartosz,
I love your patch! Perhaps something to improve:
[auto build test WARNING on clk/clk-next]
[also build test WARNING on v4.19-rc1 next-20180827]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci
Free the vdev->msi_perm in error path.
Signed-off-by: Li Qiang
---
drivers/vfio/pci/vfio_pci_config.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/vfio/pci/vfio_pci_config.c
b/drivers/vfio/pci/vfio_pci_config.c
index 115a36f6f403..62023b4a373b 100644
---
Free the vdev->msi_perm in error path.
Signed-off-by: Li Qiang
---
drivers/vfio/pci/vfio_pci_config.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/vfio/pci/vfio_pci_config.c
b/drivers/vfio/pci/vfio_pci_config.c
index 115a36f6f403..62023b4a373b 100644
---
Hi Joe,
On Sun, Aug 26, 2018 at 8:50 PM, Joe Perches wrote:
> On Sun, 2018-08-26 at 19:57 +0200, Miguel Ojeda wrote:
>> Instead of using version checks per-compiler to define (or not) each
>> attribute,
>> use __has_attribute to test for them, following the cleanup started with
>> commit
Hi Joe,
On Sun, Aug 26, 2018 at 8:50 PM, Joe Perches wrote:
> On Sun, 2018-08-26 at 19:57 +0200, Miguel Ojeda wrote:
>> Instead of using version checks per-compiler to define (or not) each
>> attribute,
>> use __has_attribute to test for them, following the cleanup started with
>> commit
Chips such as imx6sll and imx7ulp have no ethernet support so the common
development usecase of nfs boot is supported via usb ethernet dongles.
Add drivers for additional usbnet device directly into the kernel image
image produced by the imx defconfig.
This list is based on the usbnet devices
Chips such as imx6sll and imx7ulp have no ethernet support so the common
development usecase of nfs boot is supported via usb ethernet dongles.
Add drivers for additional usbnet device directly into the kernel image
image produced by the imx defconfig.
This list is based on the usbnet devices
Hi Pavel,
I would appreciate if you could send the feedback for the patch.
Thanks!
Masa
On 08/24/2018 04:29 AM, Michal Hocko wrote:
> On Fri 24-08-18 00:03:25, Naoya Horiguchi wrote:
>> (CCed related people)
>
> Fixup Pavel email.
>
>>
>> Hi Mizuma-san,
>>
>> Thank you for the report.
>> The
Hi Pavel,
I would appreciate if you could send the feedback for the patch.
Thanks!
Masa
On 08/24/2018 04:29 AM, Michal Hocko wrote:
> On Fri 24-08-18 00:03:25, Naoya Horiguchi wrote:
>> (CCed related people)
>
> Fixup Pavel email.
>
>>
>> Hi Mizuma-san,
>>
>> Thank you for the report.
>> The
On Tue, Aug 21, 2018 at 10:55 AM AceLan Kao wrote:
>
> The incomplete report flooded after S3 and touchscreen becomes
> malfunctioned.
> [ 1367.646244] i2c_hid i2c-CUST:00: i2c_hid_get_input: incomplete report
> (58/18785)
> [ 1367.649471] i2c_hid i2c-CUST:00: i2c_hid_get_input:
On Tue, Aug 21, 2018 at 10:55 AM AceLan Kao wrote:
>
> The incomplete report flooded after S3 and touchscreen becomes
> malfunctioned.
> [ 1367.646244] i2c_hid i2c-CUST:00: i2c_hid_get_input: incomplete report
> (58/18785)
> [ 1367.649471] i2c_hid i2c-CUST:00: i2c_hid_get_input:
2018-08-27 12:39 GMT+02:00 Mike Rapoport :
> On Mon, Aug 27, 2018 at 10:21:01AM +0200, Bartosz Golaszewski wrote:
>> Use devm_kstrdup_const() in the pmc-atom driver. This mostly serves as
>> an example of how to use this new routine to shrink driver code.
>>
>> While we're at it: replace a call to
2018-08-27 12:39 GMT+02:00 Mike Rapoport :
> On Mon, Aug 27, 2018 at 10:21:01AM +0200, Bartosz Golaszewski wrote:
>> Use devm_kstrdup_const() in the pmc-atom driver. This mostly serves as
>> an example of how to use this new routine to shrink driver code.
>>
>> While we're at it: replace a call to
On 08/24/2018 06:04 PM, Luca Ceresoli wrote:
> The default value of the PERIOD_LEN register is 0 and results in
> axi-i2s keeping TLAST always asserted in its AXI Stream output.
>
> When the AXI Stream is sent to a Xilinx AXI-DMA, this results in the
> DMA generating an interrupt flood and ALSA
On 08/24/2018 06:04 PM, Luca Ceresoli wrote:
> The default value of the PERIOD_LEN register is 0 and results in
> axi-i2s keeping TLAST always asserted in its AXI Stream output.
>
> When the AXI Stream is sent to a Xilinx AXI-DMA, this results in the
> DMA generating an interrupt flood and ALSA
Hi Sean,
On Thu, Aug 23, 2018 at 6:40 PM Sean O'Brien wrote:
>
> USB device
> Vendor 05ac (Apple)
> Device 026c (Magic Keyboard with Numeric Keypad)
>
> Bluetooth devices
> Vendor 004c (Apple)
> Device 0267 (Magic Keyboard)
> Device 026c (Magic Keyboard
Hi Sean,
On Thu, Aug 23, 2018 at 6:40 PM Sean O'Brien wrote:
>
> USB device
> Vendor 05ac (Apple)
> Device 026c (Magic Keyboard with Numeric Keypad)
>
> Bluetooth devices
> Vendor 004c (Apple)
> Device 0267 (Magic Keyboard)
> Device 026c (Magic Keyboard
On Wed, Aug 22, 2018 at 02:05:07PM +0300, Matti Vaittinen wrote:
> For example ROHM BD71837 and ROHM BD71847 Power management ICs have
> regulators which provide multiple linear ranges. Ranges can be
> selected by individual non contagious bit in vsel register. Add
> regmap helper functions for
On Wed, Aug 22, 2018 at 02:05:07PM +0300, Matti Vaittinen wrote:
> For example ROHM BD71837 and ROHM BD71847 Power management ICs have
> regulators which provide multiple linear ranges. Ranges can be
> selected by individual non contagious bit in vsel register. Add
> regmap helper functions for
On Fri, 24 Aug 2018 22:18:22 -0400
Steven Rostedt wrote:
> On Fri, 17 Aug 2018 01:43:20 +0900
> Masami Hiramatsu wrote:
>
> > Add a testcase for tracing_cpumask with function tracer.
> >
> > Signed-off-by: Masami Hiramatsu
> > ---
> > .../selftests/ftrace/test.d/ftrace/func_cpumask.tc |
On Fri, 24 Aug 2018 22:18:22 -0400
Steven Rostedt wrote:
> On Fri, 17 Aug 2018 01:43:20 +0900
> Masami Hiramatsu wrote:
>
> > Add a testcase for tracing_cpumask with function tracer.
> >
> > Signed-off-by: Masami Hiramatsu
> > ---
> > .../selftests/ftrace/test.d/ftrace/func_cpumask.tc |
Hi Derek,
next time, could you please avoid using html mails when replying
to the mailing list? They are not clear.
On Fri, Aug 24, 2018 at 04:07:41PM -0700, dbasehore . wrote:
>
>
> On Fri, Aug 24, 2018 at 1:49 AM Andi Shyti wrote:
>
> Hi Derek,
>
> > > > On Thu, Aug 23, 2018 at
Hi Derek,
next time, could you please avoid using html mails when replying
to the mailing list? They are not clear.
On Fri, Aug 24, 2018 at 04:07:41PM -0700, dbasehore . wrote:
>
>
> On Fri, Aug 24, 2018 at 1:49 AM Andi Shyti wrote:
>
> Hi Derek,
>
> > > > On Thu, Aug 23, 2018 at
On 27/08/18 13:26, Adrian Hunter wrote:
> On 27/08/18 13:08, Thierry Reding wrote:
>> On Fri, Aug 10, 2018 at 09:13:57PM +0300, Aapo Vienamo wrote:
>>> Hi all,
>>> This series implements support for HS400 signaling on Tegra210 and
>>> Tegra186. This includes programming the DQS trimmer values,
On 27/08/18 13:26, Adrian Hunter wrote:
> On 27/08/18 13:08, Thierry Reding wrote:
>> On Fri, Aug 10, 2018 at 09:13:57PM +0300, Aapo Vienamo wrote:
>>> Hi all,
>>> This series implements support for HS400 signaling on Tegra210 and
>>> Tegra186. This includes programming the DQS trimmer values,
> On 2 Aug 2018, at 6:07 pm, Thomas Gleixner wrote:
>
> The actiual purpose of sending V4 which is identical to V3 is?
>
>>
>> Signed-off-by: Jacek Tomaka
>> ---
Yes, thanks. I missed it initially, sorry.
> It's good practice to add a
>
> V3 -> V4: changed foo
> V2 -> V3: fixed bla
> ...
> On 2 Aug 2018, at 6:07 pm, Thomas Gleixner wrote:
>
> The actiual purpose of sending V4 which is identical to V3 is?
>
>>
>> Signed-off-by: Jacek Tomaka
>> ---
Yes, thanks. I missed it initially, sorry.
> It's good practice to add a
>
> V3 -> V4: changed foo
> V2 -> V3: fixed bla
> ...
I cannot speak to how widespread it has been adopted, but the linux
(kernel) package for version 4.17.17 has been successfully built and
installed for ia64 under Debian ports. There is clearly more work to
do to get ia64 rehabilitated, but there are over 10,000 packages
currently successfully
I cannot speak to how widespread it has been adopted, but the linux
(kernel) package for version 4.17.17 has been successfully built and
installed for ia64 under Debian ports. There is clearly more work to
do to get ia64 rehabilitated, but there are over 10,000 packages
currently successfully
On 27/08/18 13:26, Adrian Hunter wrote:
> On 27/08/18 13:10, Thierry Reding wrote:
>> On Fri, Aug 10, 2018 at 09:08:02PM +0300, Aapo Vienamo wrote:
>>> Hi all,
>>>
>>> This series implements support for faster signaling modes on Tegra
>>> SDHCI controllers. This series consist of several parts:
On 27/08/18 13:26, Adrian Hunter wrote:
> On 27/08/18 13:10, Thierry Reding wrote:
>> On Fri, Aug 10, 2018 at 09:08:02PM +0300, Aapo Vienamo wrote:
>>> Hi all,
>>>
>>> This series implements support for faster signaling modes on Tegra
>>> SDHCI controllers. This series consist of several parts:
Since commit cab673583d96 ("soc: Unconditionally include qcom Makefile"),
we unconditionally include the soc/qcom/Makefile.
This opens up the possibility to compile test the code even when building
for other architectures.
Allow COMPILE_TEST for all qcom SoC Kconfigs, except for two Kconfigs
Since commit cab673583d96 ("soc: Unconditionally include qcom Makefile"),
we unconditionally include the soc/qcom/Makefile.
This opens up the possibility to compile test the code even when building
for other architectures.
Allow COMPILE_TEST for all qcom SoC Kconfigs, except for two Kconfigs
Since we are using irq_domain_add_linear(), add a select on IRQ_DOMAIN.
This is needed in order to be able to remove the depends on ARCH_QCOM.
drivers/soc/qcom/smp2p.c: In function ‘qcom_smp2p_inbound_entry’:
drivers/soc/qcom/smp2p.c:317:18: error: implicit declaration of function
Since we are using irq_domain_add_linear(), add a select on IRQ_DOMAIN.
This is needed in order to be able to remove the depends on ARCH_QCOM.
drivers/soc/qcom/smsm.c: In function ‘smsm_inbound_entry’:
drivers/soc/qcom/smsm.c:411:18: error: implicit declaration of function
Since we are using irq_domain_add_linear(), add a select on IRQ_DOMAIN.
This is needed in order to be able to remove the depends on ARCH_QCOM.
drivers/soc/qcom/smp2p.c: In function ‘qcom_smp2p_inbound_entry’:
drivers/soc/qcom/smp2p.c:317:18: error: implicit declaration of function
Since we are using irq_domain_add_linear(), add a select on IRQ_DOMAIN.
This is needed in order to be able to remove the depends on ARCH_QCOM.
drivers/soc/qcom/smsm.c: In function ‘smsm_inbound_entry’:
drivers/soc/qcom/smsm.c:411:18: error: implicit declaration of function
QCOM_SMD_RPM builds perfectly fine without CONFIG_OF set.
Remove the bogus depends of OF.
Signed-off-by: Niklas Cassel
Reviewed-by: Vivek Gautam
Reviewed-by: Vinod Koul
---
drivers/soc/qcom/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/soc/qcom/Kconfig
Add missing include of sizes.h.
drivers/soc/qcom/llcc-slice.c: In function ‘llcc_update_act_ctrl’:
drivers/soc/qcom/llcc-slice.c:41:44: error: ‘SZ_4K’ undeclared
#define LLCC_TRP_ACT_CTRLn(n) (n * SZ_4K)
^
Signed-off-by: Niklas Cassel
QCOM_SMD_RPM builds perfectly fine without CONFIG_OF set.
Remove the bogus depends of OF.
Signed-off-by: Niklas Cassel
Reviewed-by: Vivek Gautam
Reviewed-by: Vinod Koul
---
drivers/soc/qcom/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/soc/qcom/Kconfig
Add missing include of sizes.h.
drivers/soc/qcom/llcc-slice.c: In function ‘llcc_update_act_ctrl’:
drivers/soc/qcom/llcc-slice.c:41:44: error: ‘SZ_4K’ undeclared
#define LLCC_TRP_ACT_CTRLn(n) (n * SZ_4K)
^
Signed-off-by: Niklas Cassel
Since commit cab673583d96 ("soc: Unconditionally include qcom Makefile"),
we unconditionally include the soc/qcom/Makefile.
This opens up the possibility to compile test the code even when
building for other architectures.
This patch series prepares and enables all but two Kconfigs to be
compile
Since commit cab673583d96 ("soc: Unconditionally include qcom Makefile"),
we unconditionally include the soc/qcom/Makefile.
This opens up the possibility to compile test the code even when
building for other architectures.
This patch series prepares and enables all but two Kconfigs to be
compile
Add missing include of sizes.h.
drivers/soc/qcom/smem.c: In function ‘qcom_smem_get_ptable’:
drivers/soc/qcom/smem.c:666:64: error: ‘SZ_4K’ undeclared
ptable = smem->regions[0].virt_base + smem->regions[0].size - SZ_4K;
^
Add missing include of sizes.h.
drivers/soc/qcom/smem.c: In function ‘qcom_smem_get_ptable’:
drivers/soc/qcom/smem.c:666:64: error: ‘SZ_4K’ undeclared
ptable = smem->regions[0].virt_base + smem->regions[0].size - SZ_4K;
^
Building 4.19-rc1 kernel with CONFIG_KERNEL_XZ=y fails with this error:
BOOTCC arch/powerpc/boot/decompress.o
In file included from arch/powerpc/boot/../../../lib/decompress_unxz.c:233,
from arch/powerpc/boot/decompress.c:42:
arch/powerpc/boot/../../../lib/xz/xz_crc32.c:18:10:
Building 4.19-rc1 kernel with CONFIG_KERNEL_XZ=y fails with this error:
BOOTCC arch/powerpc/boot/decompress.o
In file included from arch/powerpc/boot/../../../lib/decompress_unxz.c:233,
from arch/powerpc/boot/decompress.c:42:
arch/powerpc/boot/../../../lib/xz/xz_crc32.c:18:10:
On Mon, Aug 27, 2018 at 01:57:08AM -0700, Christoph Hellwig wrote:
> On Mon, Aug 27, 2018 at 09:47:01AM +0200, Peter Zijlstra wrote:
> > sh is trivial, arm seems doable, with a bit of luck we can do 'rm -rf
> > arch/ia64' leaving us with s390.
>
> Is removing ia64 a serious plan?
I 'joked' about
On imx7d the pcie-phy power domain is turned off in suspend and this can
make the system hang after resume when attempting any read from PCI.
Fix this by adding minimal suspend/resume code from the nxp internal
tree. This will prepare for powering down on suspend and reset the block
on resume.
On Mon, Aug 27, 2018 at 01:57:08AM -0700, Christoph Hellwig wrote:
> On Mon, Aug 27, 2018 at 09:47:01AM +0200, Peter Zijlstra wrote:
> > sh is trivial, arm seems doable, with a bit of luck we can do 'rm -rf
> > arch/ia64' leaving us with s390.
>
> Is removing ia64 a serious plan?
I 'joked' about
On imx7d the pcie-phy power domain is turned off in suspend and this can
make the system hang after resume when attempting any read from PCI.
Fix this by adding minimal suspend/resume code from the nxp internal
tree. This will prepare for powering down on suspend and reset the block
on resume.
On 10/08/18 21:08, Aapo Vienamo wrote:
> Add a quirk to disable card clock when the tuning command is sent.
>
> This has to be done to prevent the SDHCI controller from hanging on
> Tegra210. Without the quirk enabled there appears to be around 10%
> chance that the tuning sequence will fail and
On 10/08/18 21:08, Aapo Vienamo wrote:
> Add a quirk to disable card clock when the tuning command is sent.
>
> This has to be done to prevent the SDHCI controller from hanging on
> Tegra210. Without the quirk enabled there appears to be around 10%
> chance that the tuning sequence will fail and
From: Michal Hocko
93065ac753e4 ("mm, oom: distinguish blockable mode for mmu notifiers")
has introduced blockable parameter to all mmu_notifiers and the notifier
has to back off when called in !blockable case and it could block down
the road.
The above commit implemented that for
From: Michal Hocko
93065ac753e4 ("mm, oom: distinguish blockable mode for mmu notifiers")
has introduced blockable parameter to all mmu_notifiers and the notifier
has to back off when called in !blockable case and it could block down
the road.
The above commit implemented that for
From: Michal Hocko
This reverts commit 5ff7091f5a2ca1b7b642ca0dbdede8f693a56926.
MMU_INVALIDATE_DOES_NOT_BLOCK flags was the only one used and it is no
longer needed since 93065ac753e4 ("mm, oom: distinguish blockable mode
for mmu notifiers"). We now have a full support for per range !blocking
Hi Andrew,
Tetsuo has noticed some fallouts from 93065ac753e4 ("mm, oom:
distinguish blockable mode for mmu notifiers"). One of them has
been fixed and picked up by AMD/DRM maintainer [1]. XEN issue is
fixed by patch 1. I have also clarified expectations about blockable
semantic of
From: Michal Hocko
If invalidate_range_start is called for !blocking mode then all
callbacks have to guarantee they will no block/sleep. The same obviously
applies to invalidate_range_end because this operation pairs with the
former and they are called from the same context. Make sure this is
From: Michal Hocko
This reverts commit 5ff7091f5a2ca1b7b642ca0dbdede8f693a56926.
MMU_INVALIDATE_DOES_NOT_BLOCK flags was the only one used and it is no
longer needed since 93065ac753e4 ("mm, oom: distinguish blockable mode
for mmu notifiers"). We now have a full support for per range !blocking
Hi Andrew,
Tetsuo has noticed some fallouts from 93065ac753e4 ("mm, oom:
distinguish blockable mode for mmu notifiers"). One of them has
been fixed and picked up by AMD/DRM maintainer [1]. XEN issue is
fixed by patch 1. I have also clarified expectations about blockable
semantic of
From: Michal Hocko
If invalidate_range_start is called for !blocking mode then all
callbacks have to guarantee they will no block/sleep. The same obviously
applies to invalidate_range_end because this operation pairs with the
former and they are called from the same context. Make sure this is
The following commit:
368a540e0232 (x86/kvmclock: Remove memblock dependency)
caused SEV guest regression. When SEV is active, we map the shared
variables (wall_clock and hv_clock_boot) with C=0 to ensure that both
the guest and the hypervisor is able to access the data. To map the
variables
The following commit:
368a540e0232 (x86/kvmclock: Remove memblock dependency)
caused SEV guest regression. When SEV is active, we map the shared
variables (wall_clock and hv_clock_boot) with C=0 to ensure that both
the guest and the hypervisor is able to access the data. To map the
variables
The following commit
"
x86/kvmclock: Remove memblock dependency
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=368a540e0232ad446931f5a4e8a5e06f69f21343
"
introduced SEV guest regression.
The guest physical address holding the wall_clock and hv_clock_boot
are
kvmclock defines few static variables which are shared with hypervisor
during the kvmclock initialization.
When SEV is active, memory is encrypted with a guest-specific key, and
if guest OS wants to share the memory region with hypervisor then it must
clear the C-bit before sharing it.
The
The following commit
"
x86/kvmclock: Remove memblock dependency
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=368a540e0232ad446931f5a4e8a5e06f69f21343
"
introduced SEV guest regression.
The guest physical address holding the wall_clock and hv_clock_boot
are
kvmclock defines few static variables which are shared with hypervisor
during the kvmclock initialization.
When SEV is active, memory is encrypted with a guest-specific key, and
if guest OS wants to share the memory region with hypervisor then it must
clear the C-bit before sharing it.
The
On Fri, Aug 24, 2018 at 02:24:48PM -0700, Steve Muckle wrote:
> On 08/24/2018 02:47 AM, Peter Zijlstra wrote:
> > > > On 08/17/2018 11:27 AM, Steve Muckle wrote:
> >
> > > > > When rt_mutex_setprio changes a task's scheduling class to RT,
> > > > > we're seeing cases where the task's vruntime is
On Fri, Aug 24, 2018 at 02:24:48PM -0700, Steve Muckle wrote:
> On 08/24/2018 02:47 AM, Peter Zijlstra wrote:
> > > > On 08/17/2018 11:27 AM, Steve Muckle wrote:
> >
> > > > > When rt_mutex_setprio changes a task's scheduling class to RT,
> > > > > we're seeing cases where the task's vruntime is
On 27 August 2018 at 18:07, Ulf Hansson wrote:
> On 23 August 2018 at 14:50, Adrian Hunter wrote:
>> On 16/08/18 10:54, Chunyan Zhang wrote:
>>> For version 4.10 and aboves, SDHCI_ARGUMENT2 is also uses to indicate
>>> 32-bit number of blocks, it doesn't support stuff bits in argument of
>>>
On 27 August 2018 at 18:07, Ulf Hansson wrote:
> On 23 August 2018 at 14:50, Adrian Hunter wrote:
>> On 16/08/18 10:54, Chunyan Zhang wrote:
>>> For version 4.10 and aboves, SDHCI_ARGUMENT2 is also uses to indicate
>>> 32-bit number of blocks, it doesn't support stuff bits in argument of
>>>
On Mon, Aug 27, 2018 at 11:28:18AM +0200, Jiri Olsa wrote:
> When ordering events, we use preallocated buffers to store separated
> events. Those buffers currently don't have their own struct, but since
> they are basically array of 'struct ordered_event' objects, we use the
> first event to hold
On Mon, Aug 27, 2018 at 11:28:18AM +0200, Jiri Olsa wrote:
> When ordering events, we use preallocated buffers to store separated
> events. Those buffers currently don't have their own struct, but since
> they are basically array of 'struct ordered_event' objects, we use the
> first event to hold
When the devfreq driver and the governor driver are built as modules,
the call to devfreq_add_device() or governor_store() fails because the
governor driver is not loaded at the time the devfreq driver loads. The
devfreq driver has a build dependency on the governor but also should
have a runtime
When the devfreq driver and the governor driver are built as modules,
the call to devfreq_add_device() or governor_store() fails because the
governor driver is not loaded at the time the devfreq driver loads. The
devfreq driver has a build dependency on the governor but also should
have a runtime
On 10/08/18 21:08, Aapo Vienamo wrote:
> Add SDHCI_QUIRK2_TUNE_SKIP_XFERRMODE_REG_PROG to skip programming the
> SDHCI_TRANSFER_MODE in sdhci_set_transfer_mode() if tuning command is
> being sent.
>
> On Tegra210 and Tegra186 the tuning sequence hangs if the SDHCI
> transfer mode register is
On 10/08/18 21:08, Aapo Vienamo wrote:
> Add SDHCI_QUIRK2_TUNE_SKIP_XFERRMODE_REG_PROG to skip programming the
> SDHCI_TRANSFER_MODE in sdhci_set_transfer_mode() if tuning command is
> being sent.
>
> On Tegra210 and Tegra186 the tuning sequence hangs if the SDHCI
> transfer mode register is
On Mon, Aug 27, 2018 at 09:47:01AM +0200, Peter Zijlstra wrote:
> And there's only like 4 architectures that still have a custom
> mmu_gather:
>
> - sh
> - arm
> - ia64
> - s390
>
> sh is trivial, arm seems doable, with a bit of luck we can do 'rm -rf
> arch/ia64' leaving us with s390.
On Mon, Aug 27, 2018 at 09:47:01AM +0200, Peter Zijlstra wrote:
> And there's only like 4 architectures that still have a custom
> mmu_gather:
>
> - sh
> - arm
> - ia64
> - s390
>
> sh is trivial, arm seems doable, with a bit of luck we can do 'rm -rf
> arch/ia64' leaving us with s390.
On 27.08.2018 13:38, Jiri Olsa wrote:
> On Mon, Aug 27, 2018 at 01:25:35PM +0300, Alexey Budankov wrote:
>> Hi Namhyung,
>>
>> On 27.08.2018 13:05, Namhyung Kim wrote:
>>> Hello,
>>>
>>> On Mon, Aug 27, 2018 at 12:33:07PM +0300, Alexey Budankov wrote:
Hi,
On 27.08.2018 11:38, Jiri
On 27.08.2018 13:38, Jiri Olsa wrote:
> On Mon, Aug 27, 2018 at 01:25:35PM +0300, Alexey Budankov wrote:
>> Hi Namhyung,
>>
>> On 27.08.2018 13:05, Namhyung Kim wrote:
>>> Hello,
>>>
>>> On Mon, Aug 27, 2018 at 12:33:07PM +0300, Alexey Budankov wrote:
Hi,
On 27.08.2018 11:38, Jiri
Hi Guenter,
On Thu, Aug 23, 2018 at 10:08 PM Guenter Roeck wrote:
> I see the attached warning when booting 'sabrelite' images in qemu,
> using imx_v6_v7_defconfig and imx6dl-sabrelite.dts.
>
> Context suggests that the warning is seen since commit 1a4327fbf4554 ("spi:
> fix IDR collision on
Hi Guenter,
On Thu, Aug 23, 2018 at 10:08 PM Guenter Roeck wrote:
> I see the attached warning when booting 'sabrelite' images in qemu,
> using imx_v6_v7_defconfig and imx6dl-sabrelite.dts.
>
> Context suggests that the warning is seen since commit 1a4327fbf4554 ("spi:
> fix IDR collision on
On Mon, Aug 27, 2018 at 10:21:01AM +0200, Bartosz Golaszewski wrote:
> Use devm_kstrdup_const() in the pmc-atom driver. This mostly serves as
> an example of how to use this new routine to shrink driver code.
>
> While we're at it: replace a call to kcalloc() with devm_kcalloc().
>
>
On Mon, Aug 27, 2018 at 10:21:01AM +0200, Bartosz Golaszewski wrote:
> Use devm_kstrdup_const() in the pmc-atom driver. This mostly serves as
> an example of how to use this new routine to shrink driver code.
>
> While we're at it: replace a call to kcalloc() with devm_kcalloc().
>
>
Lee, Benson,
Missatge de Enric Balletbo i Serra del
dia dc., 18 de jul. 2018 a les 18:11:
>
> Dear Lee, Benson,
>
> This is another patchset to try to cleanup a bit more the interaction
> between the mfd subsystem and platform/chrome.
>
> The first patch moves some cros-ec include files from
Lee, Benson,
Missatge de Enric Balletbo i Serra del
dia dc., 18 de jul. 2018 a les 18:11:
>
> Dear Lee, Benson,
>
> This is another patchset to try to cleanup a bit more the interaction
> between the mfd subsystem and platform/chrome.
>
> The first patch moves some cros-ec include files from
On Mon, Aug 27, 2018 at 01:25:35PM +0300, Alexey Budankov wrote:
> Hi Namhyung,
>
> On 27.08.2018 13:05, Namhyung Kim wrote:
> > Hello,
> >
> > On Mon, Aug 27, 2018 at 12:33:07PM +0300, Alexey Budankov wrote:
> >> Hi,
> >>
> >> On 27.08.2018 11:38, Jiri Olsa wrote:
> >>> On Thu, Aug 23, 2018 at
On Mon, Aug 27, 2018 at 01:25:35PM +0300, Alexey Budankov wrote:
> Hi Namhyung,
>
> On 27.08.2018 13:05, Namhyung Kim wrote:
> > Hello,
> >
> > On Mon, Aug 27, 2018 at 12:33:07PM +0300, Alexey Budankov wrote:
> >> Hi,
> >>
> >> On 27.08.2018 11:38, Jiri Olsa wrote:
> >>> On Thu, Aug 23, 2018 at
Hello,
On Thu, Aug 23, 2018 at 02:29:34PM +0200, Martin Liška wrote:
> The patch changes interpretation of:
> callq *0x8(%rbx)
>
> from:
> 0.26 │ → callq *8
> to:
> 0.26 │ → callq *0x8(%rbx)
>
> in this can an address is followed by a register, thus
> one can't parse only
Hello,
On Thu, Aug 23, 2018 at 02:29:34PM +0200, Martin Liška wrote:
> The patch changes interpretation of:
> callq *0x8(%rbx)
>
> from:
> 0.26 │ → callq *8
> to:
> 0.26 │ → callq *0x8(%rbx)
>
> in this can an address is followed by a register, thus
> one can't parse only
On Mon, Aug 27, 2018 at 10:21:00AM +0200, Bartosz Golaszewski wrote:
> Provide a resource managed version of kstrdup_const(). This variant
> internally calls devm_kstrdup() on pointers that are outside of
> .rodata section. Also provide a corresponding version of devm_kfree().
>
> Signed-off-by:
On Mon, Aug 27, 2018 at 10:21:00AM +0200, Bartosz Golaszewski wrote:
> Provide a resource managed version of kstrdup_const(). This variant
> internally calls devm_kstrdup() on pointers that are outside of
> .rodata section. Also provide a corresponding version of devm_kfree().
>
> Signed-off-by:
On 27/08/18 13:10, Thierry Reding wrote:
> On Fri, Aug 10, 2018 at 09:08:02PM +0300, Aapo Vienamo wrote:
>> Hi all,
>>
>> This series implements support for faster signaling modes on Tegra
>> SDHCI controllers. This series consist of several parts: changes
>> requried for 1.8 V signaling and pad
On 27/08/18 13:10, Thierry Reding wrote:
> On Fri, Aug 10, 2018 at 09:08:02PM +0300, Aapo Vienamo wrote:
>> Hi all,
>>
>> This series implements support for faster signaling modes on Tegra
>> SDHCI controllers. This series consist of several parts: changes
>> requried for 1.8 V signaling and pad
901 - 1000 of 1294 matches
Mail list logo
