On (08/16/18 13:39), Prarit Bhargava wrote:
>
> + auto[X86] Enable ACPI SPCR console
And arm64?
Any chance we can rename param to "spcr" or something more clear?
To explicitly state what exactly it's going to do. `auto' sounds
On Wed, 15 Aug 2018 17:05:48 -0400
Tony Krowiak wrote:
> On 08/15/2018 12:38 PM, Cornelia Huck wrote:
> > On Mon, 13 Aug 2018 17:48:15 -0400
> > Tony Krowiak wrote:
> >> + case VFIO_DEVICE_RESET:
> >> + ret = vfio_ap_mdev_reset_queues(mdev, true);
> > If I see it correctly, you
On Wed, 15 Aug 2018 16:36:32 -0400
Tony Krowiak wrote:
> On 08/15/2018 12:24 PM, Cornelia Huck wrote:
> > On Mon, 13 Aug 2018 17:48:14 -0400
> > Tony Krowiak wrote:
> >
> > Nit: please drop the leading period in the subject.
>
> I assume you mean the ending period?
Err, of course.
>
> >
On Wed, 15 Aug 2018 16:36:32 -0400
Tony Krowiak wrote:
> On 08/15/2018 12:24 PM, Cornelia Huck wrote:
> > On Mon, 13 Aug 2018 17:48:14 -0400
> > Tony Krowiak wrote:
> >
> > Nit: please drop the leading period in the subject.
>
> I assume you mean the ending period?
Err, of course.
>
> >
Hi Kyeongdon,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on arm64/for-next/core]
[also build test ERROR on v4.18 next-20180817]
[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
On Thursday, August 16, 2018 3:27:24 PM CEST Frederic Weisbecker wrote:
> On Thu, Aug 09, 2018 at 07:08:34PM +0200, Rafael J. Wysocki wrote:
> > From: Rafael J. Wysocki
> >
> > If the tick has been stopped already, but the governor has not asked to
> > stop it (which it can do sometimes), the
Hi Kyeongdon,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on arm64/for-next/core]
[also build test ERROR on v4.18 next-20180817]
[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
On Thursday, August 16, 2018 3:27:24 PM CEST Frederic Weisbecker wrote:
> On Thu, Aug 09, 2018 at 07:08:34PM +0200, Rafael J. Wysocki wrote:
> > From: Rafael J. Wysocki
> >
> > If the tick has been stopped already, but the governor has not asked to
> > stop it (which it can do sometimes), the
On Fri, 17 Aug 2018 09:32:55 +0100,
Paolo Bonzini wrote:
>
> On 16/08/2018 02:15, Stephen Rothwell wrote:
> >> -#define ARM64_HAS_STAGE2_FWB 31
> >> +#define ARM64_MISMATCHED_CACHE_TYPE 31
> >> ++#define ARM64_HAS_STAGE2_FWB 32
> >>
> >>
On Fri, Aug 17, 2018 at 11:54 AM, Jianchao Wang
wrote:
> Currently, when update nr_hw_queues, io scheduler's init_hctx will
> be invoked before the mapping between ctx and hctx is adapted
> correctly by blk_mq_map_swqueue. The io scheduler init_hctx (kyber)
> may depend on this mapping and get
On Fri, 17 Aug 2018 09:32:55 +0100,
Paolo Bonzini wrote:
>
> On 16/08/2018 02:15, Stephen Rothwell wrote:
> >> -#define ARM64_HAS_STAGE2_FWB 31
> >> +#define ARM64_MISMATCHED_CACHE_TYPE 31
> >> ++#define ARM64_HAS_STAGE2_FWB 32
> >>
> >>
On Fri, Aug 17, 2018 at 11:54 AM, Jianchao Wang
wrote:
> Currently, when update nr_hw_queues, io scheduler's init_hctx will
> be invoked before the mapping between ctx and hctx is adapted
> correctly by blk_mq_map_swqueue. The io scheduler init_hctx (kyber)
> may depend on this mapping and get
On Fri, Aug 17, 2018 at 10:18:04AM +0100, Marc Zyngier wrote:
> Although GICv3 doesn't directly offers support for wake-up interrupts
> and relies on external HW for this, it shouldn't prevent the driver
> for such HW from doing it work.
>
> Let's set the required flags on the irq_chip structures.
On Fri, Aug 17, 2018 at 10:18:04AM +0100, Marc Zyngier wrote:
> Although GICv3 doesn't directly offers support for wake-up interrupts
> and relies on external HW for this, it shouldn't prevent the driver
> for such HW from doing it work.
>
> Let's set the required flags on the irq_chip structures.
On Wed, Aug 15, 2018 at 09:48:12AM +0200, Pavel Machek wrote:
> Hi!
>
> > Add new config option to enabled/disable Multi-Key Total Memory
> > Encryption support.
> >
> > MKTME uses MEMORY_PHYSICAL_PADDING to reserve enough space in per-KeyID
> > direct mappings for memory hotplug.
> >
> >
On Wed, Aug 15, 2018 at 09:48:12AM +0200, Pavel Machek wrote:
> Hi!
>
> > Add new config option to enabled/disable Multi-Key Total Memory
> > Encryption support.
> >
> > MKTME uses MEMORY_PHYSICAL_PADDING to reserve enough space in per-KeyID
> > direct mappings for memory hotplug.
> >
> >
The kernel should really say what the
[ cut here ]
lines are called, else users will say things like:
"I discovered that the user needs to use xrandr in _two_ steps for
certain resolutions, else he will trigger a
kernel: [ cut here ] line."
The kernel should really say what the
[ cut here ]
lines are called, else users will say things like:
"I discovered that the user needs to use xrandr in _two_ steps for
certain resolutions, else he will trigger a
kernel: [ cut here ] line."
Although GICv3 doesn't directly offers support for wake-up interrupts
and relies on external HW for this, it shouldn't prevent the driver
for such HW from doing it work.
Let's set the required flags on the irq_chip structures.
Reported-by: Lina Iyer
Signed-off-by: Marc Zyngier
---
Lina, please
Although GICv3 doesn't directly offers support for wake-up interrupts
and relies on external HW for this, it shouldn't prevent the driver
for such HW from doing it work.
Let's set the required flags on the irq_chip structures.
Reported-by: Lina Iyer
Signed-off-by: Marc Zyngier
---
Lina, please
--
Pozdravy,
Existuje naléhavá záležitost a vzájemná nabídka, kterou bych vám chtěl
dát soukromě a já bych ocenil vaši rychlou odpověď zde
(xu.shiq...@aol.com) pro další komunikaci.
Vyčkejte na rychlou odpověď.
Pozdravy,
--
Pozdravy,
Existuje naléhavá záležitost a vzájemná nabídka, kterou bych vám chtěl
dát soukromě a já bych ocenil vaši rychlou odpověď zde
(xu.shiq...@aol.com) pro další komunikaci.
Vyčkejte na rychlou odpověď.
Pozdravy,
Hi Zhong,
Thank you for the patch.
On Friday, 17 August 2018 06:37:26 EEST zhong jiang wrote:
> debugfs_remove_recursive has taken null pointer into account. so
> remove the unneeded check.
>
> Signed-off-by: zhong jiang
I already have a similar patch in my tree (git://linuxtv.org/pinchartl/
Hi Zhong,
Thank you for the patch.
On Friday, 17 August 2018 06:37:26 EEST zhong jiang wrote:
> debugfs_remove_recursive has taken null pointer into account. so
> remove the unneeded check.
>
> Signed-off-by: zhong jiang
I already have a similar patch in my tree (git://linuxtv.org/pinchartl/
2018-08-16 19:45 GMT+02:00 Mark Jonas :
> From: Wang Xin
>
> Within at24_loop_until_timeout the timestamp used for timeout checking
> is recorded after the I2C transfer and sleep_range(). Under high CPU
> load either the execution time for I2C transfer or sleep_range() could
> actually be larger
2018-08-16 19:45 GMT+02:00 Mark Jonas :
> From: Wang Xin
>
> Within at24_loop_until_timeout the timestamp used for timeout checking
> is recorded after the I2C transfer and sleep_range(). Under high CPU
> load either the execution time for I2C transfer or sleep_range() could
> actually be larger
From: Oscar Salvador
Before calling to unregister_mem_sect_under_nodes(),
remove_memory_section() already checks if we got a valid memory_block.
No need to check that again in unregister_mem_sect_under_nodes().
If more functions start using unregister_mem_sect_under_nodes() in the
future, we
From: Oscar Salvador
Before calling to unregister_mem_sect_under_nodes(),
remove_memory_section() already checks if we got a valid memory_block.
No need to check that again in unregister_mem_sect_under_nodes().
If more functions start using unregister_mem_sect_under_nodes() in the
future, we
From: Oscar Salvador
We are getting the nid from the pages that are not yet removed,
but a node can only be offline when its memory/cpu's have been removed.
Therefore, we know that the node is still online.
Signed-off-by: Oscar Salvador
Reviewed-by: David Hildenbrand
Reviewed-by: Pavel
From: Oscar Salvador
We are getting the nid from the pages that are not yet removed,
but a node can only be offline when its memory/cpu's have been removed.
Therefore, we know that the node is still online.
Signed-off-by: Oscar Salvador
Reviewed-by: David Hildenbrand
Reviewed-by: Pavel
From: Oscar Salvador
unregister_memory_section() calls remove_memory_section()
with three arguments:
* node_id
* section
* phys_device
Neither node_id nor phys_device are used.
Let us drop them from the function.
Signed-off-by: Oscar Salvador
Reviewed-by: David Hildenbrand
Reviewed-by:
From: Oscar Salvador
Currently, unregister_mem_sect_under_nodes() tries to allocate a nodemask_t
in order to check whithin the loop which nodes have already been unlinked,
so we do not repeat the operation on them.
NODEMASK_ALLOC calls kmalloc() if NODES_SHIFT > 8, otherwise
it just declares a
From: Oscar Salvador
unregister_memory_section() calls remove_memory_section()
with three arguments:
* node_id
* section
* phys_device
Neither node_id nor phys_device are used.
Let us drop them from the function.
Signed-off-by: Oscar Salvador
Reviewed-by: David Hildenbrand
Reviewed-by:
From: Oscar Salvador
Currently, unregister_mem_sect_under_nodes() tries to allocate a nodemask_t
in order to check whithin the loop which nodes have already been unlinked,
so we do not repeat the operation on them.
NODEMASK_ALLOC calls kmalloc() if NODES_SHIFT > 8, otherwise
it just declares a
From: Oscar Salvador
v3 -> v4:
- Make nodemask_t a stack variable
- Added Reviewed-by from David and Pavel
v2 -> v3:
- NODEMASK_FREE can deal with NULL pointers, so do not
make it conditional (by David).
- Split up node_online's check patch (David's
From: Oscar Salvador
v3 -> v4:
- Make nodemask_t a stack variable
- Added Reviewed-by from David and Pavel
v2 -> v3:
- NODEMASK_FREE can deal with NULL pointers, so do not
make it conditional (by David).
- Split up node_online's check patch (David's
On Fri, Aug 17, 2018 at 2:00 PM, Benjamin Herrenschmidt
wrote:
> On Fri, 2018-08-17 at 10:09 +0200, Marta Rybczynska wrote:
>>
>> - On 17 Aug, 2018, at 06:49, Benjamin Herrenschmidt
>> b...@kernel.crashing.org wrote:
>>
>> > This protects enable/disable operations using the state mutex to
>>
On Fri, Aug 17, 2018 at 2:00 PM, Benjamin Herrenschmidt
wrote:
> On Fri, 2018-08-17 at 10:09 +0200, Marta Rybczynska wrote:
>>
>> - On 17 Aug, 2018, at 06:49, Benjamin Herrenschmidt
>> b...@kernel.crashing.org wrote:
>>
>> > This protects enable/disable operations using the state mutex to
>>
On Fri, 17 Aug 2018 10:47:34 +0200
Arnd Bergmann wrote:
> On Fri, Aug 17, 2018 at 1:27 AM Luck, Tony wrote:
> >
> > On Thu, Aug 16, 2018 at 11:10:33PM +0200, Arnd Bergmann wrote:
> > > Another way would be to add
> > >
> > > #include
> > > +#undef PCI_IOBASE
> > >
> > > in your asm/io.h.
On Fri, 17 Aug 2018 10:47:34 +0200
Arnd Bergmann wrote:
> On Fri, Aug 17, 2018 at 1:27 AM Luck, Tony wrote:
> >
> > On Thu, Aug 16, 2018 at 11:10:33PM +0200, Arnd Bergmann wrote:
> > > Another way would be to add
> > >
> > > #include
> > > +#undef PCI_IOBASE
> > >
> > > in your asm/io.h.
On Fri, Aug 17, 2018 at 10:33 AM, Vegard Nossum wrote:
> On 16 August 2018 at 17:42, Richard Weinberger
> wrote:
>> On Thu, Aug 16, 2018 at 2:58 PM Sedat Dilek wrote:
>>>
>>> Hi Linus,
>>>
>>> I am here on Linux v4.18 and tried first to merge the l1tf-final Git-branch.
>>> Unfortunately, this
On Fri, Aug 17, 2018 at 10:33 AM, Vegard Nossum wrote:
> On 16 August 2018 at 17:42, Richard Weinberger
> wrote:
>> On Thu, Aug 16, 2018 at 2:58 PM Sedat Dilek wrote:
>>>
>>> Hi Linus,
>>>
>>> I am here on Linux v4.18 and tried first to merge the l1tf-final Git-branch.
>>> Unfortunately, this
On Fri, Aug 17, 2018 at 1:27 AM Luck, Tony wrote:
>
> On Thu, Aug 16, 2018 at 11:10:33PM +0200, Arnd Bergmann wrote:
> > Another way would be to add
> >
> > #include
> > +#undef PCI_IOBASE
> >
> > in your asm/io.h. This is about as ugly as the your version, but
> > it would be local to ia64 ;-)
On Fri, Aug 17, 2018 at 1:27 AM Luck, Tony wrote:
>
> On Thu, Aug 16, 2018 at 11:10:33PM +0200, Arnd Bergmann wrote:
> > Another way would be to add
> >
> > #include
> > +#undef PCI_IOBASE
> >
> > in your asm/io.h. This is about as ugly as the your version, but
> > it would be local to ia64 ;-)
Hi Yixun,
I know I said I would finish reviewing the driver, but I didn't have
time to do it, so feel free to send a new version addressing the
comments I already made.
On Thu, 19 Jul 2018 17:46:12 +0800
Yixun Lan wrote:
> +static void meson_nfc_select_chip(struct mtd_info *mtd, int chip)
>
Hi Yixun,
I know I said I would finish reviewing the driver, but I didn't have
time to do it, so feel free to send a new version addressing the
comments I already made.
On Thu, 19 Jul 2018 17:46:12 +0800
Yixun Lan wrote:
> +static void meson_nfc_select_chip(struct mtd_info *mtd, int chip)
>
On Thu, Aug 16, 2018 at 09:01:41AM -0500, Gustavo A. R. Silva wrote:
> Replace the whole switch statement with a for loop.
> This makes the code much clear and easy to read.
>
> This also addresses the following Coverity warnings:
>
> Addresses-Coverity-ID: 115090 ("Missing break in switch")
>
On Thu, Aug 16, 2018 at 09:01:41AM -0500, Gustavo A. R. Silva wrote:
> Replace the whole switch statement with a for loop.
> This makes the code much clear and easy to read.
>
> This also addresses the following Coverity warnings:
>
> Addresses-Coverity-ID: 115090 ("Missing break in switch")
>
On Thu, 16 Aug 2018 12:24:16 -0400
Tony Krowiak wrote:
> On 08/14/2018 07:19 AM, Cornelia Huck wrote:
> > On Mon, 13 Aug 2018 17:48:06 -0400
> > Tony Krowiak wrote:
> >> +static int vfio_ap_mdev_create(struct kobject *kobj, struct mdev_device
> >> *mdev)
> >> +{
> >> + struct ap_matrix_mdev
On Thu, 16 Aug 2018 12:24:16 -0400
Tony Krowiak wrote:
> On 08/14/2018 07:19 AM, Cornelia Huck wrote:
> > On Mon, 13 Aug 2018 17:48:06 -0400
> > Tony Krowiak wrote:
> >> +static int vfio_ap_mdev_create(struct kobject *kobj, struct mdev_device
> >> *mdev)
> >> +{
> >> + struct ap_matrix_mdev
This patch declares strcmp/strncmp as weak symbols.
(2 of them are the most used string operations)
Original functions declared as weak symbols and
strong ones in mm/kasan/kasan.c could replace them.
Assembly optimized strcmp/strncmp functions cannot detect KASan bug.
But, now we can detect
This patch declares strcmp/strncmp as weak symbols.
(2 of them are the most used string operations)
Original functions declared as weak symbols and
strong ones in mm/kasan/kasan.c could replace them.
Assembly optimized strcmp/strncmp functions cannot detect KASan bug.
But, now we can detect
On 16 August 2018 at 17:42, Richard Weinberger
wrote:
> On Thu, Aug 16, 2018 at 2:58 PM Sedat Dilek wrote:
>>
>> Hi Linus,
>>
>> I am here on Linux v4.18 and tried first to merge the l1tf-final Git-branch.
>> Unfortunately, this is no more available in the tip Git-tree.
>>
>> Then I saw Linux
On 16 August 2018 at 17:42, Richard Weinberger
wrote:
> On Thu, Aug 16, 2018 at 2:58 PM Sedat Dilek wrote:
>>
>> Hi Linus,
>>
>> I am here on Linux v4.18 and tried first to merge the l1tf-final Git-branch.
>> Unfortunately, this is no more available in the tip Git-tree.
>>
>> Then I saw Linux
On 16/08/2018 02:15, Stephen Rothwell wrote:
>> -#define ARM64_HAS_STAGE2_FWB 31
>> +#define ARM64_MISMATCHED_CACHE_TYPE31
>> ++#define ARM64_HAS_STAGE2_FWB 32
>>
>> --#define ARM64_NCAPS32
>>
On 16/08/2018 02:15, Stephen Rothwell wrote:
>> -#define ARM64_HAS_STAGE2_FWB 31
>> +#define ARM64_MISMATCHED_CACHE_TYPE31
>> ++#define ARM64_HAS_STAGE2_FWB 32
>>
>> --#define ARM64_NCAPS32
>>
On Fri, 2018-08-17 at 10:09 +0200, Marta Rybczynska wrote:
>
> - On 17 Aug, 2018, at 06:49, Benjamin Herrenschmidt
> b...@kernel.crashing.org wrote:
>
> > This protects enable/disable operations using the state mutex to
> > avoid races with, for example, concurrent enables on a bridge.
> >
On Fri, 2018-08-17 at 10:09 +0200, Marta Rybczynska wrote:
>
> - On 17 Aug, 2018, at 06:49, Benjamin Herrenschmidt
> b...@kernel.crashing.org wrote:
>
> > This protects enable/disable operations using the state mutex to
> > avoid races with, for example, concurrent enables on a bridge.
> >
James Bottomley wrote:
> > > As a step by step process, I agree. However, I think we can
> > > automate it to the point where you install a package and it says
> > > "insert your yubikey" every time you upgrade the kernel
> >
> > That's a very bad idea. You train people to unlock their
Thanks for the reminder.
Because this change is trivial, I change the subject.
On Fri, Aug 17, 2018 at 12:29 PM Jason Wang wrote:
>
>
>
> On 2018年08月17日 03:30, David Miller wrote:
> > From: Wang Jian
> > Date: Thu, 16 Aug 2018 21:01:27 +0800
> >
> >> The tap_queue and the "tap_dev" are loosely
James Bottomley wrote:
> > > As a step by step process, I agree. However, I think we can
> > > automate it to the point where you install a package and it says
> > > "insert your yubikey" every time you upgrade the kernel
> >
> > That's a very bad idea. You train people to unlock their
Thanks for the reminder.
Because this change is trivial, I change the subject.
On Fri, Aug 17, 2018 at 12:29 PM Jason Wang wrote:
>
>
>
> On 2018年08月17日 03:30, David Miller wrote:
> > From: Wang Jian
> > Date: Thu, 16 Aug 2018 21:01:27 +0800
> >
> >> The tap_queue and the "tap_dev" are loosely
On Thu 2018-08-16 13:39:01, Prarit Bhargava wrote:
> ACPI may contain an SPCR table that defines a default system console.
> On ARM if the table is present then the SPCR console is enabled by default.
> On x86 the SPCR console is used if 'earlycon' (no parameters) is
> specified as a kernel
On Thu 2018-08-16 13:39:01, Prarit Bhargava wrote:
> ACPI may contain an SPCR table that defines a default system console.
> On ARM if the table is present then the SPCR console is enabled by default.
> On x86 the SPCR console is used if 'earlycon' (no parameters) is
> specified as a kernel
- On 17 Aug, 2018, at 06:49, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
> This protects enable/disable operations using the state mutex to
> avoid races with, for example, concurrent enables on a bridge.
>
> The bus hierarchy is walked first before taking the lock to
> avoid
- On 17 Aug, 2018, at 06:49, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
> This protects enable/disable operations using the state mutex to
> avoid races with, for example, concurrent enables on a bridge.
>
> The bus hierarchy is walked first before taking the lock to
> avoid
> failed_addition:
> +#ifdef CONFIG_DEBUG_VM
> pr_debug("online_pages [mem %#010llx-%#010llx] failed\n",
>(unsigned long long) pfn << PAGE_SHIFT,
>(((unsigned long long) pfn + nr_pages) << PAGE_SHIFT) - 1);
> +#endif
I have never been sure about this.
IMO,
> failed_addition:
> +#ifdef CONFIG_DEBUG_VM
> pr_debug("online_pages [mem %#010llx-%#010llx] failed\n",
>(unsigned long long) pfn << PAGE_SHIFT,
>(((unsigned long long) pfn + nr_pages) << PAGE_SHIFT) - 1);
> +#endif
I have never been sure about this.
IMO,
2018-08-17 16:47 GMT+09:00 Andrzej Pietrasiewicz :
> Hi Bjørn,
>
> W dniu 17.08.2018 o 01:34, Bjørn Forsman pisze:
>> On Thu, 16 Aug 2018 at 18:18, Andrzej Pietrasiewicz
>> wrote:
>>>
>>> This reverts commit 9e6e0d5f2a2713402cf9dce69b9f9b516e4185d2.
>>>
>>> The reverted commit introduces broken
2018-08-17 16:47 GMT+09:00 Andrzej Pietrasiewicz :
> Hi Bjørn,
>
> W dniu 17.08.2018 o 01:34, Bjørn Forsman pisze:
>> On Thu, 16 Aug 2018 at 18:18, Andrzej Pietrasiewicz
>> wrote:
>>>
>>> This reverts commit 9e6e0d5f2a2713402cf9dce69b9f9b516e4185d2.
>>>
>>> The reverted commit introduces broken
On Fri, 2018-08-17 at 14:12 +0800, Hanjie Lin wrote:
>
> On 2018/8/16 16:33, Jerome Brunet wrote:
> > On Thu, 2018-08-16 at 11:05 +0800, Hanjie Lin wrote:
> > >
> > > On 2018/8/14 18:41, Jerome Brunet wrote:
> > > > On Tue, 2018-08-14 at 02:12 -0400, Hanjie Lin wrote:
> > > > > From: Yue Wang
>
On Fri, 2018-08-17 at 14:12 +0800, Hanjie Lin wrote:
>
> On 2018/8/16 16:33, Jerome Brunet wrote:
> > On Thu, 2018-08-16 at 11:05 +0800, Hanjie Lin wrote:
> > >
> > > On 2018/8/14 18:41, Jerome Brunet wrote:
> > > > On Tue, 2018-08-14 at 02:12 -0400, Hanjie Lin wrote:
> > > > > From: Yue Wang
>
On Friday 17 August 2018 01:09 PM, Bartosz Golaszewski wrote:
> 2018-08-17 2:49 GMT+02:00 Bjorn Andersson :
>> da8xx_rproc_mem size is of type size_t, so use %zx to format the debug
>> print of it to avoid a compile warning.
>>
>> Signed-off-by: Bjorn Andersson
>> ---
>>
On Friday 17 August 2018 01:09 PM, Bartosz Golaszewski wrote:
> 2018-08-17 2:49 GMT+02:00 Bjorn Andersson :
>> da8xx_rproc_mem size is of type size_t, so use %zx to format the debug
>> print of it to avoid a compile warning.
>>
>> Signed-off-by: Bjorn Andersson
>> ---
>>
On Fri, Aug 17, 2018 at 4:29 AM Daniel Drake wrote:
>
> On Mon, Aug 6, 2018 at 7:17 PM, Rafael J. Wysocki wrote:
> >> 'echo enabled > /sys/devices/platform/i8042/serio0/power/wakeup' can get
> >> the
> >> keyboard wake up the system as expected. We considered to work out a DMI
> >> based quirk
On Fri, Aug 17, 2018 at 4:29 AM Daniel Drake wrote:
>
> On Mon, Aug 6, 2018 at 7:17 PM, Rafael J. Wysocki wrote:
> >> 'echo enabled > /sys/devices/platform/i8042/serio0/power/wakeup' can get
> >> the
> >> keyboard wake up the system as expected. We considered to work out a DMI
> >> based quirk
Removed unnecessary parentheses and this resolve the check patch issue.
Structure dereference operator have higher precedence then Address of
operator So there is no need of parentheses.
This change is purely coding style in nature and should have not effect
on runtime code execution.
Removed unnecessary parentheses and this resolve the check patch issue.
Structure dereference operator have higher precedence then Address of
operator So there is no need of parentheses.
This change is purely coding style in nature and should have not effect
on runtime code execution.
On Fri, Aug 17, 2018 at 7:45 AM Teika Kazura wrote:
>
> For the record, about the exactness of the patch description.
>
> The patch mentions the regression by the commit c62ec4610c40, but it is not
> the cause of the bug (https://bugzilla.kernel.org/show_bug.cgi?id=20067)
> reported by me; I
On Fri, Aug 17, 2018 at 7:45 AM Teika Kazura wrote:
>
> For the record, about the exactness of the patch description.
>
> The patch mentions the regression by the commit c62ec4610c40, but it is not
> the cause of the bug (https://bugzilla.kernel.org/show_bug.cgi?id=20067)
> reported by me; I
This patch removed code which are valid for IEEE 802.11a i.e. 5GHz.
This is also mention in the TODO file.
Signed-off-by: Bhaskar Singh
---
drivers/staging/rtl8188eu/core/rtw_ieee80211.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git
Hi Bjørn,
W dniu 17.08.2018 o 01:34, Bjørn Forsman pisze:
> On Thu, 16 Aug 2018 at 18:18, Andrzej Pietrasiewicz
> wrote:
>>
>> This reverts commit 9e6e0d5f2a2713402cf9dce69b9f9b516e4185d2.
>>
>> The reverted commit introduces broken builds. Even though the cpio archive
>> does contain all the
This patch removed code which are valid for IEEE 802.11a i.e. 5GHz.
This is also mention in the TODO file.
Signed-off-by: Bhaskar Singh
---
drivers/staging/rtl8188eu/core/rtw_ieee80211.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git
Hi Bjørn,
W dniu 17.08.2018 o 01:34, Bjørn Forsman pisze:
> On Thu, 16 Aug 2018 at 18:18, Andrzej Pietrasiewicz
> wrote:
>>
>> This reverts commit 9e6e0d5f2a2713402cf9dce69b9f9b516e4185d2.
>>
>> The reverted commit introduces broken builds. Even though the cpio archive
>> does contain all the
On 2018-08-17 01:21, Yury Norov wrote:
> Hi Rasmus,
>
> On Wed, Aug 15, 2018 at 10:55:39AM +0200, Rasmus Villemoes wrote:
>> Most of the inline bitmap functions are buggy if passed a compile-time
>> constant nbits==0.
>
> I think it's bad wording. Functions are OK. The problem is in users.
Why
On 2018-08-17 01:21, Yury Norov wrote:
> Hi Rasmus,
>
> On Wed, Aug 15, 2018 at 10:55:39AM +0200, Rasmus Villemoes wrote:
>> Most of the inline bitmap functions are buggy if passed a compile-time
>> constant nbits==0.
>
> I think it's bad wording. Functions are OK. The problem is in users.
Why
2018-08-17 2:49 GMT+02:00 Bjorn Andersson :
> da8xx_rproc_mem size is of type size_t, so use %zx to format the debug
> print of it to avoid a compile warning.
>
> Signed-off-by: Bjorn Andersson
> ---
> drivers/remoteproc/da8xx_remoteproc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
2018-08-17 2:49 GMT+02:00 Bjorn Andersson :
> da8xx_rproc_mem size is of type size_t, so use %zx to format the debug
> print of it to avoid a compile warning.
>
> Signed-off-by: Bjorn Andersson
> ---
> drivers/remoteproc/da8xx_remoteproc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Hi Abel,
On Thu, Aug 16, 2018 at 06:27:15PM +0300, Abel Vesa wrote:
> Since a lot of clocks on imx8 are formed by a mux, gate, predivider and
> divider, the idea here is to combine all of those into one more complex
> clock type, therefore moving the complexity inside the composite clock and
>
Hi Abel,
On Thu, Aug 16, 2018 at 06:27:15PM +0300, Abel Vesa wrote:
> Since a lot of clocks on imx8 are formed by a mux, gate, predivider and
> divider, the idea here is to combine all of those into one more complex
> clock type, therefore moving the complexity inside the composite clock and
>
On Thu, Aug 16, 2018 at 7:14 PM, Linus Torvalds
wrote:
> On Thu, Aug 16, 2018 at 12:37 AM Sedat Dilek wrote:
>>>
>> I am here on Linux v4.18 and tried first to merge the l1tf-final Git-branch.
>> Unfortunately, this is no more available in the tip Git-tree.
>
> Right. That branch - for obvious
On Thu, Aug 16, 2018 at 7:14 PM, Linus Torvalds
wrote:
> On Thu, Aug 16, 2018 at 12:37 AM Sedat Dilek wrote:
>>>
>> I am here on Linux v4.18 and tried first to merge the l1tf-final Git-branch.
>> Unfortunately, this is no more available in the tip Git-tree.
>
> Right. That branch - for obvious
On Tue, Aug 14, 2018 at 06:35:16PM -0700, Michal Wnukowski wrote:
>
> The other side in this case is not actual controller hardware, but
> virtual one (the regular hardware should rely on normal MMIO
> doorbells).
There could very much be real hardware there. We've made it clear
in the spec
On Tue, Aug 14, 2018 at 06:35:16PM -0700, Michal Wnukowski wrote:
>
> The other side in this case is not actual controller hardware, but
> virtual one (the regular hardware should rely on normal MMIO
> doorbells).
There could very much be real hardware there. We've made it clear
in the spec
I've applied this with some major updates to the subject, changelog
and the comment in the code. Please double check it all still makes
sense.
I've applied this with some major updates to the subject, changelog
and the comment in the code. Please double check it all still makes
sense.
The spi-dw driver currently only supports 8 or 16 bits per word.
Since the hardware supports 4-16 bits per word, adapt the driver
to also support this.
Tested on socfpga cyclone5 with a 9-bit SPI display.
Signed-off-by: Simon Goldschmidt
---
Changes in v2:
- use DIV_ROUND_UP to calculate
The spi-dw driver currently only supports 8 or 16 bits per word.
Since the hardware supports 4-16 bits per word, adapt the driver
to also support this.
Tested on socfpga cyclone5 with a 9-bit SPI display.
Signed-off-by: Simon Goldschmidt
---
Changes in v2:
- use DIV_ROUND_UP to calculate
On Thu, Aug 16, 2018 at 5:42 PM, Richard Weinberger
wrote:
> On Thu, Aug 16, 2018 at 2:58 PM Sedat Dilek wrote:
>>
>> Hi Linus,
>>
>> I am here on Linux v4.18 and tried first to merge the l1tf-final Git-branch.
>> Unfortunately, this is no more available in the tip Git-tree.
>>
>> Then I saw
On Thu, Aug 16, 2018 at 5:42 PM, Richard Weinberger
wrote:
> On Thu, Aug 16, 2018 at 2:58 PM Sedat Dilek wrote:
>>
>> Hi Linus,
>>
>> I am here on Linux v4.18 and tried first to merge the l1tf-final Git-branch.
>> Unfortunately, this is no more available in the tip Git-tree.
>>
>> Then I saw
601 - 700 of 714 matches
Mail list logo
