Hello Dinghao,
On Thu, 2020-05-28 at 15:21 +0800, Dinghao Liu wrote:
> pm_runtime_get_sync() increments the runtime PM usage counter even
> the call returns an error code. Thus a pairing decrement is needed
> on the error handling path to keep the counter balanced.
>
> Signed-off-by: Dinghao Liu
Hello Dinghao,
On Wed, 2020-05-20 at 21:29 +0800, Dinghao Liu wrote:
> pm_runtime_get_sync() increments the runtime PM usage counter even
> the call returns an error code. Thus a pairing decrement is needed
> on the error handling path to keep the counter balanced.
I believe, this is the wrong
From: Alexander Sverdlin
irq_domain_associate() is the only place where irq_find_mapping() can be
used reliably (under irq_domain_mutex) to make a decision if the mapping
shall be created or not. Other calls to irq_find_mapping() (not under
any lock) cannot be used for this purpose and lead to
From: Alexander Sverdlin
irq_create_fwspec_mapping() can race with itself during IRQ trigger type
configuration. Possible scenarios include:
- Mapping exists, two irq_create_fwspec_mapping() running in parallel do
not detect type mismatch, IRQ remains configured with one of the
different
From: Alexander Sverdlin
If two irq_create_mapping() calls perform a mapping of the same hwirq on
two CPU cores in parallel they both will get 0 from irq_find_mapping(),
both will allocate unique virq using irq_domain_alloc_descs() and both
will finally irq_domain_associate() it. Giving
From: Alexander Sverdlin
Seems that the discovered race was here since adapting the PowerPC code
into genirq in 2012. I was surprized it went unnoticed all this time, but
it turns out, device registration (being it DT or ACPI) is mostly
sequential in kernel. In our case probe deferring was
Hi!
On 20/09/2019 18:07, Marc Zyngier wrote:
>> irq_create_fwspec_mapping() can race with itself during IRQ trigger type
>> configuration. Possible scenarios include:
>>
>> - Mapping exists, two irq_create_fwspec_mapping() running in parallel do
>> not detect type mismatch, IRQ remains
Hi Marc,
On 20/09/2019 17:52, Marc Zyngier wrote:
>> If two irq_create_mapping() calls perform a mapping of the same hwirq on
>> two CPU cores in parallel they both will get 0 from irq_find_mapping(),
>> both will allocate unique virq using irq_domain_alloc_descs() and both
>> will finally
Hello Jean,
On 05/09/2019 14:57, Jean Delvare wrote:
> If this is of any value to you, I tried implementing it in i2c-i801 a
> few days ago. I can't really test it though as I don't have any device
> which triggers an alert on my system, but I am sharing it with you if
> you want to give it a
Hi Jean,
On 05/09/2019 14:57, Jean Delvare wrote:
> If this is of any value to you, I tried implementing it in i2c-i801 a
> few days ago. I can't really test it though as I don't have any device
> which triggers an alert on my system, but I am sharing it with you if
> you want to give it a try.
Hello Jean,
On 05/09/2019 14:57, Jean Delvare wrote:
> If this is of any value to you, I tried implementing it in i2c-i801 a
> few days ago. I can't really test it though as I don't have any device
> which triggers an alert on my system, but I am sharing it with you if
> you want to give it a
From: Alexander Sverdlin
If two irq_create_mapping() calls perform a mapping of the same hwirq on
two CPU cores in parallel they both will get 0 from irq_find_mapping(),
both will allocate unique virq using irq_domain_alloc_descs() and both
will finally irq_domain_associate() it. Giving
From: Alexander Sverdlin
irq_create_fwspec_mapping() can race with itself during IRQ trigger type
configuration. Possible scenarios include:
- Mapping exists, two irq_create_fwspec_mapping() running in parallel do
not detect type mismatch, IRQ remains configured with one of the
different
From: Alexander Sverdlin
irq_domain_associate() is the only place where irq_find_mapping() can be
used reliably (under irq_domain_mutex) to make a decision if the mapping
shall be created or not. Other calls to irq_find_mapping() (not under
any lock) cannot be used for this purpose and lead to
From: Alexander Sverdlin
Seems that the discovered race was here since adapting the PowerPC code
into genirq in 2012. I was surprized it went unnoticed all this time, but
it turns out, device registration (being it DT or ACPI) is mostly
sequential in kernel. In our case probe deferring was
Hi!
On 19/08/2019 11:07, Adamski, Krzysztof (Nokia - PL/Wroclaw) wrote:
> This device contains both master and slave controllers which can be
> enabled simultaneously. Both controllers share the same SDA/SCL lines
> and interrupt source but has separate control and status registers.
> Controllers
Hi!
On 27/06/2019 14:07, Thomas Gleixner wrote:
> I'm in the process of merging that series and I actually adapted your
> scheme to the new unified infrastructure where it has exactly the same
> effects as with your original patches against the x86 version.
please let me know if
Hello Thomas!
On 24/06/2019 11:40, Thomas Gleixner wrote:
>>> The alternative solution for this is what Vincenzo has in his unified VDSO
>>> patch series:
>>>
>>> https://lkml.kernel.org/r/20190621095252.32307-1-vincenzo.frasc...@arm.com
>>>
>>> It leaves the data struct unmodified and has a
Hi Thomas,
On 23/06/2019 12:18, Thomas Gleixner wrote:
> The alternative solution for this is what Vincenzo has in his unified VDSO
> patch series:
>
> https://lkml.kernel.org/r/20190621095252.32307-1-vincenzo.frasc...@arm.com
>
> It leaves the data struct unmodified and has a separate array
From: Alexander Sverdlin
Add CLOCK_MONOTONIC_RAW to the existing clock_gettime() vDSO
implementation. This is based on the ideas of Jason Vas Dias and comments
of Thomas Gleixner.
Test program from the previous patch shows the following improvement:
Clock Before After Diff
From: Alexander Sverdlin
This is a preparation for CLOCK_MONOTONIC_RAW vDSO implementation.
Coincidentally it had a slight performance improvement as well:
Test code
#include
#include
#include
#include
#include
#define CLOCK_TYPE CLOCK_MONOTONIC_RAW
#define DURATION_SEC
From: Alexander Sverdlin
Trivial vDSO implementation saves a syscall and brings 700% performance
boost of clock_gettime(CLOCK_MONOTONIC_RAW, ...) call.
Changelog:
v3: Move mult and shift into struct vgtod_ts
v2: copy do_hres() into do_monotonic_raw()
Alexander Sverdlin (2):
x86/vdso: Move
From: Alexander Sverdlin
Add CLOCK_MONOTONIC_RAW to the existing clock_gettime() vDSO
implementation. This is based on the ideas of Jason Vas Dias and comments
of Thomas Gleixner.
Test code
#include
#include
#include
#include
#include
#define CLOCK_TYPE CLOCK_MONOTONIC_RAW
From: Alexander Sverdlin
Add CLOCK_MONOTONIC_RAW to the existing clock_gettime() vDSO
implementation. This is based on the ideas of Jason Vas Dias and comments
of Thomas Gleixner.
Test code
#include
#include
#include
#include
#include
#define CLOCK_TYPE CLOCK_MONOTONIC_RAW
Hello Wolfram,
On 03/04/2019 22:54, Wolfram Sang wrote:
>> Some recent commits to this driver were trying to make sure the TSS
>> interrupt is not generated on busy system due to 25ms timer expiring
>> between commands. It can still happen, however if STOP command is not
>> issued on time at the
Hi!
On 21/03/2019 13:38, Mike Crowe wrote:
[...]
> I don't mind rebasing my patch once I know which of my two solutions is
> preferred. It seems that the -ESPIPE one is the current favourite.
I think:
1. Since Linux v4.8 (!user) case in not possible any more if the device
file was opened in
Hello Paul,
On 28/01/2019 15:52, Paul Moore wrote:
> time also enables syscall auditing; this patch simplifies the Kconfig
> menus by removing the option to disable syscall auditing when audit
> is selected and the target arch supports it.
>
> Signed-off-by: Paul Moore
Hello Paul,
On 28/01/2019 15:19, Paul Moore wrote:
>>> To the best of our knowledge, everyone who enables audit at compile
>>> time also enables syscall auditing; this patch simplifies the Kconfig
>>> menus by removing the option to disable syscall auditing when audit
>>> is selected and the
Hello Paul,
On 28/01/2019 15:19, Paul Moore wrote:
>>> time also enables syscall auditing; this patch simplifies the Kconfig
>>> menus by removing the option to disable syscall auditing when audit
>>> is selected and the target arch supports it.
>>>
>>> Signed-off-by: Paul Moore
>> this patch is
Hello Paul,
On 08/12/2015 17:42, Paul Moore wrote:
> To the best of our knowledge, everyone who enables audit at compile
> time also enables syscall auditing; this patch simplifies the Kconfig
> menus by removing the option to disable syscall auditing when audit
> is selected and the target arch
Hi!
On 13/12/2018 13:09, Adamski, Krzysztof (Nokia - PL/Wroclaw) wrote:
> In order to comply with SMBus specification, the Axxia I²C module will
> abort the multi message transfer if the delay between finishing sending
> one message and starting another is longer than 25ms. Unfortunately it
>
Hi!
On 10/12/2018 16:05, Adamski, Krzysztof (Nokia - PL/Wroclaw) wrote:
> In order to comply with SMBus specification, the Axxia I²C module will
> abort the multi message transfer if the delay between finishing sending
> one message and starting another is longer than 25ms. Unfortunately it
>
Hi!
On 10/12/2018 16:01, Adamski, Krzysztof (Nokia - PL/Wroclaw) wrote:
> It was observed that when using seqentional mode contrary to the
^^^
> documentation, the SS bit (which is supposed to only be set if
> automatic/sequence command completed
Hi!
On 10/12/2018 16:00, Adamski, Krzysztof (Nokia - PL/Wroclaw) wrote:
> This patch moves configuration of hardware registers used for setting
> i2c client address to separate function. It is preparatory change for
> next commit.
Reviewed-by: Alexander Sverdlin
> Signed-off-by: Krzysztof
Hi!
On 11/12/2018 10:17, Adamski, Krzysztof (Nokia - PL/Wroclaw) wrote:
> Create separate entry for i2c-axxia and set myself as maintainer.
>
> Even though I don't work for Intel/LSI who is the manufacturer of this
> IP, I do have access to some documentation and the actual hardware using
> this
Scenario 1, ARMv7:
==
If code in arch/arm/kernel/ftrace.c would operate on mcount() pointer
the following may be generated:
0230 :
230: b5f8push{r3, r4, r5, r6, r7, lr}
232: b500push{lr}
234: f7ff fffe bl 0 <__gnu_mcount_nc>
Scenario 1, ARMv7:
==
If code in arch/arm/kernel/ftrace.c would operate on mcount() pointer
the following may be generated:
0230 :
230: b5f8push{r3, r4, r5, r6, r7, lr}
232: b500push{lr}
234: f7ff fffe bl 0 <__gnu_mcount_nc>
Hello Tudor and all,
On 26/11/2018 13:45, tudor.amba...@microchip.com wrote:
> From: Tudor Ambarus
>
> BFPT advertises all the erase types supported by all the possible
> map configurations. Mask out the erase types that are not supported
> by the current map configuration.
>
> Backward
Hello Tudor and all,
On 26/11/2018 13:45, tudor.amba...@microchip.com wrote:
> From: Tudor Ambarus
>
> BFPT advertises all the erase types supported by all the possible
> map configurations. Mask out the erase types that are not supported
> by the current map configuration.
>
> Backward
Hello Tudor,
On 23/11/2018 11:32, tudor.amba...@microchip.com wrote:
>> I've tested this patch and it fixes the erasesize for S25FS128S and
>> our 128k partitions are writeable again with this patch.
> Good. You said that the flash is configured in non-uniform mapping (hybrid
> sector option).
Hello Tudor,
On 23/11/2018 11:32, tudor.amba...@microchip.com wrote:
>> I've tested this patch and it fixes the erasesize for S25FS128S and
>> our 128k partitions are writeable again with this patch.
> Good. You said that the flash is configured in non-uniform mapping (hybrid
> sector option).
Hello Tudor,
On 22/11/2018 13:36, tudor.amba...@microchip.com wrote:
> From: Tudor Ambarus
>
> Bug reported for the out-of-tree S25FS128S flash memory.
>
> BFPT table advertises all the erase types supported by all the
> possible map configurations. Update the erase_type array to indicate
>
Hello Tudor,
On 22/11/2018 13:36, tudor.amba...@microchip.com wrote:
> From: Tudor Ambarus
>
> Bug reported for the out-of-tree S25FS128S flash memory.
>
> BFPT table advertises all the erase types supported by all the
> possible map configurations. Update the erase_type array to indicate
>
Hello Tudor,
On 22/11/2018 13:36, tudor.amba...@microchip.com wrote:
> From: Tudor Ambarus
>
> Bug reported for the out-of-tree S25FS128S flash memory.
>
> BFPT table advertises all the erase types supported by all the
> possible map configurations. Update the erase_type array to indicate
>
Hello Tudor,
On 22/11/2018 13:36, tudor.amba...@microchip.com wrote:
> From: Tudor Ambarus
>
> Bug reported for the out-of-tree S25FS128S flash memory.
>
> BFPT table advertises all the erase types supported by all the
> possible map configurations. Update the erase_type array to indicate
>
This should fix the following when statically linking host tools:
gcc .../tools/objtool/objtool-in.o -lelf .../tools/objtool/libsubcmd.a
-static -o .../tools/objtool/objtool
.../bin/ld: .../sys-root/lib/libelf.a(elf_compress.o): in function
`__libelf_compress':
.../libelf/elf_compress.c:113:
This should fix the following when statically linking host tools:
gcc .../tools/objtool/objtool-in.o -lelf .../tools/objtool/libsubcmd.a
-static -o .../tools/objtool/objtool
.../bin/ld: .../sys-root/lib/libelf.a(elf_compress.o): in function
`__libelf_compress':
.../libelf/elf_compress.c:113:
47 matches
Mail list logo
