Re: [PATCH 01/18] arm64: dts: renesas: beacon kit: Configure programmable clocks
Hi Adam,
On Mon, Dec 28, 2020 at 3:39 PM Adam Ford wrote:
> On Mon, Dec 28, 2020 at 6:33 AM Geert Uytterhoeven
> wrote:
> > On Thu, Dec 24, 2020 at 2:53 PM Adam Ford wrote:
> > > On Tue, Dec 22, 2020 at 2:03 AM Geert Uytterhoeven
> > > wrote:
> > > > On Tue, Dec 22, 2020 at 2:39 AM Adam Ford wrote:
> > > > > On Fri, Dec 18, 2020 at 7:16 AM Geert Uytterhoeven
> > > > > wrote:
> > > > > > On Thu, Dec 17, 2020 at 12:52 PM Adam Ford
> > > > > > wrote:
> > > > > > > On Thu, Dec 17, 2020 at 2:16 AM Geert Uytterhoeven
> > > > > > > wrote:
> > > > > > > > On Wed, Dec 16, 2020 at 6:03 PM Adam Ford
> > > > > > > > wrote:
> > > > > > > > > On Wed, Dec 16, 2020 at 8:55 AM Geert Uytterhoeven
> > > > > > > > > wrote:
> > > > > > > > > > On Sun, Dec 13, 2020 at 7:38 PM Adam Ford
> > > > > > > > > > wrote:
> > > > > > > > > > > When the board was added, clock drivers were being
> > > > > > > > > > > updated done at
> > > > > > > > > > > the same time to allow the versaclock driver to properly
> > > > > > > > > > > configure
> > > > > > > > > > > the modes. Unforutnately, the updates were not applied
> > > > > > > > > > > to the board
> > > > > > > >
> > > > > > > > > > > ---
> > > > > > > > > > > a/arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi
> > > > > > > > > > > +++
> > > > > > > > > > > b/arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi
> > > > > > > > > > > @@ -5,6 +5,7 @@
> > > > > > > > > > >
> > > > > > > > > > > #include
> > > > > > > > > > > #include
> > > > > > > > > > > +#include
> > > > > > > > > > >
> > > > > > > > > > > / {
> > > > > > > > > > > backlight_lvds: backlight-lvds {
> > > > > > > > > > > @@ -294,12 +295,12 @@ _out_rgb {
> > > > > > > > > > > {
> > > > > > > > > > > dr_mode = "otg";
> > > > > > > > > > > status = "okay";
> > > > > > > > > > > - clocks = < CPG_MOD 703>, < CPG_MOD 704>;
> > > > > > > > > > > + clocks = < CPG_MOD 703>, < CPG_MOD 704>,
> > > > > > > > > > > < 3>;
> > > > > > > > > >
> > > > > > > > > > Why this change? You said before you don't need this
> > > > > > > > > > https://lore.kernel.org/linux-renesas-soc/cahcn7xjwbp16sa-ok-5synnqozat8ofjo2_rtg5vrnvsn2-...@mail.gmail.com/
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > I had talked with the hardware guys about buy pre-programmed
> > > > > > > > > versaclock chips which would have been pre-configured and
> > > > > > > > > pre-enabled.
> > > > > > > > > I thought it was going to happen, but it didn't, so we need
> > > > > > > > > the
> > > > > > > > > versaclock driver to enable the reference clock for the USB
> > > > > > > > > controllers, ethernet controller and audio clocks.
> > > > > > > > > Previously we were
> > > > > > > > > manually configuring it or it was coincidentally working.
> > > > > > > > > Ideally,
> > > > > > > > > we'd have the clock system intentionally enable/disable the
> > > > > > > > > clocks
> > > > > > > > > when drivers are loaded/unloaded for for power management
> > > > > > > > > reasons.
> > > > > > > >
> > > > > > > > Can you tell me how exactly the Versaclock outputs are wired?
> > > > > > >
> > > > &g
Re: [PATCH] arm64: smp: remove unused variable
On Mon, Dec 28, 2020 at 12:55 PM Wolfram Sang
wrote:
> Not used anymore after refactoring:
>
> arch/arm64/kernel/smp.c: In function ‘arch_show_interrupts’:
> arch/arm64/kernel/smp.c:810:16: warning: unused variable ‘irq’
> [-Wunused-variable]
> 810 | unsigned int irq = irq_desc_get_irq(ipi_desc[i]);
>
> Fixes: 5089bc51f81f ("arm64/smp: Use irq_desc_kstat_cpu() in
> arch_show_interrupts()")
> Signed-off-by: Wolfram Sang
> Cc: Thomas Gleixner
> Cc: Marc Zyngier
Fix sent 13 days ago:
https://lore.kernel.org/linux-arm-kernel/20201215103026.2872532-1-geert+rene...@glider.be/
Note that the Fixes tag in my patch is different, as apparently the
offending commit was rebased a few hours later.
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
Re: [PATCH 01/18] arm64: dts: renesas: beacon kit: Configure programmable clocks
Hi Adam,
On Thu, Dec 24, 2020 at 2:53 PM Adam Ford wrote:
> On Tue, Dec 22, 2020 at 2:03 AM Geert Uytterhoeven
> wrote:
> > On Tue, Dec 22, 2020 at 2:39 AM Adam Ford wrote:
> > > On Fri, Dec 18, 2020 at 7:16 AM Geert Uytterhoeven
> > > wrote:
> > > > On Thu, Dec 17, 2020 at 12:52 PM Adam Ford wrote:
> > > > > On Thu, Dec 17, 2020 at 2:16 AM Geert Uytterhoeven
> > > > > wrote:
> > > > > > On Wed, Dec 16, 2020 at 6:03 PM Adam Ford
> > > > > > wrote:
> > > > > > > On Wed, Dec 16, 2020 at 8:55 AM Geert Uytterhoeven
> > > > > > > wrote:
> > > > > > > > On Sun, Dec 13, 2020 at 7:38 PM Adam Ford
> > > > > > > > wrote:
> > > > > > > > > When the board was added, clock drivers were being updated
> > > > > > > > > done at
> > > > > > > > > the same time to allow the versaclock driver to properly
> > > > > > > > > configure
> > > > > > > > > the modes. Unforutnately, the updates were not applied to
> > > > > > > > > the board
> > > > > >
> > > > > > > > > ---
> > > > > > > > > a/arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi
> > > > > > > > > +++
> > > > > > > > > b/arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi
> > > > > > > > > @@ -5,6 +5,7 @@
> > > > > > > > >
> > > > > > > > > #include
> > > > > > > > > #include
> > > > > > > > > +#include
> > > > > > > > >
> > > > > > > > > / {
> > > > > > > > > backlight_lvds: backlight-lvds {
> > > > > > > > > @@ -294,12 +295,12 @@ _out_rgb {
> > > > > > > > > {
> > > > > > > > > dr_mode = "otg";
> > > > > > > > > status = "okay";
> > > > > > > > > - clocks = < CPG_MOD 703>, < CPG_MOD 704>;
> > > > > > > > > + clocks = < CPG_MOD 703>, < CPG_MOD 704>,
> > > > > > > > > < 3>;
> > > > > > > >
> > > > > > > > Why this change? You said before you don't need this
> > > > > > > > https://lore.kernel.org/linux-renesas-soc/cahcn7xjwbp16sa-ok-5synnqozat8ofjo2_rtg5vrnvsn2-...@mail.gmail.com/
> > > > > > > >
> > > > > > >
> > > > > > > I had talked with the hardware guys about buy pre-programmed
> > > > > > > versaclock chips which would have been pre-configured and
> > > > > > > pre-enabled.
> > > > > > > I thought it was going to happen, but it didn't, so we need the
> > > > > > > versaclock driver to enable the reference clock for the USB
> > > > > > > controllers, ethernet controller and audio clocks. Previously we
> > > > > > > were
> > > > > > > manually configuring it or it was coincidentally working. Ideally,
> > > > > > > we'd have the clock system intentionally enable/disable the clocks
> > > > > > > when drivers are loaded/unloaded for for power management reasons.
> > > > > >
> > > > > > Can you tell me how exactly the Versaclock outputs are wired?
> > > > >
> > > > > The SoC is expecting a fixed external 50 MHz clock connected to
> > > > > USB_EXTAL. Instead of a fixed clock, we're using the Versaclock.
> > > > > We're also using the Versaclock to drive the AVB TXCRefClk,
> > > > > du_dotclkiun0 and du_dotclkin2 (also also called du_dotclkin3 on
> > > > > RZ/G2N) instead of fixed clocks.
> > > > >
> > > > > > E.g. for USB, the bindings don't say anything about a third clock
> > > > > > input,
> > > > > > so I'd like to know where that clock is fed into USB.
> > > > >
> > > > > The way the driver is crafted, it can take in multiple clocks and it
> > > > > goes through a list to enable them all, so I added the versaclock to
> > > > > the array. Without the versaclock reference, the clock doesn't get
> > > > > turned on and the USB fails to operate.
> > > >
> > > > According to the Hardware User's Manual, USBL_EXTAL is used for USB3.0,
> > > > while you added the clock references to the EHCI nodes.
> > > > Are you sure EHCI is failing without this?
>
> I talked to a colleague about the USB_EXTAL. He pointed me to table
> 60.1 of the RZ/2 Series, 2nd Generate reference manual
> (R01UH0808EJ0100 Rev.1.00), which shows the USB EHCI needing the
> 50MHz. When I clear out the references from ehci0 and echi1, the USB
> stops working, so it does appear that using the versaclock as the 3rd
> clock is needed for operating. The device tree bindings for the
> generic-ehci provide for up to 4 clocks, so it seems like referencing
> clocks = < CPG_MOD 703>, < CPG_MOD 704>, < 3> are
> not a violation of the bindings.
Perhaps you need to use renesas,rcar-usb2-clock-sel?
Documentation/devicetree/bindings/clock/renesas,rcar-usb2-clock-sel.yaml
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
[PATCH] m68k: defconfig: Update defconfigs for v5.11-rc1
- Enable modular build of netfilter nf_tables netdev REJECT support, - Enable modular build of the resource and cmdline API unit tests. Signed-off-by: Geert Uytterhoeven --- To be queued for v5.12. arch/m68k/configs/amiga_defconfig| 3 +++ arch/m68k/configs/apollo_defconfig | 3 +++ arch/m68k/configs/atari_defconfig| 3 +++ arch/m68k/configs/bvme6000_defconfig | 3 +++ arch/m68k/configs/hp300_defconfig| 3 +++ arch/m68k/configs/mac_defconfig | 3 +++ arch/m68k/configs/multi_defconfig| 3 +++ arch/m68k/configs/mvme147_defconfig | 3 +++ arch/m68k/configs/mvme16x_defconfig | 3 +++ arch/m68k/configs/q40_defconfig | 3 +++ arch/m68k/configs/sun3_defconfig | 3 +++ arch/m68k/configs/sun3x_defconfig| 3 +++ 12 files changed, 36 insertions(+) diff --git a/arch/m68k/configs/amiga_defconfig b/arch/m68k/configs/amiga_defconfig index 19b40b6bc4b7f4d9..786656090c502956 100644 --- a/arch/m68k/configs/amiga_defconfig +++ b/arch/m68k/configs/amiga_defconfig @@ -128,6 +128,7 @@ CONFIG_NFT_SYNPROXY=m CONFIG_NFT_DUP_NETDEV=m CONFIG_NFT_FWD_NETDEV=m CONFIG_NFT_FIB_NETDEV=m +CONFIG_NFT_REJECT_NETDEV=m CONFIG_NF_FLOW_TABLE_INET=m CONFIG_NF_FLOW_TABLE=m CONFIG_NETFILTER_XT_SET=m @@ -655,7 +656,9 @@ CONFIG_FIND_BIT_BENCHMARK=m CONFIG_TEST_FIRMWARE=m CONFIG_TEST_SYSCTL=m CONFIG_BITFIELD_KUNIT=m +CONFIG_RESOURCE_KUNIT_TEST=m CONFIG_LINEAR_RANGES_TEST=m +CONFIG_CMDLINE_KUNIT_TEST=m CONFIG_BITS_TEST=m CONFIG_TEST_UDELAY=m CONFIG_TEST_STATIC_KEYS=m diff --git a/arch/m68k/configs/apollo_defconfig b/arch/m68k/configs/apollo_defconfig index 07516abe04898d3d..9bb12be4a38e8a36 100644 --- a/arch/m68k/configs/apollo_defconfig +++ b/arch/m68k/configs/apollo_defconfig @@ -124,6 +124,7 @@ CONFIG_NFT_SYNPROXY=m CONFIG_NFT_DUP_NETDEV=m CONFIG_NFT_FWD_NETDEV=m CONFIG_NFT_FIB_NETDEV=m +CONFIG_NFT_REJECT_NETDEV=m CONFIG_NF_FLOW_TABLE_INET=m CONFIG_NF_FLOW_TABLE=m CONFIG_NETFILTER_XT_SET=m @@ -611,7 +612,9 @@ CONFIG_FIND_BIT_BENCHMARK=m CONFIG_TEST_FIRMWARE=m CONFIG_TEST_SYSCTL=m CONFIG_BITFIELD_KUNIT=m +CONFIG_RESOURCE_KUNIT_TEST=m CONFIG_LINEAR_RANGES_TEST=m +CONFIG_CMDLINE_KUNIT_TEST=m CONFIG_BITS_TEST=m CONFIG_TEST_UDELAY=m CONFIG_TEST_STATIC_KEYS=m diff --git a/arch/m68k/configs/atari_defconfig b/arch/m68k/configs/atari_defconfig index c61e5d015d1d0bcc..47b911cca9a39ad6 100644 --- a/arch/m68k/configs/atari_defconfig +++ b/arch/m68k/configs/atari_defconfig @@ -131,6 +131,7 @@ CONFIG_NFT_SYNPROXY=m CONFIG_NFT_DUP_NETDEV=m CONFIG_NFT_FWD_NETDEV=m CONFIG_NFT_FIB_NETDEV=m +CONFIG_NFT_REJECT_NETDEV=m CONFIG_NF_FLOW_TABLE_INET=m CONFIG_NF_FLOW_TABLE=m CONFIG_NETFILTER_XT_SET=m @@ -644,7 +645,9 @@ CONFIG_FIND_BIT_BENCHMARK=m CONFIG_TEST_FIRMWARE=m CONFIG_TEST_SYSCTL=m CONFIG_BITFIELD_KUNIT=m +CONFIG_RESOURCE_KUNIT_TEST=m CONFIG_LINEAR_RANGES_TEST=m +CONFIG_CMDLINE_KUNIT_TEST=m CONFIG_BITS_TEST=m CONFIG_TEST_UDELAY=m CONFIG_TEST_STATIC_KEYS=m diff --git a/arch/m68k/configs/bvme6000_defconfig b/arch/m68k/configs/bvme6000_defconfig index fc9a94aa7d6b1b70..819cc70b06d8663d 100644 --- a/arch/m68k/configs/bvme6000_defconfig +++ b/arch/m68k/configs/bvme6000_defconfig @@ -121,6 +121,7 @@ CONFIG_NFT_SYNPROXY=m CONFIG_NFT_DUP_NETDEV=m CONFIG_NFT_FWD_NETDEV=m CONFIG_NFT_FIB_NETDEV=m +CONFIG_NFT_REJECT_NETDEV=m CONFIG_NF_FLOW_TABLE_INET=m CONFIG_NF_FLOW_TABLE=m CONFIG_NETFILTER_XT_SET=m @@ -604,7 +605,9 @@ CONFIG_FIND_BIT_BENCHMARK=m CONFIG_TEST_FIRMWARE=m CONFIG_TEST_SYSCTL=m CONFIG_BITFIELD_KUNIT=m +CONFIG_RESOURCE_KUNIT_TEST=m CONFIG_LINEAR_RANGES_TEST=m +CONFIG_CMDLINE_KUNIT_TEST=m CONFIG_BITS_TEST=m CONFIG_TEST_UDELAY=m CONFIG_TEST_STATIC_KEYS=m diff --git a/arch/m68k/configs/hp300_defconfig b/arch/m68k/configs/hp300_defconfig index 260f1206c81030fa..8f8d5968713bfe2d 100644 --- a/arch/m68k/configs/hp300_defconfig +++ b/arch/m68k/configs/hp300_defconfig @@ -123,6 +123,7 @@ CONFIG_NFT_SYNPROXY=m CONFIG_NFT_DUP_NETDEV=m CONFIG_NFT_FWD_NETDEV=m CONFIG_NFT_FIB_NETDEV=m +CONFIG_NFT_REJECT_NETDEV=m CONFIG_NF_FLOW_TABLE_INET=m CONFIG_NF_FLOW_TABLE=m CONFIG_NETFILTER_XT_SET=m @@ -613,7 +614,9 @@ CONFIG_FIND_BIT_BENCHMARK=m CONFIG_TEST_FIRMWARE=m CONFIG_TEST_SYSCTL=m CONFIG_BITFIELD_KUNIT=m +CONFIG_RESOURCE_KUNIT_TEST=m CONFIG_LINEAR_RANGES_TEST=m +CONFIG_CMDLINE_KUNIT_TEST=m CONFIG_BITS_TEST=m CONFIG_TEST_UDELAY=m CONFIG_TEST_STATIC_KEYS=m diff --git a/arch/m68k/configs/mac_defconfig b/arch/m68k/configs/mac_defconfig index f6d50b3fe8c207d4..bf15e6c1c939bb30 100644 --- a/arch/m68k/configs/mac_defconfig +++ b/arch/m68k/configs/mac_defconfig @@ -122,6 +122,7 @@ CONFIG_NFT_SYNPROXY=m CONFIG_NFT_DUP_NETDEV=m CONFIG_NFT_FWD_NETDEV=m CONFIG_NFT_FIB_NETDEV=m +CONFIG_NFT_REJECT_NETDEV=m CONFIG_NF_FLOW_TABLE_INET=m CONFIG_NF_FLOW_TABLE=m CONFIG_NETFILTER_XT_SET=m @@ -636,7 +637,9 @@ CONFIG_FIND_BIT_BENCHMARK=m CONFIG_TEST_FIRMWARE=m CONFIG_TEST_SYSCTL=m CONFIG_BITFIELD_KUNIT=m +CONFIG_RESOURCE_KUNIT_TEST=m CONFIG_LINEAR_RANGES_TEST=m
Re: Build regressions/improvements in v5.11-rc1
On Mon, Dec 28, 2020 at 10:38 AM Geert Uytterhoeven
wrote:
> Below is the list of build error/warning regressions/improvements in
> v5.11-rc1[1] compared to v5.10[2].
>
> Summarized:
> - build errors: +1/-3
> - build warnings: +12/-132
>
> Happy fixing! ;-)
>
> Thanks to the linux-next team for providing the build service.
>
> [1]
> http://kisskb.ellerman.id.au/kisskb/branch/linus/head/5c8fe583cce542aa0b84adc939ce85293de36e5e/
> (all 192 configs)
> [2]
> http://kisskb.ellerman.id.au/kisskb/branch/linus/head/2c85ebc57b3e1817b6ce1a6b703928e113a90442/
> (all 192 configs)
>
>
> *** ERRORS ***
>
> 1 error regressions:
> + /kisskb/src/include/linux/mmzone.h: error: #error Allocator MAX_ORDER
> exceeds SECTION_SIZE: => 1156:2
ia64-defconfig (fix available)
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
Build regressions/improvements in v5.11-rc1
ernel/events/core.c: warning: 'perf_event_ksymbol_output' uses dynamic stack allocation: 8511:1 => - /kisskb/src/kernel/events/core.c: warning: 'perf_event_mmap_output' uses dynamic stack allocation: 8012:1 => - /kisskb/src/kernel/events/core.c: warning: 'perf_event_namespaces_output' uses dynamic stack allocation: 7748:1 => - /kisskb/src/kernel/events/core.c: warning: 'perf_event_read_event' uses dynamic stack allocation: 7268:1 => - /kisskb/src/kernel/events/core.c: warning: 'perf_event_switch_output' uses dynamic stack allocation: 8395:1 => - /kisskb/src/kernel/events/core.c: warning: 'perf_event_task_output' uses dynamic stack allocation: 7555:1 => - /kisskb/src/kernel/events/core.c: warning: 'perf_event_text_poke_output' uses dynamic stack allocation: 8718:1 => - /kisskb/src/kernel/events/core.c: warning: 'perf_log_itrace_start' uses dynamic stack allocation: 8791:1 => - /kisskb/src/kernel/events/core.c: warning: 'perf_log_lost_samples' uses dynamic stack allocation: 8336:1 => - /kisskb/src/kernel/events/core.c: warning: 'perf_log_throttle' uses dynamic stack allocation: 8466:1 => - /kisskb/src/kernel/events/core.c: warning: 'perf_swevent_hrtimer' uses dynamic stack allocation: 10275:1 => - /kisskb/src/kernel/events/core.c: warning: 'perf_tp_event' uses dynamic stack allocation: 9430:1 => - /kisskb/src/kernel/rcu/tasks.h: warning: 'show_rcu_tasks_rude_gp_kthread' defined but not used [-Wunused-function]: 710:13 => - /kisskb/src/kernel/rseq.c: warning: '__rseq_handle_notify_resume' uses dynamic stack allocation: 281:1 => - /kisskb/src/kernel/rseq.c: warning: 'rseq_syscall' uses dynamic stack allocation: 300:1 => - /kisskb/src/kernel/smp.c: warning: 'smp_call_function_single' uses dynamic stack allocation: 517:1 => - /kisskb/src/lib/crypto/chacha20poly1305.c: warning: 'chacha20poly1305_crypt_sg_inplace' uses dynamic stack allocation: 331:1 => - /kisskb/src/lib/test_stackinit.c: warning: 'leaf_big_hole_dynamic_all' uses dynamic stack allocation: 255:15 => - /kisskb/src/lib/test_stackinit.c: warning: 'leaf_big_hole_dynamic_partial.isra.29' uses dynamic stack allocation: 255:15 => - /kisskb/src/lib/test_stackinit.c: warning: 'leaf_big_hole_none.isra.63' uses dynamic stack allocation: 255:15 => - /kisskb/src/lib/test_stackinit.c: warning: 'leaf_big_hole_runtime_all.isra.49' uses dynamic stack allocation: 255:15 => - /kisskb/src/lib/test_stackinit.c: warning: 'leaf_big_hole_runtime_partial.isra.41' uses dynamic stack allocation: 255:15 => - /kisskb/src/lib/test_stackinit.c: warning: 'leaf_big_hole_static_all' uses dynamic stack allocation: 255:15 => - /kisskb/src/lib/test_stackinit.c: warning: 'leaf_big_hole_static_partial.isra.17' uses dynamic stack allocation: 255:15 => - /kisskb/src/lib/test_stackinit.c: warning: 'leaf_big_hole_zero.isra.9' uses dynamic stack allocation: 255:15 => - /kisskb/src/lib/test_stackinit.c: warning: 'test_big_hole_dynamic_all' uses dynamic stack allocation: 255:15 => - /kisskb/src/lib/test_stackinit.c: warning: 'test_big_hole_dynamic_partial' uses dynamic stack allocation: 255:15 => - /kisskb/src/lib/test_stackinit.c: warning: 'test_big_hole_none' uses dynamic stack allocation: 255:15 => - /kisskb/src/lib/test_stackinit.c: warning: 'test_big_hole_runtime_all' uses dynamic stack allocation: 255:15 => - /kisskb/src/lib/test_stackinit.c: warning: 'test_big_hole_runtime_partial' uses dynamic stack allocation: 255:15 => - /kisskb/src/lib/test_stackinit.c: warning: 'test_big_hole_static_all' uses dynamic stack allocation: 255:15 => - /kisskb/src/lib/test_stackinit.c: warning: 'test_big_hole_static_partial' uses dynamic stack allocation: 255:15 => - /kisskb/src/lib/test_stackinit.c: warning: 'test_big_hole_zero' uses dynamic stack allocation: 255:15 => - /kisskb/src/mm/slub.c: warning: '___slab_alloc' uses dynamic stack allocation: 2759:1 => - /kisskb/src/mm/slub.c: warning: '__slab_free' uses dynamic stack allocation: 3073:1 => - /kisskb/src/mm/slub.c: warning: 'deactivate_slab.isra.60' uses dynamic stack allocation: 2295:1 => - /kisskb/src/mm/slub.c: warning: 'get_partial_node.isra.59' uses dynamic stack allocation: 1992:1 => - /kisskb/src/mm/slub.c: warning: 'unfreeze_partials.isra.58' uses dynamic stack allocation: 2363:1 => - /kisskb/src/net/bridge/netfilter/ebtables.c: warning: 'compat_copy_everything_to_user' uses dynamic stack allocation: 1767:1 => - /kisskb/src/net/sched/sch_cake.c: warning: the frame size of 1480 bytes is larger than 1280 bytes [-Wframe-larger-than=]: 2942:1 => - /kisskb/src/samples/seccomp/user-trap.c: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]: 50:2, 83:2 => - warning: 4 bad relocat
[PATCH] openrisc: io: Add missing __iomem annotation to iounmap()
With C=1:
drivers/soc/renesas/rmobile-sysc.c:330:33: sparse: sparse: incorrect type
in argument 1 (different address spaces) @@ expected void *addr @@ got
void [noderef] __iomem *[assigned] base @@
drivers/soc/renesas/rmobile-sysc.c:330:33: sparse: expected void *addr
drivers/soc/renesas/rmobile-sysc.c:330:33: sparse: got void [noderef]
__iomem *[assigned] base
Fix this by adding the missing __iomem annotation to iounmap().
Reported-by: kernel test robot
Signed-off-by: Geert Uytterhoeven
---
arch/openrisc/include/asm/io.h | 2 +-
arch/openrisc/mm/ioremap.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/openrisc/include/asm/io.h b/arch/openrisc/include/asm/io.h
index 7d6b4a77b379d8e2..c298061c70a7ee2e 100644
--- a/arch/openrisc/include/asm/io.h
+++ b/arch/openrisc/include/asm/io.h
@@ -31,7 +31,7 @@
void __iomem *ioremap(phys_addr_t offset, unsigned long size);
#define iounmap iounmap
-extern void iounmap(void *addr);
+extern void iounmap(void __iomem *addr);
#include
diff --git a/arch/openrisc/mm/ioremap.c b/arch/openrisc/mm/ioremap.c
index a978590d802d0c3b..9595be51b100c40e 100644
--- a/arch/openrisc/mm/ioremap.c
+++ b/arch/openrisc/mm/ioremap.c
@@ -78,7 +78,7 @@ void __iomem *__ref ioremap(phys_addr_t addr, unsigned long
size)
}
EXPORT_SYMBOL(ioremap);
-void iounmap(void *addr)
+void iounmap(void __iomem *addr)
{
/* If the page is from the fixmap pool then we just clear out
* the fixmap mapping.
--
2.25.1
Re: [PATCH] m68k: let clk_enable() return immediately if clk is NULL
Hi Defang,
On Mon, Dec 28, 2020 at 3:08 AM Defang Bo wrote:
> Similar to commit<742859adc721>("m68k: let clk_disable() return immediately
> if clk is NULL").
> there should be a check for clk to prevent NULL pointer dereference.
>
> Signed-off-by: Defang Bo
Thanks for your patch!
> --- a/arch/m68k/coldfire/clk.c
> +++ b/arch/m68k/coldfire/clk.c
> @@ -90,6 +90,9 @@ EXPORT_SYMBOL(clk_get);
> int clk_enable(struct clk *clk)
> {
> unsigned long flags;
Please keep the blank line between variable declarations and
statements (no complaint from scripts/checkpatch.pl? See
Documentation/process/submitting-patches.rst
).
> + if (!clk)
> + return -EINVAL;
> +
> spin_lock_irqsave(_lock, flags);
> if ((clk->enabled++ == 0) && clk->clk_ops)
> clk->clk_ops->enable(clk);
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
Re: [PATCH v2] local64.h: make mandatory
CC Arnd On Sun, Dec 27, 2020 at 3:48 AM Randy Dunlap wrote: > > Make mandatory in include/asm-generic/Kbuild > and remove all arch/*/include/asm/local64.h arch-specific files since > they only #include . > > This fixes build errors on arch/c6x/ and arch/nios2/ for > block/blk-iocost.c. > > Build-tested on 21 of 25 arch-es. (tools problems on the others) > > Yes, we could even rename to > and change all #includes to use > instead. > > Signed-off-by: Randy Dunlap > Suggested-by: Christoph Hellwig > Cc: Jens Axboe > Cc: linux-bl...@vger.kernel.org > Cc: Ley Foon Tan > Cc: Mark Salter > Cc: Aurelien Jacquiot > Cc: linux-c6x-...@linux-c6x.org > Cc: Peter Zijlstra > Cc: Masahiro Yamada > Cc: Andrew Morton > --- > Would some $maintainer please plan to apply/merge this. > > v2: instead of making local64.h a generic-y header file and adding it > to the missing arch/ header locations, make it a mandotory-y header file > and remove it from most arch/ header locations. (Christoph) > > arch/alpha/include/asm/local64.h |1 - > arch/arc/include/asm/Kbuild|1 - > arch/arm/include/asm/Kbuild|1 - > arch/arm64/include/asm/Kbuild |1 - > arch/csky/include/asm/Kbuild |1 - > arch/h8300/include/asm/Kbuild |1 - > arch/hexagon/include/asm/Kbuild|1 - > arch/ia64/include/asm/local64.h|1 - > arch/m68k/include/asm/Kbuild |1 - > arch/microblaze/include/asm/Kbuild |1 - > arch/mips/include/asm/Kbuild |1 - > arch/nds32/include/asm/Kbuild |1 - > arch/openrisc/include/asm/Kbuild |1 - > arch/parisc/include/asm/Kbuild |1 - > arch/powerpc/include/asm/Kbuild|1 - > arch/riscv/include/asm/Kbuild |1 - > arch/s390/include/asm/Kbuild |1 - > arch/sh/include/asm/Kbuild |1 - > arch/sparc/include/asm/Kbuild |1 - > arch/x86/include/asm/local64.h |1 - > arch/xtensa/include/asm/Kbuild |1 - > include/asm-generic/Kbuild |1 + > 22 files changed, 1 insertion(+), 21 deletions(-) > > --- linux-next-20201209.orig/include/asm-generic/Kbuild > +++ linux-next-20201209/include/asm-generic/Kbuild > @@ -34,6 +34,7 @@ mandatory-y += kmap_size.h > mandatory-y += kprobes.h > mandatory-y += linkage.h > mandatory-y += local.h > +mandatory-y += local64.h > mandatory-y += mm-arch-hooks.h > mandatory-y += mmiowb.h > mandatory-y += mmu.h > --- linux-next-20201209.orig/arch/arc/include/asm/Kbuild > +++ linux-next-20201209/arch/arc/include/asm/Kbuild > @@ -1,7 +1,6 @@ > # SPDX-License-Identifier: GPL-2.0 > generic-y += extable.h > generic-y += kvm_para.h > -generic-y += local64.h > generic-y += mcs_spinlock.h > generic-y += parport.h > generic-y += user.h > --- linux-next-20201209.orig/arch/arm64/include/asm/Kbuild > +++ linux-next-20201209/arch/arm64/include/asm/Kbuild > @@ -1,6 +1,5 @@ > # SPDX-License-Identifier: GPL-2.0 > generic-y += early_ioremap.h > -generic-y += local64.h > generic-y += mcs_spinlock.h > generic-y += qrwlock.h > generic-y += qspinlock.h > --- linux-next-20201209.orig/arch/arm/include/asm/Kbuild > +++ linux-next-20201209/arch/arm/include/asm/Kbuild > @@ -2,7 +2,6 @@ > generic-y += early_ioremap.h > generic-y += extable.h > generic-y += flat.h > -generic-y += local64.h > generic-y += parport.h > > generated-y += mach-types.h > --- linux-next-20201209.orig/arch/csky/include/asm/Kbuild > +++ linux-next-20201209/arch/csky/include/asm/Kbuild > @@ -2,7 +2,6 @@ > generic-y += asm-offsets.h > generic-y += gpio.h > generic-y += kvm_para.h > -generic-y += local64.h > generic-y += mcs_spinlock.h > generic-y += qrwlock.h > generic-y += qspinlock.h > --- linux-next-20201209.orig/arch/h8300/include/asm/Kbuild > +++ linux-next-20201209/arch/h8300/include/asm/Kbuild > @@ -2,7 +2,6 @@ > generic-y += asm-offsets.h > generic-y += extable.h > generic-y += kvm_para.h > -generic-y += local64.h > generic-y += mcs_spinlock.h > generic-y += parport.h > generic-y += spinlock.h > --- linux-next-20201209.orig/arch/hexagon/include/asm/Kbuild > +++ linux-next-20201209/arch/hexagon/include/asm/Kbuild > @@ -2,5 +2,4 @@ > generic-y += extable.h > generic-y += iomap.h > generic-y += kvm_para.h > -generic-y += local64.h > generic-y += mcs_spinlock.h > --- linux-next-20201209.orig/arch/m68k/include/asm/Kbuild > +++ linux-next-20201209/arch/m68k/include/asm/Kbuild > @@ -2,6 +2,5 @@ > generated-y += syscall_table.h > generic-y += extable.h > generic-y += kvm_para.h > -generic-y += local64.h > generic-y += mcs_spinlock.h > generic-y += spinlock.h > --- linux-next-20201209.orig/arch/microblaze/include/asm/Kbuild > +++ linux-next-20201209/arch/microblaze/include/asm/Kbuild > @@ -2,7 +2,6 @@ > generated-y += syscall_table.h > generic-y += extable.h > generic-y += kvm_para.h > -generic-y += local64.h > generic-y += mcs_spinlock.h > generic-y += parport.h > generic-y += syscalls.h > ---
Re: [PATCH] arch: consolidate pm_power_off callback
Hi Enrico,
On Tue, Dec 22, 2020 at 9:15 PM Enrico Weigelt, metux IT consult
wrote:
> On 22.12.20 19:54, Geert Uytterhoeven wrote:
> > On Tue, Dec 22, 2020 at 7:46 PM Enrico Weigelt, metux IT consult
> > wrote:
> >> Move the pm_power_off callback into one global place and also add an
> >> function for conditionally calling it (when not NULL), in order to remove
> >> code duplication in all individual archs.
> >>
> >> Signed-off-by: Enrico Weigelt, metux IT consult
> >
> > Thanks for your patch!
> >
> >> --- a/arch/alpha/kernel/process.c
> >> +++ b/arch/alpha/kernel/process.c
> >> @@ -43,12 +43,6 @@
> >> #include "proto.h"
> >> #include "pci_impl.h"
> >>
> >> -/*
> >> - * Power off function, if any
> >> - */
> >> -void (*pm_power_off)(void) = machine_power_off;
> >
> > Assignments like these are lost in the conversion.
>
> Yes, but this doesn't seem to be ever called anyways. (in arch/alpha)
> And, BTW, letting it point to machine_power_off() doesn't make much
> sense, since it's the arch's machine_power_off() function, who're
> calling pm_power_off().
>
> Actually, we could remove pm_power_off completely from here, assuming
> nobody would *build* any drivers that register themselves into
> pm_power_off.
>
> If you feel better with it, I could post a patch that just removes
> pm_power_off from arch/alpha.
This is not limited to alpha, there are similar initializations on
m68k, openrisc,
and s390.
If none of these are called, they can be removed, but you should mention
that in the patch description.
Thanks!
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
Re: [PATCH] arch: consolidate pm_power_off callback
Hi Enrico,
On Tue, Dec 22, 2020 at 7:46 PM Enrico Weigelt, metux IT consult
wrote:
> Move the pm_power_off callback into one global place and also add an
> function for conditionally calling it (when not NULL), in order to remove
> code duplication in all individual archs.
>
> Signed-off-by: Enrico Weigelt, metux IT consult
Thanks for your patch!
> --- a/arch/alpha/kernel/process.c
> +++ b/arch/alpha/kernel/process.c
> @@ -43,12 +43,6 @@
> #include "proto.h"
> #include "pci_impl.h"
>
> -/*
> - * Power off function, if any
> - */
> -void (*pm_power_off)(void) = machine_power_off;
Assignments like these are lost in the conversion.
> -EXPORT_SYMBOL(pm_power_off);
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
Re: [PATCH v4 12/12] mfd: bd9571mwv: Add support for BD9574MWF
Hi Shimoda-san,
On Tue, Dec 22, 2020 at 10:23 AM Yoshihiro Shimoda
wrote:
> > From: Geert Uytterhoeven, Sent: Tuesday, December 22, 2020 5:53 PM
> > On Mon, Dec 21, 2020 at 3:56 AM Yoshihiro Shimoda
> > wrote:
>
> > > --- a/drivers/mfd/bd9571mwv.c
> > > +++ b/drivers/mfd/bd9571mwv.c
> >
> > > @@ -200,12 +277,14 @@ static int bd9571mwv_probe(struct i2c_client
> > > *client,
> > >
> > > static const struct of_device_id bd9571mwv_of_match_table[] = {
> > > { .compatible = "rohm,bd9571mwv", },
> > > + { .compatible = "rohm,bd9574mwf", },
> > > { /* sentinel */ }
> > > };
> > > MODULE_DEVICE_TABLE(of, bd9571mwv_of_match_table);
> > >
> > > static const struct i2c_device_id bd9571mwv_id_table[] = {
> > > - { "bd9571mwv", 0 },
> > > + { "bd9571mwv", ROHM_CHIP_TYPE_BD9571 },
> > > + { "bd9574mwf", ROHM_CHIP_TYPE_BD9574 },
> >
> > Why add the chip types? These are unused, and the driver uses
> > autodetection of the chip variant anyway.
>
> I just added the chip types in the future use. As you said,
> these are unused and we should not add a future use in general.
> So, I'll remove this change.
OK.
> Also, I think I should remove the following patch.
>
> [PATCH v4 08/12] gpio: bd9571mwv: Add BD9574MWF support
You mean removing the chip types from bd9571mwv_gpio_id_table[]?
You still need the "bd9574mwf-gpio" entry, don't you?
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
Re: [PATCH 5/5] WIP soc: v3u: allow WDT reset
On Fri, Dec 18, 2020 at 6:37 PM Wolfram Sang
wrote:
> Other Gen3 SoCs do this in the bootloader. Maybe V3U will also later?
> For now, add it so we can properly reboot via remote.
>
> Not to be applied yet, just for demonstration.
Agreed.
> Signed-off-by: Wolfram Sang
Reviewed-by: Geert Uytterhoeven
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
Re: [PATCH 4/5] arm64: dts: renesas: falcon: Enable watchdog timer
On Fri, Dec 18, 2020 at 6:37 PM Wolfram Sang
wrote:
> From: Hoang Vo
>
> Enable the watchdog on the Falcon board.
>
> Signed-off-by: Hoang Vo
> [wsa: rebased to mainline]
> Signed-off-by: Wolfram Sang
Reviewed-by: Geert Uytterhoeven
i.e. will queue in renesas-devel for v5.12.
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
Re: [PATCH 3/5] arm64: dts: renesas: r8a779a0: Add RWDT node
On Fri, Dec 18, 2020 at 6:37 PM Wolfram Sang
wrote:
> From: Hoang Vo
>
> Add a device node for the Watchdog Timer (WDT) controller on the
> R8A779A0 SoC.
>
> Signed-off-by: Hoang Vo
> [wsa: rebased to mainline]
> Signed-off-by: Wolfram Sang
Reviewed-by: Geert Uytterhoeven
i.e. will queue in renesas-devel for v5.12 (with sort order fixed).
> --- a/arch/arm64/boot/dts/renesas/r8a779a0.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a779a0.dtsi
> @@ -85,6 +85,16 @@ rst: reset-controller@e616 {
> reg = <0 0xe616 0 0x4000>;
> };
>
> + rwdt: watchdog@e602 {
> + compatible = "renesas,r8a779a0-wdt",
> +"renesas,rcar-gen3-wdt";
> + reg = <0 0xe602 0 0x0c>;
> + clocks = < CPG_MOD 907>;
> + power-domains = < R8A779A0_PD_ALWAYS_ON>;
> + resets = < 907>;
> + status = "disabled";
No interrupts property? ;-)
As we don't have it described yet for the other R-Car Gen3 SoCs, I
suggest we do that in one batch...
> + };
> +
> sysc: system-controller@e618 {
> compatible = "renesas,r8a779a0-sysc";
> reg = <0 0xe618 0 0x4000>;
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
Re: [PATCH 2/5] clk: renesas: r8a779a0: Add RWDT clocks
On Fri, Dec 18, 2020 at 6:37 PM Wolfram Sang
wrote:
> And introduce critical clocks, too, because RWDT is one.
>
> Signed-off-by: Wolfram Sang
Reviewed-by: Geert Uytterhoeven
i.e. will queue in renesas-clk-for-v5.12.
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
Re: [PATCH 1/5] dt-bindings: watchdog: renesas,wdt: add r8a779a0 (V3U) support
On Fri, Dec 18, 2020 at 6:37 PM Wolfram Sang
wrote:
> Signed-off-by: Wolfram Sang
Reviewed-by: Geert Uytterhoeven
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
Re: [PATCH 2/2] arm64: proper comment formatting in reboot handler
On Sat, Dec 19, 2020 at 3:38 PM Wolfram Sang
wrote:
> This comment was probably copied from arm32 and then shortened. It fits
> to single line now.
>
> Signed-off-by: Wolfram Sang
Reviewed-by: Geert Uytterhoeven
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
Re: [PATCH v4 12/12] mfd: bd9571mwv: Add support for BD9574MWF
Hi Shimoda-san,
On Mon, Dec 21, 2020 at 3:56 AM Yoshihiro Shimoda
wrote:
> From: Khiem Nguyen
>
> The new PMIC BD9574MWF inherits features from BD9571MWV.
> Add the support of new PMIC to existing bd9571mwv driver.
>
> Signed-off-by: Khiem Nguyen
> Co-developed-by: Yoshihiro Shimoda
> Signed-off-by: Yoshihiro Shimoda
Thanks for your patch!
> --- a/drivers/mfd/bd9571mwv.c
> +++ b/drivers/mfd/bd9571mwv.c
> @@ -200,12 +277,14 @@ static int bd9571mwv_probe(struct i2c_client *client,
>
> static const struct of_device_id bd9571mwv_of_match_table[] = {
> { .compatible = "rohm,bd9571mwv", },
> + { .compatible = "rohm,bd9574mwf", },
> { /* sentinel */ }
> };
> MODULE_DEVICE_TABLE(of, bd9571mwv_of_match_table);
>
> static const struct i2c_device_id bd9571mwv_id_table[] = {
> - { "bd9571mwv", 0 },
> + { "bd9571mwv", ROHM_CHIP_TYPE_BD9571 },
> + { "bd9574mwf", ROHM_CHIP_TYPE_BD9574 },
Why add the chip types? These are unused, and the driver uses
autodetection of the chip variant anyway.
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
Re: [PATCH v4 10/12] mfd: bd9571mwv: Use devm_regmap_add_irq_chip()
On Mon, Dec 21, 2020 at 3:57 AM Yoshihiro Shimoda
wrote:
> Use dev_regmap_add_irq_chip() to simplify the code.
>
> Signed-off-by: Yoshihiro Shimoda
> Acked-for-MFD-by: Lee Jones
Reviewed-by: Geert Uytterhoeven
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
Re: [PATCH v4 01/12] mfd: bd9571mwv: Use devm_mfd_add_devices()
On Mon, Dec 21, 2020 at 3:57 AM Yoshihiro Shimoda
wrote:
> To remove mfd devices when unload this driver, should use
> devm_mfd_add_devices() instead.
>
> Fixes: d3ea21272094 ("mfd: Add ROHM BD9571MWV-M MFD PMIC driver")
> Signed-off-by: Yoshihiro Shimoda
> Acked-for-MFD-by: Lee Jones
Reviewed-by: Geert Uytterhoeven
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
Re: [PATCH 01/18] arm64: dts: renesas: beacon kit: Configure programmable clocks
Hi Adam,
On Tue, Dec 22, 2020 at 2:39 AM Adam Ford wrote:
> On Fri, Dec 18, 2020 at 7:16 AM Geert Uytterhoeven
> wrote:
> > On Thu, Dec 17, 2020 at 12:52 PM Adam Ford wrote:
> > > On Thu, Dec 17, 2020 at 2:16 AM Geert Uytterhoeven
> > > wrote:
> > > > On Wed, Dec 16, 2020 at 6:03 PM Adam Ford wrote:
> > > > > On Wed, Dec 16, 2020 at 8:55 AM Geert Uytterhoeven
> > > > > wrote:
> > > > > > On Sun, Dec 13, 2020 at 7:38 PM Adam Ford
> > > > > > wrote:
> > > > > > > When the board was added, clock drivers were being updated done at
> > > > > > > the same time to allow the versaclock driver to properly configure
> > > > > > > the modes. Unforutnately, the updates were not applied to the
> > > > > > > board
> > > >
> > > > > > > --- a/arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi
> > > > > > > +++ b/arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi
> > > > > > > @@ -5,6 +5,7 @@
> > > > > > >
> > > > > > > #include
> > > > > > > #include
> > > > > > > +#include
> > > > > > >
> > > > > > > / {
> > > > > > > backlight_lvds: backlight-lvds {
> > > > > > > @@ -294,12 +295,12 @@ _out_rgb {
> > > > > > > {
> > > > > > > dr_mode = "otg";
> > > > > > > status = "okay";
> > > > > > > - clocks = < CPG_MOD 703>, < CPG_MOD 704>;
> > > > > > > + clocks = < CPG_MOD 703>, < CPG_MOD 704>,
> > > > > > > < 3>;
> > > > > >
> > > > > > Why this change? You said before you don't need this
> > > > > > https://lore.kernel.org/linux-renesas-soc/cahcn7xjwbp16sa-ok-5synnqozat8ofjo2_rtg5vrnvsn2-...@mail.gmail.com/
> > > > > >
> > > > >
> > > > > I had talked with the hardware guys about buy pre-programmed
> > > > > versaclock chips which would have been pre-configured and pre-enabled.
> > > > > I thought it was going to happen, but it didn't, so we need the
> > > > > versaclock driver to enable the reference clock for the USB
> > > > > controllers, ethernet controller and audio clocks. Previously we were
> > > > > manually configuring it or it was coincidentally working. Ideally,
> > > > > we'd have the clock system intentionally enable/disable the clocks
> > > > > when drivers are loaded/unloaded for for power management reasons.
> > > >
> > > > Can you tell me how exactly the Versaclock outputs are wired?
> > >
> > > The SoC is expecting a fixed external 50 MHz clock connected to
> > > USB_EXTAL. Instead of a fixed clock, we're using the Versaclock.
> > > We're also using the Versaclock to drive the AVB TXCRefClk,
> > > du_dotclkiun0 and du_dotclkin2 (also also called du_dotclkin3 on
> > > RZ/G2N) instead of fixed clocks.
> > >
> > > > E.g. for USB, the bindings don't say anything about a third clock input,
> > > > so I'd like to know where that clock is fed into USB.
> > >
> > > The way the driver is crafted, it can take in multiple clocks and it
> > > goes through a list to enable them all, so I added the versaclock to
> > > the array. Without the versaclock reference, the clock doesn't get
> > > turned on and the USB fails to operate.
> >
> > According to the Hardware User's Manual, USBL_EXTAL is used for USB3.0,
> > while you added the clock references to the EHCI nodes.
> > Are you sure EHCI is failing without this?
> >
> > Still, it means we need to extend the bindings/driver for
> > renesas,rcar-gen3-xhci to handle USB_EXTAL.
>
> After investigating this, it looks like the USB_EXTAL is already
> referenced from the device tree and it's referenced by the USB3 Phy.
> The SoC calls it usb_extal_clk. Since the phy driver is calling
> devm_clk_get() it looks like i could just redefine the clocks of
> usb3_phy0 to point to the versaclock instead of usb_extal_clk.
>
> The other option is to use a similar method I proposed for the audio
> reference clock and redefine the usb_extal_clk as a fixed
> fixed-factor-clock.
>
> Do you have a preference as to which direction I go?
I'd go for the classical solution: override the clocks property of the
usb3_phy0 node.
Thanks!
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
Re: linux-next: Fixes tag needs some work in the clk tree
Hi Stephen,
On Sun, Dec 20, 2020 at 10:35 PM Stephen Rothwell wrote:
> On Thu, 10 Dec 2020 08:52:41 +0100 Geert Uytterhoeven
> wrote:
> > > trees can be pulled into linux-next? That would find this earlier.
> >
> > That sounds like a great idea, also for pinctrl.
> > Can you please add the following:
> > git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git
> > renesas-clk
> > git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git
> > renesas-pinctrl
> > ?
>
> Added from today. Called clk-renesas and pinctrl-renesas respectively.
Thank you, the result looks good.
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
Re: [PATCH] m68k: Enable seccomp architecture tracking
Hi Adrian,
On Sun, Dec 20, 2020 at 12:24 PM John Paul Adrian Glaubitz
wrote:
> On 12/20/20 9:51 AM, Geert Uytterhoeven wrote:
> > To enable seccomp constant action bitmaps, we need to have a static
> > mapping to the audit architecture and system call table size.
> >
> > Signed-off-by: Geert Uytterhoeven
> > ---
> > Needed for CONFIG_SECCOMP_CACHE_DEBUG.
> > Note that upstream doesn't have m68k seccomp support yet.
>
> Have we added SECCOMP support for m68k to the kernel yet?
No, but I have applied locally the patches floating on the list...
> It's actually something I was hoping to do over the holidays ;-).
Happy to hear that!
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
[PATCH] m68k: Enable seccomp architecture tracking
To enable seccomp constant action bitmaps, we need to have a static mapping to the audit architecture and system call table size. Signed-off-by: Geert Uytterhoeven --- Needed for CONFIG_SECCOMP_CACHE_DEBUG. Note that upstream doesn't have m68k seccomp support yet. arch/m68k/include/asm/Kbuild| 1 - arch/m68k/include/asm/seccomp.h | 11 +++ 2 files changed, 11 insertions(+), 1 deletion(-) create mode 100644 arch/m68k/include/asm/seccomp.h diff --git a/arch/m68k/include/asm/Kbuild b/arch/m68k/include/asm/Kbuild index d9f0f283707ff352..1bff55aa2d54e2ce 100644 --- a/arch/m68k/include/asm/Kbuild +++ b/arch/m68k/include/asm/Kbuild @@ -4,5 +4,4 @@ generic-y += extable.h generic-y += kvm_para.h generic-y += local64.h generic-y += mcs_spinlock.h -generic-y += seccomp.h generic-y += spinlock.h diff --git a/arch/m68k/include/asm/seccomp.h b/arch/m68k/include/asm/seccomp.h new file mode 100644 index ..feefe511dd1f370d --- /dev/null +++ b/arch/m68k/include/asm/seccomp.h @@ -0,0 +1,11 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +#ifndef _ASM_M68K_SECCOMP_H +#define _ASM_M68K_SECCOMP_H + +#include + +#define SECCOMP_ARCH_NATIVEAUDIT_ARCH_M68K +#define SECCOMP_ARCH_NATIVE_NR NR_syscalls +#define SECCOMP_ARCH_NATIVE_NAME "m68k" + +#endif /* _ASM_M68K_SECCOMP_H */ -- 2.25.1
Re: [PATCH] clk: vc5: Use "idt,voltage-microvolt" instead of "idt,voltage-microvolts"
Hi Luca,
On Fri, Dec 18, 2020 at 11:18 PM Luca Ceresoli wrote:
> On 18/12/20 13:52, Geert Uytterhoeven wrote:
> > Commit 45c940184b501fc6 ("dt-bindings: clk: versaclock5: convert to
> > yaml") accidentally changed "idt,voltage-microvolts" to
> > "idt,voltage-microvolt" in the DT bindings, while the driver still used
> > the former.
> >
> > Update the driver to match the bindings, as
> > Documentation/devicetree/bindings/property-units.txt actually recommends
> > using "microvolt".
> >
> > Fixes: 260249f929e81d3d ("clk: vc5: Enable addition output configurations
> > of the Versaclock")
> > Signed-off-by: Geert Uytterhoeven
> > ---
> > There are no upstream users yet, but they are planned for v5.12, so I
> > think this should be in v5.11-rc1.
> >
> > Thanks!
> > ---
> > drivers/clk/clk-versaclock5.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/clk/clk-versaclock5.c b/drivers/clk/clk-versaclock5.c
> > index c90460e7ef2153fe..43db67337bc06824 100644
> > --- a/drivers/clk/clk-versaclock5.c
> > +++ b/drivers/clk/clk-versaclock5.c
> > @@ -739,8 +739,8 @@ static int vc5_update_power(struct device_node
> > *np_output,
> > {
> > u32 value;
> >
> > - if (!of_property_read_u32(np_output,
> > - "idt,voltage-microvolts", )) {
> > + if (!of_property_read_u32(np_output, "idt,voltage-microvolt",
> > + )) {
>
> Reviewed-by: Luca Ceresoli
Thanks!
> Now the example in the bindings needs the same fix. I guess you doing it
> in your "Miscellaneous fixes and improvements" v2 series, otherwise I
> can do that.
Yep, planned for v2.
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
Re: [PATCH 01/18] arm64: dts: renesas: beacon kit: Configure programmable clocks
Hi Adam,
CC Shimoda-san
On Thu, Dec 17, 2020 at 12:52 PM Adam Ford wrote:
> On Thu, Dec 17, 2020 at 2:16 AM Geert Uytterhoeven
> wrote:
> > On Wed, Dec 16, 2020 at 6:03 PM Adam Ford wrote:
> > > On Wed, Dec 16, 2020 at 8:55 AM Geert Uytterhoeven
> > > wrote:
> > > > On Sun, Dec 13, 2020 at 7:38 PM Adam Ford wrote:
> > > > > When the board was added, clock drivers were being updated done at
> > > > > the same time to allow the versaclock driver to properly configure
> > > > > the modes. Unforutnately, the updates were not applied to the board
> >
> > > > > --- a/arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi
> > > > > +++ b/arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi
> > > > > @@ -5,6 +5,7 @@
> > > > >
> > > > > #include
> > > > > #include
> > > > > +#include
> > > > >
> > > > > / {
> > > > > backlight_lvds: backlight-lvds {
> > > > > @@ -294,12 +295,12 @@ _out_rgb {
> > > > > {
> > > > > dr_mode = "otg";
> > > > > status = "okay";
> > > > > - clocks = < CPG_MOD 703>, < CPG_MOD 704>;
> > > > > + clocks = < CPG_MOD 703>, < CPG_MOD 704>,
> > > > > < 3>;
> > > >
> > > > Why this change? You said before you don't need this
> > > > https://lore.kernel.org/linux-renesas-soc/cahcn7xjwbp16sa-ok-5synnqozat8ofjo2_rtg5vrnvsn2-...@mail.gmail.com/
> > > >
> > >
> > > I had talked with the hardware guys about buy pre-programmed
> > > versaclock chips which would have been pre-configured and pre-enabled.
> > > I thought it was going to happen, but it didn't, so we need the
> > > versaclock driver to enable the reference clock for the USB
> > > controllers, ethernet controller and audio clocks. Previously we were
> > > manually configuring it or it was coincidentally working. Ideally,
> > > we'd have the clock system intentionally enable/disable the clocks
> > > when drivers are loaded/unloaded for for power management reasons.
> >
> > Can you tell me how exactly the Versaclock outputs are wired?
>
> The SoC is expecting a fixed external 50 MHz clock connected to
> USB_EXTAL. Instead of a fixed clock, we're using the Versaclock.
> We're also using the Versaclock to drive the AVB TXCRefClk,
> du_dotclkiun0 and du_dotclkin2 (also also called du_dotclkin3 on
> RZ/G2N) instead of fixed clocks.
>
> > E.g. for USB, the bindings don't say anything about a third clock input,
> > so I'd like to know where that clock is fed into USB.
>
> The way the driver is crafted, it can take in multiple clocks and it
> goes through a list to enable them all, so I added the versaclock to
> the array. Without the versaclock reference, the clock doesn't get
> turned on and the USB fails to operate.
According to the Hardware User's Manual, USBL_EXTAL is used for USB3.0,
while you added the clock references to the EHCI nodes.
Are you sure EHCI is failing without this?
Still, it means we need to extend the bindings/driver for
renesas,rcar-gen3-xhci to handle USB_EXTAL.
> The DU clocks are also expecting an array, so I added the versaclock
> to that array as well.
For DU, the clock inputs are clearly defined in the bindings.
> It's similar to the rationale that I'm trying to add the option clock
> for the AVB TXC_Ref clock on the other path. We're using the
> versaclock there as well. The difference is that in the case of the
> AVB_TXCRefClk, the driver isn't expecting an array of clocks, it's
> only expecting a single clock. In order to enable the additional
> clock, I started the patch to accept the optional clock for the
> TXCRefClk in order to get the clock system to enable the clock.
Sure.
> Because the Versaclock isn't programmed to automatically start, they
> need the consumers of the clock to request and enable them.
>
> I admit that I'll probably need to update the bindings to add the
> extra clocks as optional, so if you want, I can submit additional
> patches to add these optional clocks to their respective bindings.
Thanks!
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
Re: [PATCH 04/18] arm64: dts: renesas: beacon kit: Fix Audio Clock sources
Hi Adam,
On Thu, Dec 17, 2020 at 1:01 PM Adam Ford wrote:
> On Thu, Dec 17, 2020 at 4:54 AM Geert Uytterhoeven
> wrote:
> > On Sun, Dec 13, 2020 at 7:38 PM Adam Ford wrote:
> > > The SoC was expecting two clock sources with different frequencies.
> > > One to support 44.1KHz and one to support 48KHz. With the newly added
> > > ability to configure the programmably clock, configure both clocks.
> > >
> > > Beacause the SoC is expecting a fixed clock/oscillator, it doesn't
> > > attempt to get and enable the clock for audio_clk_a. The choice to
> > > use a fixed-factor-clock was due to the fact that it will automatically
> > > enable the programmable clock frequency without change any code.
> > >
> > > Signed-off-by: Adam Ford
> >
> > Thanks for your patch!
> >
> > > --- a/arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi
> > > +++ b/arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi
> > > @@ -250,9 +250,12 @@ ss_ep: endpoint {
> > > };
> > >
> > > _clk_a {
> > > - clock-frequency = <24576000>;
> > > - assigned-clocks = <_bb 4>;
> > > - assigned-clock-rates = <24576000>;
> > > + /delete-property/ clock-frequency;
> > > + #clock-cells = <0>;
> > > + compatible = "fixed-factor-clock";
> > > + clock-mult = <1>;
> > > + clock-div = <1>;
> > > + clocks = <_bb 4>;
> > > };
> >
> > Shouldn't you override the clocks property in the rcar_sound node
> > instead, like is done in several other board DTS files (with cs2000)?
> >
>
> I guess there are multiple ways to do this. Because the rcar_sound
> was already expecting a reference to audio_clk_a, it seemed less
> intrusive this way. The way I proposed, we can use the default
> rcar_sound clocking and just change the audio_clk node to enable the
> versaclock output. The versaclock is driving the audio_clk_a
> reference clock, so it seemed appropriate to put it there.
>
> If you want me to change, I will.
Taking a fresh look at this, I start to like it.
What do other people think?
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
Re: [PATCH 02/18] arm64: dts: renesas: beacon kit: Fix choppy Bluetooth Audio
Hi Adam,
On Thu, Dec 17, 2020 at 1:16 PM Adam Ford wrote:
> On Thu, Dec 17, 2020 at 4:41 AM Geert Uytterhoeven
> wrote:
> > On Sun, Dec 13, 2020 at 7:38 PM Adam Ford wrote:
> > > The Bluetooth chip is capable of operating at 4Mbps, but the
> > > max-speed setting was on the UART node instead of the Bluetooth
> > > node, so the chip didn't operate at the correct speed resulting
> > > in choppy audio. Fix this by setting the max-speed in the proper
> > > node.
> > >
> > > Fixes: a1d8a344f1ca ("arm64: dts: renesas: Introduce
> > > r8a774a1-beacon-rzg2m-kit")
> > > Signed-off-by: Adam Ford
> >
> > Reviewed-by: Geert Uytterhoeven
> > i.e. will queue in renesas-devel for v5.12.
>
> Since various other patches in the series need a V2, should this be
> included in the V2 as no-change, or should I skip this and others that
> have been queued? If/when they appear in your branch, I can rebase
> the series against that branch and just submit V2's on what's missing.
>
> I want to do whatever creates less work for you.
I think it's best to postpone v2 until I have queued up the accepted patches
in renesas-devel. Probably that will happen on Monday.
Thanks!
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
Re: [PATCH] ASoC: wm8962: Add optional mclk device tree binding
On Thu, Dec 17, 2020 at 5:27 PM Adam Ford wrote:
> The driver can request an optional clock for mclk.
> Update the txt file to reflect this.
>
> Suggested-by: Geert Uytterhoeven
> Signed-off-by: Adam Ford
Reviewed-by: Geert Uytterhoeven
> --- a/Documentation/devicetree/bindings/sound/wm8962.txt
> +++ b/Documentation/devicetree/bindings/sound/wm8962.txt
> @@ -9,6 +9,9 @@ Required properties:
>- reg : the I2C address of the device.
>
> Optional properties:
> +
This blank line is not needed (but it will probably be removed during a
future txt-to-yaml conversion ;-)
> + - clocks : The clock source of the mclk
> +
>- spk-mono: This is a boolean property. If present, the SPK_MONO bit
> of R51 (Class D Control 2) gets set, indicating that the speaker is
> in mono mode.
> @@ -27,6 +30,7 @@ Example:
> wm8962: codec@1a {
> compatible = "wlf,wm8962";
> reg = <0x1a>;
> + clocks = < IMX6QDL_CLK_CKO>;
>
> gpio-cfg = <
> 0x /* 0:Default */
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
Re: [PATCH 06/18] arm64: dts: renesas: beacon: Configure Audio CODEC clocks
Hi Adam,
On Thu, Dec 17, 2020 at 2:33 PM Adam Ford wrote:
> On Thu, Dec 17, 2020 at 5:12 AM Geert Uytterhoeven
> wrote:
> > CC alsa-devel
> >
> > On Sun, Dec 13, 2020 at 7:38 PM Adam Ford wrote:
> > > With the newly added configurable clock options, the audio CODEC can
> > > configure the mclk automatically. Add the reference to the versaclock.
> > > Since the devices on I2C5 can communicate at 400KHz, let's also increase
> > > that too
> > >
> > > Signed-off-by: Adam Ford
> >
> > Thanks for your patch!
> >
> > > --- a/arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi
> > > +++ b/arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi
> > > @@ -424,13 +424,15 @@ {
> > >
> > > {
> > > status = "okay";
> > > - clock-frequency = <10>;
> > > + clock-frequency = <40>;
> > > pinctrl-0 = <_pins>;
> > > pinctrl-names = "default";
> > >
> > > codec: wm8962@1a {
> > > compatible = "wlf,wm8962";
> > > reg = <0x1a>;
> > > + clocks = <_bb 3>;
> > > + clock-names = "mclk";
> >
> > While the driver does get the (nameless) clock, the DT bindings lack any
> > mention of a clocks property. It would be good to update the bindings.
>
> Agreed. I'll push an update to add the clocks property.
Thanks!
> > Note that arch/arm/boot/dts/imx6-logicpd-baseboard.dtsi and
> > arch/arm64/boot/dts/freescale/imx8mm-beacon-baseboard.dtsi (both by your
> > hand) use "xclk" instead of "mclk"?
>
> On the schematics for the two imx boards, it's labeled as xclk, so it
> was named as such. For this board, the schematic names it mclk. The
> driver doesn't care about the clock-names property, so I'll just
> remove them.
If there's a single clock, not using clock-names is fine.
If you do use clock-names, the names should be clock-centric, not
board-centric.
BTW, looking at the WM8962 datasheet, it's called "MCLK".
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
[PATCH] clk: vc5: Use "idt,voltage-microvolt" instead of "idt,voltage-microvolts"
Commit 45c940184b501fc6 ("dt-bindings: clk: versaclock5: convert to
yaml") accidentally changed "idt,voltage-microvolts" to
"idt,voltage-microvolt" in the DT bindings, while the driver still used
the former.
Update the driver to match the bindings, as
Documentation/devicetree/bindings/property-units.txt actually recommends
using "microvolt".
Fixes: 260249f929e81d3d ("clk: vc5: Enable addition output configurations of
the Versaclock")
Signed-off-by: Geert Uytterhoeven
---
There are no upstream users yet, but they are planned for v5.12, so I
think this should be in v5.11-rc1.
Thanks!
---
drivers/clk/clk-versaclock5.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/clk-versaclock5.c b/drivers/clk/clk-versaclock5.c
index c90460e7ef2153fe..43db67337bc06824 100644
--- a/drivers/clk/clk-versaclock5.c
+++ b/drivers/clk/clk-versaclock5.c
@@ -739,8 +739,8 @@ static int vc5_update_power(struct device_node *np_output,
{
u32 value;
- if (!of_property_read_u32(np_output,
- "idt,voltage-microvolts", )) {
+ if (!of_property_read_u32(np_output, "idt,voltage-microvolt",
+ )) {
clk_out->clk_output_cfg0_mask |= VC5_CLK_OUTPUT_CFG0_PWR_MASK;
switch (value) {
case 180:
--
2.25.1
Re: [PATCH v5 seccomp 5/5] seccomp/cache: Report cache data through /proc/pid/seccomp_cache
Hi YiFei,
On Thu, Dec 17, 2020 at 7:34 PM YiFei Zhu wrote:
> On Thu, Dec 17, 2020 at 6:14 AM Geert Uytterhoeven
> wrote:
> > Should there be a dependency on SECCOMP_ARCH_NATIVE?
> > Should all architectures that implement seccomp have this?
> >
> > E.g. mips does select HAVE_ARCH_SECCOMP_FILTER, but doesn't
> > have SECCOMP_ARCH_NATIVE?
> >
> > (noticed with preliminary out-of-tree seccomp implementation for m68k,
> > which doesn't have SECCOMP_ARCH_NATIVE
>
> You are correct. This specific patch in this series was not applied,
> and this was addressed in a follow up patch series [1]. MIPS does not
> define SECCOMP_ARCH_NATIVE because the bitmap expects syscall numbers
> to start from 0, whereas MIPS does not (defines
> CONFIG_HAVE_SPARSE_SYSCALL_NR). The follow up patch makes it so that
> any arch with HAVE_SPARSE_SYSCALL_NR (currently just MIPS) cannot have
> CONFIG_SECCOMP_CACHE_DEBUG on, by the depend on clause.
>
> I see that you are doing an out of tree seccomp implementation for
> m68k. Assuming unchanged arch/xtensa/include/asm/syscall.h, something
> like this to arch/m68k/include/asm/seccomp.h should make it work:
>
> #define SECCOMP_ARCH_NATIVEAUDIT_ARCH_M68K
> #define SECCOMP_ARCH_NATIVE_NRNR_syscalls
> #define SECCOMP_ARCH_NATIVE_NAME"m68k"
>
> If the file does not exist already, arch/xtensa/include/asm/seccomp.h
> is a good example of how the file should look like, and remember to
> remove `generic-y += seccomp.h` from arch/m68k/include/asm/Kbuild.
>
> [1] https://lore.kernel.org/lkml/cover.1605101222.git.yifei...@illinois.edu/T/
Thank you for your extensive explanation.
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
Re: [PATCH v5 seccomp 5/5] seccomp/cache: Report cache data through /proc/pid/seccomp_cache
Hi Yifei,
On Sun, Oct 11, 2020 at 8:08 PM YiFei Zhu wrote:
> From: YiFei Zhu
>
> Currently the kernel does not provide an infrastructure to translate
> architecture numbers to a human-readable name. Translating syscall
> numbers to syscall names is possible through FTRACE_SYSCALL
> infrastructure but it does not provide support for compat syscalls.
>
> This will create a file for each PID as /proc/pid/seccomp_cache.
> The file will be empty when no seccomp filters are loaded, or be
> in the format of:
>
> where ALLOW means the cache is guaranteed to allow the syscall,
> and filter means the cache will pass the syscall to the BPF filter.
>
> For the docker default profile on x86_64 it looks like:
> x86_64 0 ALLOW
> x86_64 1 ALLOW
> x86_64 2 ALLOW
> x86_64 3 ALLOW
> [...]
> x86_64 132 ALLOW
> x86_64 133 ALLOW
> x86_64 134 FILTER
> x86_64 135 FILTER
> x86_64 136 FILTER
> x86_64 137 ALLOW
> x86_64 138 ALLOW
> x86_64 139 FILTER
> x86_64 140 ALLOW
> x86_64 141 ALLOW
> [...]
>
> This file is guarded by CONFIG_SECCOMP_CACHE_DEBUG with a default
> of N because I think certain users of seccomp might not want the
> application to know which syscalls are definitely usable. For
> the same reason, it is also guarded by CAP_SYS_ADMIN.
>
> Suggested-by: Jann Horn
> Link:
> https://lore.kernel.org/lkml/CAG48ez3Ofqp4crXGksLmZY6=fgrf_twyucg7pbkaetvbbop...@mail.gmail.com/
> Signed-off-by: YiFei Zhu
> @@ -2311,3 +2314,59 @@ static int __init seccomp_sysctl_init(void)
> device_initcall(seccomp_sysctl_init)
>
> #endif /* CONFIG_SYSCTL */
> +
> +#ifdef CONFIG_SECCOMP_CACHE_DEBUG
> +/* Currently CONFIG_SECCOMP_CACHE_DEBUG implies SECCOMP_ARCH_NATIVE */
Should there be a dependency on SECCOMP_ARCH_NATIVE?
Should all architectures that implement seccomp have this?
E.g. mips does select HAVE_ARCH_SECCOMP_FILTER, but doesn't
have SECCOMP_ARCH_NATIVE?
(noticed with preliminary out-of-tree seccomp implementation for m68k,
which doesn't have SECCOMP_ARCH_NATIVE
> +static void proc_pid_seccomp_cache_arch(struct seq_file *m, const char *name,
> + const void *bitmap, size_t
> bitmap_size)
> +{
> + int nr;
> +
> + for (nr = 0; nr < bitmap_size; nr++) {
> + bool cached = test_bit(nr, bitmap);
> + char *status = cached ? "ALLOW" : "FILTER";
> +
> + seq_printf(m, "%s %d %s\n", name, nr, status);
> + }
> +}
> +
> +int proc_pid_seccomp_cache(struct seq_file *m, struct pid_namespace *ns,
> + struct pid *pid, struct task_struct *task)
> +{
> + struct seccomp_filter *f;
> + unsigned long flags;
> +
> + /*
> +* We don't want some sandboxed process to know what their seccomp
> +* filters consist of.
> +*/
> + if (!file_ns_capable(m->file, _user_ns, CAP_SYS_ADMIN))
> + return -EACCES;
> +
> + if (!lock_task_sighand(task, ))
> + return -ESRCH;
> +
> + f = READ_ONCE(task->seccomp.filter);
> + if (!f) {
> + unlock_task_sighand(task, );
> + return 0;
> + }
> +
> + /* prevent filter from being freed while we are printing it */
> + __get_seccomp_filter(f);
> + unlock_task_sighand(task, );
> +
> + proc_pid_seccomp_cache_arch(m, SECCOMP_ARCH_NATIVE_NAME,
> + f->cache.allow_native,
error: ‘struct action_cache’ has no member named ‘allow_native’
struct action_cache is empty if SECCOMP_ARCH_NATIVE is not
defined (so there are checks for it).
> + SECCOMP_ARCH_NATIVE_NR);
> +
> +#ifdef SECCOMP_ARCH_COMPAT
> + proc_pid_seccomp_cache_arch(m, SECCOMP_ARCH_COMPAT_NAME,
> + f->cache.allow_compat,
> + SECCOMP_ARCH_COMPAT_NR);
> +#endif /* SECCOMP_ARCH_COMPAT */
> +
> + __put_seccomp_filter(f);
> + return 0;
> +}
> +#endif /* CONFIG_SECCOMP_CACHE_DEBUG */
> --
> 2.28.0
>
--
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
Re: [PATCH 18/18] arm64: dts: renesas: Introduce r8a774e1-beacon-rzg2h-kit
Hi Adam,
On Sun, Dec 13, 2020 at 7:38 PM Adam Ford wrote:
> Beacon EmebeddedWorks is introducing a new kit based on the
Embedded Works (suggested by Google ;-)
> RZ/G2H SoC from Renesas.
>
> The SOM supports eMMC, WiFi and Bluetooth, along with a Cat-M1
> cellular radio.
>
> The Baseboard has Ethernet, USB, HDMI, stereo audio in and out,
> along with a variety of push buttons and LED's, and support for
> a parallel RGB and an LVDS display. It uses the same baseboard
> and SOM files as the RZ/G2M and RZ/G2N kits.
>
> Signed-off-by: Adam Ford
Thanks for your patch!
> --- /dev/null
> +++ b/arch/arm64/boot/dts/renesas/r8a774e1-beacon-rzg2h-kit.dts
> @@ -0,0 +1,48 @@
> + {
> + status = "okay";
Missing pinctrl properties?
> +
> + clocks = < CPG_MOD 724>,
> + < CPG_MOD 723>,
> + < CPG_MOD 721>,
> + < 1>,
> + <_clk>,
> + < 2>;
> + clock-names = "du.0", "du.1", "du.3",
> + "dclkin.0", "dclkin.1", "dclkin.3";
> +};
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
Re: [PATCH 17/18] arm64: dts: renesas: Introduce r8a774b1-beacon-rzg2n-kit
Hi Adam,
On Sun, Dec 13, 2020 at 7:38 PM Adam Ford wrote:
> Beacon EmebeddedWorks is introducing a new kit based on the
> RZ/G2N SoC from Renesas.
>
> The SOM supports eMMC, WiFi and Bluetooth, along with a Cat-M1
> cellular radio.
>
> The Baseboard has Ethernet, USB, HDMI, stereo audio in and out,
> along with a variety of push buttons and LED's, and support for
> a parallel RGB and an LVDS display. It uses the same baseboard
> and SOM as the RZ/G2M.
>
> Signed-off-by: Adam Ford
Thanks for your patch!
> --- /dev/null
> +++ b/arch/arm64/boot/dts/renesas/r8a774b1-beacon-rzg2n-kit.dts
> @@ -0,0 +1,43 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright 2020, Compass Electronics Group, LLC
> + */
> +
> +/dts-v1/;
> +
> +#include "r8a774b1.dtsi"
> +#include "beacon-renesom-som.dtsi"
> +#include "beacon-renesom-baseboard.dtsi"
> +
> +/ {
> + model = "Beacon Embedded Works RZ/G2N Development Kit";
> + compatible ="beacon,beacon-rzg2n", "renesas,r8a774b1";
> +
> + aliases {
> + serial0 =
> + serial1 =
> + serial2 =
> + serial3 =
> + serial4 =
> + serial5 =
> + serial6 =
> + ethernet0 =
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
No memory nodes? Are you relying on U-Boot to fill them in?
If yes, why do you have them in the other board DTS files?
> +};
> +
> + {
> + status = "okay";
Missing pinctrl properties?
> +
> + clocks = < CPG_MOD 724>,
> + < CPG_MOD 723>,
> + < CPG_MOD 721>,
> + < 1>,
> + <_clk>,
> + < 2>;
> + clock-names = "du.0", "du.1", "du.3",
> + "dclkin.0", "dclkin.1", "dclkin.3";
> +};
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
Re: [PATCH 15/18] arm64: dts: renesas: beacon-rzg2m-kit: Rearange SoC unique functions
Hi Adam,
On Thu, Dec 17, 2020 at 12:41 PM Geert Uytterhoeven
wrote:
> On Sun, Dec 13, 2020 at 7:38 PM Adam Ford wrote:
> > In preparation for adding new dev kits, move anything specific to the
> > RZ/G2M from the SOM-level and baseboard-levels and move them to the
> > kit-level. This allows the SOM and baseboard to be reused with
> > other SoC's.
> >
> > Signed-off-by: Adam Ford
>
> Reviewed-by: Geert Uytterhoeven
> i.e. will queue in renesas-devel for v5.12.
Sorry, spoke too soon. What happened to:
- pinctrl-0 = <_pins>;
- pinctrl-names = "default";
- status = "okay";
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
Re: [PATCH 16/18] dt-bindings: arm: renesas: Add Beacon RZ/G2N and RZ/G2H boards
On Sun, Dec 13, 2020 at 7:38 PM Adam Ford wrote:
> Add beacon,beacon-rzg2n and beacon,beacon-rzg2h to the bindings
> list.
>
> Signed-off-by: Adam Ford
Reviewed-by: Geert Uytterhoeven
i.e. will queue in renesas-devel for v5.12.
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
Re: [PATCH 15/18] arm64: dts: renesas: beacon-rzg2m-kit: Rearange SoC unique functions
On Sun, Dec 13, 2020 at 7:38 PM Adam Ford wrote:
> In preparation for adding new dev kits, move anything specific to the
> RZ/G2M from the SOM-level and baseboard-levels and move them to the
> kit-level. This allows the SOM and baseboard to be reused with
> other SoC's.
>
> Signed-off-by: Adam Ford
Reviewed-by: Geert Uytterhoeven
i.e. will queue in renesas-devel for v5.12.
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
Re: [PATCH 14/18] arm64: dts: renesas: beacon: Correct I2C bus speeds
On Sun, Dec 13, 2020 at 7:38 PM Adam Ford wrote:
> For greater compatibility with upcoming kits that will reuse the baseboard
> and SOM-level files, adjust the I2C speeds to make it the most compatible
> with all devices.
>
> Signed-off-by: Adam Ford
Thanks, all i2c devices on the bus support 400 kHz.
Reviewed-by: Geert Uytterhoeven
i.e. will queue in renesas-devel for v5.12.
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
Re: [PATCH 13/18] arm64: dts: renesas: beacon: Enable SPI
On Sun, Dec 13, 2020 at 7:38 PM Adam Ford wrote:
> The baseboard routes the SPI to a header which can/will be configured at
> either the kit level or using device tree overlays. Because the baseboard
> be supporting more than one kit, enable at the baseboard level rather
> than a bunch of duplicates later.
>
> Signed-off-by: Adam Ford
Thanks, I have to trust you on this one, i.e. will queue in
renesas-devel for v5.12.
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
Re: [PATCH 12/18] arm64: dts: renesas: beacon: Better describe keys
Hi Adam,
On Sun, Dec 13, 2020 at 7:38 PM Adam Ford wrote:
> The keys on the baseboard are laid out in an diamond pattern, up, down,
> left, right and center. Update the descriptions to make it easier to
> read.
>
> Signed-off-by: Adam Ford
Thanks for your patch!
> --- a/arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi
> +++ b/arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi
> @@ -40,38 +40,38 @@ hdmi0_con: endpoint {
> keys {
> compatible = "gpio-keys";
>
> - key-1 {
> + key-1 { /* S19 */
> gpios = < 6 GPIO_ACTIVE_LOW>;
> linux,code = ;
> - label = "Switch-1";
> + label = "Up";
> wakeup-source;
> debounce-interval = <20>;
> };
> - key-2 {
> + key-2 { /*S20 */
> gpios = < 13 GPIO_ACTIVE_LOW>;
> linux,code = ;
> - label = "Switch-2";
> + label = "Left";
> wakeup-source;
> debounce-interval = <20>;
> };
> - key-3 {
> + key-3 { /* S21 */
> gpios = < 17 GPIO_ACTIVE_LOW>;
> linux,code = ;
> - label = "Switch-3";
> + label = "Down";
> wakeup-source;
> debounce-interval = <20>;
> };
> - key-4 {
> + key-4 { /* S22 */
> gpios = < 20 GPIO_ACTIVE_LOW>;
> linux,code = ;
> - label = "Switch-4";
> + label = "Right";
> wakeup-source;
> debounce-interval = <20>;
> };
> - key-5 {
> + key-5 { /* S23 */
> gpios = < 22 GPIO_ACTIVE_LOW>;
> linux,code = ;
> - label = "Switch-4";
> + label = "Center";
> wakeup-source;
> debounce-interval = <20>;
> };
Wouldn't it make sense for the linux,code properties to reflect this, and thus
change them to KEY_{UP,LEFT,DOWN,RIGHT,ENTER} (or SELECT, or OK)?
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
Re: [PATCH 10/18] arm64: dts: renesas: Don't make vccq_sdhi0 always on
On Sun, Dec 13, 2020 at 7:38 PM Adam Ford wrote:
> vccq_sdhi0 is referenced from sdhi0, so there is no need to force
> this regualtor to be always-on. In theory it could help with
regulator
> low power modes in the future.
>
> Signed-off-by: Adam Ford
Reviewed-by: Geert Uytterhoeven
i.e. will queue in renesas-devel for v5.12 (with the typo fixed, and "beacon"
added to the one-line summary).
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
Re: [PATCH 09/18] arm64: dts: renesas: beacon: Fix RGB Display PWM Backlight
On Sun, Dec 13, 2020 at 7:38 PM Adam Ford wrote:
> The backlight didn't really work correctly due to some updates that were
> made in hardware. It should be safe to apply these, because the older
> hardware was never shipped to anyone, so it shouldn't break anything.
> Because the display driver refers to the display as DPI, this also
> renames the backlight to use DPI for consistency.
>
> Signed-off-by: Adam Ford
Thanks, I have to trust you on this one, i.e. will queue in
renesas-devel for v5.12.
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
Re: [PATCH 08/18] arm64: dts: renesas: beacon: Enable SCIF4
Hi Adam,
On Sun, Dec 13, 2020 at 7:38 PM Adam Ford wrote:
> The baseboard supports SCIF4, enable the pins and the node for it.
>
> Signed-off-by: Adam Ford
Thanks for your patch!
> --- a/arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi
> +++ b/arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi
> @@ -578,6 +578,11 @@ pwm2_pins: pwm2 {
> function = "pwm2";
> };
>
> + scif4_pins: scif4 {
> + groups = "scif4_data_c";
> + function = "scif4";
> + };
> +
> sdhi0_pins: sd0 {
> groups = "sdhi0_data4", "sdhi0_ctrl";
> function = "sdhi0";
> @@ -706,6 +711,12 @@ {
> status = "okay";
> };
>
> + {
> + pinctrl-0 = <_pins>;
> + pinctrl-names = "default";
> + status = "okay";
> +};
> +
> {
> pinctrl-0 = <_pins>;
> pinctrl-names = "default";
As mixing SCIF ports with and without aliases may lead to failures,
depending on probe order, you want to add an aliases for scif4 to
arch/arm64/boot/dts/renesas/r8a774a1-beacon-rzg2m-kit.dts.
I see you did that for the rzg2h and rzg2n kits, but rzh2m lacks it.
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
Re: [PATCH 07/18] arm64: dts: renesas: beacon: Fix LVDS PWM Backlight
On Sun, Dec 13, 2020 at 7:38 PM Adam Ford wrote:
> The backlight didn't really work correctly due to some updates that were
> made in hardware. It should be safe to apply these, because the older
> hardware was never shipped to anyone, so it shouldn't break anything.
>
> Signed-off-by: Adam Ford
Thanks, I have to trust you on this one, i.e. will queue in
renesas-devel for v5.12.
> --- a/arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi
> +++ b/arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi
> @@ -575,7 +575,7 @@ pwm0_pins: pwm0 {
>
> pwm2_pins: pwm2 {
> groups = "pwm2_a";
> - function = "pwm2_a";
> + function = "pwm2";
> };
This part is definitely correct.
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
Re: [PATCH 06/18] arm64: dts: renesas: beacon: Configure Audio CODEC clocks
Hi Adam,
CC alsa-devel
On Sun, Dec 13, 2020 at 7:38 PM Adam Ford wrote:
> With the newly added configurable clock options, the audio CODEC can
> configure the mclk automatically. Add the reference to the versaclock.
> Since the devices on I2C5 can communicate at 400KHz, let's also increase
> that too
>
> Signed-off-by: Adam Ford
Thanks for your patch!
> --- a/arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi
> +++ b/arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi
> @@ -424,13 +424,15 @@ {
>
> {
> status = "okay";
> - clock-frequency = <10>;
> + clock-frequency = <40>;
> pinctrl-0 = <_pins>;
> pinctrl-names = "default";
>
> codec: wm8962@1a {
> compatible = "wlf,wm8962";
> reg = <0x1a>;
> + clocks = <_bb 3>;
> + clock-names = "mclk";
While the driver does get the (nameless) clock, the DT bindings lack any
mention of a clocks property. It would be good to update the bindings.
Note that arch/arm/boot/dts/imx6-logicpd-baseboard.dtsi and
arch/arm64/boot/dts/freescale/imx8mm-beacon-baseboard.dtsi (both by your
hand) use "xclk" instead of "mclk"?
> DCVDD-supply = <_audio>;
> DBVDD-supply = <_audio>;
> AVDD-supply = <_audio>;
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
Re: [PATCH 05/18] arm64: dts: renesas: beacon: Fix audio-1.8V pin enable
On Sun, Dec 13, 2020 at 7:38 PM Adam Ford wrote:
> The fact the audio worked at all was a coindicence because the wrong
coincidence.
> gpio enable was used. Use the correct GPIO pin to ensure its operation.
>
> Fixes: a1d8a344f1ca ("arm64: dts: renesas: Introduce
> r8a774a1-beacon-rzg2m-kit")
> Signed-off-by: Adam Ford
Thanks, I have to trust you on this one, i.e. will queue in
renesas-devel for v5.12
(with the above fixed).
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
Re: [PATCH 04/18] arm64: dts: renesas: beacon kit: Fix Audio Clock sources
Hi Adam,
On Sun, Dec 13, 2020 at 7:38 PM Adam Ford wrote:
> The SoC was expecting two clock sources with different frequencies.
> One to support 44.1KHz and one to support 48KHz. With the newly added
> ability to configure the programmably clock, configure both clocks.
>
> Beacause the SoC is expecting a fixed clock/oscillator, it doesn't
> attempt to get and enable the clock for audio_clk_a. The choice to
> use a fixed-factor-clock was due to the fact that it will automatically
> enable the programmable clock frequency without change any code.
>
> Signed-off-by: Adam Ford
Thanks for your patch!
> --- a/arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi
> +++ b/arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi
> @@ -250,9 +250,12 @@ ss_ep: endpoint {
> };
>
> _clk_a {
> - clock-frequency = <24576000>;
> - assigned-clocks = <_bb 4>;
> - assigned-clock-rates = <24576000>;
> + /delete-property/ clock-frequency;
> + #clock-cells = <0>;
> + compatible = "fixed-factor-clock";
> + clock-mult = <1>;
> + clock-div = <1>;
> + clocks = <_bb 4>;
> };
Shouldn't you override the clocks property in the rcar_sound node
instead, like is done in several other board DTS files (with cs2000)?
>
> _clk_b {
> @@ -591,7 +594,7 @@ sound_pins: sound {
> };
>
> sound_clk_pins: sound_clk {
> - groups = "audio_clk_a_a";
> + groups = "audio_clk_a_a", "audio_clk_b_a";
> function = "audio_clk";
> };
Yes, this part was definitely missing.
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
Re: [PATCH 03/18] arm64: dts: renesas: beacon kit: Remove unnecessary nodes
On Sun, Dec 13, 2020 at 7:38 PM Adam Ford wrote:
> VSPI0 and VSPB are already enabled by default. There is no need
> to add extra nodes to enable them. Remove the redundant nodes.
>
> Signed-off-by: Adam Ford
Reviewed-by: Geert Uytterhoeven
i.e. will queue in renesas-devel for v5.12.
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
Re: [PATCH 02/18] arm64: dts: renesas: beacon kit: Fix choppy Bluetooth Audio
On Sun, Dec 13, 2020 at 7:38 PM Adam Ford wrote:
> The Bluetooth chip is capable of operating at 4Mbps, but the
> max-speed setting was on the UART node instead of the Bluetooth
> node, so the chip didn't operate at the correct speed resulting
> in choppy audio. Fix this by setting the max-speed in the proper
> node.
>
> Fixes: a1d8a344f1ca ("arm64: dts: renesas: Introduce
> r8a774a1-beacon-rzg2m-kit")
> Signed-off-by: Adam Ford
Reviewed-by: Geert Uytterhoeven
i.e. will queue in renesas-devel for v5.12.
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
Re: [PATCH 01/18] arm64: dts: renesas: beacon kit: Configure programmable clocks
Hi Adam,
On Wed, Dec 16, 2020 at 6:03 PM Adam Ford wrote:
> On Wed, Dec 16, 2020 at 8:55 AM Geert Uytterhoeven
> wrote:
> > On Sun, Dec 13, 2020 at 7:38 PM Adam Ford wrote:
> > > When the board was added, clock drivers were being updated done at
> > > the same time to allow the versaclock driver to properly configure
> > > the modes. Unforutnately, the updates were not applied to the board
> > > --- a/arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi
> > > +++ b/arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi
> > > @@ -5,6 +5,7 @@
> > >
> > > #include
> > > #include
> > > +#include
> > >
> > > / {
> > > backlight_lvds: backlight-lvds {
> > > @@ -294,12 +295,12 @@ _out_rgb {
> > > {
> > > dr_mode = "otg";
> > > status = "okay";
> > > - clocks = < CPG_MOD 703>, < CPG_MOD 704>;
> > > + clocks = < CPG_MOD 703>, < CPG_MOD 704>, < 3>;
> >
> > Why this change? You said before you don't need this
> > https://lore.kernel.org/linux-renesas-soc/cahcn7xjwbp16sa-ok-5synnqozat8ofjo2_rtg5vrnvsn2-...@mail.gmail.com/
> >
>
> I had talked with the hardware guys about buy pre-programmed
> versaclock chips which would have been pre-configured and pre-enabled.
> I thought it was going to happen, but it didn't, so we need the
> versaclock driver to enable the reference clock for the USB
> controllers, ethernet controller and audio clocks. Previously we were
> manually configuring it or it was coincidentally working. Ideally,
> we'd have the clock system intentionally enable/disable the clocks
> when drivers are loaded/unloaded for for power management reasons.
Can you tell me how exactly the Versaclock outputs are wired?
E.g. for USB, the bindings don't say anything about a third clock input,
so I'd like to know where that clock is fed into USB.
> Thank you for the review. Is that the only patch in the series with
> concerns? I probably won't get to V2 until this weekend.
Sorry, I still have to review the other patches in your series.
Anyway, we have time until the end of January to queue DT patches for
v5.12...
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
Re: [PATCH] hwmon: SENSORS_SBTSI should depend on X86
Hi Kun, Günter,
On Wed, Dec 16, 2020 at 9:17 PM Guenter Roeck wrote:
> On Wed, Dec 16, 2020 at 09:27:28AM -0800, Kun Yi wrote:
> > On Wed, Dec 16, 2020 at 8:31 AM Guenter Roeck wrote:
> > >
> > > On Wed, Dec 16, 2020 at 02:46:41PM +0100, Geert Uytterhoeven wrote:
> > > > The AMD SB Temperature Sensor Interface (SB-TSI) is only present on AMD
> > > > X86 SoCs. Hence add a dependency on X86, to prevent asking the user
> > > > about this driver when configuring a kernel without AMD X86 platform
> > > > support.
> >
> > Sorry, I think there is some confusion. AMD SoC is a 'remote sensor',
> > or the client, whereas the device using the SB-TSI hwmon driver is the
> > master.
> > In industry, a typical scenario is ARM-based Board Management
> > Controllers (BMCs) using SB-TSI to monitor the host CPU temperature.
Thanks for the explanation!
> Ah, good point. I'll drop this patch.
Agreed.
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
Re: [PATCH 01/18] arm64: dts: renesas: beacon kit: Configure programmable clocks
Hi Adam,
On Sun, Dec 13, 2020 at 7:38 PM Adam Ford wrote:
> When the board was added, clock drivers were being updated done at
> the same time to allow the versaclock driver to properly configure
> the modes. Unforutnately, the updates were not applied to the board
Unfortunately
> files at the time they should have been, so do it now.
>
> Signed-off-by: Adam Ford
Thanks for your patch!
> --- a/arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi
> +++ b/arch/arm64/boot/dts/renesas/beacon-renesom-baseboard.dtsi
> @@ -5,6 +5,7 @@
>
> #include
> #include
> +#include
>
> / {
> backlight_lvds: backlight-lvds {
> @@ -294,12 +295,12 @@ _out_rgb {
> {
> dr_mode = "otg";
> status = "okay";
> - clocks = < CPG_MOD 703>, < CPG_MOD 704>;
> + clocks = < CPG_MOD 703>, < CPG_MOD 704>, < 3>;
Why this change? You said before you don't need this
https://lore.kernel.org/linux-renesas-soc/cahcn7xjwbp16sa-ok-5synnqozat8ofjo2_rtg5vrnvsn2-...@mail.gmail.com/
BTW, something I missed in the earlier review: is there an override
needed at all?
> };
>
> {
> status = "okay";
> - clocks = < CPG_MOD 703>, < CPG_MOD 704>;
> + clocks = < CPG_MOD 703>, < CPG_MOD 704>, < 3>;
Same here.
BTW, something I missed in the earlier review: why did you override
clocks = < CPG_MOD 702>;
by
clocks = < CPG_MOD 703>, < CPG_MOD 704>;
?
> };
>
> {
> @@ -373,12 +374,40 @@ versaclock6_bb: clock-controller@6a {
> #clock-cells = <1>;
> clocks = <_clk>;
> clock-names = "xin";
> - /* CSI0_MCLK, CSI1_MCLK, AUDIO_CLKIN, USB_HUB_MCLK_BB */
> + clock-output-names = "versaclock6_bb.out0_sel_i2cb",
> + "versaclock6_bb.out1",
> + "versaclock6_bb.out2",
> + "versaclock6_bb.out3",
> + "versaclock6_bb.out4";
Why? IIUIC, the driver doesn't parse clock-output-names
(and it shouldn't).
> assigned-clocks = <_bb 1>,
><_bb 2>,
><_bb 3>,
><_bb 4>;
> assigned-clock-rates = <2400>, <2400>, <2400>,
> <24576000>;
> +
> + OUT1 {
> + idt,mode = ;
> + idt,voltage-microvolts = <180>;
Oops. The DT bindings say "idt,voltage-microvolt", the example in the DT
bindings says "idt,voltage-microvolts", and the driver parses
"idt,voltage-microvolts".
According to Documentation/devicetree/bindings/property-units.txt, the
property name should end in "microvolt".
Patch sent.
https://lore.kernel.org/linux-clk/20201216145231.1344317-1-geert+rene...@glider.be/
> + idt,slew-percent = <100>;
> + };
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
Re: [PATCH 1/3] ARM: uncompress: Fix dbgadtb size parameter name
On Wed, Dec 16, 2020 at 2:46 PM Geert Uytterhoeven wrote:
> From: Geert Uytterhoeven
>
> The dbgadtb macro is passed the size of the appended DTB, not the end
> address.
>
> Fixes: c03e41470e901123 ("ARM: 9010/1: uncompress: Print the location of
> appended DTB")
> Signed-off-by: Geert Uytterhoeven
> Reviewed-by: Linus Walleij
Please ignore. I screwed up some scripting. Sorry for the mess.
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
[PATCH 1/3] ARM: uncompress: Fix dbgadtb size parameter name
From: Geert Uytterhoeven
The dbgadtb macro is passed the size of the appended DTB, not the end
address.
Fixes: c03e41470e901123 ("ARM: 9010/1: uncompress: Print the location of
appended DTB")
Signed-off-by: Geert Uytterhoeven
Reviewed-by: Linus Walleij
---
arch/arm/boot/compressed/head.S | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
index 87d6be9340febdc8..835ce64f1674c9a2 100644
--- a/arch/arm/boot/compressed/head.S
+++ b/arch/arm/boot/compressed/head.S
@@ -116,7 +116,7 @@
/*
* Debug print of the final appended DTB location
*/
- .macro dbgadtb, begin, end
+ .macro dbgadtb, begin, size
#ifdef DEBUG
kputc #'D'
kputc #'T'
@@ -129,7 +129,7 @@
kputc #'('
kputc #'0'
kputc #'x'
- kphex \end, 8 /* End of appended DTB */
+ kphex \size, 8/* Size of appended DTB */
kputc #')'
kputc #'\n'
#endif
--
2.25.1
[PATCH] hwmon: SENSORS_SBTSI should depend on X86
The AMD SB Temperature Sensor Interface (SB-TSI) is only present on AMD
X86 SoCs. Hence add a dependency on X86, to prevent asking the user
about this driver when configuring a kernel without AMD X86 platform
support.
Fixes: e7bb1a2ab8c4b156 ("hwmon: (sbtsi) Add basic support for SB-TSI sensors")
Signed-off-by: Geert Uytterhoeven
---
drivers/hwmon/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 1ecf697d8d99b70c..63d28f98108d4bb5 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -1536,6 +1536,7 @@ config SENSORS_SL28CPLD
config SENSORS_SBTSI
tristate "Emulated SB-TSI temperature sensor"
depends on I2C
+ depends on X86 || COMPILE_TEST
help
If you say yes here you get support for emulated temperature
sensors on AMD SoCs with SB-TSI interface connected to a BMC device.
--
2.25.1
[PATCH] platform/surface: SURFACE_PLATFORMS should depend on ACPI
All Microsoft Surface platform-specific device drivers depend on ACPI, but the gatekeeper symbol SURFACE_PLATFORMS does not. Hence when the user is configuring a kernel without ACPI support, he is still asked about Microsoft Surface drivers, even though this question is irrelevant. Fix this by moving the dependency on ACPI from the individual driver symbols to SURFACE_PLATFORMS. Signed-off-by: Geert Uytterhoeven --- drivers/platform/surface/Kconfig | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/platform/surface/Kconfig b/drivers/platform/surface/Kconfig index 33040b0b3b799c2d..2c941cdac9eedc6f 100644 --- a/drivers/platform/surface/Kconfig +++ b/drivers/platform/surface/Kconfig @@ -5,6 +5,7 @@ menuconfig SURFACE_PLATFORMS bool "Microsoft Surface Platform-Specific Device Drivers" + depends on ACPI default y help Say Y here to get to see options for platform-specific device drivers @@ -29,20 +30,19 @@ config SURFACE3_WMI config SURFACE_3_BUTTON tristate "Power/home/volume buttons driver for Microsoft Surface 3 tablet" - depends on ACPI && KEYBOARD_GPIO && I2C + depends on KEYBOARD_GPIO && I2C help This driver handles the power/home/volume buttons on the Microsoft Surface 3 tablet. config SURFACE_3_POWER_OPREGION tristate "Surface 3 battery platform operation region support" - depends on ACPI && I2C + depends on I2C help This driver provides support for ACPI operation region of the Surface 3 battery platform driver. config SURFACE_GPE tristate "Surface GPE/Lid Support Driver" - depends on ACPI depends on DMI help This driver marks the GPEs related to the ACPI lid device found on @@ -52,7 +52,7 @@ config SURFACE_GPE config SURFACE_PRO3_BUTTON tristate "Power/home/volume buttons driver for Microsoft Surface Pro 3/4 tablet" - depends on ACPI && INPUT + depends on INPUT help This driver handles the power/home/volume buttons on the Microsoft Surface Pro 3/4 tablet. -- 2.25.1
[PATCH trivial] dm crypt: Spelling s/cihper/cipher/
Fix a misspelling of "cipher".
Signed-off-by: Geert Uytterhoeven
---
drivers/md/dm-crypt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/md/dm-crypt.c b/drivers/md/dm-crypt.c
index 392337f16ecfd87f..3e6a06c93865e311 100644
--- a/drivers/md/dm-crypt.c
+++ b/drivers/md/dm-crypt.c
@@ -133,7 +133,7 @@ enum flags { DM_CRYPT_SUSPENDED, DM_CRYPT_KEY_VALID,
DM_CRYPT_WRITE_INLINE };
enum cipher_flags {
- CRYPT_MODE_INTEGRITY_AEAD, /* Use authenticated mode for cihper */
+ CRYPT_MODE_INTEGRITY_AEAD, /* Use authenticated mode for cipher */
CRYPT_IV_LARGE_SECTORS, /* Calculate IV from sector_size, not
512B sectors */
CRYPT_ENCRYPT_PREPROCESS, /* Must preprocess data for encryption
(elephant) */
};
--
2.25.1
[PATCH] crypto: CRYPTO_DEV_KEEMBAY_OCS_AES_SM4 should depend on ARCH_KEEMBAY
The Intel Keem Bay Offload and Crypto Subsystem (OCS) is only present on
Intel Keem Bay SoCs. Hence add a dependency on ARCH_KEEMBAY, to prevent
asking the user about this driver when configuring a kernel without
Intel Keem Bay platform support.
While at it, fix a misspelling of "cipher".
Fixes: 88574332451380f4 ("crypto: keembay - Add support for Keem Bay OCS
AES/SM4")
Signed-off-by: Geert Uytterhoeven
---
drivers/crypto/keembay/Kconfig | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/keembay/Kconfig b/drivers/crypto/keembay/Kconfig
index 3c16797b25b9497d..6f62c838a3fa0b2e 100644
--- a/drivers/crypto/keembay/Kconfig
+++ b/drivers/crypto/keembay/Kconfig
@@ -1,12 +1,12 @@
config CRYPTO_DEV_KEEMBAY_OCS_AES_SM4
tristate "Support for Intel Keem Bay OCS AES/SM4 HW acceleration"
- depends on OF || COMPILE_TEST
+ depends on ARCH_KEEMBAY || COMPILE_TEST
select CRYPTO_SKCIPHER
select CRYPTO_AEAD
select CRYPTO_ENGINE
help
Support for Intel Keem Bay Offload and Crypto Subsystem (OCS) AES and
- SM4 cihper hardware acceleration for use with Crypto API.
+ SM4 cipher hardware acceleration for use with Crypto API.
Provides HW acceleration for the following transformations:
cbc(aes), ctr(aes), ccm(aes), gcm(aes), cbc(sm4), ctr(sm4), ccm(sm4)
--
2.25.1
Re: [PATCH] spi: Fix the clamping of spi->max_speed_hz
On Wed, Dec 16, 2020 at 10:23 AM Tudor Ambarus
wrote:
> If spi->controller->max_speed_hz is zero, a non-zero spi->max_speed_hz
> will be overwritten by zero. Make sure spi->controller->max_speed_hz
> is not zero when clamping spi->max_speed_hz.
>
> Put the spi->controller->max_speed_hz non-zero check higher in the if,
> so that we avoid a superfluous init to zero when both spi->max_speed_hz
> and spi->controller->max_speed_hz are zero.
>
> Fixes: 9326e4f1e5dd ("spi: Limit the spi device max speed to controller's max
> speed")
> Reported-by: Geert Uytterhoeven
> Suggested-by: Geert Uytterhoeven
> Signed-off-by: Tudor Ambarus
Tested-by: Geert Uytterhoeven
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
Re: [PATCH tip/core/rcu 3/4] rcutorture: Make grace-period kthread report match RCU flavor being tested
Hi Paul,
On Tue, Dec 15, 2020 at 7:24 PM Paul E. McKenney wrote:
> On Tue, Dec 15, 2020 at 09:40:26AM +0100, Geert Uytterhoeven wrote:
> > On Fri, Nov 6, 2020 at 12:40 AM wrote:
> > > From: "Paul E. McKenney"
> > >
> > > At the end of the test and after rcu_torture_writer() stalls, rcutorture
> > > invokes show_rcu_gp_kthreads() in order to dump out information on the
> > > RCU grace-period kthread. This makes a lot of sense when testing vanilla
> > > RCU, but not so much for the other flavors. This commit therefore allows
> > > per-flavor kthread-dump functions to be specified.
> > >
> > > [ paulmck: Apply feedback from kernel test robot . ]
> > > Signed-off-by: Paul E. McKenney
> >
> > Thanks for your patch, which is now commit 27c0f1448389baf7
> > ("rcutorture: Make grace-period kthread report match RCU flavor being
> > tested").
> >
> > > --- a/kernel/rcu/rcu.h
> > > +++ b/kernel/rcu/rcu.h
> > > @@ -533,4 +533,20 @@ static inline bool rcu_is_nocb_cpu(int cpu) { return
> > > false; }
> > > static inline void rcu_bind_current_to_nocb(void) { }
> > > #endif
> > >
> > > +#if !defined(CONFIG_TINY_RCU) && defined(CONFIG_TASKS_RCU)
> > > +void show_rcu_tasks_classic_gp_kthread(void);
> > > +#else
> > > +static inline void show_rcu_tasks_classic_gp_kthread(void) {}
> > > +#endif
> > > +#if !defined(CONFIG_TINY_RCU) && defined(CONFIG_TASKS_RUDE_RCU)
> > > +void show_rcu_tasks_rude_gp_kthread(void);
> > > +#else
> > > +static inline void show_rcu_tasks_rude_gp_kthread(void) {}
> > > +#endif
> >
> > The #ifdef expression does not match the one for the implementation
> > below.
>
> That does sound like something I would do...
>
> The definition of show_rcu_tasks_rude_gp_kthread() must be provided
> elsewhere if !TINY_RCU && TASKS_RUDE_RCU, correct?
>
> > > --- a/kernel/rcu/rcutorture.c
> > > +++ b/kernel/rcu/rcutorture.c
> >
> > > @@ -762,6 +765,7 @@ static struct rcu_torture_ops tasks_rude_ops = {
> > > .exp_sync = synchronize_rcu_tasks_rude,
> > > .call = call_rcu_tasks_rude,
> > > .cb_barrier = rcu_barrier_tasks_rude,
> > > + .gp_kthread_dbg = show_rcu_tasks_rude_gp_kthread,
> >
> > Perhaps you just want to have a NULL pointer for the dummy case, instead
> > of instantiating a dummy static inline function and taking its address?
>
> You mean something like this in kernel/rcu/rcu.h?
>
> #if !defined(CONFIG_TINY_RCU) && defined(CONFIG_TASKS_RUDE_RCU)
> void show_rcu_tasks_rude_gp_kthread(void);
> #else
> #define show_rcu_tasks_rude_gp_kthread NULL
> #endif
>
> This does looks better to me, and at first glance would work.
Exactly. This is similar to how unimplemented PM callbacks are handled
(git grep "#define\s*pm_.*NULL").
> > > .fqs= NULL,
> > > .stats = NULL,
> > > .irq_capable= 1,
> >
> >
> > > --- a/kernel/rcu/tasks.h
> > > +++ b/kernel/rcu/tasks.h
> >
> > > @@ -696,16 +696,14 @@ static int __init rcu_spawn_tasks_rude_kthread(void)
> > > }
> > > core_initcall(rcu_spawn_tasks_rude_kthread);
> > >
> > > -#ifndef CONFIG_TINY_RCU
> > > -static void show_rcu_tasks_rude_gp_kthread(void)
> > > +#if !defined(CONFIG_TINY_RCU)
> >
> > Different #ifdef expression.
>
> I don't believe that it is. The above supplies the !TINY_RCU, and a
> prior #ifdef supplies the TASKS_RUDE_RCU. So what am I missing here?
Sorry, you're right. I missed the outer #ifdef.
> > > +void show_rcu_tasks_rude_gp_kthread(void)
> >
> > Do you really want to define a non-static function...
>
> Yes, because its user is in kernel/rcu/rcutorture.c, which is in
> a separate translation unit, so it must be non-static. The earlier
> version instead only called it from this file, but that turned out to
> produce confusing output containing information for flavors of RCU that
> were not under test. So this commit exported it to allow rcutorture to
> complain about only that RCU flavor being tested.
>
> > > {
> > > show_rcu_tasks_generic_gp_kthread(_tasks_rude, "");
> > > }
> > > -#endif /* #ifndef CONFIG_TINY_RCU */
> > > -
> > > -#else /* #ifdef CONFIG_TASKS_RUDE_RCU */
> > > -static void show_rcu_tasks_rude_gp_kthread(void) {}
> > > -#endif /* #else #ifdef CONFI
[PATCH] dt-bindings: phy: Rename Intel Keem Bay USB PHY bindings
This is the only file not using the "intel,keembay-*" pattern.
Fortunately the actual compatible value is already following the
standard scheme.
Fixes: 4086afa2a1627939 ("dt-bindings: phy: Add Intel Keem Bay USB PHY
bindings")
Signed-off-by: Geert Uytterhoeven
---
.../{intel,phy-keembay-usb.yaml => intel,keembay-phy-usb.yaml} | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
rename Documentation/devicetree/bindings/phy/{intel,phy-keembay-usb.yaml =>
intel,keembay-phy-usb.yaml} (93%)
diff --git a/Documentation/devicetree/bindings/phy/intel,phy-keembay-usb.yaml
b/Documentation/devicetree/bindings/phy/intel,keembay-phy-usb.yaml
similarity index 93%
rename from Documentation/devicetree/bindings/phy/intel,phy-keembay-usb.yaml
rename to Documentation/devicetree/bindings/phy/intel,keembay-phy-usb.yaml
index a217bb8ac5bc0887..52815b6c2b88d019 100644
--- a/Documentation/devicetree/bindings/phy/intel,phy-keembay-usb.yaml
+++ b/Documentation/devicetree/bindings/phy/intel,keembay-phy-usb.yaml
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
-$id: http://devicetree.org/schemas/phy/intel,phy-keembay-usb.yaml#
+$id: http://devicetree.org/schemas/phy/intel,keembay-phy-usb.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Intel Keem Bay USB PHY bindings
--
2.25.1
Re: [PATCH v2 03/10] regulator: bd9571mwv: rid of using struct bd9571mwv
On Tue, Dec 15, 2020 at 5:02 PM Geert Uytterhoeven wrote:
> On Fri, Dec 11, 2020 at 3:03 PM Vaittinen, Matti
> wrote:
> > On Fri, 2020-12-11 at 20:27 +0900, Yoshihiro Shimoda wrote:
> > > To simplify this driver, use dev_get_regmap() and
> > > rid of using struct bd9571mwv.
> > >
> > > Signed-off-by: Yoshihiro Shimoda
> > > ---
> > > drivers/regulator/bd9571mwv-regulator.c | 49 +
> > >
> > > 1 file changed, 26 insertions(+), 23 deletions(-)
> > >
> > > diff --git a/drivers/regulator/bd9571mwv-regulator.c
> > > b/drivers/regulator/bd9571mwv-regulator.c
> > > index e690c2c..02120b0 100644
> > > --- a/drivers/regulator/bd9571mwv-regulator.c
> > > +++ b/drivers/regulator/bd9571mwv-regulator.c
> > > @@ -17,7 +17,7 @@
> > > #include
> > >
> > > struct bd9571mwv_reg {
> > > - struct bd9571mwv *bd;
> > > + struct regmap *regmap;
> >
> > As a 'nit':
> > I might consider adding the dev pointer here to avoid extra argument
> > with all the bkup_mode functions below. (just pass this struct and
> > mode). But that's only my preference - feel free to ignore this comment
> > if patch is Ok to Mark, Marek & Others :)
>
> Struct regmap already contains a struct device pointer, but that's internal
> to regmap.
>
> Perhaps adding a regmap_device() helper to retrieve the device pointer
> might be worthwhile?
-EEXISTS ;-)
struct device *regmap_get_device(struct regmap *map)
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
Re: [PATCH v2 05/10] gpio: bd9571mwv: Use the SPDX license identifier
On Fri, Dec 11, 2020 at 2:47 PM Yoshihiro Shimoda
wrote:
> Use the SPDX license identifier instead of a local description.
>
> Signed-off-by: Yoshihiro Shimoda
Reviewed-by: Geert Uytterhoeven
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
Re: [PATCH v2 03/10] regulator: bd9571mwv: rid of using struct bd9571mwv
Hi Matti,
On Fri, Dec 11, 2020 at 3:03 PM Vaittinen, Matti
wrote:
> On Fri, 2020-12-11 at 20:27 +0900, Yoshihiro Shimoda wrote:
> > To simplify this driver, use dev_get_regmap() and
> > rid of using struct bd9571mwv.
> >
> > Signed-off-by: Yoshihiro Shimoda
> > ---
> > drivers/regulator/bd9571mwv-regulator.c | 49 +
> >
> > 1 file changed, 26 insertions(+), 23 deletions(-)
> >
> > diff --git a/drivers/regulator/bd9571mwv-regulator.c
> > b/drivers/regulator/bd9571mwv-regulator.c
> > index e690c2c..02120b0 100644
> > --- a/drivers/regulator/bd9571mwv-regulator.c
> > +++ b/drivers/regulator/bd9571mwv-regulator.c
> > @@ -17,7 +17,7 @@
> > #include
> >
> > struct bd9571mwv_reg {
> > - struct bd9571mwv *bd;
> > + struct regmap *regmap;
>
> As a 'nit':
> I might consider adding the dev pointer here to avoid extra argument
> with all the bkup_mode functions below. (just pass this struct and
> mode). But that's only my preference - feel free to ignore this comment
> if patch is Ok to Mark, Marek & Others :)
Struct regmap already contains a struct device pointer, but that's internal
to regmap.
Perhaps adding a regmap_device() helper to retrieve the device pointer
might be worthwhile?
Or a regmap_err() helper to print error messages?
>
> Overall, looks good to me :)
> Reviewed-By: Matti Vaittinen
>
> >
> > /* DDR Backup Power */
> > u8 bkup_mode_cnt_keepon;/* from "rohm,ddr-backup-power" */
> > @@ -137,26 +137,30 @@ static const struct regulator_desc regulators[]
> > = {
> > };
> >
> > #ifdef CONFIG_PM_SLEEP
> > -static int bd9571mwv_bkup_mode_read(struct bd9571mwv *bd, unsigned
> > int *mode)
> > +static int bd9571mwv_bkup_mode_read(struct device * dev,
> > + struct bd9571mwv_reg *bdreg,
> > + unsigned int *mode)
> > {
> > int ret;
> >
> > - ret = regmap_read(bd->regmap, BD9571MWV_BKUP_MODE_CNT, mode);
> > + ret = regmap_read(bdreg->regmap, BD9571MWV_BKUP_MODE_CNT,
> > mode);
> > if (ret) {
> > - dev_err(bd->dev, "failed to read backup mode (%d)\n",
> > ret);
> > + dev_err(dev, "failed to read backup mode (%d)\n", ret);
> > return ret;
> > }
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
Re: [PATCH] spi: Limit the spi device max speed to controller's max speed
Hi Mark, Tudor,
On Fri, Dec 11, 2020 at 8:02 PM Mark Brown wrote:
> On Wed, 9 Dec 2020 19:35:14 +0200, Tudor Ambarus wrote:
> > Make sure the max_speed_hz of spi_device does not override
> > the max_speed_hz of controller.
>
> Applied to
>
>https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next
>
> Thanks!
>
> [1/1] spi: Limit the spi device max speed to controller's max speed
> commit: 9326e4f1e5dd1a4410c429638d3c412b6fc17040
> - if (!spi->max_speed_hz)
> + if (!spi->max_speed_hz ||
> + spi->max_speed_hz > spi->controller->max_speed_hz)
> spi->max_speed_hz = spi->controller->max_speed_hz;
If spi->controller->max_speed_hz is zero, a non-zero spi->max_speed_hz
will be overwritten by zero.
Hence this broke spi-sh-msiof, which has the following check in
sh_msiof_spi_set_clk_regs():
if (!spi_hz || !parent_rate) {
WARN(1, "Invalid clock rate parameters %lu and %u\n",
parent_rate, spi_hz);
return;
}
Without this, the driver would trigger a division-by-zero later...
Arguably all SPI controller drivers should fill in
spi_controller.{min,max}_speed_hz, but as long as that is not the case,
I think this patch should be reverted, or the check should be enhanced
to make sure spi->controller->max_speed_hz is non-zero.
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
Re: [PATCH v5 2/8] dt-bindings: media: max9286: Document 'maxim,initial-reverse-channel-mV'
Hi Jacopo,
On Tue, Dec 15, 2020 at 12:14 PM Jacopo Mondi wrote:
> On Mon, Nov 30, 2020 at 03:00:48PM -0700, Rob Herring wrote:
> > On Mon, Nov 16, 2020 at 02:52:59PM +0100, Jacopo Mondi wrote:
> > > Document the 'initial-reverse-channel-mV' vendor property in the
> > > bindings document of the max9286 driver.
> > >
> > > The newly introduced property allows to specifying the initial
> > > configuration of the GMSL reverse control channel to accommodate
> > > remote serializers pre-programmed with the high threshold power
> > > supply noise immunity enabled.
> > >
> > > Reviewed-by: Kieran Bingham
> > > Signed-off-by: Jacopo Mondi
> > > ---
> > > .../bindings/media/i2c/maxim,max9286.yaml | 23 +++
> > > 1 file changed, 23 insertions(+)
> > >
> > > diff --git
> > > a/Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml
> > > b/Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml
> > > index 9ea827092fdd..f61234d204fa 100644
> > > --- a/Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml
> > > +++ b/Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml
> > > @@ -51,6 +51,26 @@ properties:
> > >'#gpio-cells':
> > > const: 2
> > >
> > > + maxim,initial-reverse-channel-mV:
> >
> > Use standard unit suffix.
> >
>
> Which one ? :)
Documentation/devicetree/bindings/property-units.txt
> I see in v5.10 one 'mV', three 'mv', one 'millivolts', several
> 'microvolts'.
>
> I'll go with the majority and make this
> 'maxim,initial-reverse-channel-mv'
Wrong guess ;-)
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
[PATCH] arm64/smp: Remove unused irq variable in arch_show_interrupts()
arch/arm64/kernel/smp.c: In function ‘arch_show_interrupts’:
arch/arm64/kernel/smp.c:808:16: warning: unused variable ‘irq’
[-Wunused-variable]
808 | unsigned int irq = irq_desc_get_irq(ipi_desc[i]);
|^~~
The removal of the last user forgot to remove the variable.
Fixes: 2f516e34383d0e97 ("arm64/smp: Use irq_desc_kstat_cpu() in
arch_show_interrupts()")
Signed-off-by: Geert Uytterhoeven
---
One more issue in irq-core-2020-12-14.
arch/arm64/kernel/smp.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index 3aef3bc22d3250b5..10b39328268687e3 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -805,7 +805,6 @@ int arch_show_interrupts(struct seq_file *p, int prec)
unsigned int cpu, i;
for (i = 0; i < NR_IPI; i++) {
- unsigned int irq = irq_desc_get_irq(ipi_desc[i]);
seq_printf(p, "%*s%u:%s", prec - 1, "IPI", i,
prec >= 4 ? " " : "");
for_each_online_cpu(cpu)
--
2.25.1
Re: linux-next: manual merge of the drm tree with the crypto tree
On Mon, Dec 14, 2020 at 2:44 PM Stephen Rothwell wrote:
> Today's linux-next merge of the drm tree got a conflict in:
>
> MAINTAINERS
>
> between commit:
>
> 885743324513 ("crypto: keembay - Add support for Keem Bay OCS AES/SM4")
>
> from the crypto tree and commit:
>
> ed794057b052 ("drm/kmb: Build files for KeemBay Display driver")
>
> from the drm tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc MAINTAINERS
> index 3b358262de8f,eb18459c1d16..
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@@ -8985,16 -8962,13 +8993,23 @@@ M: Deepak SaxenaS:Maintained
> F:drivers/char/hw_random/ixp4xx-rng.c
>
> + INTEL KEEMBAY DRM DRIVER
Is it KEEMBAY?
> + M:Anitha Chrisanthus
> + M:Edmund Dea
> + S:Maintained
> + F:Documentation/devicetree/bindings/display/intel,kmb_display.yaml
I was just going to comment about "intel,kmb_*" vs. "intel,keembay-*", until
I noticed intel,kmb_display.yaml does not exist, but is called
Documentation/devicetree/bindings/display/intel,keembay-display.yaml
in next-20201214.
> + F:drivers/gpu/drm/kmb/
> +
> +INTEL KEEM BAY OCS AES/SM4 CRYPTO DRIVER
or KEEM BAY?
Or Keem Bay? Keembay? KeemBay?
All of them are present in next-20201214.
> +M:Daniele Alessandrelli
> +S:Maintained
> +F:Documentation/devicetree/bindings/crypto/intel,keembay-ocs-aes.yaml
> +F:drivers/crypto/keembay/Kconfig
> +F:drivers/crypto/keembay/Makefile
> +F:drivers/crypto/keembay/keembay-ocs-aes-core.c
> +F:drivers/crypto/keembay/ocs-aes.c
> +F:drivers/crypto/keembay/ocs-aes.h
> +
> INTEL MANAGEMENT ENGINE (mei)
> M:Tomas Winkler
> L:linux-kernel@vger.kernel.org
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
Re: [PATCH tip/core/rcu 3/4] rcutorture: Make grace-period kthread report match RCU flavor being tested
Hi Paul,
On Fri, Nov 6, 2020 at 12:40 AM wrote:
>
> From: "Paul E. McKenney"
>
> At the end of the test and after rcu_torture_writer() stalls, rcutorture
> invokes show_rcu_gp_kthreads() in order to dump out information on the
> RCU grace-period kthread. This makes a lot of sense when testing vanilla
> RCU, but not so much for the other flavors. This commit therefore allows
> per-flavor kthread-dump functions to be specified.
>
> [ paulmck: Apply feedback from kernel test robot . ]
> Signed-off-by: Paul E. McKenney
Thanks for your patch, which is now commit 27c0f1448389baf7
("rcutorture: Make grace-period kthread report match RCU flavor being
tested").
> --- a/kernel/rcu/rcu.h
> +++ b/kernel/rcu/rcu.h
> @@ -533,4 +533,20 @@ static inline bool rcu_is_nocb_cpu(int cpu) { return
> false; }
> static inline void rcu_bind_current_to_nocb(void) { }
> #endif
>
> +#if !defined(CONFIG_TINY_RCU) && defined(CONFIG_TASKS_RCU)
> +void show_rcu_tasks_classic_gp_kthread(void);
> +#else
> +static inline void show_rcu_tasks_classic_gp_kthread(void) {}
> +#endif
> +#if !defined(CONFIG_TINY_RCU) && defined(CONFIG_TASKS_RUDE_RCU)
> +void show_rcu_tasks_rude_gp_kthread(void);
> +#else
> +static inline void show_rcu_tasks_rude_gp_kthread(void) {}
> +#endif
The #ifdef expression does not match the one for the implementation
below.
> --- a/kernel/rcu/rcutorture.c
> +++ b/kernel/rcu/rcutorture.c
> @@ -762,6 +765,7 @@ static struct rcu_torture_ops tasks_rude_ops = {
> .exp_sync = synchronize_rcu_tasks_rude,
> .call = call_rcu_tasks_rude,
> .cb_barrier = rcu_barrier_tasks_rude,
> + .gp_kthread_dbg = show_rcu_tasks_rude_gp_kthread,
Perhaps you just want to have a NULL pointer for the dummy case, instead
of instantiating a dummy static inline function and taking its address?
> .fqs= NULL,
> .stats = NULL,
> .irq_capable= 1,
> --- a/kernel/rcu/tasks.h
> +++ b/kernel/rcu/tasks.h
> @@ -696,16 +696,14 @@ static int __init rcu_spawn_tasks_rude_kthread(void)
> }
> core_initcall(rcu_spawn_tasks_rude_kthread);
>
> -#ifndef CONFIG_TINY_RCU
> -static void show_rcu_tasks_rude_gp_kthread(void)
> +#if !defined(CONFIG_TINY_RCU)
Different #ifdef expression.
> +void show_rcu_tasks_rude_gp_kthread(void)
Do you really want to define a non-static function...
> {
> show_rcu_tasks_generic_gp_kthread(_tasks_rude, "");
> }
> -#endif /* #ifndef CONFIG_TINY_RCU */
> -
> -#else /* #ifdef CONFIG_TASKS_RUDE_RCU */
> -static void show_rcu_tasks_rude_gp_kthread(void) {}
> -#endif /* #else #ifdef CONFIG_TASKS_RUDE_RCU */
> +EXPORT_SYMBOL_GPL(show_rcu_tasks_rude_gp_kthread);
... and export its symbol, from a header file?
I know the file is included only once.
> +#endif // !defined(CONFIG_TINY_RCU)
> +#endif /* #ifdef CONFIG_TASKS_RUDE_RCU */
>
>
> //
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
Re: [GIT PULL] ARM: SoC fixes for v5.10, part 3
Hi Ulf, On Mon, Dec 14, 2020 at 9:23 PM Ulf Hansson wrote: > On Tue, 8 Dec 2020 at 08:32, Geert Uytterhoeven wrote: > > On Mon, Dec 7, 2020 at 11:15 PM Doug Anderson wrote: > > > On Mon, Dec 7, 2020 at 1:55 PM Arnd Bergmann wrote: > > > > On Mon, Dec 7, 2020 at 9:23 PM Geert Uytterhoeven > > > > wrote: > > > > > On Tue, Dec 1, 2020 at 3:06 PM Arnd Bergmann wrote: > > > > > > On Tue, Dec 1, 2020 at 12:39 PM Ulf Hansson > > > > > > wrote: > > > > > > > So, I think we have two options. If people are willing to move to > > > > > > > "disk labels" or to patch their DTBs with mmc aliases, things can > > > > > > > stay > > > > > > > as is. Otherwise, we can revert the async probe parts of the mmc > > > > > > > host > > > > > > > drivers, but that would still leave us in a fragile situation. > > > > > > > > > > > > Can you reliably detect whether the mmc aliases in the dt exist? > > > > > > If that's possible, maybe the async flag could be masked out to > > > > > > only have > > > > > > an effect when the device number is known. > > > > > > > > > > IMHO DT aliases are not a proper solution for this. > > > > > > > > > > Yes, you can detect reliably if an alias exists in the DT. > > > > > The problems start when having multiple devices, some with aliases, > > > > > some without. And when devices can appear dynamically (without > > > > > aliases, as there is no support for dynamically updating the aliases > > > > > list). > > > > > > > > Actually you hit a problem earlier than that: the async probe is a > > > > property of the host controller driver, which may be a pci_driver, > > > > platform_driver, usb_driver, or anything else really. To figure out > > > > whether to probe it asynchronously, it would have to be the driver > > > > core, or each bus type that can host these to understand which > > > > device driver is responsible for probing an eMMC device attached > > > > to the host. > > > > > > From what I've seen so far, my current thought on this issue is that > > > it's up to Ulf as the MMC maintainer what the next steps are. For me, > > > at least, his argument that MMC block numbers have already shuffled > > > around several times in the last several years is at least some > > > evidence that they weren't exactly stable to begin with. While we > > > could go back to the numbers that happened to be chosen as of kernel > > > v5.9, if someone was updating from a much older kernel then they may > > > have different expectations of what numbers are good / bad I think. > > > > > > I will also offer one possible suggestion: what about a KConfig option > > > here? In theory we could add a KConfig option like > > > "CONFIG_MMC_LEGACY_PROBE" or something that. One can argue about what > > > the default ought to be, but maybe that would satisfy folks? If you > > > were happy giving up a little bit of boot speed to get the v5.9 block > > > numbers then you could set this. > > > > This is not limited to MMC. > > The same is true for sdX, ethX (e* these days), ttyS*, i2cX, spiX, ... > > The rule has always been to handle it by udev, disklabels, ... > > That's right. > > Although, those rules haven't been sufficient for some cases, which > has been discussed many many times by now. I can dig out some of the > old threads from the mail archive, just tell me and will help to find > them. > > For mmc we have decided to improve the situation by adding support for > aliases in DT. The support seems robust enough to me, but if you think > there are problems with it, please tell me and I am happy to help to > improve it. DT rule #1: DT is hardware description (device naming is software policy). The only generally accepted aliases are "serial0" (the first serial port, as such labeled on the board, to be used for the console; there may be more labeled ports, and thus more "serialX" aliases), and "ethernet0" (the first Ethernet port, so U-Boot knows to which port to add an appropriate "local-mac-address" property, when booting over the network). So yeah, you can claim the first SD card slot is labeled as such, and thus deserves an alias. Then the issue is what you do with the remaining slots, which can be added either statically o
Re: [RFC] ravb: Add support for optional txc_refclk
Hi Adam,
On Sun, Dec 13, 2020 at 5:18 PM Adam Ford wrote:
> The SoC expects the txv_refclk is provided, but if it is provided
> by a programmable clock, there needs to be a way to get and enable
> this clock to operate. It needs to be optional since it's only
> necessary for those with programmable clocks.
>
> Signed-off-by: Adam Ford
Thanks for your patch!
> --- a/drivers/net/ethernet/renesas/ravb.h
> +++ b/drivers/net/ethernet/renesas/ravb.h
> @@ -994,6 +994,7 @@ struct ravb_private {
> struct platform_device *pdev;
> void __iomem *addr;
> struct clk *clk;
> + struct clk *ref_clk;
> struct mdiobb_ctrl mdiobb;
> u32 num_rx_ring[NUM_RX_QUEUE];
> u32 num_tx_ring[NUM_TX_QUEUE];
> diff --git a/drivers/net/ethernet/renesas/ravb_main.c
> b/drivers/net/ethernet/renesas/ravb_main.c
> index bd30505fbc57..4c3f95923ef2 100644
> --- a/drivers/net/ethernet/renesas/ravb_main.c
> +++ b/drivers/net/ethernet/renesas/ravb_main.c
> @@ -2148,6 +2148,18 @@ static int ravb_probe(struct platform_device *pdev)
> goto out_release;
> }
>
> + priv->ref_clk = devm_clk_get(>dev, "txc_refclk");
Please also update the DT bindings[1], to document the optional
presence of the clock.
> + if (IS_ERR(priv->ref_clk)) {
> + if (PTR_ERR(priv->ref_clk) == -EPROBE_DEFER) {
> + /* for Probe defer return error */
> + error = PTR_ERR(priv->ref_clk);
> + goto out_release;
> + }
> + /* Ignore other errors since it's optional */
> + } else {
> + (void)clk_prepare_enable(priv->ref_clk);
This can fail.
Does this clock need to be enabled all the time?
At least it should be disabled in the probe failure path, and in
ravb_remove().
[1] Documentation/devicetree/bindings/net/renesas,etheravb.yaml
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
[GIT PULL] m68k updates for 5.11
Hi Linus,
The following changes since commit 3650b228f83adda7e5ee532e2b90429c03f7b9ec:
Linux 5.10-rc1 (2020-10-25 15:14:11 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k.git
tags/m68k-for-v5.11-tag1
for you to fetch changes up to 2ae92e8b9b7eb042ccb7e9fc7ea9431f211a1bd3:
MAINTAINERS: Update m68k Mac entry (2020-12-07 10:48:16 +0100)
m68k updates for v5.11
- Fix WARNING splat in pmac_zilog driver,
- Fix ADB input device regression,
- Assume maintainership for adb-iop and via-macii,
- Minor fixes and improvements,
- Defconfig updates.
Thanks for pulling!
Arnd Bergmann (1):
m68k: Avoid xchg() warning
Finn Thain (8):
m68k: mac: Refactor iop_preinit() and iop_init()
m68k: mac: Remove dead code
m68k: mac: Remove redundant VIA register writes
m68k: mac: Update Kconfig help
m68k: Fix WARNING splat in pmac_zilog driver
macintosh/adb-iop: Always wait for reply message from IOP
macintosh/adb-iop: Send correct poll command
MAINTAINERS: Update m68k Mac entry
Geert Uytterhoeven (2):
m68k: defconfig: Update defconfigs for v5.10-rc1
m68k: defconfig: Enable KUnit tests
Laurent Vivier (1):
m68k: Remove unused mach_max_dma_address
Youling Tang (2):
m68k: Drop redundant NOTES in link script
m68k: Add a missing ELF_DETAILS in link script
MAINTAINERS | 2 ++
arch/m68k/Kconfig.machine| 8 ++
arch/m68k/amiga/config.c | 8 --
arch/m68k/apollo/config.c| 1 -
arch/m68k/atari/config.c | 1 -
arch/m68k/bvme6000/config.c | 1 -
arch/m68k/configs/amiga_defconfig| 9 --
arch/m68k/configs/apollo_defconfig | 9 --
arch/m68k/configs/atari_defconfig| 9 --
arch/m68k/configs/bvme6000_defconfig | 9 --
arch/m68k/configs/hp300_defconfig| 9 --
arch/m68k/configs/mac_defconfig | 9 --
arch/m68k/configs/multi_defconfig| 9 --
arch/m68k/configs/mvme147_defconfig | 9 --
arch/m68k/configs/mvme16x_defconfig | 9 --
arch/m68k/configs/q40_defconfig | 9 --
arch/m68k/configs/sun3_defconfig | 9 --
arch/m68k/configs/sun3x_defconfig| 9 --
arch/m68k/hp300/config.c | 1 -
arch/m68k/include/asm/cmpxchg.h | 10 +++
arch/m68k/include/asm/machdep.h | 1 -
arch/m68k/kernel/setup_mm.c | 1 -
arch/m68k/kernel/vmlinux-nommu.lds | 3 +-
arch/m68k/kernel/vmlinux-std.lds | 3 +-
arch/m68k/kernel/vmlinux-sun3.lds| 2 +-
arch/m68k/mac/config.c | 26 ++---
arch/m68k/mac/iop.c | 54 --
arch/m68k/mac/via.c | 21 --
arch/m68k/mvme147/config.c | 1 -
arch/m68k/mvme16x/config.c | 1 -
arch/m68k/q40/config.c | 5
arch/m68k/sun3x/config.c | 2 --
drivers/macintosh/adb-iop.c | 56
drivers/tty/serial/pmac_zilog.c | 14 +
34 files changed, 171 insertions(+), 159 deletions(-)
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
Build regressions/improvements in v5.10
ing: "in_be32" redefined:
37 =>
- /kisskb/src/drivers/media/platform/fsl-viu.c: warning: "out_be32"
redefined: 36 =>
- /kisskb/src/drivers/misc/habanalabs/common/habanalabs_ioctl.c: warning:
(near initialization for 'cs_counters.cs_counters') [-Wmissing-braces]: 282:9
=>
- /kisskb/src/drivers/misc/habanalabs/common/habanalabs_ioctl.c: warning:
missing braces around initializer [-Wmissing-braces]: 282:9 =>
- /kisskb/src/drivers/net/ethernet/intel/ice/ice_flow.h: warning: cast from
pointer to integer of different size [-Wpointer-to-int-cast]: 197:33 =>
- /kisskb/src/drivers/net/ethernet/intel/ice/ice_flow.h: warning: cast to
pointer from integer of different size [-Wint-to-pointer-cast]: 198:32 =>
- /kisskb/src/drivers/scsi/ufs/ufshcd-crypto.c: warning: (near initialization
for 'cfg.reg_val') [-Wmissing-braces]: 103:8, 62:8 =>
- /kisskb/src/drivers/scsi/ufs/ufshcd-crypto.c: warning: missing braces
around initializer [-Wmissing-braces]: 103:8, 62:8 =>
- /kisskb/src/drivers/staging/media/tegra-vde/vde.c: warning:
'tegra_vde_runtime_suspend' defined but not used [-Wunused-function]: 916:12 =>
- /kisskb/src/drivers/target/iscsi/cxgbit/cxgbit_target.c: warning:
'cxgbit_tx_datain_iso.isra.39' uses dynamic stack allocation: 482:1 =>
- /kisskb/src/kernel/bpf/cpumap.c: warning:
'cpu_map_bpf_prog_run_xdp.isra.15' uses dynamic stack allocation: 298:1 =>
- /kisskb/src/kernel/events/ring_buffer.c: warning: 'perf_output_begin' uses
dynamic stack allocation: 283:1 =>
- /kisskb/src/kernel/events/ring_buffer.c: warning:
'perf_output_begin_backward' uses dynamic stack allocation: 275:1 =>
- /kisskb/src/kernel/events/ring_buffer.c: warning:
'perf_output_begin_forward' uses dynamic stack allocation: 269:1 =>
- /kisskb/src/lib/lz4/lz4hc_compress.c: warning: the frame size of 2144 bytes
is larger than 2048 bytes [-Wframe-larger-than=]: 579:1 =>
- /kisskb/src/mm/slub.c: warning: 'deactivate_slab.isra.59' uses dynamic
stack allocation: 2293:1 =>
- /kisskb/src/mm/slub.c: warning: 'get_partial_node.isra.58' uses dynamic
stack allocation: 1992:1 =>
- /kisskb/src/mm/slub.c: warning: 'unfreeze_partials.isra.57' uses dynamic
stack allocation: 2361:1 =>
- /kisskb/src/net/bridge/br_device.c: warning: 'br_get_stats64' uses dynamic
stack allocation: 230:1 =>
- /kisskb/src/net/smc/smc_llc.c: warning: (near initialization for
'add_llc.hd') [-Wmissing-braces]: 1212:9 =>
- /kisskb/src/net/smc/smc_llc.c: warning: (near initialization for
'del_llc.hd') [-Wmissing-braces]: 1245:9 =>
- /kisskb/src/net/smc/smc_llc.c: warning: (near initialization for
'delllc.hd') [-Wmissing-braces]: 1317:9 =>
- /kisskb/src/net/smc/smc_llc.c: warning: missing braces around initializer
[-Wmissing-braces]: 1212:9, 1245:9, 1317:9 =>
- warning: 136 bad relocations: N/A =>
- warning: 140 bad relocations: N/A =>
- warning: 148 bad relocations: N/A =>
- warning: You need at least binutils >= 2.19 to build a CONFIG_RELOCATABLE
kernel: N/A =>
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
Re: [PATCH] media: vsp1: Fix an error handling path in the probe function
On Sun, Dec 13, 2020 at 5:22 PM Christophe JAILLET
wrote:
> A previous 'rcar_fcp_get()' call must be undone in the error handling path,
> as already done in the remove function.
>
> Fixes: 94fcdf829793 ("[media] v4l: vsp1: Add FCP support")
> Signed-off-by: Christophe JAILLET
Reviewed-by: Geert Uytterhoeven
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
Re: [PATCH] powerpc/ps3: use dma_mapping_error()
On Sun, Dec 13, 2020 at 8:06 PM Vincent Stehlé
wrote:
> The DMA address returned by dma_map_single() should be checked with
> dma_mapping_error(). Fix the ps3stor_setup() function accordingly.
>
> Fixes: 80071802cb9c ("[POWERPC] PS3: Storage Driver Core")
> Signed-off-by: Vincent Stehlé
Reviewed-by: Geert Uytterhoeven
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
[irqchip: irq/irqchip-next] irqchip/gic: Spelling s/REturn/Return/
The following commit has been merged into the irq/irqchip-next branch of irqchip: Commit-ID: 42a590b0fdf72498ebf47b01ddf006ee92cbfc70 Gitweb: https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms/42a590b0fdf72498ebf47b01ddf006ee92cbfc70 Author:Geert Uytterhoeven AuthorDate:Wed, 09 Dec 2020 11:15:04 +01:00 Committer: Marc Zyngier CommitterDate: Fri, 11 Dec 2020 14:40:17 irqchip/gic: Spelling s/REturn/Return/ Fix a capitalization typo. Signed-off-by: Geert Uytterhoeven Signed-off-by: Marc Zyngier Link: https://lore.kernel.org/r/20201209101504.2206941-1-geert+rene...@glider.be --- drivers/irqchip/irq-gic.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c index 6053245..a3c2f18 100644 --- a/drivers/irqchip/irq-gic.c +++ b/drivers/irqchip/irq-gic.c @@ -973,7 +973,7 @@ void gic_migrate_target(unsigned int new_cpu_id) /* * gic_get_sgir_physaddr - get the physical address for the SGI register * - * REturn the physical address of the SGI register to be used + * Return the physical address of the SGI register to be used * by some early assembly code when the kernel is not yet available. */ static unsigned long gic_dist_physaddr;
[PATCH] serial: 8250_pci: Drop bogus __refdata annotation
Since commit d73dfc6a4199e0e3 ("serial: 8250_pci: remove __devexit
usage") in v3.9, the 8250/16550 PCI serial driver no longer has any code
or data located in initmem, hence there is no need to annotate the
pci_serial_quirks structure with __refdata. Drop the annotation, to
avoid suppressing future section warnings.
Signed-off-by: Geert Uytterhoeven
---
drivers/tty/serial/8250/8250_pci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/serial/8250/8250_pci.c
b/drivers/tty/serial/8250/8250_pci.c
index d5a513efb2613dff..689d8227f95f7dfb 100644
--- a/drivers/tty/serial/8250/8250_pci.c
+++ b/drivers/tty/serial/8250/8250_pci.c
@@ -1964,7 +1964,7 @@ pci_moxa_setup(struct serial_private *priv,
* This list is ordered alphabetically by vendor then device.
* Specific entries must come before more generic entries.
*/
-static struct pci_serial_quirk pci_serial_quirks[] __refdata = {
+static struct pci_serial_quirk pci_serial_quirks[] = {
/*
* ADDI-DATA GmbH communication cards
*/
--
2.25.1
[PATCH] media: sh_vou: Drop bogus __refdata annotation
Since commit 4c62e9764ab403d4 ("Drivers: media: remove __dev*
attributes.") in v3.8, the SuperH Video Output Unit driver no longer has
any code or data located in initmem, hence there is no need to annotate
the sh_vou structure with __refdata. Drop the annotation, to avoid
suppressing future section warnings.
Signed-off-by: Geert Uytterhoeven
---
drivers/media/platform/sh_vou.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/platform/sh_vou.c b/drivers/media/platform/sh_vou.c
index b22dc1d725276f61..4ac48441f22c44a3 100644
--- a/drivers/media/platform/sh_vou.c
+++ b/drivers/media/platform/sh_vou.c
@@ -1355,7 +1355,7 @@ static int sh_vou_remove(struct platform_device *pdev)
return 0;
}
-static struct platform_driver __refdata sh_vou = {
+static struct platform_driver sh_vou = {
.remove = sh_vou_remove,
.driver = {
.name = "sh-vou",
--
2.25.1
[PATCH] mwifiex: pcie: Drop bogus __refdata annotation
As the Marvell PCIE WiFi-Ex driver does not have any code or data
located in initmem, there is no need to annotate the mwifiex_pcie
structure with __refdata. Drop the annotation, to avoid suppressing
future section warnings.
Signed-off-by: Geert Uytterhoeven
---
drivers/net/wireless/marvell/mwifiex/pcie.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c
b/drivers/net/wireless/marvell/mwifiex/pcie.c
index 5f0a61b974ee521a..94228b316df1b210 100644
--- a/drivers/net/wireless/marvell/mwifiex/pcie.c
+++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
@@ -571,7 +571,7 @@ static SIMPLE_DEV_PM_OPS(mwifiex_pcie_pm_ops,
mwifiex_pcie_suspend,
#endif
/* PCI Device Driver */
-static struct pci_driver __refdata mwifiex_pcie = {
+static struct pci_driver mwifiex_pcie = {
.name = "mwifiex_pcie",
.id_table = mwifiex_ids,
.probe= mwifiex_pcie_probe,
--
2.25.1
[PATCH] Input: adc-keys - drop bogus __refdata annotation
As the ADC ladder input driver does not have any code or data located in
initmem, there is no need to annotate the adc_keys_driver structure with
__refdata. Drop the annotation, to avoid suppressing future section
warnings.
Signed-off-by: Geert Uytterhoeven
---
drivers/input/keyboard/adc-keys.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/input/keyboard/adc-keys.c
b/drivers/input/keyboard/adc-keys.c
index 6d5be48d1b3d7988..bf72ab8df817756f 100644
--- a/drivers/input/keyboard/adc-keys.c
+++ b/drivers/input/keyboard/adc-keys.c
@@ -193,7 +193,7 @@ static const struct of_device_id adc_keys_of_match[] = {
MODULE_DEVICE_TABLE(of, adc_keys_of_match);
#endif
-static struct platform_driver __refdata adc_keys_driver = {
+static struct platform_driver adc_keys_driver = {
.driver = {
.name = "adc_keys",
.of_match_table = of_match_ptr(adc_keys_of_match),
--
2.25.1
[PATCH] hwmon: (iio_hwmon) Drop bogus __refdata annotation
As the IIO hardware monitoring driver does not have any code or data
located in initmem, there is no need to annotate the iio_hwmon_driver
structure with __refdata. Drop the annotation, to avoid suppressing
future section warnings.
Signed-off-by: Geert Uytterhoeven
---
drivers/hwmon/iio_hwmon.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hwmon/iio_hwmon.c b/drivers/hwmon/iio_hwmon.c
index b85a125dd86f46a2..580a7d125b88667b 100644
--- a/drivers/hwmon/iio_hwmon.c
+++ b/drivers/hwmon/iio_hwmon.c
@@ -169,7 +169,7 @@ static const struct of_device_id iio_hwmon_of_match[] = {
};
MODULE_DEVICE_TABLE(of, iio_hwmon_of_match);
-static struct platform_driver __refdata iio_hwmon_driver = {
+static struct platform_driver iio_hwmon_driver = {
.driver = {
.name = "iio_hwmon",
.of_match_table = iio_hwmon_of_match,
--
2.25.1
[PATCH] hwmon: (xgene) Drop bogus __refdata annotation
As the X-Gene hardware monitoring driver does not have any code or data
located in initmem, there is no need to annotate the xgene_hwmon_driver
structure with __refdata. Drop the annotation, to avoid suppressing
future section warnings.
Signed-off-by: Geert Uytterhoeven
---
drivers/hwmon/xgene-hwmon.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hwmon/xgene-hwmon.c b/drivers/hwmon/xgene-hwmon.c
index f2a5af239c9569b2..1489e83cb0c44011 100644
--- a/drivers/hwmon/xgene-hwmon.c
+++ b/drivers/hwmon/xgene-hwmon.c
@@ -784,7 +784,7 @@ static const struct of_device_id xgene_hwmon_of_match[] = {
};
MODULE_DEVICE_TABLE(of, xgene_hwmon_of_match);
-static struct platform_driver xgene_hwmon_driver __refdata = {
+static struct platform_driver xgene_hwmon_driver = {
.probe = xgene_hwmon_probe,
.remove = xgene_hwmon_remove,
.driver = {
--
2.25.1
[PATCH] clocksource/drivers/sh_cmt: Make sure channel clock supply is enabled
The Renesas Compare Match Timer 0 and 1 (CMT0/1) variants have a
register to control the clock supply to the individual channels.
Currently the driver does not touch this register, and relies on the
documented initial value, which has the clock supply enabled for all
channels present.
However, when Linux starts on the APE6-EVM development board, only the
clock supply to the first CMT1 channel is enabled. Hence the first
channel (used as a clockevent) works, while the second channel (used as
a clocksource) does not. Note that the default system clocksource is
the Cortex-A15 architectured timer, and the user needs to manually
switch to the CMT1 clocksource to trigger the broken behavior.
Fix this by removing the fragile dependency on implicit reset and/or
boot loader state, and by enabling the clock supply explicitly for all
channels used instead. This requires postponing the clk_disable() call,
else the timer's registers cannot be accessed in sh_cmt_setup_channel().
Signed-off-by: Geert Uytterhoeven
---
Tested on R-Mobile APE6, R-Car M2-W, and R-Car H3 ES2.0.
---
drivers/clocksource/sh_cmt.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/clocksource/sh_cmt.c b/drivers/clocksource/sh_cmt.c
index e258230d432c0002..c98f8851fd680454 100644
--- a/drivers/clocksource/sh_cmt.c
+++ b/drivers/clocksource/sh_cmt.c
@@ -235,6 +235,8 @@ static const struct sh_cmt_info sh_cmt_info[] = {
#define CMCNT 1 /* channel register */
#define CMCOR 2 /* channel register */
+#define CMCLKE 0x1000 /* CLK Enable Register (R-Car Gen2) */
+
static inline u32 sh_cmt_read_cmstr(struct sh_cmt_channel *ch)
{
if (ch->iostart)
@@ -853,6 +855,7 @@ static int sh_cmt_setup_channel(struct sh_cmt_channel *ch,
unsigned int index,
unsigned int hwidx, bool clockevent,
bool clocksource, struct sh_cmt_device *cmt)
{
+ u32 value;
int ret;
/* Skip unused channels. */
@@ -882,6 +885,11 @@ static int sh_cmt_setup_channel(struct sh_cmt_channel *ch,
unsigned int index,
ch->iostart = cmt->mapbase + ch->hwidx * 0x100;
ch->ioctrl = ch->iostart + 0x10;
ch->timer_bit = 0;
+
+ /* Enable the clock supply to the channel */
+ value = ioread32(cmt->mapbase + CMCLKE);
+ value |= BIT(hwidx);
+ iowrite32(value, cmt->mapbase + CMCLKE);
break;
}
@@ -1014,12 +1022,10 @@ static int sh_cmt_setup(struct sh_cmt_device *cmt,
struct platform_device *pdev)
else
cmt->rate = clk_get_rate(cmt->clk) / 8;
- clk_disable(cmt->clk);
-
/* Map the memory resource(s). */
ret = sh_cmt_map_memory(cmt);
if (ret < 0)
- goto err_clk_unprepare;
+ goto err_clk_disable;
/* Allocate and setup the channels. */
cmt->num_channels = hweight8(cmt->hw_channels);
@@ -1047,6 +1053,8 @@ static int sh_cmt_setup(struct sh_cmt_device *cmt, struct
platform_device *pdev)
mask &= ~(1 << hwidx);
}
+ clk_disable(cmt->clk);
+
platform_set_drvdata(pdev, cmt);
return 0;
@@ -1054,6 +1062,8 @@ static int sh_cmt_setup(struct sh_cmt_device *cmt, struct
platform_device *pdev)
err_unmap:
kfree(cmt->channels);
iounmap(cmt->mapbase);
+err_clk_disable:
+ clk_disable(cmt->clk);
err_clk_unprepare:
clk_unprepare(cmt->clk);
err_clk_put:
--
2.25.1
Re: [PATCH v2] pinctrl: remove empty lines in pinctrl subsystem
On Thu, Dec 10, 2020 at 6:35 PM Zhaoyu Liu wrote:
> Remove all empty lines at the end of functions in pinctrl subsystem,
> make the code neat.
> Target files: grep -nwR -B1 ^} drivers/pinctrl/* | grep '[0-9]-$' | less
>
> Reviewed-by: Linus Walleij
> Reviewed-by: Andy Shevchenko
> Signed-off-by: Zhaoyu Liu
Thanks for your patch!
> drivers/pinctrl/renesas/pfc-r8a77950.c| 1 -
> drivers/pinctrl/renesas/pfc-r8a77951.c| 3 ---
> drivers/pinctrl/renesas/pfc-r8a7796.c | 1 -
> drivers/pinctrl/renesas/pfc-r8a77965.c| 1 -
Acked-by: Geert Uytterhoeven
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
[PATCH v11] ARM: uncompress: Validate start of physical memory against passed DTB
Currently, the start address of physical memory is obtained by masking
the program counter with a fixed mask of 0xf800. This mask value
was chosen as a balance between the requirements of different platforms.
However, this does require that the start address of physical memory is
a multiple of 128 MiB, precluding booting Linux on platforms where this
requirement is not fulfilled.
Fix this limitation by validating the masked address against the memory
information in the passed DTB. Only use the start address
from DTB when masking would yield an out-of-range address, prefer the
traditional method in all other cases. Note that this applies only to the
explicitly passed DTB on modern systems, and not to a DTB appended to
the kernel, or to ATAGS. The appended DTB may need to be augmented by
information from ATAGS, which may need to rely on knowledge of the start
address of physical memory itself.
This allows to boot Linux on r7s9210/rza2mevb using the 64 MiB of SDRAM
on the RZA2MEVB sub board, which is located at 0x0C00 (CS3 space),
i.e. not at a multiple of 128 MiB.
Suggested-by: Nicolas Pitre
Suggested-by: Ard Biesheuvel
Signed-off-by: Geert Uytterhoeven
Reviewed-by: Ard Biesheuvel
Acked-by: Nicolas Pitre
---
I plan to submit this to Russell's patch tracker after v5.11-rc1.
v11:
- Add Reviewed-by, Acked-by,
- Document GOT fixup caveat,
v10:
- Update for commit 9443076e4330a14a ("ARM: p2v: reduce p2v alignment
requirement to 2 MiB"),
- Use OF_DT_MAGIC macro,
- Rename fdt_get_mem_start() to fdt_check_mem_start(),
- Skip validation if there is an appended DTB,
- Pass mem_start to fdt_check_mem_start() to streamline code,
- Optimize register allocation,
- Update CONFIG_AUTO_ZRELADDR help text,
- Check all memory nodes and ranges (not just the first one), and
"linux,usable-memory", similar to early_init_dt_scan_memory(),
- Drop Reviewed-by, Tested-by tags,
v9:
- Add minlen parameter to getprop(), for better validation of
memory properties,
- Only use start of memory from the DTB if masking would yield an
out-of-range address, to fix kdump, as suggested by Ard.
v8:
- Rebase on top of commit 893ab00439a45513 ("kbuild: remove cc-option
test of -fno-stack-protector"),
v7:
- Rebase on top of commit 161e04a5bae58a65 ("ARM: decompressor: split
off _edata and stack base into separate object"),
v6:
- Rebase on top of commit 7ae4a78daacf240a ("ARM: 8969/1:
decompressor: simplify libfdt builds"),
- Include instead of ,
v5:
- Add Tested-by, Reviewed-by,
- Round up start of memory to satisfy 16 MiB alignment rule,
v4:
- Fix stack location after commit 184bf653a7a452c1 ("ARM:
decompressor: factor out routine to obtain the inflated image
size"),
v3:
- Add Reviewed-by,
- Fix ATAGs with appended DTB,
- Add Tested-by,
v2:
- Use "cmp r0, #-1", instead of "cmn r0, #1",
- Add missing stack setup,
- Support appended DTB.
---
arch/arm/Kconfig | 7 +-
arch/arm/boot/compressed/Makefile | 5 +-
.../arm/boot/compressed/fdt_check_mem_start.c | 131 ++
arch/arm/boot/compressed/head.S | 36 -
4 files changed, 172 insertions(+), 7 deletions(-)
create mode 100644 arch/arm/boot/compressed/fdt_check_mem_start.c
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 97f9d004e6d03108..cd980b070f8a99fd 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1909,9 +1909,10 @@ config AUTO_ZRELADDR
help
ZRELADDR is the physical address where the decompressed kernel
image will be placed. If AUTO_ZRELADDR is selected, the address
- will be determined at run-time by masking the current IP with
- 0xf800. This assumes the zImage being placed in the first 128MB
- from start of memory.
+ will be determined at run-time, either by masking the current IP
+ with 0xf800, or, if invalid, from the DTB passed in r2.
+ This assumes the zImage being placed in the first 128MB from
+ start of memory.
config EFI_STUB
bool
diff --git a/arch/arm/boot/compressed/Makefile
b/arch/arm/boot/compressed/Makefile
index fb521efcc6c20a4f..fd94e27ba4fa3d12 100644
--- a/arch/arm/boot/compressed/Makefile
+++ b/arch/arm/boot/compressed/Makefile
@@ -87,10 +87,13 @@ libfdt_objs := fdt_rw.o fdt_ro.o fdt_wip.o fdt.o
ifeq ($(CONFIG_ARM_ATAG_DTB_COMPAT),y)
OBJS += $(libfdt_objs) atags_to_fdt.o
endif
+ifeq ($(CONFIG_USE_OF),y)
+OBJS += $(libfdt_objs) fdt_check_mem_start.o
+endif
# -fstack-protector-strong triggers protection checks in this code,
# but it is being used too early to link to meaningful stack_chk logic.
-$(foreach o, $(libfdt_objs) atags_to_fdt.o, \
+$(foreach o, $(libfdt_objs) atags_to_fdt.o fdt_check_mem_start.o, \
$(eval CFLAGS_$(o) := -I $(srctree)/scripts/dtc/libfdt
-fno-stack
Re: [PATCH 2/2] powerpc/64s: Trim offlined CPUs from mm_cpumasks
Hi Nicholas,
On Fri, Nov 20, 2020 at 4:01 AM Nicholas Piggin wrote:
>
> When offlining a CPU, powerpc/64s does not flush TLBs, rather it just
> leaves the CPU set in mm_cpumasks, so it continues to receive TLBIEs
> to manage its TLBs.
>
> However the exit_flush_lazy_tlbs() function expects that after
> returning, all CPUs (except self) have flushed TLBs for that mm, in
> which case TLBIEL can be used for this flush. This breaks for offline
> CPUs because they don't get the IPI to flush their TLB. This can lead
> to stale translations.
>
> Fix this by clearing the CPU from mm_cpumasks, then flushing all TLBs
> before going offline.
>
> These offlined CPU bits stuck in the cpumask also prevents the cpumask
> from being trimmed back to local mode, which means continual broadcast
> IPIs or TLBIEs are needed for TLB flushing. This patch prevents that
> situation too.
>
> Signed-off-by: Nicholas Piggin
Thanks for your patch!
> --- a/arch/powerpc/platforms/powermac/smp.c
> +++ b/arch/powerpc/platforms/powermac/smp.c
> @@ -911,6 +911,8 @@ static int smp_core99_cpu_disable(void)
>
> mpic_cpu_set_priority(0xf);
>
> + cleanup_cpu_mmu_context();
> +
I guess this change broke pmac32_defconfig+SMP in v5.10-rc7?
arch/powerpc/platforms/powermac/smp.c: error: implicit
declaration of function 'cleanup_cpu_mmu_context'
[-Werror=implicit-function-declaration]: => 914:2
http://kisskb.ellerman.id.au/kisskb/buildresult/14423174/
> return 0;
> }
>
> diff --git a/arch/powerpc/platforms/powernv/smp.c
> b/arch/powerpc/platforms/powernv/smp.c
> index 54c4ba45c7ce..cbb67813cd5d 100644
> --- a/arch/powerpc/platforms/powernv/smp.c
> +++ b/arch/powerpc/platforms/powernv/smp.c
> @@ -143,6 +143,9 @@ static int pnv_smp_cpu_disable(void)
> xive_smp_disable_cpu();
> else
> xics_migrate_irqs_away();
> +
> + cleanup_cpu_mmu_context();
> +
> return 0;
> }
>
> diff --git a/arch/powerpc/platforms/pseries/hotplug-cpu.c
> b/arch/powerpc/platforms/pseries/hotplug-cpu.c
> index f2837e33bf5d..a02012f1b04a 100644
> --- a/arch/powerpc/platforms/pseries/hotplug-cpu.c
> +++ b/arch/powerpc/platforms/pseries/hotplug-cpu.c
> @@ -90,6 +90,9 @@ static int pseries_cpu_disable(void)
> xive_smp_disable_cpu();
> else
> xics_migrate_irqs_away();
> +
> + cleanup_cpu_mmu_context();
> +
> return 0;
> }
>
> --
> 2.23.0
>
--
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
Re: [PATCH 2/3] mfd: bd9571mwv: Make the driver more generic
Hi Shimoda-san,
On Thu, Dec 10, 2020 at 5:10 AM Yoshihiro Shimoda
wrote:
> > From: Geert Uytterhoeven, Sent: Wednesday, December 9, 2020 10:26 PM
> > On Tue, Dec 8, 2020 at 9:06 AM Yoshihiro Shimoda
> > wrote:
>
> > > index 80c6ef0..57bdb6a 100644
> > > --- a/drivers/mfd/bd9571mwv.c
> > > +++ b/drivers/mfd/bd9571mwv.c
> >
> > > @@ -127,13 +137,12 @@ static int bd9571mwv_identify(struct bd9571mwv *bd)
> > > ret);
> > > return ret;
> > > }
> > > -
> > > - if (value != BD9571MWV_PRODUCT_CODE_VAL) {
> > > + /* Confirm the product code */
> > > + if (value != bd->data->product_code_val) {
> > > dev_err(dev, "Invalid product code ID %02x (expected
> > > %02x)\n",
> > > - value, BD9571MWV_PRODUCT_CODE_VAL);
> > > + value, bd->data->product_code_val);
> > > return -EINVAL;
> > > }
> >
> > Reading the product code register, and checking the product code value
> > can be removed, as bd9571mwv_probe() has verified it already.
>
> Indeed. I'll remove this.
OK.
> > > --- a/include/linux/mfd/bd9571mwv.h
> > > +++ b/include/linux/mfd/bd9571mwv.h
> > > + */
> > > +struct bd957x_data {
> > > + int product_code_val;
> >
> > unsigned int?
>
> We can remove this member.
True.
> Or, keeping this member and then we check the product code by this member
> instead of switch() like below?
>
> /* No build test, JFYI */
> struct bd957x_data *data_array[] = {
> _data,
> _data,
> };
>
> for (i = 0; I < ARRAY_SIZE(data_array); i++) {
> if (val == data_array[i].product_code_val) {
> bd->data = data_array[i];
> break;
> }
> }
Given we probably won't have more than a handful variants, I'm
leaning towards the switch() approach.
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
Re: [PATCH 3/3] mfd: bd9571mwv: Add support for BD9574MWF
Hi Matti, Shimoda-san,
On Thu, Dec 10, 2020 at 8:33 AM Vaittinen, Matti
wrote:
> On Thu, 2020-12-10 at 04:44 +, Yoshihiro Shimoda wrote:
> > > From: Geert Uytterhoeven, Sent: Wednesday, December 9, 2020 10:30
> > > PM
> >
> > > > --- a/drivers/mfd/bd9571mwv.c
> > > > +++ b/drivers/mfd/bd9571mwv.c
> > > >
> > > > @@ -182,6 +272,8 @@ static int bd9571mwv_probe(struct i2c_client
> > > > *client,
> > > > product_code = (unsigned int)ret;
> > > > if (product_code == BD9571MWV_PRODUCT_CODE_VAL)
> > > > bd->data = _data;
> > > > + else if (product_code == BD9574MWF_PRODUCT_CODE_VAL)
> > > > + bd->data = _data;
> > > >
> > > > if (!bd->data) {
> > > > dev_err(bd->dev, "No found supported device
> > > > %d\n",
> > >
> > > While BD9571MWV and BD9574MWF can be distinguished at runtime,
> > > I think it would still be a good idea to document a
> > > "rohm,bd9574mwf"
> > > compatible value in the DT bindings, and let the driver match on
> > > that.
> >
> > In this driver point of view, we can use such the DT bindings,
> > however, in the board point of view, it's difficult to describe
> > which chip is installed on r8a77990-ebisu.dts. So, I'd like to
> > keep this runtime detection.
To clarify: I meant to document and add the compatible value, but
treat both compatible values the same in the driver, and still do runtime
probing.
> First of all - I don't want to insist changes here so my comment can be
> ignored. I would definitely like seeing the support for BD9574 in-tree!
>
> But as a 'nit':
> I don't know what are the difficulties you are referring to so it's
> hard for me to comment this. Without better understanding of board dts
> files - I think BD9574MWF should really have own compatible as I
> understood it is different from the BD9571MWV. Relying on product code
> probing sounds like something that may easily break when/if new
> variants are produced. ( I've seen new HW variants using the same
> ID information being produced in previous companies I've worked. Sure
Yes, this happens from time to time, unfortunately.
> ROHM wouldn't do this but still... :] ). And producing boards where DTS
> does not allow describing the correct components sounds like asking for
> a nose-bleed to me... If probing of IC type fails AND there is devices
> with wrong PMIC information burned in DT - then fixing it can be a
> nightmare. So I would really try make DTS files such that they can be
The issue we're facing is that older Ebisu-4D boards have BD9571, while
newer boards have BD9574. The schematics say "BD9574MWF-M (tentative
ver:BD9571TL1_E3)", so it looks like both parts are pin-compatible
(ignoring missing pins for AVS, LDO1, LDO2, and LDO6 on BD9574).
Hence arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts has a device node
compatible with "rohm,bd9571mwv". If we have runtime probing, we can
keep on using that for both variants.
> changed to match the actual board. (Perhaps introduce the compatible
> for BD9574MWF - make this driver to match both of the PMICs - leave the
> runtime probing here for now - and in parallel work with the DTS files
> so that eventually the probing can be removed(?) That was my 10 cents
> on this topic :] )
Exactly. Thanks!
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
Re: linux-next: Fixes tag needs some work in the clk tree
Hi Stephen²,
On Wed, Dec 9, 2020 at 6:29 PM Stephen Boyd wrote:
> Quoting Geert Uytterhoeven (2020-12-08 00:37:00)
> > On Mon, Dec 7, 2020 at 11:06 PM Stephen Rothwell
> > wrote:
> > > In commit
> > >
> > > c3f207f6d23d ("clk: renesas: r8a779a0: Make
> > > rcar_r8a779a0_cpg_clk_register() static")
> > >
> > > Fixes tag
> > >
> > > Fixes: c07439dea94050b6 ("clk: renesas: cpg-mssr: Add support for R-Car
> > > V3U")
> > >
> > > has these problem(s):
> > >
> > > - Target SHA1 does not exist
> >
> > Oops, my bad.
> >
> > > Maybe you meant
> > >
> > > Fixes: 17bcc8035d2d ("clk: renesas: cpg-mssr: Add support for R-Car V3U")
> >
> > Yes I did.
> >
> > Mike/Stephen: do you want me to respin my pull requests?
>
> Sure a respin is fine. I can fix it up in clk tree. Any chance your
Done, sorry for the mess.
> trees can be pulled into linux-next? That would find this earlier.
That sounds like a great idea, also for pinctrl.
Can you please add the following:
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git
renesas-clk
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git
renesas-pinctrl
?
Thanks!
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
Re: [PATCH 3/3] mfd: bd9571mwv: Add support for BD9574MWF
Hi Shimoda-san,
CC Matti (BD9573/6 driver for R-Car platforms)
(I don't have the BD9574 datasheet, so I have to base my review on
https://www.rohm.com/r-car-pmic)
On Tue, Dec 8, 2020 at 9:06 AM Yoshihiro Shimoda
wrote:
> From: Khiem Nguyen
>
> The new PMIC BD9574MWF inherits features from BD9571MWV.
> Add the support of new PMIC to existing bd9571mwv driver.
>
> Signed-off-by: Khiem Nguyen
> [shimoda: rebase and refactor]
> Signed-off-by: Yoshihiro Shimoda
Thanks for your patch!
> --- a/drivers/mfd/bd9571mwv.c
> +++ b/drivers/mfd/bd9571mwv.c
> @@ -20,6 +20,7 @@ static const struct mfd_cell bd9571mwv_cells[] = {
> { .name = "bd9571mwv-gpio", },
> };
>
> +/* Regmap for BD9571MWV */
Note that bd9571mwv_cells[] above also applies to BD9571MWV.
> static const struct regmap_range bd9571mwv_readable_yes_ranges[] = {
> regmap_reg_range(BD9571MWV_VENDOR_CODE, BD9571MWV_PRODUCT_REVISION),
> regmap_reg_range(BD9571MWV_BKUP_MODE_CNT, BD9571MWV_BKUP_MODE_CNT),
> @@ -112,6 +113,95 @@ static const struct bd957x_data bd9571mwv_data = {
> .num_cells = ARRAY_SIZE(bd9571mwv_cells),
> };
>
> +static const struct mfd_cell bd9574mwf_cells[] = {
> + { .name = "bd9571mwv-gpio", },
No regulator cell?
> +};
> +
> +/* Regmap for BD9574MWF */
Note that bd9574mwf_cells[] above also applies to BD9574MWF.
Perhaps the comments should be changed slightly, and moved up,
to serve as a separator between chip variants?
> +static const struct regmap_range bd9574mwf_readable_yes_ranges[] = {
> + regmap_reg_range(BD9574MWF_VENDOR_CODE, BD9574MWF_PRODUCT_REVISION),
Missing BD9574MWF_BKUP_MODE_CNT and BD9574MWF_DVFS_*?
> + regmap_reg_range(BD9574MWF_GPIO_IN, BD9574MWF_GPIO_IN),
> + regmap_reg_range(BD9574MWF_GPIO_INT, BD9574MWF_GPIO_INTMASK),
> + regmap_reg_range(BD9574MWF_GPIO_MUX, BD9574MWF_GPIO_MUX),
> + regmap_reg_range(BD9574MWF_INT_INTREQ, BD9574MWF_INT_INTMASK),
> +};
> +
> +static const struct regmap_access_table bd9574mwf_readable_table = {
> + .yes_ranges = bd9574mwf_readable_yes_ranges,
> + .n_yes_ranges = ARRAY_SIZE(bd9574mwf_readable_yes_ranges),
> +};
> +
> +static const struct regmap_range bd9574mwf_writable_yes_ranges[] = {
Missing BD9574MWF_BKUP_MODE_CNT and BD9574MWF_DVFS_*?
> + regmap_reg_range(BD9574MWF_GPIO_DIR, BD9574MWF_GPIO_OUT),
> + regmap_reg_range(BD9574MWF_GPIO_INT_SET, BD9574MWF_GPIO_INTMASK),
> + regmap_reg_range(BD9574MWF_INT_INTREQ, BD9574MWF_INT_INTMASK),
> +};
> @@ -182,6 +272,8 @@ static int bd9571mwv_probe(struct i2c_client *client,
> product_code = (unsigned int)ret;
> if (product_code == BD9571MWV_PRODUCT_CODE_VAL)
> bd->data = _data;
> + else if (product_code == BD9574MWF_PRODUCT_CODE_VAL)
> + bd->data = _data;
>
> if (!bd->data) {
> dev_err(bd->dev, "No found supported device %d\n",
While BD9571MWV and BD9574MWF can be distinguished at runtime,
I think it would still be a good idea to document a "rohm,bd9574mwf"
compatible value in the DT bindings, and let the driver match on that.
> diff --git a/include/linux/mfd/bd9571mwv.h b/include/linux/mfd/bd9571mwv.h
> index 0126b52..e9e219b 100644
> --- a/include/linux/mfd/bd9571mwv.h
> +++ b/include/linux/mfd/bd9571mwv.h
> +#define BD9574MWF_VDCORE_VINIT 0x50
> +#define BD9574MWF_VD09_VINIT 0x51
> +#define BD9574MWF_VDCORE_SETVMAX 0x52
> +#define BD9574MWF_VDCORE_SETVID0x54
> +#define BD9574MWF_VDCORE_MONIVDAC 0x55
> +#define BD9574MWF_VDCORE_PGD_CNT 0x56
Some of the above are the same as the corresponding BD9571MWV
registers, so using the same define may simplify regulator support
(cfr. BD9571MWV_DVFS_SETVID and BD9571MWV_DVFS_MONIVDAC).
> +#define BD9574MWF_PART_NUMBER "BD9574MWF"
BD9574MWF_PART_NAME?
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
Re: [PATCH 2/3] mfd: bd9571mwv: Make the driver more generic
Hi Shimoda-san,
On Tue, Dec 8, 2020 at 9:06 AM Yoshihiro Shimoda
wrote:
> From: Khiem Nguyen
>
> Since the driver supports BD9571MWV PMIC only,
> this patch makes the functions and data structure become more generic
> so that it can support other PMIC variants as well.
>
> Signed-off-by: Khiem Nguyen
> [shimoda: rebase and refactor]
> Signed-off-by: Yoshihiro Shimoda
Thanks for your patch!
> index 80c6ef0..57bdb6a 100644
> --- a/drivers/mfd/bd9571mwv.c
> +++ b/drivers/mfd/bd9571mwv.c
> @@ -127,13 +137,12 @@ static int bd9571mwv_identify(struct bd9571mwv *bd)
> ret);
> return ret;
> }
> -
> - if (value != BD9571MWV_PRODUCT_CODE_VAL) {
> + /* Confirm the product code */
> + if (value != bd->data->product_code_val) {
> dev_err(dev, "Invalid product code ID %02x (expected %02x)\n",
> - value, BD9571MWV_PRODUCT_CODE_VAL);
> + value, bd->data->product_code_val);
> return -EINVAL;
> }
Reading the product code register, and checking the product code value
can be removed, as bd9571mwv_probe() has verified it already.
> @@ -150,6 +160,7 @@ static int bd9571mwv_probe(struct i2c_client *client,
> const struct i2c_device_id *ids)
> {
> struct bd9571mwv *bd;
> + unsigned int product_code;
No need for a new variable...
> int ret;
>
> bd = devm_kzalloc(>dev, sizeof(*bd), GFP_KERNEL);
> @@ -160,7 +171,25 @@ static int bd9571mwv_probe(struct i2c_client *client,
> bd->dev = >dev;
> bd->irq = client->irq;
>
> - bd->regmap = devm_regmap_init_i2c(client, _regmap_config);
> + /* Read the PMIC product code */
> + ret = i2c_smbus_read_byte_data(client, BD9571MWV_PRODUCT_CODE);
> + if (ret < 0) {
> + dev_err(>dev, "failed reading at 0x%02x\n",
> + BD9571MWV_PRODUCT_CODE);
> + return ret;
> + }
> +
> + product_code = (unsigned int)ret;
> + if (product_code == BD9571MWV_PRODUCT_CODE_VAL)
... as you can just check if ret == BD9571MWV_PRODUCT_CODE_VAL here.
> + bd->data = _data;
> +
> + if (!bd->data) {
> + dev_err(bd->dev, "No found supported device %d\n",
"Unsupported device 0x%x"?
> + product_code);
> + return -ENOENT;
> + }
The construct above may be easier to read and extend by using a switch()
statement, with a default case for unsupported devices.
> --- a/include/linux/mfd/bd9571mwv.h
> +++ b/include/linux/mfd/bd9571mwv.h
> @@ -83,6 +85,8 @@
>
> #define BD9571MWV_ACCESS_KEY 0xff
>
> +#define BD9571MWV_PART_NUMBER "BD9571MWV"
BD9571MWV_PART_NAME?
> +
> /* Define the BD9571MWV IRQ numbers */
> enum bd9571mwv_irqs {
> BD9571MWV_IRQ_MD1,
> @@ -96,6 +100,20 @@ enum bd9571mwv_irqs {
> };
>
> /**
> + * struct bd957x_data - internal data for the bd957x driver
> + *
> + * Internal data to distinguish bd9571mwv chip and bd9574mwf chip
... distinguish bd957x variants?
> + */
> +struct bd957x_data {
> + int product_code_val;
unsigned int?
> + char *part_number;
part_name?
> + const struct regmap_config *regmap_config;
> + const struct regmap_irq_chip *irq_chip;
> + const struct mfd_cell *cells;
> + int num_cells;
I'd say "unsigned int", but mfd_add_devices() takes plain "int".
Please put the "product_code_val" and "num_cells" fields next to
each other, to avoid two 4-byte gaps on 64-bit platforms.
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
[PATCH trivial] irqchip/gic: Spelling s/REturn/Return/
Fix a capitalization typo. Signed-off-by: Geert Uytterhoeven --- drivers/irqchip/irq-gic.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c index 6053245a4754c092..a3c2f18131b2b1da 100644 --- a/drivers/irqchip/irq-gic.c +++ b/drivers/irqchip/irq-gic.c @@ -973,7 +973,7 @@ void gic_migrate_target(unsigned int new_cpu_id) /* * gic_get_sgir_physaddr - get the physical address for the SGI register * - * REturn the physical address of the SGI register to be used + * Return the physical address of the SGI register to be used * by some early assembly code when the kernel is not yet available. */ static unsigned long gic_dist_physaddr; -- 2.25.1
[PATCH trivial] ARM: uncompress: atags_to_fdt: Spelling s/REturn/Return/
Fix a capitalization typo. Signed-off-by: Geert Uytterhoeven --- arch/arm/boot/compressed/atags_to_fdt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/boot/compressed/atags_to_fdt.c b/arch/arm/boot/compressed/atags_to_fdt.c index 8452753efebe5621..503ad35a251a115e 100644 --- a/arch/arm/boot/compressed/atags_to_fdt.c +++ b/arch/arm/boot/compressed/atags_to_fdt.c @@ -120,7 +120,7 @@ static void hex_str(char *out, uint32_t value) /* * Convert and fold provided ATAGs into the provided FDT. * - * REturn values: + * Return values: *= 0 -> pretend success *= 1 -> bad ATAG (may retry with another possible ATAG pointer) *< 0 -> error from libfdt -- 2.25.1
Re: [PATCH 1/3] mfd: bd9571mwv: Use the SPDX license identifier
On Tue, Dec 8, 2020 at 9:06 AM Yoshihiro Shimoda
wrote:
> Use the SPDX license identifier instead of a local description.
>
> Signed-off-by: Yoshihiro Shimoda
Reviewed-by: Geert Uytterhoeven
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
Re: [Ksummit-discuss] crediting bug reports and fixes folded into original patch
On Wed, Dec 9, 2020 at 9:45 AM Vlastimil Babka wrote:
> On 12/9/20 8:58 AM, Dan Carpenter wrote:
> > On Tue, Dec 08, 2020 at 09:01:49PM -0800, Joe Perches wrote:
> >> On Tue, 2020-12-08 at 16:34 -0800, Kees Cook wrote:
> >>
> >> > If not "Adjusted-by", what about "Tweaked-by", "Helped-by",
> >> > "Corrected-by"?
> >>
> >> Improved-by: / Enhanced-by: / Revisions-by:
> >>
> >
> > I don't think we should give any credit for improvements or enhancements,
>
> Well, some are actually useful and not about reviewer's preferred style :) But
> if an author redoes the patch as a result, it's their choice to mention useful
> improvements in the next version's change log.
>
> > only for fixes. Complaining about style is its own reward.
>
> Right, let's focus on fixes and reports of bugs, that would have resulted in a
> standalone commit, but don't.
>
> > Having to redo a patch is already a huge headache. Normally, I already
> > considered the reviewer's prefered style and decided I didn't like it.
> > Then to make me redo the patch in an ugly style and say thankyou on
> > top of that??? Forget about it. Plus, as a reviewer I hate reviewing
> > patches over and over.
> >
> > I've argued for years that we should have a Fixes-from: tag. The zero
>
> Standardizing the Fixes-from: tag (or any better name) would be a forward
> progress, yes.
>
> > day bot is already encouraging people to add Reported-by tags for this
> > and a lot of people do.
>
> "Reported-by:" becomes ambiguous once the bugfix for the reported issue in the
> patch is folded, as it's no longer clear whether the bot reported the original
> issue the patch is fixing, or a bug in the fix. So we should have a different
> variant. "Fixes-reported-by:" so it has the same prefix?
Taken-into-account-comments-from:
Any terse English word for that?
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
[PATCH 0/2] Documentation/kbuild: Document COMPILE_TEST and platform dependencies
Hi all,
This patch series documents best practices for COMPILE_TEST and
architecture/platform dependencies, like already in use in most
subsystems, to serve as a point of reference.
Thanks for your comments!
Geert Uytterhoeven (2):
Documentation/kbuild: Document COMPILE_TEST dependencies
Documentation/kbuild: Document platform dependency practises
Documentation/kbuild/kconfig-language.rst | 35 +++
1 file changed, 35 insertions(+)
--
2.25.1
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
[PATCH 1/2] Documentation/kbuild: Document COMPILE_TEST dependencies
Document best practises for using COMPILE_TEST dependencies. Signed-off-by: Geert Uytterhoeven --- Documentation/kbuild/kconfig-language.rst | 11 +++ 1 file changed, 11 insertions(+) diff --git a/Documentation/kbuild/kconfig-language.rst b/Documentation/kbuild/kconfig-language.rst index 1cf1aebdd6cdf8fa..2b746332d8aa6bce 100644 --- a/Documentation/kbuild/kconfig-language.rst +++ b/Documentation/kbuild/kconfig-language.rst @@ -553,6 +553,17 @@ with "depends on m". E.g.:: limits FOO to module (=m) or disabled (=n). +Compile-testing +~~~ +If a config symbol has a dependency, but the code controlled by the config +symbol can still be compiled if the dependency is not met, it is encouraged to +increase build coverage by adding an "|| COMPILE_TEST" clause to the +dependency. This is especially useful for drivers for more exotic hardware, as +it allows continuous-integration systems to compile-test the code on a more +common system, and detect bugs that way. +Note that compile-tested code should avoid crashing when run on a system where +the dependency is not met. + Kconfig recursive dependency limitations -- 2.25.1
[PATCH 2/2] Documentation/kbuild: Document platform dependency practises
Document best practises for using architecture and platform dependencies. Signed-off-by: Geert Uytterhoeven --- Documentation/kbuild/kconfig-language.rst | 24 +++ 1 file changed, 24 insertions(+) diff --git a/Documentation/kbuild/kconfig-language.rst b/Documentation/kbuild/kconfig-language.rst index 2b746332d8aa6bce..87e9bbe14a21ce83 100644 --- a/Documentation/kbuild/kconfig-language.rst +++ b/Documentation/kbuild/kconfig-language.rst @@ -564,6 +564,30 @@ common system, and detect bugs that way. Note that compile-tested code should avoid crashing when run on a system where the dependency is not met. +Architecture and platform dependencies +~~ +Due to the presence of stubs, most drivers can now be compiled on most +architectures. However, this does not mean it makes sense to have all drivers +available everywhere, as the actual hardware may only exist on specific +architectures and platforms. This is especially true for on-SoC IP cores, +which may be limited to a specific vendor or SoC family. + +To prevent asking the user about drivers that cannot be used on the system(s) +the user is compiling a kernel for, and if it makes sense, config symbols +controlling the compilation of a driver should contain proper dependencies, +limiting the visibility of the symbol to (a superset of) the platform(s) the +driver can be used on. The dependency can be an architecture (e.g. ARM) or +platform (e.g. ARCH_OMAP4) dependency. This makes life simpler not only for +distro config owners, but also for every single developer or user who +configures a kernel. + +Such a dependency can be relaxed by combining it with the compile-testing rule +above, leading to: + + config FOO + bool "Support for foo hardware" + depends on ARCH_FOO_VENDOR || COMPILE_TEST + Kconfig recursive dependency limitations -- 2.25.1
