On Tue, Jul 16, 2024 at 11:48 AM Geert Uytterhoeven
wrote:
> On Wed, Jul 10, 2024 at 10:14 PM Stephen Boyd wrote:
> > We'd like to apply overlays to the root node in KUnit so we can test
> > platform devices created as children of the root node.
> >
> > On some a
/linux/kernel/git/geert/renesas-drivers.git/tree/arch/arm64/boot/dts/renesas/r8a77990-ebisu-cn41-msiof0-25lc040.dtso?h=topic/renesas-overlays
[2]
https://elixir.bootlin.com/linux/latest/source/drivers/i2c/muxes/i2c-demux-pinctrl.c#L60
[3]
https://elixir.bootlin.com/linux/latest/source/drivers/i2c/m
r address, or
vice versa?
Does the test work on systems that use 4G/4G for kernel/userspace
instead of the usual 1G/3G split?
/me runs the old test_user_copy.ko on ARAnyM
Seems to take a while? Or it hangs, too?
Related reading material
https://lore.kernel.org/all/camuhmduzhwm5_tl7tnaof+uqhejnkgs
ned-off-by: Geert Uytterhoeven
Reviewed-by: Thomas Gleixner
---
v2:
- Add Reviewed-by.
---
tools/testing/selftests/timers/clocksource-switch.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tools/testing/selftests/timers/clocksource-switch.c
b/tools/testing/selfte
robably you just want to make this explicit, by adding
u16 pad;
here.
>
> + /* used to support CHECKSUM_COMPLETE for tunneling protocols */
> + __wsum csum;
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
names in BUG/WARNING messages). That change, if
> desired, can be made later.
Unfortunately this also increases kernel size in the CONFIG_KUNIT=m
case (ca. 80 KiB for atari_defconfig), making it less attractive to have
kunit and all tests enabled as modules in my standard kernel.
Gr{oetje,ee
_), \
> + : : "i" (__BUG_FUNC), \
> + "i" (__LINE__), \
> "i" (x),
On Tue, Mar 12, 2024 at 3:41 PM Geert Uytterhoeven wrote:
> On Wed, Feb 21, 2024 at 3:06 PM Rob Herring wrote:
> > On Fri, Feb 16, 2024 at 11:08 PM Saurabh Singh Sengar
> > wrote:
> > > This adds the strict check for compatible which makes compatible
> > > to be
hanism for
* enabling full constraints and since it's much more natural
* with DT to provide them just assume that a DT enabled
* system has full constraints.
*/
if (of_have_populated_dt())
has_full_constraints = tru
Hi Maxime,
On Mon, Mar 4, 2024 at 11:20 AM Maxime Ripard wrote:
> On Mon, Mar 04, 2024 at 11:07:22AM +0100, Geert Uytterhoeven wrote:
> > On Mon, Mar 4, 2024 at 10:15 AM Maxime Ripard wrote:
> > > On Mon, Mar 04, 2024 at 09:12:38AM +0100, Geert Uytterhoeven wrote:
> > &g
Hi Maxime,
On Mon, Mar 4, 2024 at 10:15 AM Maxime Ripard wrote:
> On Mon, Mar 04, 2024 at 09:12:38AM +0100, Geert Uytterhoeven wrote:
> > On Sun, Mar 3, 2024 at 10:30 AM Geert Uytterhoeven
> > wrote:
> > > On Sun, Mar 3, 2024 at 3:30 AM Randy Dunlap wrote:
> >
On Sun, Mar 3, 2024 at 10:30 AM Geert Uytterhoeven wrote:
> On Sun, Mar 3, 2024 at 3:30 AM Randy Dunlap wrote:
> > On 3/2/24 14:10, Guenter Roeck wrote:
> > > While checkpatch is indeed of arguable value, I think it would help a
> > > lot not having to bother a
d.au/kisskb/
Kisskb can send out email when builds get broken, and when they get
fixed again. I receive such emails for the m68k builds.
I have the feeling this is not used up to its full potential yet.
My initial plan with the "Build regressions/improvements in ..." emails
[1] wa
.
What is the point of writing tests for a core functionality like network
checksumming that do not match the expected functionality?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.or
lled ntsync.
> +
> + If unsure, say N.
Is it useful to have this feature on systems or architectures that
are not supported by Windows NT?
If not, this should depend on || COMPILE_TEST.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of
ned-off-by: Geert Uytterhoeven
---
When just running the test, the output looks like:
# Validating clocksource arch_sys_counter
TAP version 13
1..12
ok 1 CLOCK_REALTIME
...
# Validating clocksource ffca.timer
TAP version 13
1..12
ok 1 CLOCK_REALTIME
k fails because it doesn't call the
> unflatten_(and_copy)?_device_tree() function, so we don't populate a
> root node on that architecture. One solution would be to make CONFIG_OF
> unavailable on m68k. Or we have to make sure DT works on any
> architecture. Rob, what do you p
y the start address is checked
> v2:
> - add include
>
> Fixes: 2810c1e99867 ("kunit: Fix wild-memory-access bug in
> kunit_free_suite_set()")
> Reviewed-by: David Gow
> Tested-by: Rae Moar
> Tested-by: Richard Fitzgerald
> Reviewed-by: Javier Martinez Canill
s is all so that we can run DT tests for the clk
> framework; why can't that just depend on the system being booted with DT
> rather
> than ACPI? We have other tests which are architecture and/or configuration
> dependent...
There is definitely a merit in running (platform-independ
Hi Mark,
On Thu, Jan 18, 2024 at 4:23 PM Mark Rutland wrote:
> On Tue, Jan 16, 2024 at 03:13:42PM +0100, Geert Uytterhoeven wrote:
> > On Tue, Jan 16, 2024 at 12:51 PM Mark Rutland wrote:
> > > On Fri, Jan 12, 2024 at 12:07:44PM -0800, Stephen Boyd wrote:
> >
limited.
>
> We could probably restrict the root node to new nodes only and no new
> or changed properties.
Changing (or appending to) the root
"compatible" and/or "model" properties is useful in case of large
extension boards, though. This is also the case
roblems. In addition, we don't want people being
> "clever" and describing disparate portions of their system in ACPI and DT.
We'd get to the latter anyway, when plugging in a USB device where the
circuitry on/behind the USB device is described in DT.
Gr{oetje,eeting}s,
me, 457 and 458 are already taken by statmount() and
listmount():
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/m68k/kernel/syscalls/syscall.tbl#n459
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@
ned-off-by: Geert Uytterhoeven
---
When just running the test, the output looks like:
# Validating clocksource arch_sys_counter
TAP version 13
1..12
ok 1 CLOCK_REALTIME
...
# Validating clocksource ffca.timer
TAP version 13
1..12
ok 1 CLOCK_REALTIME
y, and
which haven't? I expect reviewers/maintainers to scrutinize (extra)
patches that lack such a tag (or lack the same under the "---"),
and/or run the test suite theirselves.
I.e. does this serve any purpose _after_ the patch has been applied?
Gr{oetje,eeting}s,
ckpatch fixes
> as seen on drivers/staging/)?
After having seen the introduction of too many build failures, I'm
inclined to ask for an even stronger proof of testing for "trivial"
fixes for drivers/staging...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterho
There is no reason why the KUnit Tests for the property entry API can
only be built-in. Add support for building these tests as a loadable
module, like is supported by most other tests.
Signed-off-by: Geert Uytterhoeven
---
drivers/base/test/Kconfig | 4 ++--
drivers/base/test
27 matches
Mail list logo
