From: Bruce Ashfield
To make the usbc fragment more generally usable, we enable
the Type-C Port Controller driver for TCPCI-compliant controller.
Signed-off-by: Bruce Ashfield
---
meta/recipes-kernel/linux/linux-yocto-rt_5.13.bb | 2 +-
meta/recipes-kernel/linux/linux-yocto-tiny_5.13.bb | 2
From: Bruce Ashfield
To make the usbc fragment more generally usable, we enable
the Type-C Port Controller driver for TCPCI-compliant controller.
Signed-off-by: Bruce Ashfield
---
meta/recipes-kernel/linux/linux-yocto-rt_5.10.bb | 2 +-
meta/recipes-kernel/linux/linux-yocto-tiny_5.10.bb | 2
From: Bruce Ashfield
Integrating the following commit(s) to linux-yocto/5.10:
969fef49cbbc Linux 5.10.52-rt47
bb5ff998ba62 Linux 5.10.47-rt46
340f6b6cdd37 sched: Don't defer CPU pick to migration_cpu_stop()
f3d0be7cdae8 sched: Simplify set_affinity_pending refcounts
From: Bruce Ashfield
Updating linux-yocto/5.13 to the latest korg -stable release that comprises
the following commits:
25423f4bd9a9 Linux 5.13.5
c50bcc85a057 mt76: mt7921: continue to probe driver when fw already
downloaded
c1b582a7e364 udp: properly flush normal packet at GRO
From: Bruce Ashfield
Updating linux-yocto/5.4 to the latest korg -stable release that comprises
the following commits:
0a0beb1f9120 Linux 5.4.135
d2f7b384a74f udp: annotate data races around unix_sk(sk)->gso_size
c72374978b3f perf test bpf: Free obj_buf
17bc942c0b96 bpftool:
From: Bruce Ashfield
Updating linux-yocto/5.10 to the latest korg -stable release that comprises
the following commits:
71046eac2db9 Linux 5.10.53
6cd9bd2a2ddb udp: annotate data races around unix_sk(sk)->gso_size
bfdb38a4268a drm/panel: nt35510: Do not fail if DSI read fails
From: Bruce Ashfield
Richard,
Here's the next set of -stable updates to the active kernels, a -rt
bugfix import and some configuration tweaks requested by Ross.
I do have commits locally to make 5.13 the default kernel for the
reference poky layers, but I'm heading out on vacation and won't
be
From: Teoh Jay Shen
This test mimic the
Test_if_usb_hid_device_works_well_after_resume_from_suspend_state manual test
case from oeqa/manual/bsp-hw.json.
(From OE-Core rev: 23a3dc370a52907ee3261746405fb9b2af9e9a11)
Signed-off-by: Teoh Jay Shen
Signed-off-by: Richard Purdie
---
From: Teoh Jay Shen
-Improve this test case to fulfill the requirements of replacing the
click_terminal_icon_on_X_desktop manual test case from oeqa/manual/bsp-hw :
1) verify that the terminal window is working without problem
2) verify that there's only 1 terminal window is launched
(From
From: TeohJayShen
This test is checking that the terminal application is able to run. The
click_terminal_icon_on_X_desktop manual test case from oeqa/manual/bsp-hw can
be replace by this runtime test.
(From OE-Core rev: cfa9c1ce853bfd31c1febe61d0f7ad9c5d35f709)
Signed-off-by: TeohJayShen
From: Teoh Jay Shen
This test case is checking the command and LAN device behaviour before and
after suspend state. The
Test_if_LAN_device_works_well_after_resume_from_suspend_state and standby
manual test cases from oeqa/manual/bsp-hw can be replace by this runtime test.
(From OE-Core rev:
From: Wes Lindauer
Previously doing a stop/start worked, but using a disable/enable does
not work on a read-only rootfs. Add a --runtime flag to systemctl so
that systemd only modifies the current boot and does not attempt to
write to the filesystem.
This also keeps the test from making a
From: Teoh Jay Shen
This test is checking the functionality of the RTC(Real Time Clock). The
Check_if_RTC_(Real_Time_Clock)_can_work_correctly manual test case from
oeqa/manual/bsp-hw can be replace by this runtime test.
(From OE-Core rev: c6961c2fc04edbc5bc3827c7703997085d9c609e)
From: Teoh Jay Shen
This test mimic the ethernet_static_ip_set_in_connman and
ethernet_get_IP_in_connman_via_DHCP test case from oeqa/manual/bsp-hw.json.
The ethernet_static_ip_set_in_connman and ethernet_get_IP_in_connman_via_DHCP
manual test case should be remove from oeqa/manual/bsp-hw.json
On Wed, 2021-07-28 at 22:28 +0100, Richard Purdie via lists.openembedded.org
wrote:
> On Wed, 2021-07-28 at 14:21 -0700, Andre McCurdy wrote:
> > On Wed, Jul 28, 2021 at 1:54 PM Richard Purdie
> > wrote:
> > >
> > > On Wed, 2021-07-28 at 13:43 -0700, Andre McCurdy wrote:
> > >
> > > > Since
On Wed, 2021-07-28 at 14:21 -0700, Andre McCurdy wrote:
> On Wed, Jul 28, 2021 at 1:54 PM Richard Purdie
> wrote:
> >
> > On Wed, 2021-07-28 at 13:43 -0700, Andre McCurdy wrote:
> >
> > > Since the script will be reused many times for many private layers I'd
> > > say making it as robust as
On Wed, Jul 28, 2021 at 1:54 PM Richard Purdie
wrote:
>
> On Wed, 2021-07-28 at 13:43 -0700, Andre McCurdy wrote:
> > On Wed, Jul 28, 2021 at 1:24 PM Richard Purdie
> > wrote:
> > >
> > > On Wed, 2021-07-28 at 21:00 +0100, Richard Purdie via
> > > lists.openembedded.org wrote:
> > > > On Wed,
On Wed, 2021-07-28 at 13:43 -0700, Andre McCurdy wrote:
> On Wed, Jul 28, 2021 at 1:24 PM Richard Purdie
> wrote:
> >
> > On Wed, 2021-07-28 at 21:00 +0100, Richard Purdie via
> > lists.openembedded.org wrote:
> > > On Wed, 2021-07-28 at 12:32 -0700, Andre McCurdy wrote:
> > > > On Wed, Jul 28,
On Wed, 28 Jul 2021 13:49:17 -0700
Andre McCurdy wrote:
> If the caller only cares about yes/no then how about returning 1/0
> instead of a pointer?
Other callers are actually using the response, because the pseudo_msg_t*
returned from this is how, say, OP_STAT responds with the stat
On Wed, Jul 28, 2021 at 1:16 PM Seebs wrote:
>
> On Wed, 28 Jul 2021 11:36:22 +0200
> "Damian Wrobel" wrote:
>
> > Do I correctly assume that pseudo_client_op() has to be fully
> > reentrant?
>
> No. It's never been even a tiny bit reentrant. We used to do the
> allocate and free thing, and it
On Wed, Jul 28, 2021 at 1:24 PM Richard Purdie
wrote:
>
> On Wed, 2021-07-28 at 21:00 +0100, Richard Purdie via lists.openembedded.org
> wrote:
> > On Wed, 2021-07-28 at 12:32 -0700, Andre McCurdy wrote:
> > > On Wed, Jul 28, 2021 at 7:15 AM Richard Purdie
> > > wrote:
> > > >
> > > > The
On 7/26/21 8:48 AM, Rasmus Villemoes wrote:
Looking at log.do_rootfs, it seems that opkg gets invoked in exactly the
same way with and without the RRECOMMENDS in play:
With RRECOMMENDS, where the build succeeds:
NOTE: Installing the following packages: [...] glib-2.0 iproute2
kernel-image
On Wed, 2021-07-28 at 21:00 +0100, Richard Purdie via lists.openembedded.org
wrote:
> On Wed, 2021-07-28 at 12:32 -0700, Andre McCurdy wrote:
> > On Wed, Jul 28, 2021 at 7:15 AM Richard Purdie
> > wrote:
> > >
> > > The automated conversion of OE-Core to use the new override sytax isn't
> > >
On Wed, 28 Jul 2021 11:36:22 +0200
"Damian Wrobel" wrote:
> Do I correctly assume that pseudo_client_op() has to be fully
> reentrant?
No. It's never been even a tiny bit reentrant. We used to do the
allocate and free thing, and it was incredibly expensive, and the
nature of the thing requires
On Wed, 2021-07-28 at 12:32 -0700, Andre McCurdy wrote:
> On Wed, Jul 28, 2021 at 7:15 AM Richard Purdie
> wrote:
> >
> > The automated conversion of OE-Core to use the new override sytax isn't
> > perfect. This patches some mis-converted lines and some lines which were
> > missed
> > by the
On Wed, Jul 28, 2021 at 7:15 AM Richard Purdie
wrote:
>
> The automated conversion of OE-Core to use the new override sytax isn't
> perfect. This patches some mis-converted lines and some lines which were
> missed
> by the automation.
>
> Signed-off-by: Richard Purdie
> ---
>
All of the errors being masked off for qemuarm are legacy from before
the migration of qemuarm to qemuarmv5. Rename the machine to that to
allow for qemuarmv5 to pass parselog test. Light testing shows no
errors in dmesg for qemuarm.
Signed-off-by: Jon Mason
---
On 7/28/21 4:15 PM, Richard Purdie wrote:
> This adds a script I've developed to migrate metadata to use the new override
> syntax. It is a bit rough but since its for a single use with validation, it
> doesn't need to be perfect. It is run simply as:
>
> scripts/contrib/convert-overrides.py
>
>
The automated conversion of OE-Core to use the new override sytax isn't
perfect. This patches some mis-converted lines and some lines which were missed
by the automation.
Signed-off-by: Richard Purdie
---
meta/classes/insane.bbclass | 2 +-
meta/classes/kernel-grub.bbclass
This adds a script I've developed to migrate metadata to use the new override
syntax. It is a bit rough but since its for a single use with validation, it
doesn't need to be perfect. It is run simply as:
scripts/contrib/convert-overrides.py
It is setup and has been tested to work with OE-Core,
The GNU Atomic library is a GCC support runtime library for atomic
operations not supported by hardware.
Otherwise we get the following when building:
| arm-oe-linux-gnueabi-gcc -mcpu=arm926ej-s -mfpu=vfp -mfloat-abi=hard
-marm
New xkeyboard-config writes defines that use _EVDEVK(), which makekeys
can't parse. Take a patch from upstream to also parse these symbols.
[ YOCTO #14489 ]
Signed-off-by: Ross Burton
---
.../xorg-lib/libx11/keysym.patch | 46 +++
Source: https://sourceware.org/git/glibc.git
Tracking -- https://sourceware.org/bugzilla/show_bug.cgi?id=28011
Backported upstream commit 5adda61f62b77384718b4c0d8336ade8f2b4b35c to
glibc-2.33 source.
Upstream-Status: Backport
On Tue, 27 Jul 2021 18:52:46 +0200 Seebs wrote
> On Tue, 27 Jul 2021 18:30:33 +0200
> Damian Wrobel wrote:
>
> > The returned pointer has to be freed by the caller not by the callee
> > function itself.
>
> So, this predates the public release, but long ago, that was
Hi Nagesh,
On 7/28/21 10:17 AM, Michael Opdenacker wrote:
> Hi Nagesh,
>
> On 7/28/21 9:53 AM, nagesh shamnur wrote:
>> Dear Group,
>> When include newlib and libgloss under DEPENDS in custom recipe,
>> then newlib compilation is successful however libgloss compilation
>> fails since it is
Thanks Michael for the feedback. Will surely keep that in mind and take care.
Cheers!
Nagesh.
On Wed, Jul 28, 2021 at 1:47 PM Michael Opdenacker
wrote:
>
> Hi Nagesh,
>
> On 7/28/21 9:53 AM, nagesh shamnur wrote:
> > Dear Group,
> > When include newlib and libgloss under DEPENDS in custom
Hi Nagesh,
On 7/28/21 9:53 AM, nagesh shamnur wrote:
> Dear Group,
> When include newlib and libgloss under DEPENDS in custom recipe,
> then newlib compilation is successful however libgloss compilation
> fails since it is unable to find the needed include path under
>
Dear Group,
When include newlib and libgloss under DEPENDS in custom recipe,
then newlib compilation is successful however libgloss compilation
fails since it is unable to find the needed include path under
recipe-sysroot/usr/include. This patch is to fix this issue by
including
Dear Group,
When include newlib and libgloss under DEPENDS in custom recipe,
then newlib compilation is successful however libgloss compilation
fails since it is unable to find the needed include path under
recipe-sysroot/usr/include. This patch is to fix this issue by
including
Source: https://sourceware.org/git/glibc.git
Tracking -- https://sourceware.org/bugzilla/show_bug.cgi?id=28011
Backported upstream commit 5adda61f62b77384718b4c0d8336ade8f2b4b35c to
glibc-2.33 source.
Upstream-Status: Backport
40 matches
Mail list logo
