, OTOH, is rather complex. At least the current
implementation breaks some of the isolation we have between the MMU code
and the page table walker library on arm64, which I'm not ecstatic about.
It _could_ be justified by a massive performance uplift over locking, but
it'd have to be a sizable win.
--
Thanks,
Oliver
the underlying implementation has
changed since the original attempt.
> What I have in v2 is RCU based. I hope Oliver or someone else can help
> make that work.
Why? If there's data to show that RCU has a material benefit over taking
the MMU lock for read then I'm all for it. Otherwise, the wor
hi, Kees,
On Tue, Jan 30, 2024 at 04:23:06PM -0800, Kees Cook wrote:
> On Tue, Jan 30, 2024 at 10:52:56PM +0800, kernel test robot wrote:
> >
...
> > while testing, we observed below different (and same part) between parent
> > and
> > this commit:
> >
> > ea804316c9db5148
ut 13. 4. 2021 o 23:33 Daniel Latypov napísal(a):
>
> On Tue, Apr 13, 2021 at 3:07 AM wrote:
> >
> > From: Oliver Glitta
> >
> > SLUB has resiliency_test() function which is hidden behind #ifdef
> > SLUB_RESILIENCY_TEST that is not part of Kconfig,
ut 13. 4. 2021 o 15:54 Marco Elver napísal(a):
>
> On Tue, 13 Apr 2021 at 12:07, wrote:
> > From: Oliver Glitta
> >
> > SLUB has resiliency_test() function which is hidden behind #ifdef
> > SLUB_RESILIENCY_TEST that is not part of Kconfig, so nobody
> &g
allow users to run setserial with cdc-acm")
> Signed-off-by: Johan Hovold
Acked-by: Oliver Neukum
d that the
> TIOCSSERIAL ioctl was not even implemented when a non-privileged user
> set the current values.
>
> Fixes: ba2d8ce9db0a ("cdc-acm: implement TIOCSSERIAL to avoid blocking
> close(2)")
> Signed-off-by: Johan Hovold
Acked-by: Oliver Neukum
HZ value not divisible by two, the lack of rounding when setting
> the default values in tty_port_init() could result in an -EPERM being
> returned, but this is hardly something we need to worry about.
>
> Cc: Anthony Mallet
> Cc: sta...@vger.kernel.org
> Signed-off-by: Johan Hovold
Acked-by: Oliver Neukum
Am Donnerstag, den 08.04.2021, 13:54 +0200 schrieb Johan Hovold:
> On Thu, Apr 08, 2021 at 01:34:12PM +0200, Oliver Neukum wrote:
> > Am Donnerstag, den 08.04.2021, 11:48 +0200 schrieb Johan Hovold:
> > > On Thu, Apr 08, 2021 at 10:36:46AM +0200, Oliver Neukum wrote:
> &
Am Donnerstag, den 08.04.2021, 11:42 +0200 schrieb Johan Hovold:
> On Thu, Apr 08, 2021 at 09:48:38AM +0200, Oliver Neukum wrote:
> > Am Mittwoch, den 07.04.2021, 12:28 +0200 schrieb Johan Hovold:
> > > TIOCSSERIAL is a horrid, underspecified, legacy interface which for most
&g
Am Donnerstag, den 08.04.2021, 11:48 +0200 schrieb Johan Hovold:
> On Thu, Apr 08, 2021 at 10:36:46AM +0200, Oliver Neukum wrote:
> > Am Mittwoch, den 07.04.2021, 12:28 +0200 schrieb Johan Hovold:
> > Well, the devices report it. It is part of the standard.
>
> No, the sta
Am Donnerstag, den 01.04.2021, 09:46 +0200 schrieb Johan Hovold:
> On Wed, Mar 31, 2021 at 01:21:15PM +0200, Oliver Neukum wrote:
> > Am Mittwoch, den 31.03.2021, 09:08 +0200 schrieb Oliver Neukum:
> > on the third hand, the more I look at this, would you mind putting
>
n be
> directly added to the white list.
Hi,
shouldn't this set a flag for a missing functionality?
Regards
Oliver
change
only these two parameters. So can the test really be dropped
as opposed to be modified?
Regards
Oliver
TERate);
If we do this, we have a value that can be set, but is not reported.
That looks a bit strange to me.
Regards
Oliver
me heuristics we can use
> to determine if the physical layer/link is ethernet?
> I'm pessimistic we will be able to since this is at odds with the
> intent of the CDC spec.
Yes, CDC intends to hide that. We can conclude that an asymmetric link
rules out ethernet, but anything else is difficult.
Regards
Oliver
Am Mittwoch, den 31.03.2021, 09:08 +0200 schrieb Oliver Neukum:
> Am Dienstag, den 30.03.2021, 17:22 +0200 schrieb Johan Hovold:
> > On Tue, Mar 30, 2021 at 04:44:32PM +0200, Oliver Neukum wrote:
> > > Am Dienstag, den 30.03.2021, 16:38 +0200 schrieb Johan Hovold:
> >
Am Dienstag, den 30.03.2021, 17:22 +0200 schrieb Johan Hovold:
> On Tue, Mar 30, 2021 at 04:44:32PM +0200, Oliver Neukum wrote:
> > Am Dienstag, den 30.03.2021, 16:38 +0200 schrieb Johan Hovold:
> > > @@ -1115,6 +1161,8 @@ static void usb_serial_disconnect(struct
> > &g
fraid that is an assumption you cannot make. In fact, if somebody
is doing odd things with sysfs you cannot even assume both will see a
disconnect()
Regards
Oliver
Fix address of the pad control register
(IOMUXC_SW_PAD_CTL_PAD_SD1_DATA0) for SD1_DATA0_GPIO2_IO2. This seems
to be a typo but it leads to an exception when pinctrl is applied due to
wrong memory address access.
Signed-off-by: Oliver Stäbler
---
arch/arm64/boot/dts/freescale/imx8mm-pinfunc.h
On 23.03.21 21:54, Rasmus Villemoes wrote:
On 23/03/2021 19.59, Oliver Hartkopp wrote:
On 23.03.21 15:00, Rasmus Villemoes wrote:
Now what CONFIG_* knobs are responsible for putting -mabi=apcs-gnu in
CFLAGS is left as an exercise for the reader. Regardless, it is not a
bug
Fix address of the pad control register
(IOMUXC_SW_PAD_CTL_PAD_SD1_DATA0) for SD1_DATA0_GPIO2_IO2. This seems
to be a typo but it leads to an exception when pinctrl is applied due to
wrong memory address access.
Signed-off-by: Oliver Stäbler
---
arch/arm64/boot/dts/freescale/imx8mm-pinfunc.h
On 23.03.21 15:00, Rasmus Villemoes wrote:
On 23/03/2021 13.49, Oliver Hartkopp wrote:
On 23.03.21 12:36, Rasmus Villemoes wrote:
and more directly from the horse's mouth:
https://developer.arm.com/documentation/dui0067/d/arm-compiler-reference/c-and-c---implementation-details
On 23.03.21 12:36, Rasmus Villemoes wrote:
On 23/03/2021 08.45, Oliver Hartkopp wrote:
IMO we facing a compiler problem here - and we should be very happy that
the BUILD_BUG_ON() triggered an issue after years of silence.
I do not have a good feeling about what kind of strange effects
Answering myself ...
On 23.03.21 08:45, Oliver Hartkopp wrote:
On 23.03.21 08:34, Marc Kleine-Budde wrote:
On 23.03.2021 10:54:40, Rong Chen wrote:
I tried arm-linux-gnueabi (gcc version 10.2.0) and the problem still
exists, btw we prefer to not use the latest gcc compiler to avoid
false
this
compiler issue might have in other code of other projects.
So I would explicitly suggest NOT to change the af_can.c code to work
around this compiler issue.
Let the gcc people fix their product and let them thank all of us for
detecting it.
Regards,
Oliver
Hi Rong,
On 22.03.21 09:52, Rong Chen wrote:
On 3/21/21 10:19 PM, Oliver Hartkopp wrote:
Two reminders in two days? ;-)
Did you check my answer here?
https://lore.kernel.org/lkml/afffeb73-ba4c-ca2c-75d0-9e7899e5c...@hartkopp.net/
And did you try the partly revert?
Hi Oliver,
Sorry
BUSY;
}
That check is ancient. BKL still existed. If you want to remove it
and do proper error handling, that would be good. But if you do
error handling, the check has to go, too.
Regards
Oliver
Am Donnerstag, den 18.03.2021, 16:52 +0100 schrieb Johan Hovold:
> Use negation consistently throughout the driver for NULL checks.
>
> Signed-off-by: Johan Hovold
Acked-by: Oliver Neukum
d-off-by: Johan Hovold
Acked-by: Oliver Neukum
Am Donnerstag, den 18.03.2021, 16:51 +0100 schrieb Johan Hovold:
> There's no need to clear the interface driver data on failed probe (and
> driver core will clear it anyway).
>
> Signed-off-by: Johan Hovold
Acked-by: Oliver Neukum
Am Donnerstag, den 18.03.2021, 16:51 +0100 schrieb Johan Hovold:
> The interface driver data has already been set by
> usb_driver_claim_interface() so drop the redundant subsequent
> assignment.
>
> Signed-off-by: Johan Hovold
Acked-by: Oliver Neukum
t; releasing already freed resources.
>
> Fixes: c93d81955005 ("usb: cdc-acm: fix error handling in acm_probe()")
> Cc: sta...@vger.kernel.org # 3.9
> Cc: Alexey Khoroshilov
> Signed-off-by: Johan Hovold ]
Acked-by: Oliver Neukum
Drop the first erroneous free that was left when fixing a tty-port
> resource leak.
>
> Fixes: cae2bc768d17 ("usb: cdc-acm: Decrement tty port's refcount if probe()
> fail")
> Cc: sta...@vger.kernel.org # 4.19
> Cc: Jaejoong Kim
> Signed-off-by: Johan Hovold
Acked-by: Oliver Neukum
Hi Vlastimil,
On Wed, Mar 17, 2021 at 12:29:40PM +0100, Vlastimil Babka wrote:
> On 3/17/21 9:36 AM, kernel test robot wrote:
> >
> >
> > Greeting,
> >
> > FYI, we noticed the following commit (built with gcc-9):
> >
> > commit: e48d82b67a2b760eedf7b95ca15f41267496386c ("[PATCH 1/2]
here:
https://lore.kernel.org/lkml/6e57d5d2-9b88-aee6-fb7a-82e24144d...@hartkopp.net/
In both cases I can not really fix the issue.
When the partly revert (suggested above) works, this would be a hack too.
Best,
Oliver
On 20.03.21 21:43, kernel test robot wrote:
Hi Oliver,
FYI, the error
On 19.03.21 09:06, kernel test robot wrote:
Hi Oliver,
FYI, the error/warning still remains.
Hm - I have no clue either.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 8b12a62a4e3ed4ae99c715034f557eb391d6b196
commit
Hi Minchan,
On Wed, Mar 17, 2021 at 09:29:38AM -0700, Minchan Kim wrote:
> On Wed, Mar 17, 2021 at 10:37:57AM +0800, kernel test robot wrote:
> >
> >
> > Greeting,
> >
> > FYI, we noticed the following commit (built with gcc-9):
> >
> > commit: 8fd8d23ab10cc2fceeac25ea7b0e2eaf98e78d64
xf5/0x160
> >> [ 890.653833] ? vfs_iter_read+0x80/0x80
> >> [ 890.664229] ? __fdget_pos+0xc0/0xe0
> >> [ 890.674236] ? pvclock_clocksource_read+0xd9/0x1a0
> >> [ 890.684259] ? kvm_sched_clock_read+0x14/0x40
> >> [ 890.693852] ? sched_clock+0x1b/0x40
> >> [ 890.702898] ? sched_clock_cpu+0x18/0x120
> >> [ 890.711648] ? write_comp_data+0x2a/0xa0
> >> [ 890.720243] ? __sanitizer_cov_trace_pc+0x1d/0x60
> >> [ 890.729290] do_readv+0x111/0x260
> >> [ 890.738205] ? vfs_readv+0x160/0x160
> >> [ 890.747154] ? lockdep_hardirqs_on+0x77/0x100
> >> [ 890.756100] ? syscall_enter_from_user_mode+0x8a/0x100
> >> [ 890.765126] do_syscall_64+0x34/0x80
> >> [ 890.773795] entry_SYSCALL_64_after_hwframe+0x44/0xa9
> >> [ 890.782630] RIP: 0033:0x453b29
> >> [ 890.791189] Code: 00 f3 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48
> >> 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05
> >> <48> 3d 01 f0 ff ff 0f 83 3b 84 00 00 c3 66 2e 0f 1f 84 00 00 00 00
> >> [ 890.810866] RSP: 002b:7ffcda44fb18 EFLAGS: 0246 ORIG_RAX:
> >> 0013
> >> [ 890.820764] RAX: ffda RBX: 0013 RCX:
> >> 00453b29
> >> [ 890.830792] RDX: 009a RSI: 01de1c00 RDI:
> >> 00b9
> >> [ 890.840626] RBP: 7ffcda44fbc0 R08: 722c279d69ffc468 R09:
> >> 0400
> >> [ 890.850366] R10: 0098d82a42c63c22 R11: 0246 R12:
> >> 0002
> >> [ 890.860001] R13: 7f042ae6f058 R14: 010a2830 R15:
> >> 7f042ae6f000
> >>
> >>
> >>
> >> To reproduce:
> >>
> >> # build kernel
> >>cd linux
> >>cp config-5.11.0-rc4-8-g79991caf5202 .config
> >>make HOSTCC=gcc-9 CC=gcc-9 ARCH=x86_64 olddefconfig prepare
> >> modules_prepare bzImage
> >>
> >> git clone
> >> https://urldefense.com/v3/__https://github.com/intel/lkp-tests.git__;!!GqivPVa7Brio!LfgrgVVtPAjwjqTZX8yANgsix4f3cJmAA_CcMeCVymh5XYcamWdR9dnbIQA-Qkr9TyI$
> >>
> >> cd lkp-tests
> >> bin/lkp qemu -k job-script # job-script is attached in
> >> this email
> >>
> >>
> >>
> >> Thanks,
> >> Oliver Sang
> >>
>
Hi Nikolay,
On Tue, Mar 09, 2021 at 10:36:52AM +0200, Nikolay Borisov wrote:
>
>
> On 9.03.21 г. 10:49 ч., kernel test robot wrote:
> >
> >
> > Greeting,
> >
> > FYI, we noticed the following commit (built with gcc-9):
> >
> > commit: 5297199a8bca12b8b96afcbf2341605efb6005de ("btrfs: remove
Hi Ira,
On Thu, Mar 11, 2021 at 08:02:20AM -0800, Ira Weiny wrote:
> On Tue, Mar 09, 2021 at 08:53:04PM +, Chaitanya Kulkarni wrote:
> > Ira,
> >
> > On 3/4/21 00:23, kernel test robot wrote:
> > > Greeting,
> > >
> > > FYI, we noticed the following commit (built with gcc-9):
> > >
> > >
d them upstream.
Regards
Oliver
t) from [<809c6584>]
(sch_direct_xmit+0xcc/0x264) r10:834e5600 r9: r8: r7:82b44000 r6:82ab1f00
r5:834e5600 r4:83f27400
| [<809c64b8>] (sch_direct_xmit) from [<809c6c0c>] (__qdisc_run+0x4f0/0x534)
To fix this problem, only set skb ownership to sockets which have sti
the kernel has increased change of reproducing
> oops.
OK, so this is not an additional problem.
According to your logs, an URB that should have been killed wasn't.
> I am ready to test new patches and will continue to report oops
Could you test the attached patches?
Regard
Hi, Neal,
On Wed, Feb 24, 2021 at 10:13:02PM +0800, Oliver Sang wrote:
> Hi, Neal,
>
> On Fri, Feb 19, 2021 at 09:52:04AM -0500, Neal Cardwell wrote:
> > On Thu, Feb 18, 2021 at 8:33 PM kernel test robot
> > wrote:
> > >
> > >
> > > Greeting,
0 r4:834e5600
| [<80972408>] (dev_hard_start_xmit) from [<809c6584>]
(sch_direct_xmit+0xcc/0x264) r10:834e5600 r9: r8: r7:82b44000 r6:82ab1f00
r5:834e5600 r4:83f27400
| [<809c64b8>] (sch_direct_xmit) from [<809c6c0c>] (__qdisc_run+0x4f0/0x534)
To fix th
Hi, Neal,
On Fri, Feb 19, 2021 at 09:52:04AM -0500, Neal Cardwell wrote:
> On Thu, Feb 18, 2021 at 8:33 PM kernel test robot
> wrote:
> >
> >
> > Greeting,
> >
> > FYI, we noticed the following commit (built with gcc-9):
> >
> > commit: 9d9b1ee0b2d1c9e02b2338c4a4b0a062d2d3edac ("tcp: fix
> >
On Tue, Feb 23, 2021 at 9:44 AM Linus Torvalds
wrote:
>
> On Mon, Feb 22, 2021 at 4:06 AM Michael Ellerman wrote:
> >
> > Please pull powerpc updates for 5.12.
>
> Pulled. However:
>
> > mode change 100755 => 100644
> > tools/testing/selftests/powerpc/eeh/eeh-functions.sh
> > create mode
just build it as much as possible myself.
Is this a regression? Does it work after reverting the patch? Which
version of iOS?
Regards
Oliver
nd
> it produce similar issue. Hopefully that make the oops more useful.
> Issue has been seen on multiple devices, so I don't think it's a bad
> hardware issue.
Hi,
is this a regression from 5.10?
Regards
Oliver
Add the compatibles for Variscite i.MX6UL compatibles
Signed-off-by: Oliver Graute
---
Changelog:
v4:
- added missing 6 in i.MX6
v3:
- rebased
v2:
- renamed binding
- removed superflous "
Documentation/devicetree/bindings/arm/fsl.yaml | 1 +
1 file changed, 1 insertion(+)
diff
This patch adds DeviceTree Source for the i.MX6 UltraLite DART NAND/WIFI
Signed-off-by: Oliver Graute
Cc: Shawn Guo
Cc: Neil Armstrong
Cc: Marco Felsch
Cc: Parthiban Nallathambi
---
Changelog:
v9:
- removed display-timing node
- added 5V power supply for display
- added assigned clocks
This patch adds support for the i.MX6UL variant of the Variscite DART-6UL
SoM Carrier-Board
Signed-off-by: Oliver Graute
Cc: Shawn Guo
Cc: Neil Armstrong
Cc: Marco Felsch
Cc: Parthiban Nallathambi
---
.../boot/dts/imx6ul-imx6ull-var-dart-common.dtsi | 314 +
1 file
This patch series adds support for the Variscite DART-6UL SoM
Product Page: https://www.variscite.com/product/evaluation-kits/dart-6ul-kits
Oliver Graute (3):
ARM: dts: imx6ul: Add Variscite DART-6UL SoM support
ARM: dts: Add support for i.MX6 UltraLite DART Variscite Customboard
dt
On 13.02.21 20:57, kernel test robot wrote:
Hi Oliver,
FYI, the error/warning still remains.
Yes, because of the this union, see:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/linux/can.h?id=c7b74967799b1af52b3045d69d4c26836b2d41de#n109
Maybe I
things into a union that have a completely
different purpose - and we might finally run into similar problems like
today.
Best regards,
Oliver
len' in the reported c7b74967799b1 commit, it compiles
without problems.
Regards,
Oliver
git remote add linus
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout c7b74967799b1af52b3045d69d4c26836b2d41de
# save
Add support for the Solomon Goldentek Display Model: GKTW70SDAD1SD
to panel-simple.
The panel spec from Variscite can be found at:
https://www.variscite.com/wp-content/uploads/2017/12/VLCD-CAP-GLD-RGB.pdf
Signed-off-by: Oliver Graute
Reviewed-by: Marco Felsch
Reviewed-by: Fabio Estevam
On Fri, Feb 5, 2021 at 5:17 AM Mayank Suman wrote:
>
> Signed-off-by: Mayank Suman
commit messages aren't optional
> ---
> arch/powerpc/kernel/eeh.c| 8
> arch/powerpc/platforms/powernv/eeh-powernv.c | 4 ++--
> 2 files changed, 6 insertions(+), 6 deletions(-)
>
>
On 02/02/21, Marco Felsch wrote:
> Hi Oliver,
>
> On 21-02-02 18:35, Oliver Graute wrote:
> > Add support for the Solomon Goldentek Display Model: GKTW70SDAD1SD
> > to panel-simple.
> >
> > The panel spec from Variscite can be found at:
> > https://www.v
Add support for the Solomon Goldentek Display Model: GKTW70SDAD1SD
to panel-simple.
The panel spec from Variscite can be found at:
https://www.variscite.com/wp-content/uploads/2017/12/VLCD-CAP-GLD-RGB.pdf
Signed-off-by: Oliver Graute
Cc: Marco Felsch
Cc: Fabio Estevam
---
v3:
- added flags
On Tue, Feb 2, 2021 at 2:21 PM Yang Li wrote:
>
> Eliminate the following coccicheck warning:
> ./arch/powerpc/kernel/eeh.c:782:2-3: Unneeded semicolon
Doesn't appear to be a load-bearing semicolon. It's hard to tell with EEH.
Reviewed-by: Oliver O'Halloran
>
> Reported-
On 01/02/21, Marco Felsch wrote:
> Hi Oliver,
>
> thanks for the patch :)
>
> On 21-01-29 20:09, Oliver Graute wrote:
> > Add support for the Solomon Goldentek Display Model: GKTW70SDAD1SD
> > to panel-simple.
> >
> > The panel spec from Variscite can be
Am Samstag, den 23.01.2021, 18:32 +0100 schrieb Emil Renner Berthing:
> From: Emil Renner Berthing
>
> This converts the driver to use the new tasklet API introduced in
> commit 12cc923f1ccc ("tasklet: Introduce new initialization API")
>
> Signed-off-by: Emil Renne
Am Samstag, den 23.01.2021, 18:32 +0100 schrieb Emil Renner Berthing:
> From: Emil Renner Berthing
>
> Initialize tasklet using tasklet_init() rather than open-coding it.
>
> Signed-off-by: Emil Renner Berthing
Acked-by: Oliver Neukum
Am Samstag, den 23.01.2021, 13:11 +0800 schrieb Dongliang Mu:
> Every line of code should start with tab (8 characters)
>
> Signed-off-by: Dongliang Mu
Acked-by: Oliver Neukum
Add support for the Solomon Goldentek Display Model: GKTW70SDAD1SD
to panel-simple.
The panel spec from Variscite can be found at:
https://www.variscite.com/wp-content/uploads/2017/12/VLCD-CAP-GLD-RGB.pdf
Signed-off-by: Oliver Graute
Cc: Marco Felsch
Cc: Fabio Estevam
---
v2:
- changed bpc
On Tue, Jan 26, 2021 at 09:03:26AM +0100, Geert Uytterhoeven wrote:
> Hi Oliver,
>
> On Tue, Jan 26, 2021 at 6:35 AM kernel test robot
> wrote:
> > FYI, we noticed the following commit (built with gcc-9):
> >
> > commit: d97e11e25dd226c44257284f95494bb06d1ebf5a (&q
On 26/01/21, Fabio Estevam wrote:
> Hi Oliver,
>
> On Mon, Jan 25, 2021 at 7:17 PM Oliver Graute wrote:
>
> > I would prefer mine, because I got a wrong colored penguin on bootup
> > with yours :-)
The wrong colored Tux is caused by the bus_format:
.bus_format = MEDIA_
imum version of GCC
> to 5.1 for arm64"), which forbids GCC 4.9 as it has been
> demonstrated to mis-compile the kernel (and this patch is targeting
> stable anyway)
If the latter is hitting stable then it sounds like high time to throw
out my broken GCC. Thanks Marc!
--
Oliver
On 16/01/21, Fabio Estevam wrote:
> On Sat, Jan 16, 2021 at 9:49 AM Oliver Graute wrote:
>
> > > power-supply = <_touch_3v3> is not correct, as the reg_touch_3v3
> > > does not power the LCD.
> >
> > yes, but how is the LCD correctly powered the
On 25/01/21, Fabio Estevam wrote:
> Hi Oliver,
>
> On Mon, Jan 25, 2021 at 6:29 PM Oliver Graute wrote:
>
> > Ok I fixed the pin conflict with regulator-gpio and added a 5V
> > regulator node in my dts file. Now the display is working fine!
>
> That's good new
d as David has suggested? It was
backported to 5.4 LTS in commit 653ae33b030b ("KVM: arm64: Fix symbol
dependency in __hyp_call_panic_nvhe")
and is causing build issues with a 4.9.4 vintage of GCC.
Thanks!
--
Oliver
is issued for every of its uses.
So, add the missing __user annotation (this remove ~700 warnings when
using defconfig).
Many thanks that you were able to spot this issue, Luc!
Best regards,
Oliver
Link: https://lore.kernel.org/r/202101141753.ropiz9nh-...@intel.com
Reported-by: kernel test robot
On Fri, Jan 15, 2021 at 03:24:32PM +0800, Hillf Danton wrote:
> Thu, 14 Jan 2021 15:45:11 +0800
> >
> > FYI, we noticed the following commit (built with gcc-9):
> >
> > commit: d5bff968ea9cc005e632d9369c26cbd8148c93d5 ("workqueue: break
> > affinity initiatively")
> >
On Thu, Jan 14, 2021 at 04:42:48PM +0800, Hillf Danton wrote:
> Thu, 14 Jan 2021 15:45:11 +0800
> >
> > FYI, we noticed the following commit (built with gcc-9):
> >
> > commit: d5bff968ea9cc005e632d9369c26cbd8148c93d5 ("workqueue: break
> > affinity initiatively")
> >
On Wed Jan 20, 2021 at 5:44 PM NZDT, Linus Torvalds wrote:
>
> But in the meantime, here's two more patches to try on top of the
> previous four. They shouldn't matter, other than making the non-icanon
> throughput a lot better. But the more coverage they get, the happier
> I'll be.
>
I tried
On Wed Jan 20, 2021 at 9:24 AM NZDT, Linus Torvalds wrote:
> Anyway, anybody willing to test these tty/pipe patches on the loads
> that failed? Oliver?
Writing this from a kernel with those patches in; happily splice()ing
to and from a pty.
On Wed Jan 20, 2021 at 5:56 AM NZDT, Robert Karszniewicz wrote:
>
> I have bisected this issue down to this commit:
> 4d03e3cc5982 ("fs: don't allow kernel reads and writes without iter
> ops")
>
> Another case I've also noticed is writing to a serial connection:
> kernel write not supported for
On Sun Jan 17, 2021 at 5:46 AM NZDT, Johannes Berg wrote:
> On Sat, 2021-01-16 at 20:35 +1300, Oliver Giles wrote:
> > Commit 36e2c7421f02 (fs: don't allow splice read/write without
> > explicit ops) broke my userspace application which talks to an SSL VPN
> > by splice(
On 10/01/21, Fabio Estevam wrote:
> On Sun, Jan 10, 2021 at 5:09 PM Oliver Graute wrote:
>
> > here the schematics and my dts. The board is using a LVDS connector for
> > the display.
>
> The schematics shows the GKTW70SDAD1SD panel in the J4 connector, not
> the
Commit 36e2c7421f02 (fs: don't allow splice read/write without explicit ops)
broke my userspace application which talks to an SSL VPN by splice()ing between
"openssl s_client" and "pppd". The latter operates over a pty, and since that
commit there is no fallback for splice()ing between a pipe
of similar code snippets in the kernel, e.g. in
net/can/raw.c or net/bluetooth/hci_sock.c ...
And these code snippets do not trigger such sparse warnings?!?
Any idea?
Regards,
Oliver
vim +1240 net/can/isotp.c
1229
1230 static int isotp_getsockopt(struct socket *sock, int level, int
we need a memset(0) in isotp_getname().
Yes m(
Sent a patch to fix it:
https://lore.kernel.org/linux-can/20210112090457.11262-1-socket...@hartkopp.net/T/#u
Many thanks!
Oliver
gt; case -EPIPE:
> case -EPROTO:
> case -ESHUTDOWN:
> + usb_free_coherent(urb->dev, urb->transfer_buffer_length,
> + urb->transfer_buffer, urb->transfer_dma);
> return;
>
Can you call usb_free_coherent() in what can be hard IRQ context?
Regards
Oliver
On 10/01/21, Fabio Estevam wrote:
> Hi Oliver,
>
> On Sun, Jan 10, 2021 at 12:35 PM Oliver Graute
> wrote:
>
> > the first two errors are gone. But I still get this:
> >
> > [ 42.387107] mxsfb 21c8000.lcdif: Cannot connect bridge: -517
> >
> > Th
On 09/01/21, Fabio Estevam wrote:
> On Fri, Jan 8, 2021 at 7:23 PM Oliver Graute wrote:
>
> > + panel1: panel-lcd {
> > + compatible = "sgd,gktw70sdad1sd";
> > +
> > + backlight = <_lcd>;
> > + po
On 09/01/21, Fabio Estevam wrote:
> On Fri, Jan 8, 2021 at 7:23 PM Oliver Graute wrote:
>
> > diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml
> > b/Documentation/devicetree/bindings/arm/fsl.yaml
> > index 05906e2..5f74d78 100644
> > --- a/Documen
On 09/01/21, Fabio Estevam wrote:
> Hi Oliver,
>
> On Fri, Jan 8, 2021 at 7:24 PM Oliver Graute wrote:
> >
> > On 19/12/20, Oliver Graute wrote:
> > > Add support for the Solomon Goldentek Display Model: GKTW70SDAD1SD
> > > to panel-simple.
> > >
On 19/12/20, Oliver Graute wrote:
> Add support for the Solomon Goldentek Display Model: GKTW70SDAD1SD
> to panel-simple.
>
> The panel spec from Variscite can be found at:
> https://www.variscite.com/wp-content/uploads/2017/12/VLCD-CAP-GLD-RGB.pdf
some clue what bus_format and b
Add the compatibles for Variscite i.MX6UL compatibles
Signed-off-by: Oliver Graute
---
Changelog:
v3:
- rebased
v2:
- renamed binding
- removed superflous "
Documentation/devicetree/bindings/arm/fsl.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devic
This patch adds support for the i.MX6UL variant of the Variscite DART-6UL
SoM Carrier-Board
Signed-off-by: Oliver Graute
Cc: Shawn Guo
Cc: Neil Armstrong
Cc: Marco Felsch
Cc: Parthiban Nallathambi
---
.../boot/dts/imx6ul-imx6ull-var-dart-common.dtsi | 300 +
1 file
This patch adds DeviceTree Source for the i.MX6 UltraLite DART NAND/WIFI
Signed-off-by: Oliver Graute
Cc: Shawn Guo
Cc: Neil Armstrong
Cc: Marco Felsch
Cc: Parthiban Nallathambi
---
Changelog:
v8:
- backlight droped the status line
- port the display panel
- added pinctrl for touch
v7
This patch series adds support for the Variscite DART-6UL SoM
Product Page: https://www.variscite.com/product/evaluation-kits/dart-6ul-kits
Oliver Graute (3):
ARM: dts: imx6ul: Add Variscite DART-6UL SoM support
ARM: dts: Add support for i.MX6 UltraLite DART Variscite Customboard
dt
Am Dienstag, den 05.01.2021, 04:50 + schrieb Zhang, Qiang:
>
>
> 发件人: Oliver Neukum
> 发送时间: 2021年1月5日 0:28
> 收件人: syzbot; andreyk...@google.com; gre...@linuxfoundation.org;
> gustavo...@kernel.org; ingras...@epigenesys.com; le
yzkaller.appspotmail.com
#syz test: https://github.com/google/kasan.git 5e60366d
>From f51e3c5a202f3abc805edd64b21a68d29dd9d60e Mon Sep 17 00:00:00 2001
From: Oliver Neukum
Date: Mon, 4 Jan 2021 17:26:33 +0100
Subject: [PATCH] cdc-wdm: poison URBs upon disconnect
We have a chicken and egg
t; [2 .noinstr.text] 0xc04b8d00
> > [1 uevent] KEY=10007 ff9807ff febeffdfffef
> > fffe
> > [50 modules] netconsole 20480 0 - Live 0xc00cb000
> > [337 blacklist] 0x81c00880-0x81c008a0 asm_exc_overflow
> > [1 .rodata.cst32.byteshift_table] 0xc00a7100
> > [2 wchan] 0xc93c/proc/bus/input/devices: B: KEY=10007
> > ff9807ff febeffdfffef fffe
> > [6 .ref.data] 0xc02817a0
> > [14 __ksymtab_gpl] 0xc03b503c
> > [42 .rodata] 0xc009f2c0
> > [50 .symtab] 0xc00b9000
> >
> >
> >
> > To reproduce:
> >
> > git clone https://github.com/intel/lkp-tests.git
> > cd lkp-tests
> > bin/lkp install job.yaml # job file is attached in this email
> > bin/lkp run job.yaml
> >
> >
> >
> > Thanks,
> > Oliver Sang
> >
>
nsight?
When going through isotp_rcv_fc() there is no other way than
so->tx.state already contains ISOTP_WAIT_FC at that point.
Or did I miss something?
Best regards,
Oliver
On 20.12.20 15:37, Oleksij Rempel wrote:
Hello Oliver,
On Sun, Dec 20, 2020 at 02:18:27PM +0100, Oliver Hartkopp wrote:
Hello Oleksij,
I assume there is some ndev->ml_priv value set - but not from a CAN
netdevice.
it is kind of CAN device :)
No, it is not.
Team and bonding devi
tify_done:
return NOTIFY_DONE;
}
If so, I can send a proper patch if you like.
Best regards,
Oliver
On 20.12.20 06:34, syzbot wrote:
Hello,
syzbot found the following issue on:
HEAD commit:d635a69d Merge tag 'net-next-5.11' of git://git.kernel.org..
git tree: upstream
conso
1 - 100 of 3377 matches
Mail list logo
