Hello Adrian,
Could you post a kernel patch for that? I would be happy to test it on my
SH-7785CLR board. Also, I'm going to file a bug report against GCC.
I filed the bug already. It's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108483.
The diff is attached. It's published as CC0 in case
On Fri, 20 Jan 2023, Arnd Bergmann wrote:
> On Fri, Jan 20, 2023, at 18:15, Lee Jones wrote:
> > On Fri, 20 Jan 2023, Arnd Bergmann wrote:
>
> >> > Marek Behún (3):
> >> > leds: turris-omnia: support HW controlled mode via private trigger
> >> > leds: turris-omnia: initialize multi-intensity
* Suren Baghdasaryan [230120 12:50]:
> On Fri, Jan 20, 2023 at 9:32 AM Matthew Wilcox wrote:
> >
> > On Fri, Jan 20, 2023 at 09:17:46AM -0800, Suren Baghdasaryan wrote:
> > > On Fri, Jan 20, 2023 at 9:08 AM Liam R. Howlett
> > > wrote:
> > > >
> > > > * Matthew Wilcox [230120 11:50]:
> > > >
On Fri, Jan 20, 2023 at 9:21 AM Paul E. McKenney wrote:
>
> On Fri, Jan 20, 2023 at 04:49:42PM +, Matthew Wilcox wrote:
> > On Fri, Jan 20, 2023 at 08:45:21AM -0800, Suren Baghdasaryan wrote:
> > > On Fri, Jan 20, 2023 at 8:20 AM Suren Baghdasaryan
> > > wrote:
> > > >
> > > > On Fri, Jan
Hello!
Can someone please file a GCC PR? With reduced testcase preferably.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108483
There you are.
Kind regars,
Michael Karcher
Since Linux 5.19 this error is observed:
sysfs: cannot create duplicate filename '/devices/platform/of-display'
This is because multiple devices with the same name 'of-display' are
created on the same bus.
Update the code to create numbered device names for the non-boot
disaplay.
cc:
Hello,
On Fri, Jan 20, 2023 at 11:23:39AM -0600, Rob Herring wrote:
> On Thu, Jan 19, 2023 at 3:53 AM Michal Suchanek wrote:
> >
> > The commit 2d681d6a23a1 ("of: Make of framebuffer devices unique")
> > breaks build because of wrong argument to snprintf. That certainly
> > avoids the runtime
On Fri, Jan 20, 2023 at 9:32 AM Matthew Wilcox wrote:
>
> On Fri, Jan 20, 2023 at 09:17:46AM -0800, Suren Baghdasaryan wrote:
> > On Fri, Jan 20, 2023 at 9:08 AM Liam R. Howlett
> > wrote:
> > >
> > > * Matthew Wilcox [230120 11:50]:
> > > > On Fri, Jan 20, 2023 at 08:45:21AM -0800, Suren
On Fri, Jan 20, 2023, at 18:15, Lee Jones wrote:
> On Fri, 20 Jan 2023, Arnd Bergmann wrote:
>> > Marek Behún (3):
>> > leds: turris-omnia: support HW controlled mode via private trigger
>> > leds: turris-omnia: initialize multi-intensity to full
>> > leds: turris-omnia: change max
On 20/01/2023 14:34, Alexander Stein wrote:
> From: Matthias Schiffer
>
> TQMLS102xA is a SOM family using NXP LS1021A CPU family.
> MBLS102xA is an evaluation mainboard for this SOM.
>
> Signed-off-by: Matthias Schiffer
> Signed-off-by: Alexander Stein
> ---
> Changes in v2:
> * Improved the
On Fri, Jan 20, 2023 at 09:17:46AM -0800, Suren Baghdasaryan wrote:
> On Fri, Jan 20, 2023 at 9:08 AM Liam R. Howlett
> wrote:
> >
> > * Matthew Wilcox [230120 11:50]:
> > > On Fri, Jan 20, 2023 at 08:45:21AM -0800, Suren Baghdasaryan wrote:
> > > > On Fri, Jan 20, 2023 at 8:20 AM Suren
On Thu, Jan 19, 2023 at 3:53 AM Michal Suchanek wrote:
>
> The commit 2d681d6a23a1 ("of: Make of framebuffer devices unique")
> breaks build because of wrong argument to snprintf. That certainly
> avoids the runtime error but is not the intended outcome.
>
> Also use standard device name format
On Fri, Jan 20, 2023 at 04:49:42PM +, Matthew Wilcox wrote:
> On Fri, Jan 20, 2023 at 08:45:21AM -0800, Suren Baghdasaryan wrote:
> > On Fri, Jan 20, 2023 at 8:20 AM Suren Baghdasaryan
> > wrote:
> > >
> > > On Fri, Jan 20, 2023 at 12:52 AM Michal Hocko wrote:
> > > >
> > > > On Thu
On Fri, Jan 20, 2023, at 14:34, Alexander Stein wrote:
> From: Nicolas Saenz Julienne
>
> The only missing configuration option preventing us from using
> multi_v7_defconfig with the Raspberry Pi 4 is ARM_LPAE. It's needed as
> the PCIe controller found on the SoC depends on 64bit addressing, yet
On Fri, Jan 20, 2023 at 9:08 AM Liam R. Howlett wrote:
>
> * Matthew Wilcox [230120 11:50]:
> > On Fri, Jan 20, 2023 at 08:45:21AM -0800, Suren Baghdasaryan wrote:
> > > On Fri, Jan 20, 2023 at 8:20 AM Suren Baghdasaryan
> > > wrote:
> > > >
> > > > On Fri, Jan 20, 2023 at 12:52 AM Michal
On Fri, 20 Jan 2023, Arnd Bergmann wrote:
> On Mon, Dec 26, 2022, at 13:36, Pali Rohár wrote:
> > Linus Walleij suggested me to send these patches to SoC tree [1]
> > instead. So I'm doing it.
> >
> > This patch series contains LED patches which are on the linux-leds
> > mailing list for a long
On Fri, Jan 20, 2023, at 14:34, Alexander Stein wrote:
> From: Nicolas Saenz Julienne
>
> So far this function was only used locally in powerpc, some other
> architectures might benefit from it. Move it into
> scripts/Makefile.defconf.
>
> Signed-off-by: Nicolas Saenz Julienne
> Signed-off-by:
* Matthew Wilcox [230120 11:50]:
> On Fri, Jan 20, 2023 at 08:45:21AM -0800, Suren Baghdasaryan wrote:
> > On Fri, Jan 20, 2023 at 8:20 AM Suren Baghdasaryan
> > wrote:
> > >
> > > On Fri, Jan 20, 2023 at 12:52 AM Michal Hocko wrote:
> > > >
> > > > On Thu 19-01-23 10:52:03, Suren Baghdasaryan
On Mon, Dec 26, 2022, at 13:36, Pali Rohár wrote:
> Linus Walleij suggested me to send these patches to SoC tree [1]
> instead. So I'm doing it.
>
> This patch series contains LED patches which are on the linux-leds
> mailing list for a long time without any future movement. Could you
> please
On Fri, Jan 20, 2023 at 08:45:21AM -0800, Suren Baghdasaryan wrote:
> On Fri, Jan 20, 2023 at 8:20 AM Suren Baghdasaryan wrote:
> >
> > On Fri, Jan 20, 2023 at 12:52 AM Michal Hocko wrote:
> > >
> > > On Thu 19-01-23 10:52:03, Suren Baghdasaryan wrote:
> > > > On Thu, Jan 19, 2023 at 4:59 AM
On Fri, Jan 20, 2023 at 8:20 AM Suren Baghdasaryan wrote:
>
> On Fri, Jan 20, 2023 at 12:52 AM Michal Hocko wrote:
> >
> > On Thu 19-01-23 10:52:03, Suren Baghdasaryan wrote:
> > > On Thu, Jan 19, 2023 at 4:59 AM Michal Hocko wrote:
> > > >
> > > > On Mon 09-01-23 12:53:34, Suren Baghdasaryan
On 1/20/23 03:06, Vinod Koul wrote:
> On 19-01-23, 11:22, Sean Anderson wrote:
>> On 1/18/23 11:54, Vinod Koul wrote:
>> > On 17-01-23, 11:46, Sean Anderson wrote:
>> >>
>> >> I noticed that this series is marked "changes requested" on patchwork.
>> >> However, I have received only automated
On Fri, Jan 20, 2023 at 12:52 AM Michal Hocko wrote:
>
> On Thu 19-01-23 10:52:03, Suren Baghdasaryan wrote:
> > On Thu, Jan 19, 2023 at 4:59 AM Michal Hocko wrote:
> > >
> > > On Mon 09-01-23 12:53:34, Suren Baghdasaryan wrote:
> > > > call_rcu() can take a long time when callback offloading is
On Fri, Jan 20, 2023 at 09:57:05AM +0100, Michal Hocko wrote:
> On Thu 19-01-23 11:17:07, Paul E. McKenney wrote:
> > On Thu, Jan 19, 2023 at 01:52:14PM +0100, Michal Hocko wrote:
> > > On Wed 18-01-23 11:01:08, Suren Baghdasaryan wrote:
> > > > On Wed, Jan 18, 2023 at 10:34 AM Paul E. McKenney
Em Fri, Jan 20, 2023 at 08:51:59AM +, David Laight escreveu:
> From: Arnaldo Carvalho de Melo
> > Sent: 19 January 2023 17:00
> >
> > Em Thu, Jan 19, 2023 at 03:49:15PM +, David Laight escreveu:
> > > From: Athira Rajeev
> > > > Sent: 19 January 2023 14:27
> > > ...
> > > > The test
Em Fri, Jan 20, 2023 at 05:32:56PM +0530, Athira Rajeev escreveu:
> While parsing the tracepoint events in parse_events_add_tracepoint()
> function, code checks for HAVE_LIBTRACEEVENT support. This is needed
> since libtraceevent is necessary for tracepoint. But while adding
> probe points, check
From: Nicolas Saenz Julienne
The only missing configuration option preventing us from using
multi_v7_defconfig with the Raspberry Pi 4 is ARM_LPAE. It's needed as
the PCIe controller found on the SoC depends on 64bit addressing, yet
can't be included as not all v7 boards support LPAE.
Introduce
From: Nicolas Saenz Julienne
So far this function was only used locally in powerpc, some other
architectures might benefit from it. Move it into
scripts/Makefile.defconf.
Signed-off-by: Nicolas Saenz Julienne
Signed-off-by: Alexander Stein
---
Directly applied from
Enable drivers used on TQMLS102xA + MBLS1021A.
Signed-off-by: Alexander Stein
---
Changes in v2:
* Changed symbols to 'm' where possible
arch/arm/configs/multi_v7_defconfig | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/arm/configs/multi_v7_defconfig
Add device tree overlay for LVDS display usage.
Signed-off-by: Alexander Stein
---
Changes in v2:
* None
arch/arm/boot/dts/Makefile| 2 +
...1021a-tqmls1021a-mbls1021a-cdtech-fc21.dts | 55 +++
2 files changed, 57 insertions(+)
create mode 100644
Add device tree overlay for LVDS display usage.
Signed-off-by: Alexander Stein
---
Changes in v2:
* None
arch/arm/boot/dts/Makefile| 2 +
...1021a-tqmls1021a-mbls1021a-cdtech-dc44.dts | 55 +++
2 files changed, 57 insertions(+)
create mode 100644
Add device tree overlay for HDMI usage.
Signed-off-by: Alexander Stein
---
Changes in v2:
* None
arch/arm/boot/dts/Makefile| 2 ++
.../ls1021a-tqmls1021a-mbls1021a-hdmi.dtso| 36 +++
2 files changed, 38 insertions(+)
create mode 100644
Add device tree overlay for LVDS display usage.
Signed-off-by: Alexander Stein
---
Changes in v2:
* None
arch/arm/boot/dts/Makefile| 5 ++
...tqmls1021a-mbls1021a-lvds-tm070jvhg33.dtso | 56 +++
2 files changed, 61 insertions(+)
create mode 100644
The bootloader does not add the partitions into DT, so add them manually
here.
Signed-off-by: Alexander Stein
---
Changes in v2:
* None
arch/arm/boot/dts/ls1021a-tqmls1021a.dtsi | 31 +++
1 file changed, 31 insertions(+)
diff --git
Add device tree for the MBLS102xA mainboard with TQMLS1021A SoM.
Signed-off-by: Alexander Stein
---
Changes in v2:
* Remove unnecessary status = "okay"
* Remove underscore from node names
* Move reg direct below compatiblefor i2c devices
* Remove i2c device nodes without software support
Add a
From: Matthias Schiffer
TQMLS102xA is a SOM family using NXP LS1021A CPU family.
MBLS102xA is an evaluation mainboard for this SOM.
Signed-off-by: Matthias Schiffer
Signed-off-by: Alexander Stein
---
Changes in v2:
* Improved the description mentioning this is a socketable module
Hi,
this is the second round of this series to add support for the TQMLS1021A
using the MBLS1021A mainboard.
The changelog is included in the individual patches but the most notable
one is picking up the old patch series for adding lpae config snippet
support.
Best regards,
Alexander
Alexander
On Thu, Jan 12, 2023 at 08:43:30PM +0100, Peter Zijlstra wrote:
> The __cpuidle functions will become a noinstr class, as such they need
> explicit annotations.
>
> Signed-off-by: Peter Zijlstra (Intel)
> Reviewed-by: Rafael J. Wysocki
> Acked-by: Frederic Weisbecker
> Tested-by: Tony Lindgren
For LoongArch parts,
Acked-by: Huacai Chen
On Thu, Jan 19, 2023 at 10:37 PM Valentin Schneider wrote:
>
> To be able to trace invocations of smp_send_reschedule(), rename the
> arch-specific definitions of it to arch_smp_send_reschedule() and wrap it
> into an smp_send_reschedule() that
On Thu, Jan 19, 2023 at 11:34:46AM +0100, Michal Suchánek wrote:
> Hello,
>
> On Thu, Jan 19, 2023 at 10:24:07AM +, Christophe Leroy wrote:
> >
> >
> > Le 19/01/2023 à 10:53, Michal Suchanek a écrit :
> > > The commit 2d681d6a23a1 ("of: Make of framebuffer devices unique")
> > > breaks
While parsing the tracepoint events in parse_events_add_tracepoint()
function, code checks for HAVE_LIBTRACEEVENT support. This is needed
since libtraceevent is necessary for tracepoint. But while adding
probe points, check for LIBTRACEEVENT is not done in case of perf probe.
Hence, in environment
On Fri, Jan 20, 2023 at 12:39:23PM +0100, Thomas Zimmermann wrote:
> Hi
>
> Am 20.01.23 um 12:27 schrieb Michal Suchánek:
> > Hello,
> >
> > On Thu, Jan 19, 2023 at 04:20:57PM +0100, Thomas Zimmermann wrote:
> > > Hi
> > >
> > > Am 19.01.23 um 14:23 schrieb Michal Suchánek:
> > > > On Thu, Jan
From: Segher Boessenkool
> Sent: 20 January 2023 10:54
...
> > > I suggest to file a bug against gcc complaining about a "spurious
> > > warning", and using "-Werror -Wno-error-sizeof-pointer-div" until gcc is
> > > adapted to not emit the warning about the pointer division if the result
> > > is
On 19/01/2023 19:29:52, Laurent Dufour wrote:
> On 15/01/2023 16:02:02, Sourabh Jain wrote:
>> On architectures like PowerPC the crash notes are available for all
>> possible CPUs. So let's populate the elfcorehdr for all possible
>> CPUs having crash notes to avoid updating elfcorehdr during
Hi
Am 20.01.23 um 12:27 schrieb Michal Suchánek:
Hello,
On Thu, Jan 19, 2023 at 04:20:57PM +0100, Thomas Zimmermann wrote:
Hi
Am 19.01.23 um 14:23 schrieb Michal Suchánek:
On Thu, Jan 19, 2023 at 02:11:13PM +0100, Thomas Zimmermann wrote:
Hi
Am 19.01.23 um 11:24 schrieb Christophe Leroy:
Hello,
On Thu, Jan 19, 2023 at 04:20:57PM +0100, Thomas Zimmermann wrote:
> Hi
>
> Am 19.01.23 um 14:23 schrieb Michal Suchánek:
> > On Thu, Jan 19, 2023 at 02:11:13PM +0100, Thomas Zimmermann wrote:
> > > Hi
> > >
> > > Am 19.01.23 um 11:24 schrieb Christophe Leroy:
> > > >
> > > >
> > > >
On Thu, Jan 19, 2023 at 09:31:21PM -0600, Rob Landley wrote:
> On 1/19/23 16:11, Michael.Karcher wrote:
> > I don't see a clear bug at this point. We are talking about the C expression
> >
> > __same_type((void*)0, (void*)0)? 0 : sizeof((void*)0)/sizeof(*((void*0))
(__same_type is a kernel
pnv_ioda_setup_pe_res() calls opal to map a resource with a PE. However,
the code assumes the resource is allocated and it uses the resource
address to find out the segment(s) which need to be mapped to the
PE. In the unlikely case where the resource hasn't been allocated, the
computation for the
On Thu 19-01-23 11:17:07, Paul E. McKenney wrote:
> On Thu, Jan 19, 2023 at 01:52:14PM +0100, Michal Hocko wrote:
> > On Wed 18-01-23 11:01:08, Suren Baghdasaryan wrote:
> > > On Wed, Jan 18, 2023 at 10:34 AM Paul E. McKenney
> > > wrote:
> > [...]
> > > > There are a couple of possibilities
On Thu 19-01-23 10:52:03, Suren Baghdasaryan wrote:
> On Thu, Jan 19, 2023 at 4:59 AM Michal Hocko wrote:
> >
> > On Mon 09-01-23 12:53:34, Suren Baghdasaryan wrote:
> > > call_rcu() can take a long time when callback offloading is enabled.
> > > Its use in the vm_area_free can cause regressions
From: Arnaldo Carvalho de Melo
> Sent: 19 January 2023 17:00
>
> Em Thu, Jan 19, 2023 at 03:49:15PM +, David Laight escreveu:
> > From: Athira Rajeev
> > > Sent: 19 January 2023 14:27
> > ...
> > > The test script "tests/shell/buildid.sh" uses some of the
> > > string substitution ways which
Hi Michael!
On 1/19/23 23:11, Michael.Karcher wrote:
I suggest to file a bug against gcc complaining about a "spurious warning",
and using "-Werror -Wno-error-sizeof-pointer-div" until gcc is adapted to
not emit the warning about the pointer division if the result is not used.
Could you post
On 19-01-23, 11:22, Sean Anderson wrote:
> On 1/18/23 11:54, Vinod Koul wrote:
> > On 17-01-23, 11:46, Sean Anderson wrote:
> >>
> >> I noticed that this series is marked "changes requested" on patchwork.
> >> However, I have received only automated feedback. I have done my best
> >> effort to
Environment with /bin/sh
# readlink -f $(which sh)
/bin/dash
Running perf test from tmp.perf/urgent
# ./perf test -v "build id cache operations"
73: build id cache operations :
--- start ---
test child forked, pid 71063
WARNING: wine not found. PE binaries
From: Russell Currey
Currently the max object size is handled in the core secvar code with an
entirely OPAL-specific implementation, so create a new max_size() op and
move the existing implementation into the powernv platform. Should be
no functional change.
Signed-off-by: Russell Currey
If attempting to read the size or data attributes of a non-existent
variable (which will be possible after a later patch to expose the PLPKS
via the secvar interface), don't spam the kernel log with error messages.
Only print errors for return codes that aren't ENOENT.
Reported-by: Sudhakar
Currently, plpks_read_var() allocates a buffer to pass to the
H_PKS_READ_OBJECT hcall, then allocates another buffer, of the caller's
preferred size if necessary, into which the data is copied, and returns
that buffer to the caller.
This is a bit over the top - while we probably still want to
From: Russell Currey
A few improvements to load_powerpc.c:
- include integrity.h for the pr_fmt()
- move all error reporting out of get_cert_list()
- use ERR_PTR() to better preserve error detail
- don't use pr_err() for missing keys
Signed-off-by: Russell Currey
Signed-off-by: Andrew
It seems a bit unnecessary for the PLPKS code to have a user-visible
config option when it doesn't do anything on its own, and there's existing
options for enabling Secure Boot-related features.
It should be enabled by PPC_SECURE_BOOT, which will eventually be what
uses PLPKS to populate
From: Russell Currey
Before interacting with the PLPKS, we ask the hypervisor to generate a
password for the current boot, which is then required for most further
PLPKS operations.
If we kexec into a new kernel, the new kernel will try and fail to
generate a new password, as the password has
From: Russell Currey
The pseries platform can support dynamic secure boot (i.e. secure boot
using user-defined keys) using variables contained with the PowerVM LPAR
Platform KeyStore (PLPKS). Using the powerpc secvar API, expose the
relevant variables for pseries dynamic secure boot through the
61 matches
Mail list logo
