* Re: [PATCH 1/4] dt-bindings: clock: airoha: add EN7581 binding
From: Krzysztof Kozlowski @ 2024-04-04 6:34 UTC (permalink / raw)
To: Lorenzo Bianconi, linux-clk
Cc: mturquette, sboyd, linux-arm-kernel, robh+dt,
krzysztof.kozlowski+dt, conor+dt, nbd, john, devicetree, dd,
catalin.marinas, will, upstream, lorenzo.bianconi83,
angelogioacchino.delregno
In-Reply-To: <1988a4460ed327bea7841f6a0f3a756dd7cec4bb.1712160869.git.lorenzo@kernel.org>
On 03/04/2024 18:20, Lorenzo Bianconi wrote:
> Introduce Airoha EN7581 entry in Airoha EN7523 clock binding
>
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> ---
> .../bindings/clock/airoha,en7523-scu.yaml | 26 +++++++++++++++++--
> 1 file changed, 24 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/clock/airoha,en7523-scu.yaml b/Documentation/devicetree/bindings/clock/airoha,en7523-scu.yaml
> index 79b0752faa91..cf893d4c74cd 100644
> --- a/Documentation/devicetree/bindings/clock/airoha,en7523-scu.yaml
> +++ b/Documentation/devicetree/bindings/clock/airoha,en7523-scu.yaml
> @@ -29,10 +29,13 @@ description: |
> properties:
> compatible:
> items:
> - - const: airoha,en7523-scu
> + - enum:
> + - airoha,en7523-scu
> + - airoha,en7581-scu
>
> reg:
> - maxItems: 2
> + minItems: 2
> + maxItems: 3
>
> "#clock-cells":
> description:
> @@ -45,6 +48,25 @@ required:
> - reg
> - '#clock-cells'
>
> +allOf:
> + - if:
> + properties:
> + compatible:
> + const: airoha,en7523-scu
> + then:
> + properties:
> + reg:
> + maxItems: 2
> +
> + - if:
> + properties:
> + compatible:
> + const: airoha,en7581-scu
> + then:
> + properties:
> + reg:
> + maxItems: 3
Original code had here issue - lack of description of the items. You are
now growing it. Please instead list the items (items: - description: foo
bar .....).
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v6 1/2] dt-bindings: usb: Add the binding example for the Genesys Logic GL3523 hub
From: Anand Moon @ 2024-04-04 6:34 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Rob Herring, Greg Kroah-Hartman, Krzysztof Kozlowski,
Conor Dooley, Icenowy Zheng, Neil Armstrong, linux-amlogic,
Conor Dooley, linux-usb, devicetree, linux-kernel
In-Reply-To: <CANAwSgR4zwoHUZRFmbjV9Z5kX9P_bU=HjkUokZm3eNStPXwwOw@mail.gmail.com>
Hi Krzysztof,
On Thu, 4 Apr 2024 at 12:02, Anand Moon <linux.amoon@gmail.com> wrote:
>
> Hi,
>
> On Thu, 4 Apr 2024 at 11:42, Krzysztof Kozlowski
> <krzysztof.kozlowski@linaro.org> wrote:
> >
> > On 04/04/2024 06:27, Anand Moon wrote:
> > > Hi Krzysztof,
> > >
> > > On Tue, 12 Dec 2023 at 18:47, Anand Moon <linux.amoon@gmail.com> wrote:
> > >>
> > >> Hi Krzysztof,
> > >>
> > >> On Tue, 12 Dec 2023 at 18:39, Krzysztof Kozlowski
> > >> <krzysztof.kozlowski@linaro.org> wrote:
> > >>>
> > >>> On 12/12/2023 13:51, Anand Moon wrote:
> > >>>> Hi Krzysztof,
> > >>>>
> > >>>> On Tue, 12 Dec 2023 at 17:22, Krzysztof Kozlowski
> > >>>> <krzysztof.kozlowski@linaro.org> wrote:
> > >>>>>
> > >>>>> On 12/12/2023 12:37, Anand Moon wrote:
> > >>>>>>
> > >>>>>> Here is the list of warnings I observed with this patch
> > >>>>>>
> > >>>>>> DTC_CHK Documentation/devicetree/bindings/usb/nvidia,tegra186-xusb.example.dtb
> > >>>>>> /home/amoon/mainline/linux-amlogic-6.y-devel/Documentation/devicetree/bindings/usb/usb-device.example.dtb:
> > >>>>>> hub@1: 'vdd-supply' is a required property
> > >>>>>
> > >>>>> You always require the property, but it is not valid for some devices.
> > >>>>> Just require it only where it is applicable (in if:then: clause).
> > >>>>>
> > >>>> I had already done this check many times before.
> > >>>
> > >>> I don't ask you to check. I ask you to change the code.
> > >>>
> > >> I have tried this and it's not working for me.
> > >>
> > >>>> my v6 original patch was doing the same and it passed all the tests
> > >>>> but since I updated the required field it not parsing correctly.
> > >>>
> > >>> Your original v6 patch was different. I don't understand what you are
> > >>> trying to achieve. Or rather: how is it different, that my simple advice
> > >>> above does not work for you (as in the past you reply with some really
> > >>> unrelated sentence).
> > >>>
> > >> Ok, It's my poor English grammar, thanks for your review comments.
> > >>
> > >>> Best regards,
> > >>> Krzysztof
> > >>>
> > >
> > > Any reason this device tree binding got removed,I cannot find this file
> > > Can not find the commit which removed this file.
> >
> > Use git log.
> >
I got confused with the file name and my local changes.
> > Best regards,
> > Krzysztof
> >
Thanks
-Anand
^ permalink raw reply
* Re: [PATCH 4/4] clk: en7523: add EN7581 support
From: Krzysztof Kozlowski @ 2024-04-04 6:36 UTC (permalink / raw)
To: Lorenzo Bianconi, linux-clk
Cc: mturquette, sboyd, linux-arm-kernel, robh+dt,
krzysztof.kozlowski+dt, conor+dt, nbd, john, devicetree, dd,
catalin.marinas, will, upstream, lorenzo.bianconi83,
angelogioacchino.delregno
In-Reply-To: <3aaf638b846ecfdbfc1c903206b7d519d56c9130.1712160869.git.lorenzo@kernel.org>
On 03/04/2024 18:20, Lorenzo Bianconi wrote:
> Introduce EN7581 clock support to clk-en7523 driver.
>
> Tested-by: Zhengping Zhang <zhengping.zhang@airoha.com>
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> + return 0;
> +}
> +
> static int en7523_clk_probe(struct platform_device *pdev)
> {
> struct device_node *node = pdev->dev.of_node;
> @@ -306,6 +413,12 @@ static int en7523_clk_probe(struct platform_device *pdev)
> if (IS_ERR(np_base))
> return PTR_ERR(np_base);
>
> + if (of_device_is_compatible(node, "airoha,en7581-scu")) {
Having matching and compatible comparisons inside various code is
discouraged. Does not scale. Use driver/match data to store some sort of
flags and check for the flag or some other parameter. The best if
compatible appears once and only once: in of_device_id.
> + r = en7581_clk_hw_init(pdev, base, np_base);
> + if (r)
> + return r;
> + }
> +
> clk_data = devm_kzalloc(&pdev->dev,
> struct_size(clk_data, hws, EN7523_NUM_CLOCKS),
> GFP_KERNEL);
> @@ -329,8 +442,15 @@ static const struct clk_ops en7523_pcie_ops = {
> .unprepare = en7523_pci_unprepare,
> };
>
> +static const struct clk_ops en7581_pcie_ops = {
> + .is_enabled = en7581_pci_is_enabled,
> + .prepare = en7581_pci_prepare,
> + .unprepare = en7581_pci_unprepare,
> +};
> +
> static const struct of_device_id of_match_clk_en7523[] = {
> { .compatible = "airoha,en7523-scu", .data = &en7523_pcie_ops },
> + { .compatible = "airoha,en7581-scu", .data = &en7581_pcie_ops },
> { /* sentinel */ }
> };
>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] arm64: dts: imx8m/qxp: Pass the tcpci compatible
From: Krzysztof Kozlowski @ 2024-04-04 6:38 UTC (permalink / raw)
To: Fabio Estevam, shawnguo
Cc: robh, krzk+dt, conor+dt, devicetree, linux-arm-kernel,
Fabio Estevam
In-Reply-To: <20240403194019.453253-1-festevam@gmail.com>
On 03/04/2024 21:40, Fabio Estevam wrote:
> From: Fabio Estevam <festevam@denx.de>
>
> Per nxp,ptn5110.yaml, also pass the fallback "tcpci" compatible
> to fix the following dt-schema warning:
>
> usb-typec@50: compatible: ['nxp,ptn5110'] is too short
> from schema $id: http://devicetree.org/schemas/usb/nxp,ptn5110.yaml#
>
> Signed-off-by: Fabio Estevam <festevam@denx.de>
> ---
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v4 0/8] cpufreq: sun50i: Add Allwinner H616 support
From: Viresh Kumar @ 2024-04-04 6:40 UTC (permalink / raw)
To: Andre Przywara
Cc: Yangtao Li, Viresh Kumar, Nishanth Menon, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland, Rafael J . Wysocki, linux-pm,
devicetree, linux-sunxi, linux-arm-kernel, Brandon Cheo Fusi,
Martin Botka, Martin Botka, Chris Morgan, Ryan Walklin,
Mark Rutland, Lorenzo Pieralisi, Sudeep Holla
In-Reply-To: <20240329141311.27158-1-andre.przywara@arm.com>
On 29-03-24, 14:13, Andre Przywara wrote:
> This series adds cpufreq support to the Allwinner H616 SoC.
> v4 allows compilation outside of arm/arm64, by making the SMCCC call
> optional, the rest of the changes are added tags and cosmetic fixes.
> This is based on Martin's original series from about half a year ago[1].
> Thanks for the comments on the list!
> See below for a changelog.
Is it okay to merge all the changes via the cpufreq tree ?
--
viresh
^ permalink raw reply
* Re: [PATCH v3 21/25] drivers: media: i2c: imx258: Use macros
From: Sakari Ailus @ 2024-04-04 6:46 UTC (permalink / raw)
To: Luigi311
Cc: linux-media, dave.stevenson, jacopo.mondi, mchehab, robh,
krzysztof.kozlowski+dt, conor+dt, shawnguo, s.hauer, kernel,
festevam, devicetree, imx, linux-arm-kernel, linux-kernel, pavel,
phone-devel, Ondrej Jirman
In-Reply-To: <df8c245a-40e9-4bf5-b870-7efe321d820a@luigi311.com>
On Wed, Apr 03, 2024 at 01:17:26PM -0600, Luigi311 wrote:
> On 4/3/24 10:23, Sakari Ailus wrote:
> > Hi Luis,
> >
> > On Wed, Apr 03, 2024 at 09:03:50AM -0600, git@luigi311.com wrote:
> >> From: Luis Garcia <git@luigi311.com>
> >>
> >> Use understandable macros instead of raw values.
> >>
> >> Signed-off-by: Ondrej Jirman <megi@xff.cz>
> >> Signed-off-by: Luis Garcia <git@luigi311.com>
> >> ---
> >> drivers/media/i2c/imx258.c | 434 ++++++++++++++++++-------------------
> >> 1 file changed, 207 insertions(+), 227 deletions(-)
> >>
> >> diff --git a/drivers/media/i2c/imx258.c b/drivers/media/i2c/imx258.c
> >> index e2ecf6109516..30352c33f63c 100644
> >> --- a/drivers/media/i2c/imx258.c
> >> +++ b/drivers/media/i2c/imx258.c
> >> @@ -33,8 +33,6 @@
> >> #define IMX258_VTS_30FPS_VGA 0x034c
> >> #define IMX258_VTS_MAX 65525
> >>
> >> -#define IMX258_REG_VTS 0x0340
> >> -
> >> /* HBLANK control - read only */
> >> #define IMX258_PPL_DEFAULT 5352
> >>
> >> @@ -90,6 +88,53 @@
> >> #define IMX258_PIXEL_ARRAY_WIDTH 4208U
> >> #define IMX258_PIXEL_ARRAY_HEIGHT 3120U
> >>
> >> +/* regs */
> >> +#define IMX258_REG_PLL_MULT_DRIV 0x0310
> >> +#define IMX258_REG_IVTPXCK_DIV 0x0301
> >> +#define IMX258_REG_IVTSYCK_DIV 0x0303
> >> +#define IMX258_REG_PREPLLCK_VT_DIV 0x0305
> >> +#define IMX258_REG_IOPPXCK_DIV 0x0309
> >> +#define IMX258_REG_IOPSYCK_DIV 0x030b
> >> +#define IMX258_REG_PREPLLCK_OP_DIV 0x030d
> >> +#define IMX258_REG_PHASE_PIX_OUTEN 0x3030
> >> +#define IMX258_REG_PDPIX_DATA_RATE 0x3032
> >> +#define IMX258_REG_SCALE_MODE 0x0401
> >> +#define IMX258_REG_SCALE_MODE_EXT 0x3038
> >> +#define IMX258_REG_AF_WINDOW_MODE 0x7bcd
> >> +#define IMX258_REG_FRM_LENGTH_CTL 0x0350
> >> +#define IMX258_REG_CSI_LANE_MODE 0x0114
> >> +#define IMX258_REG_X_EVN_INC 0x0381
> >> +#define IMX258_REG_X_ODD_INC 0x0383
> >> +#define IMX258_REG_Y_EVN_INC 0x0385
> >> +#define IMX258_REG_Y_ODD_INC 0x0387
> >> +#define IMX258_REG_BINNING_MODE 0x0900
> >> +#define IMX258_REG_BINNING_TYPE_V 0x0901
> >> +#define IMX258_REG_FORCE_FD_SUM 0x300d
> >> +#define IMX258_REG_DIG_CROP_X_OFFSET 0x0408
> >> +#define IMX258_REG_DIG_CROP_Y_OFFSET 0x040a
> >> +#define IMX258_REG_DIG_CROP_IMAGE_WIDTH 0x040c
> >> +#define IMX258_REG_DIG_CROP_IMAGE_HEIGHT 0x040e
> >> +#define IMX258_REG_SCALE_M 0x0404
> >> +#define IMX258_REG_X_OUT_SIZE 0x034c
> >> +#define IMX258_REG_Y_OUT_SIZE 0x034e
> >> +#define IMX258_REG_X_ADD_STA 0x0344
> >> +#define IMX258_REG_Y_ADD_STA 0x0346
> >> +#define IMX258_REG_X_ADD_END 0x0348
> >> +#define IMX258_REG_Y_ADD_END 0x034a
> >> +#define IMX258_REG_EXCK_FREQ 0x0136
> >> +#define IMX258_REG_CSI_DT_FMT 0x0112
> >> +#define IMX258_REG_LINE_LENGTH_PCK 0x0342
> >> +#define IMX258_REG_SCALE_M_EXT 0x303a
> >> +#define IMX258_REG_FRM_LENGTH_LINES 0x0340
> >> +#define IMX258_REG_FINE_INTEG_TIME 0x0200
> >> +#define IMX258_REG_PLL_IVT_MPY 0x0306
> >> +#define IMX258_REG_PLL_IOP_MPY 0x030e
> >> +#define IMX258_REG_REQ_LINK_BIT_RATE_MBPS_H 0x0820
> >> +#define IMX258_REG_REQ_LINK_BIT_RATE_MBPS_L 0x0822
> >> +
> >> +#define REG8(a, v) { a, v }
> >> +#define REG16(a, v) { a, ((v) >> 8) & 0xff }, { (a) + 1, (v) & 0xff }
> >
> > The patch is nice but these macros are better replaced by the V4L2 CCI
> > helper that also offers register access functions. Could you add a patch to
> > convert the driver to use it (maybe after this one)?
> >
>
> Ohh perfect, using something else would be great. Ill go ahead and see
> if I can get that working.
Thanks. It may be easier to just do it in this one actually. Up to you.
--
Sakari Ailus
^ permalink raw reply
* Re: [PATCH v3 22/25] dt-bindings: media: imx258: Add binding for powerdown-gpio
From: Sakari Ailus @ 2024-04-04 6:47 UTC (permalink / raw)
To: git
Cc: linux-media, dave.stevenson, jacopo.mondi, mchehab, robh,
krzysztof.kozlowski+dt, conor+dt, shawnguo, s.hauer, kernel,
festevam, devicetree, imx, linux-arm-kernel, linux-kernel, pavel,
phone-devel, Ondrej Jirman
In-Reply-To: <20240403150355.189229-23-git@luigi311.com>
Hi Luigi,
On Wed, Apr 03, 2024 at 09:03:51AM -0600, git@luigi311.com wrote:
> From: Luis Garcia <git@luigi311.com>
>
> Add powerdown-gpio binding as it is required for some boards
>
> Signed-off-by: Ondrej Jirman <megi@xff.cz>
> Signed-off-by: Luis Garcia <git@luigi311.com>
> ---
> Documentation/devicetree/bindings/media/i2c/sony,imx258.yaml | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx258.yaml b/Documentation/devicetree/bindings/media/i2c/sony,imx258.yaml
> index c978abc0cdb3..33338139e6e8 100644
> --- a/Documentation/devicetree/bindings/media/i2c/sony,imx258.yaml
> +++ b/Documentation/devicetree/bindings/media/i2c/sony,imx258.yaml
> @@ -36,6 +36,10 @@ properties:
> reg:
> maxItems: 1
>
> + powerdown-gpios:
> + description:
> + Reference to the GPIO connected to the PWDN pin, if any.
The sensor datasheet does not mention this one so I presume this is
unrelated to the sensor. Could it be for GPIO regulator control instead?
> +
> reset-gpios:
> description: |-
> Reference to the GPIO connected to the XCLR pin, if any.
--
Regards,
Sakari Ailus
^ permalink raw reply
* Re: [PATCH 1/1] dt-bindings: media: imx-jpeg: add clocks,clock-names,slot to fix warning
From: Krzysztof Kozlowski @ 2024-04-04 6:54 UTC (permalink / raw)
To: Frank Li, Mirela Rabulea, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam,
open list:NXP i.MX 8QXP/8QM JPEG V4L2 DRIVER,
open list:NXP i.MX 8QXP/8QM JPEG V4L2 DRIVER,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
open list
In-Reply-To: <af602862-5120-4717-adb6-694ada09e8d8@linaro.org>
On 04/04/2024 08:26, Krzysztof Kozlowski wrote:
> On 04/04/2024 05:52, Frank Li wrote:
>> Fix below DTB_CHECK warning.
>>
>> make CHECK_DTBS=y freescale/imx8qxp-mek.dtb
>> DTC_CHK arch/arm64/boot/dts/freescale/imx8qxp-mek.dtb
>> arch/arm64/boot/dts/freescale/imx8qxp-mek.dtb: jpegdec@58400000: 'assigned-clock-rates', 'assigned-clocks', 'clock-names', 'clocks', 'slot' do not match any of the regexes: 'pinctrl-[0-9]+'
>> from schema $id: http://devicetree.org/schemas/media/nxp,imx8-jpeg.yaml#
>
> No, that's not the reason to add properties. Add them if they are valid.
And for the clocks, instead pick up this patch:
https://lore.kernel.org/all/20230721111020.1234278-3-alexander.stein@ew.tq-group.com/
Please check for same work on lore before working on old issues. dfn in
lore is your friend.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: mailbox: arm,mhuv3: Add bindings
From: Cristian Marussi @ 2024-04-04 6:54 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: linux-kernel, linux-arm-kernel, devicetree, sudeep.holla,
jassisinghbrar, robh+dt, krzysztof.kozlowski+dt, conor+dt
In-Reply-To: <da62846c-884f-4059-a4bd-2e5f5c879e8b@linaro.org>
On Thu, Apr 04, 2024 at 08:30:27AM +0200, Krzysztof Kozlowski wrote:
> On 04/04/2024 08:23, Cristian Marussi wrote:
> > Add bindings for the ARM MHUv3 Mailbox controller.
> >
> > Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
> > ---
> > v2 -> v3
> > - fixed spurious tabs in dt_binding_check
>
> Did you test this patch before sending?
>
Tested with:
make -j8 DT_SCHEMA_FILES=arm,mhuv3.yaml DT_CHECKER_FLAGS=-m dt_binding_check
(with dtschema upgraded)
...and indeed even v2 was supposedly already tested (since included a
bunch of changes as advised), then I made a small last-minute nitpick and
my editor splipped in a couple of tabs...apologies for that.
Thanks,
Cristian
^ permalink raw reply
* Re: [RESEND v7 26/37] dt-bindings: vendor-prefixes: Add iodata
From: Krzysztof Kozlowski @ 2024-04-04 6:57 UTC (permalink / raw)
To: Yoshinori Sato, linux-sh
Cc: Damien Le Moal, Niklas Cassel, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Geert Uytterhoeven, Michael Turquette, Stephen Boyd,
David Airlie, Daniel Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Thomas Gleixner, Bjorn Helgaas,
Lorenzo Pieralisi, Krzysztof Wilczyński, Greg Kroah-Hartman,
Jiri Slaby, Magnus Damm, Daniel Lezcano, Rich Felker,
John Paul Adrian Glaubitz, Lee Jones, Helge Deller,
Heiko Stuebner, Shawn Guo, Sebastian Reichel, Chris Morgan,
Linus Walleij, Arnd Bergmann, David Rientjes, Hyeonggon Yoo,
Vlastimil Babka, Baoquan He, Andrew Morton, Guenter Roeck,
Kefeng Wang, Stephen Rothwell, Javier Martinez Canillas, Guo Ren,
Azeem Shaikh, Max Filippov, Jonathan Corbet, Jacky Huang,
Herve Codina, Manikanta Guntupalli, Anup Patel, Biju Das,
Uwe Kleine-König, Sam Ravnborg, Sergey Shtylyov,
Laurent Pinchart, linux-ide, devicetree, linux-kernel,
linux-renesas-soc, linux-clk, dri-devel, linux-pci, linux-serial,
linux-fbdev
In-Reply-To: <4649938dc48da6e449ef6f1987c7739ba3a80b42.1712207606.git.ysato@users.sourceforge.jp>
On 04/04/2024 07:14, Yoshinori Sato wrote:
> Add IO DATA DEVICE INC.
> https://www.iodata.com/
>
> Signed-off-by: Yoshinori Sato <ysato@users.sourceforge.jp>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
> 1 file changed, 2 insertions(+)
>
This is a friendly reminder during the review process.
It looks like you received a tag and forgot to add it.
If you do not know the process, here is a short explanation:
Please add Acked-by/Reviewed-by/Tested-by tags when posting new
versions, under or above your Signed-off-by tag. Tag is "received", when
provided in a message replied to you on the mailing list. Tools like b4
can help here. However, there's no need to repost patches *only* to add
the tags. The upstream maintainer will do that for tags received on the
version they apply.
https://elixir.bootlin.com/linux/v6.5-rc3/source/Documentation/process/submitting-patches.rst#L577
If a tag was not added on purpose, please state why and what changed.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [RESEND v7 27/37] dt-bindings: ata: ata-generic: Add new targets
From: Krzysztof Kozlowski @ 2024-04-04 6:57 UTC (permalink / raw)
To: Yoshinori Sato, linux-sh
Cc: Damien Le Moal, Niklas Cassel, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Geert Uytterhoeven, Michael Turquette, Stephen Boyd,
David Airlie, Daniel Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Thomas Gleixner, Bjorn Helgaas,
Lorenzo Pieralisi, Krzysztof Wilczyński, Greg Kroah-Hartman,
Jiri Slaby, Magnus Damm, Daniel Lezcano, Rich Felker,
John Paul Adrian Glaubitz, Lee Jones, Helge Deller,
Heiko Stuebner, Shawn Guo, Sebastian Reichel, Chris Morgan,
Linus Walleij, Arnd Bergmann, David Rientjes, Hyeonggon Yoo,
Vlastimil Babka, Baoquan He, Andrew Morton, Guenter Roeck,
Kefeng Wang, Stephen Rothwell, Javier Martinez Canillas, Guo Ren,
Azeem Shaikh, Max Filippov, Jonathan Corbet, Jacky Huang,
Herve Codina, Manikanta Guntupalli, Anup Patel, Biju Das,
Uwe Kleine-König, Sam Ravnborg, Sergey Shtylyov,
Laurent Pinchart, linux-ide, devicetree, linux-kernel,
linux-renesas-soc, linux-clk, dri-devel, linux-pci, linux-serial,
linux-fbdev
In-Reply-To: <53f85cc2e124d1c2e7394458b73293d797817d6d.1712207606.git.ysato@users.sourceforge.jp>
On 04/04/2024 07:14, Yoshinori Sato wrote:
> Added new ata-generic target.
> - iodata,usl-5p-ata
> - renesas,rts7751r2d-ata
>
> Each boards have simple IDE Interface. Use ATA generic driver.
>
This is a friendly reminder during the review process.
It looks like you received a tag and forgot to add it.
If you do not know the process, here is a short explanation:
Please add Acked-by/Reviewed-by/Tested-by tags when posting new
versions, under or above your Signed-off-by tag. Tag is "received", when
provided in a message replied to you on the mailing list. Tools like b4
can help here. However, there's no need to repost patches *only* to add
the tags. The upstream maintainer will do that for tags received on the
version they apply.
https://elixir.bootlin.com/linux/v6.5-rc3/source/Documentation/process/submitting-patches.rst#L577
If a tag was not added on purpose, please state why and what changed.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: mfd: Add ROHM BD71879
From: Krzysztof Kozlowski @ 2024-04-04 6:59 UTC (permalink / raw)
To: Andreas Kemnade, lee, robh+dt, krzysztof.kozlowski+dt, conor+dt,
mazziesaccount, devicetree, linux-kernel
In-Reply-To: <20240402193515.513713-2-andreas@kemnade.info>
On 02/04/2024 21:35, Andreas Kemnade wrote:
> As this chip was seen in several devices in the wild, add it.
>
> Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
> Suggested-by: Matti Vaittinen <mazziesaccount@gmail.com>
> ---
> Documentation/devicetree/bindings/mfd/rohm,bd71828-pmic.yaml | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/mfd/rohm,bd71828-pmic.yaml b/Documentation/devicetree/bindings/mfd/rohm,bd71828-pmic.yaml
> index 0b62f854bf6b..e4df09e8961c 100644
> --- a/Documentation/devicetree/bindings/mfd/rohm,bd71828-pmic.yaml
> +++ b/Documentation/devicetree/bindings/mfd/rohm,bd71828-pmic.yaml
> @@ -17,7 +17,9 @@ description: |
>
> properties:
> compatible:
> - const: rohm,bd71828
> + enum:
> + - rohm,bd71828
> + - rohm,bd71879
In your second commit you claim they are compatible, so why they are not
marked as such?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: iio: imu: add icm42688 inside inv_icm42600
From: Krzysztof Kozlowski @ 2024-04-04 7:03 UTC (permalink / raw)
To: inv.git-commit, jic23, robh, krzysztof.kozlowski+dt, conor+dt
Cc: lars, linux-iio, devicetree, Jean-Baptiste Maneyrol
In-Reply-To: <20240402090046.764572-2-inv.git-commit@tdk.com>
On 02/04/2024 11:00, inv.git-commit@tdk.com wrote:
> From: Jean-Baptiste Maneyrol <jean-baptiste.maneyrol@tdk.com>
>
> Add bindings for ICM-42688-P chip.
>
> Signed-off-by: Jean-Baptiste Maneyrol <jean-baptiste.maneyrol@tdk.com>
> ---
> .../devicetree/bindings/iio/imu/invensense,icm42600.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/iio/imu/invensense,icm42600.yaml b/Documentation/devicetree/bindings/iio/imu/invensense,icm42600.yaml
> index 7cd05bcbee31..5e0bed2c45de 100644
> --- a/Documentation/devicetree/bindings/iio/imu/invensense,icm42600.yaml
> +++ b/Documentation/devicetree/bindings/iio/imu/invensense,icm42600.yaml
> @@ -32,6 +32,7 @@ properties:
> - invensense,icm42605
> - invensense,icm42622
> - invensense,icm42631
> + - invensense,icm42688
>
> reg:
> maxItems: 1
> --
> 2.34.1
>
> TDK-Micronas GmbH
> Company Headquarters / Sitz der Gesellschaft: Freiburg i. Br. - Municipal Court of / Amtsgericht: Freiburg i. Br. HRB 6108. VAT ID / USt-IdNr.: DE 812878184
> Management / Geschäftsführung: Sam Maddalena
>
> This e-mail and any files transmitted with it are confidential information of TDK-Micronas and intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error please notify the sender by return e-mail and delete all copies of this e-mail message along with all attachments. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.
Don't send patches which are confidential. Community cannot take them.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 2/2] iio: imu: inv_icm42600: add support of ICM-42688-P
From: Krzysztof Kozlowski @ 2024-04-04 7:04 UTC (permalink / raw)
To: inv.git-commit, jic23, robh, krzysztof.kozlowski+dt, conor+dt
Cc: lars, linux-iio, devicetree, Jean-Baptiste Maneyrol
In-Reply-To: <20240402090046.764572-3-inv.git-commit@tdk.com>
On 02/04/2024 11:00, inv.git-commit@tdk.com wrote:
> From: Jean-Baptiste Maneyrol <jean-baptiste.maneyrol@tdk.com>
>
Missing commit msg explaining why/what is happening.
> Signed-off-by: Jean-Baptiste Maneyrol <jean-baptiste.maneyrol@tdk.com>
> ---
> drivers/iio/imu/inv_icm42600/inv_icm42600.h | 2 ++
> drivers/iio/imu/inv_icm42600/inv_icm42600_core.c | 5 +++++
> drivers/iio/imu/inv_icm42600/inv_icm42600_i2c.c | 3 +++
> drivers/iio/imu/inv_icm42600/inv_icm42600_spi.c | 3 +++
> 4 files changed, 13 insertions(+)
> 2.34.1
>
> TDK-Micronas GmbH
> Company Headquarters / Sitz der Gesellschaft: Freiburg i. Br. - Municipal Court of / Amtsgericht: Freiburg i. Br. HRB 6108. VAT ID / USt-IdNr.: DE 812878184
> Management / Geschäftsführung: Sam Maddalena
>
> This e-mail and any files transmitted with it are confidential information of TDK-Micronas and intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error please notify the sender by return e-mail and delete all copies of this e-mail message along with all attachments. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.
Sorry, we cannot work with confidential IP. You also made public your
company confidential data, so it looks bad. Please double check it with
your company legal department.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v7 00/37] Device Tree support for SH7751 based board
From: Niklas Cassel @ 2024-04-04 7:06 UTC (permalink / raw)
To: Yoshinori Sato
Cc: linux-sh, Damien Le Moal, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Geert Uytterhoeven, Michael Turquette, Stephen Boyd,
David Airlie, Daniel Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Thomas Gleixner, Bjorn Helgaas,
Lorenzo Pieralisi, Krzysztof Wilczyński, Greg Kroah-Hartman,
Jiri Slaby, Magnus Damm, Daniel Lezcano, Rich Felker,
John Paul Adrian Glaubitz, Lee Jones, Helge Deller,
Heiko Stuebner, Shawn Guo, Sebastian Reichel, Chris Morgan,
Linus Walleij, Arnd Bergmann, David Rientjes, Hyeonggon Yoo,
Vlastimil Babka, Baoquan He, Andrew Morton, Guenter Roeck,
Kefeng Wang, Stephen Rothwell, Javier Martinez Canillas, Guo Ren,
Azeem Shaikh, Max Filippov, Jonathan Corbet, Jacky Huang,
Herve Codina, Manikanta Guntupalli, Anup Patel, Biju Das,
Uwe Kleine-König, Sam Ravnborg, Sergey Shtylyov,
Laurent Pinchart, linux-ide, devicetree, linux-kernel,
linux-renesas-soc, linux-clk, dri-devel, linux-pci, linux-serial,
linux-fbdev
In-Reply-To: <cover.1712205900.git.ysato@users.sourceforge.jp>
On Thu, Apr 04, 2024 at 01:59:25PM +0900, Yoshinori Sato wrote:
> This is an updated version of something I wrote about 7 years ago.
> Minimum support for R2D-plus and LANDISK.
> I think R2D-1 will work if you add AX88796 to dts.
> And board-specific functions and SCI's SPI functions are not supported.
>
> You can get it working with qemu found here.
> https://gitlab.com/yoshinori.sato/qemu/-/tree/landisk
Why send this as one huge series?
These are the mailing lists that you have on CC:
linux-ide, devicetree, linux-kernel,
linux-renesas-soc, linux-clk, dri-devel,
linux-pci, linux-serial, linux-fbdev
I really think that you will be able to get all these changes accepted much
faster if you split this series in to one series per subsystem/mailing list.
Kind regards,
Niklas
^ permalink raw reply
* Re: [PATCH v3 23/25] drivers: media: i2c: imx258: Add support for powerdown gpio
From: Sakari Ailus @ 2024-04-04 7:07 UTC (permalink / raw)
To: Ondřej Jirman, git, linux-media, dave.stevenson,
jacopo.mondi, mchehab, robh, krzysztof.kozlowski+dt, conor+dt,
shawnguo, s.hauer, kernel, festevam, devicetree, imx,
linux-arm-kernel, linux-kernel, pavel, phone-devel
In-Reply-To: <wjlcde7yoooygj4hhdmiwrdloh6l4p6i2qbmjek5uwsifyzwgu@xjhutvmsdfou>
Hi Ondřej,
On Wed, Apr 03, 2024 at 06:57:56PM +0200, Ondřej Jirman wrote:
> Hi Sakari and Luis,
>
> On Wed, Apr 03, 2024 at 04:25:41PM GMT, Sakari Ailus wrote:
> > Hi Luis, Ondrej,
> >
> > On Wed, Apr 03, 2024 at 09:03:52AM -0600, git@luigi311.com wrote:
> > > From: Luis Garcia <git@luigi311.com>
> > >
> > > On some boards powerdown signal needs to be deasserted for this
> > > sensor to be enabled.
> > >
> > > Signed-off-by: Ondrej Jirman <megi@xff.cz>
> > > Signed-off-by: Luis Garcia <git@luigi311.com>
> > > ---
> > > drivers/media/i2c/imx258.c | 13 +++++++++++++
> > > 1 file changed, 13 insertions(+)
> > >
> > > diff --git a/drivers/media/i2c/imx258.c b/drivers/media/i2c/imx258.c
> > > index 30352c33f63c..163f04f6f954 100644
> > > --- a/drivers/media/i2c/imx258.c
> > > +++ b/drivers/media/i2c/imx258.c
> > > @@ -679,6 +679,8 @@ struct imx258 {
> > > unsigned int lane_mode_idx;
> > > unsigned int csi2_flags;
> > >
> > > + struct gpio_desc *powerdown_gpio;
> > > +
> > > /*
> > > * Mutex for serialized access:
> > > * Protect sensor module set pad format and start/stop streaming safely.
> > > @@ -1213,6 +1215,8 @@ static int imx258_power_on(struct device *dev)
> > > struct imx258 *imx258 = to_imx258(sd);
> > > int ret;
> > >
> > > + gpiod_set_value_cansleep(imx258->powerdown_gpio, 0);
> >
> > What does the spec say? Should this really happen before switching on the
> > supplies below?
>
> There's no powerdown input in the IMX258 manual. The manual only mentions
> that XCLR (reset) should be held low during power on.
>
> https://megous.com/dl/tmp/15b0992a720ab82d.png
>
> https://megous.com/dl/tmp/f2cc991046d97641.png
>
> This sensor doesn’t have a built-in “Power ON Reset” function. The XCLR pin
> is set to “LOW” and the power supplies are brought up. Then the XCLR pin
> should be set to “High” after INCK supplied.
>
> So this input is some feature on camera module itself outside of the
> IMX258 chip, which I think is used to gate power to the module. Eg. on Pinephone
> Pro, there are two modules with shared power rails, so enabling supply to
> one module enables it to the other one, too. So this input becomes the only way
> to really enable/disable power to the chip when both are used at once at some
> point, because regulator_bulk_enable/disable becomes ineffective at that point.
The hardware designers sometimes do not consider the difficulty of
implementing software support for their choice of design. Maybe this could
be modelled as a GPIO regulator? But it'd depend on another regulator and
I'm not sure that is covered.
The camera sensor generally consume very little power in software standby
mode so the potential saving here are probably irrelevant.
>
> Luis, maybe you saw some other datasheet that mentions this input? IMO,
> it just gates the power rails via some mosfets on the module itself, since
> there's not power down input to the chip itself.
>
> kind regards,
> o.
>
> > > +
> > > ret = regulator_bulk_enable(IMX258_NUM_SUPPLIES,
> > > imx258->supplies);
> > > if (ret) {
> > > @@ -1224,6 +1228,7 @@ static int imx258_power_on(struct device *dev)
> > > ret = clk_prepare_enable(imx258->clk);
> > > if (ret) {
> > > dev_err(dev, "failed to enable clock\n");
> > > + gpiod_set_value_cansleep(imx258->powerdown_gpio, 1);
> > > regulator_bulk_disable(IMX258_NUM_SUPPLIES, imx258->supplies);
> > > }
> > >
> > > @@ -1238,6 +1243,8 @@ static int imx258_power_off(struct device *dev)
> > > clk_disable_unprepare(imx258->clk);
> > > regulator_bulk_disable(IMX258_NUM_SUPPLIES, imx258->supplies);
> > >
> > > + gpiod_set_value_cansleep(imx258->powerdown_gpio, 1);
> > > +
> > > return 0;
> > > }
> > >
> > > @@ -1541,6 +1548,12 @@ static int imx258_probe(struct i2c_client *client)
> > > if (!imx258->variant_cfg)
> > > imx258->variant_cfg = &imx258_cfg;
> > >
> > > + /* request optional power down pin */
> > > + imx258->powerdown_gpio = devm_gpiod_get_optional(&client->dev, "powerdown",
> > > + GPIOD_OUT_HIGH);
> > > + if (IS_ERR(imx258->powerdown_gpio))
> > > + return PTR_ERR(imx258->powerdown_gpio);
> > > +
> > > /* Initialize subdev */
> > > v4l2_i2c_subdev_init(&imx258->sd, client, &imx258_subdev_ops);
> > >
> >
> > --
> > Regards,
> >
> > Sakari Ailus
--
Regards,
Sakari Ailus
^ permalink raw reply
* Re: [PATCH v19 2/9] usb: dwc3: core: Access XHCI address space temporarily to read port info
From: Johan Hovold @ 2024-04-04 7:21 UTC (permalink / raw)
To: Krishna Kurapati
Cc: Krzysztof Kozlowski, Rob Herring, Bjorn Andersson, Wesley Cheng,
Konrad Dybcio, Greg Kroah-Hartman, Conor Dooley, Thinh Nguyen,
Felipe Balbi, devicetree, linux-arm-msm, linux-usb, linux-kernel,
quic_ppratap, quic_jackp, Johan Hovold
In-Reply-To: <20240404051229.3082902-3-quic_kriskura@quicinc.com>
On Thu, Apr 04, 2024 at 10:42:22AM +0530, Krishna Kurapati wrote:
> +static int dwc3_get_num_ports(struct dwc3 *dwc)
> +{
> + void __iomem *base;
> + u8 major_revision;
> + u32 offset;
> + u32 val;
> +
> + /*
> + * Remap xHCI address space to access XHCI ext cap regs since it is
> + * needed to get information on number of ports present.
> + */
> + base = ioremap(dwc->xhci_resources[0].start,
> + resource_size(&dwc->xhci_resources[0]));
> + if (!base)
> + return PTR_ERR(base);
This is obviously still broken. You need to update the return value as
well.
Fix in v20.
Johan
^ permalink raw reply
* Re: [RFC PATCH 0/6] Support ROHM BD96801 scalable PMIC
From: Matti Vaittinen @ 2024-04-04 7:26 UTC (permalink / raw)
To: Matti Vaittinen
Cc: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Liam Girdwood, Mark Brown, Wim Van Sebroeck, Guenter Roeck,
devicetree, linux-kernel, linux-watchdog
In-Reply-To: <cover.1712058690.git.mazziesaccount@gmail.com>
On 4/2/24 16:07, Matti Vaittinen wrote:
> Another "oddity" is that the PMIC has two physical IRQ lines. When I
> last wrote this patch in 2021 I had some naming collison in debugfs for
> the IRQ domains. Back then I used:
> irq_domain_update_bus_token(intb_domain, DOMAIN_BUS_WIRED);
> to work-around the issue. Now, when rebasing to v6.9-rc1 the naming
> collision was gone and things seemed to work. However, it'd be great if
> the IRQ code in MFD driver was reviewed by greater minds :)
It appears my statement "things seemed to work" is a bit too optimistic.
I am afraid my approach of having two separate IRQ domains for one
device (and DT-node) is just somehow fundamentally wrong. It'd be great
to learn what's the correct "ideology" here.
It appears the naming collision is still there. My config just had the
CONFIG_GENERIC_IRQ_DEBUGFS disabled. Enabling it shows the same naming
collison:
debugfs: File
':ocp:interconnect@48000000:segment@100000:target-module@9c000:i2c@0:pmic@60'
in directory 'domains' already present!
If I'm not mistaken the debugfs file name is generated from the
device-tree node path+name. This is a subtle hint that it is not
expected there are more than 1 IRQ-domain / device. I guess this kind of
makes sense if we can have more than 1 HWIRQ handled by a single domain
(I don't recall having to ever write such domain/IRQ-controller before,
but I think it should be possible).
I have now 3 new questions =)
1. Should we be able to have more than 1 IRQ domain / device?
2. Should regmap_irq support having more than 1 HWIRQ
3. If answer to 1 is "no" - should we protect against this somehow? (see
why below).
When CONFIG_GENERIC_IRQ_DEBUGFS is disabled, adding the two IRQ
controllers with own IRQ domains (intb and errb here) to a single device
is seemingly successful. I see no complaints / errors. Also, most of the
IRQs seem to work - but not all. In my case trying to issue:
cat /proc/interrupts
will oops. Also, looking in the /sys/kernel/irq/ lists folders for all
the "intb" and "errb" IRQs - but reading the files contained in these
directories will cause an oops for all "errb" interrupts except for the
first 16.
Finally, if I use the
irq_domain_update_bus_token(intb_domain, DOMAIN_BUS_WIRED);
to add "-1" at the end of the "intb" - domain name resulting domains:
:ocp:interconnect@48000000:segment@100000:target-module@9c000:i2c@0:pmic@60
:ocp:interconnect@48000000:segment@100000:target-module@9c000:i2c@0:pmic@60-1
then it seems that reading the IRQ information from the /proc/interrupts
works as expected. Here I am making a wild guess that the name of the
domain is used as a key for some data-lookups, and having two domains
with a same name will either overwrite something or cause wrong domain
data to be fetched. (This is just guessing for now).
Any tips, hints or thoughts on this?
Yours,
-- Matti
--
Matti Vaittinen
Linux kernel developer at ROHM Semiconductors
Oulu Finland
~~ When things go utterly wrong vim users can always type :help! ~~
^ permalink raw reply
* [PATCH] clk: rockchip: clk-rk3568.c: Add missing USB480M_PHY mux
From: Sascha Hauer @ 2024-04-04 7:27 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Heiko Stuebner, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-clk, linux-arm-kernel, linux-rockchip, linux-kernel,
devicetree, David Jander, Sascha Hauer
From: David Jander <david@protonic.nl>
The USB480M clock can source from a MUX that selects the clock to come
from either of the USB-phy internal 480MHz PLLs. These clocks are
provided by the USB phy driver.
Signed-off-by: David Jander <david@protonic.nl>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
drivers/clk/rockchip/clk-rk3568.c | 4 ++++
include/dt-bindings/clock/rk3568-cru.h | 1 +
2 files changed, 5 insertions(+)
diff --git a/drivers/clk/rockchip/clk-rk3568.c b/drivers/clk/rockchip/clk-rk3568.c
index 8cb21d10beca2..2d44bcaef046b 100644
--- a/drivers/clk/rockchip/clk-rk3568.c
+++ b/drivers/clk/rockchip/clk-rk3568.c
@@ -215,6 +215,7 @@ static const struct rockchip_cpuclk_reg_data rk3568_cpuclk_data = {
PNAME(mux_pll_p) = { "xin24m" };
PNAME(mux_usb480m_p) = { "xin24m", "usb480m_phy", "clk_rtc_32k" };
+PNAME(mux_usb480m_phy_p) = { "clk_usbphy0_480m", "clk_usbphy1_480m"};
PNAME(mux_armclk_p) = { "apll", "gpll" };
PNAME(clk_i2s0_8ch_tx_p) = { "clk_i2s0_8ch_tx_src", "clk_i2s0_8ch_tx_frac", "i2s0_mclkin", "xin_osc0_half" };
PNAME(clk_i2s0_8ch_rx_p) = { "clk_i2s0_8ch_rx_src", "clk_i2s0_8ch_rx_frac", "i2s0_mclkin", "xin_osc0_half" };
@@ -485,6 +486,9 @@ static struct rockchip_clk_branch rk3568_clk_branches[] __initdata = {
MUX(USB480M, "usb480m", mux_usb480m_p, CLK_SET_RATE_PARENT,
RK3568_MODE_CON0, 14, 2, MFLAGS),
+ MUX(USB480M_PHY, "usb480m_phy", mux_usb480m_phy_p, CLK_SET_RATE_PARENT,
+ RK3568_MISC_CON2, 15, 1, MFLAGS),
+
/* PD_CORE */
COMPOSITE(0, "sclk_core_src", apll_gpll_npll_p, CLK_IGNORE_UNUSED,
RK3568_CLKSEL_CON(2), 8, 2, MFLAGS, 0, 4, DFLAGS | CLK_DIVIDER_READ_ONLY,
diff --git a/include/dt-bindings/clock/rk3568-cru.h b/include/dt-bindings/clock/rk3568-cru.h
index d29890865150d..5263085c5b238 100644
--- a/include/dt-bindings/clock/rk3568-cru.h
+++ b/include/dt-bindings/clock/rk3568-cru.h
@@ -78,6 +78,7 @@
#define CPLL_333M 9
#define ARMCLK 10
#define USB480M 11
+#define USB480M_PHY 12
#define ACLK_CORE_NIU2BUS 18
#define CLK_CORE_PVTM 19
#define CLK_CORE_PVTM_CORE 20
---
base-commit: 39cd87c4eb2b893354f3b850f916353f2658ae6f
change-id: 20240404-clk-rockchip-rk3568-add-usb480m-phy-mux-882e40565a26
Best regards,
--
Sascha Hauer <s.hauer@pengutronix.de>
^ permalink raw reply related
* Re: [PATCH v2] arm64: dts: debix-a: Disable i2c2 in base .dts
From: Marco Felsch @ 2024-04-04 7:42 UTC (permalink / raw)
To: Laurent Pinchart
Cc: devicetree, imx, linux-arm-kernel, Rob Herring, Jacopo Mondi,
Pengutronix Kernel Team, Shawn Guo, Sascha Hauer, Conor Dooley,
Krzysztof Kozlowski, Jacopo Mondi, Fabio Estevam
In-Reply-To: <20240404002009.10052-1-laurent.pinchart@ideasonboard.com>
On 24-04-04, Laurent Pinchart wrote:
> From: Jacopo Mondi <jacopo@jmondi.org>
>
> The I2C2 bus is used for the CSI and DSI connectors only, no devices are
> connected to it on neither the Debix Model A nor its IO board. Disable
> the bus in the board's .dts and remove its clock frequency settings, as
> the value depends solely on the devices conncted to the CSI and DSI
> connectors. Display panel or camera sensor overlays will configure and
> enable the bus when necessary.
>
> Signed-off-by: Jacopo Mondi <jacopo@jmondi.org>
> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Marco Felsch <m.felsch@pengutronix.de>
^ permalink raw reply
* Re: [PATCH v4 0/8] cpufreq: sun50i: Add Allwinner H616 support
From: Ryan Walklin @ 2024-04-04 7:44 UTC (permalink / raw)
To: Viresh Kumar, Andre Przywara
Cc: Yangtao Li, Viresh Kumar, Nishanth Menon, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland, Rafael J . Wysocki, linux-pm,
devicetree, linux-sunxi, linux-arm-kernel, Brandon Cheo Fusi,
Martin Botka, Martin Botka, Chris Morgan, Mark Rutland,
Lorenzo Pieralisi, Sudeep Holla
In-Reply-To: <20240404064027.shjqvqih7s5rnv2i@vireshk-i7>
On Thu, 4 Apr 2024, at 7:40 PM, Viresh Kumar wrote:
> Is it okay to merge all the changes via the cpufreq tree ?
I have tested this series with an H700-based board, and have at least one speed-bin (1.032GHz) is not supported although the governor attempts to enable it based on the opp-supported-hw bitmask, and I am unable to reach the 1.5GHz bin at 1.16v (or higher) despite it working on the vendor BSP (kernel panic at boot if enabled), so this may need some slight rework.
I have reached out to Andre on IRC to debug.
Ryan
^ permalink raw reply
* RE: [PATCH v2 2/5] irqchip/renesas-rzg2l: Add support for RZ/Five SoC
From: Biju Das @ 2024-04-04 7:44 UTC (permalink / raw)
To: Prabhakar, Geert Uytterhoeven, Thomas Gleixner, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Magnus Damm, Paul Walmsley,
Palmer Dabbelt, Albert Ou
Cc: linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
linux-renesas-soc@vger.kernel.org,
linux-riscv@lists.infradead.org, Prabhakar Mahadev Lad
In-Reply-To: <20240403203503.634465-3-prabhakar.mahadev-lad.rj@bp.renesas.com>
Hi Prabhakar,
Thanks for the patch.
> -----Original Message-----
> From: Prabhakar <prabhakar.csengg@gmail.com>
> Sent: Wednesday, April 3, 2024 9:35 PM
> Subject: [PATCH v2 2/5] irqchip/renesas-rzg2l: Add support for RZ/Five SoC
>
> From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
>
> The IX45 block has additional mask registers (NMSK/IMSK/TMSK) as compared to the RZ/G2L (family)
> SoC.
>
> Introduce masking/unmasking support for IRQ and TINT interrupts in IRQC controller driver. Two new
> registers, IMSK and TMSK, are defined to handle masking on RZ/Five SoC. The implementation utilizes
> a new data structure, `struct rzg2l_irqc_data`, to determine mask support for a specific controller
> instance.
>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> ---
> v1->v2
> - Added IRQCHIP_MATCH() for RZ/Five
> - Retaining a copy of OF data in priv
> - Rebased the changes
> ---
> drivers/irqchip/irq-renesas-rzg2l.c | 137 +++++++++++++++++++++++++++-
> 1 file changed, 132 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/irqchip/irq-renesas-rzg2l.c b/drivers/irqchip/irq-renesas-rzg2l.c
> index f6484bf15e0b..6fa8d65605dc 100644
> --- a/drivers/irqchip/irq-renesas-rzg2l.c
> +++ b/drivers/irqchip/irq-renesas-rzg2l.c
> @@ -37,6 +37,8 @@
> #define TSSEL_SHIFT(n) (8 * (n))
> #define TSSEL_MASK GENMASK(7, 0)
> #define IRQ_MASK 0x3
> +#define IMSK 0x10010
> +#define TMSK 0x10020
>
> #define TSSR_OFFSET(n) ((n) % 4)
> #define TSSR_INDEX(n) ((n) / 4)
> @@ -66,15 +68,25 @@ struct rzg2l_irqc_reg_cache {
> u32 titsr[2];
> };
>
> +/**
> + * struct rzg2l_irqc_of_data - OF data structure
> + * @mask_supported: Indicates if mask registers are available */
> +struct rzg2l_irqc_of_data {
> + bool mask_supported;
> +};
> +
> /**
> * struct rzg2l_irqc_priv - IRQ controller private data structure
> * @base: Controller's base address
> + * @data: OF data pointer
> * @fwspec: IRQ firmware specific data
> * @lock: Lock to serialize access to hardware registers
> * @cache: Registers cache for suspend/resume
> */
> static struct rzg2l_irqc_priv {
> void __iomem *base;
> + const struct rzg2l_irqc_of_data *data;
> struct irq_fwspec fwspec[IRQC_NUM_IRQ];
> raw_spinlock_t lock;
> struct rzg2l_irqc_reg_cache cache;
> @@ -138,18 +150,102 @@ static void rzg2l_irqc_eoi(struct irq_data *d)
> irq_chip_eoi_parent(d);
> }
>
> +static void rzg2l_irqc_mask_irq_interrupt(struct rzg2l_irqc_priv *priv,
> + unsigned int hwirq)
> +{
> + u32 imsk = readl_relaxed(priv->base + IMSK);
> + u32 bit = BIT(hwirq - IRQC_IRQ_START);
> +
> + writel_relaxed(imsk | bit, priv->base + IMSK); }
> +
> +static void rzg2l_irqc_unmask_irq_interrupt(struct rzg2l_irqc_priv *priv,
> + unsigned int hwirq)
> +{
> + u32 imsk = readl_relaxed(priv->base + IMSK);
> + u32 bit = BIT(hwirq - IRQC_IRQ_START);
> +
> + writel_relaxed(imsk & ~bit, priv->base + IMSK); }
> +
> +static void rzg2l_irqc_mask_tint_interrupt(struct rzg2l_irqc_priv *priv,
> + unsigned int hwirq)
> +{
> + u32 tmsk = readl_relaxed(priv->base + TMSK);
> + u32 bit = BIT(hwirq - IRQC_TINT_START);
> +
> + writel_relaxed(tmsk | bit, priv->base + TMSK); }
> +
> +static void rzg2l_irqc_unmask_tint_interrupt(struct rzg2l_irqc_priv *priv,
> + unsigned int hwirq)
> +{
> + u32 tmsk = readl_relaxed(priv->base + TMSK);
> + u32 bit = BIT(hwirq - IRQC_TINT_START);
> +
> + writel_relaxed(tmsk & ~bit, priv->base + TMSK); }
> +
> +/* Must be called while priv->lock is held */ static void
> +rzg2l_irqc_mask_once(struct rzg2l_irqc_priv *priv, unsigned int hwirq)
> +{
> + if (!priv->data->mask_supported)
> + return;
> +
> + if (hwirq >= IRQC_IRQ_START && hwirq <= IRQC_IRQ_COUNT)
> + rzg2l_irqc_mask_irq_interrupt(priv, hwirq);
> + else if (hwirq >= IRQC_TINT_START && hwirq < IRQC_NUM_IRQ)
> + rzg2l_irqc_mask_tint_interrupt(priv, hwirq); }
> +
> +static void rzg2l_irqc_mask(struct irq_data *d) {
> + struct rzg2l_irqc_priv *priv = irq_data_to_priv(d);
> +
> + raw_spin_lock(&priv->lock);
> + rzg2l_irqc_mask_once(priv, irqd_to_hwirq(d));
> + raw_spin_unlock(&priv->lock);
> + irq_chip_mask_parent(d);
> +}
> +
> +/* Must be called while priv->lock is held */ static void
> +rzg2l_irqc_unmask_once(struct rzg2l_irqc_priv *priv, unsigned int
> +hwirq) {
> + if (!priv->data->mask_supported)
> + return;
> +
> + if (hwirq >= IRQC_IRQ_START && hwirq <= IRQC_IRQ_COUNT)
> + rzg2l_irqc_unmask_irq_interrupt(priv, hwirq);
> + else if (hwirq >= IRQC_TINT_START && hwirq < IRQC_NUM_IRQ)
> + rzg2l_irqc_unmask_tint_interrupt(priv, hwirq); }
> +
> +static void rzg2l_irqc_unmask(struct irq_data *d) {
> + struct rzg2l_irqc_priv *priv = irq_data_to_priv(d);
> +
> + raw_spin_lock(&priv->lock);
> + rzg2l_irqc_unmask_once(priv, irqd_to_hwirq(d));
> + raw_spin_unlock(&priv->lock);
> + irq_chip_unmask_parent(d);
> +}
> +
> static void rzg2l_tint_irq_endisable(struct irq_data *d, bool enable) {
> + struct rzg2l_irqc_priv *priv = irq_data_to_priv(d);
> unsigned int hw_irq = irqd_to_hwirq(d);
>
> if (hw_irq >= IRQC_TINT_START && hw_irq < IRQC_NUM_IRQ) {
> - struct rzg2l_irqc_priv *priv = irq_data_to_priv(d);
> u32 offset = hw_irq - IRQC_TINT_START;
> u32 tssr_offset = TSSR_OFFSET(offset);
> u8 tssr_index = TSSR_INDEX(offset);
> u32 reg;
>
> raw_spin_lock(&priv->lock);
> + if (enable)
> + rzg2l_irqc_unmask_once(priv, hw_irq);
> + else
> + rzg2l_irqc_mask_once(priv, hw_irq);
> reg = readl_relaxed(priv->base + TSSR(tssr_index));
> if (enable)
> reg |= TIEN << TSSEL_SHIFT(tssr_offset); @@ -157,6 +253,13 @@ static void
> rzg2l_tint_irq_endisable(struct irq_data *d, bool enable)
> reg &= ~(TIEN << TSSEL_SHIFT(tssr_offset));
> writel_relaxed(reg, priv->base + TSSR(tssr_index));
> raw_spin_unlock(&priv->lock);
> + } else {
> + raw_spin_lock(&priv->lock);
> + if (enable)
> + rzg2l_irqc_unmask_once(priv, hw_irq);
> + else
> + rzg2l_irqc_mask_once(priv, hw_irq);
> + raw_spin_unlock(&priv->lock);
> }
> }
>
> @@ -324,8 +427,8 @@ static struct syscore_ops rzg2l_irqc_syscore_ops = { static const struct
> irq_chip irqc_chip = {
> .name = "rzg2l-irqc",
> .irq_eoi = rzg2l_irqc_eoi,
> - .irq_mask = irq_chip_mask_parent,
> - .irq_unmask = irq_chip_unmask_parent,
> + .irq_mask = rzg2l_irqc_mask,
> + .irq_unmask = rzg2l_irqc_unmask,
I feel this will be clean, if we have
static const struct irq_chip rzg2l_irqc_chip = {
.name = "rzg2l-irqc",
...
.irq_mask = irq_chip_mask_parent,
.irq_unmask = irq_chip_unmask_parent,
....
};
static const struct irq_chip rzfive_irqc_chip = {
.name = "rzfive-irqc",
...
.irq_mask = rzfive_irqc_mask,
.irq_unmask = rzfive_irqc_unmask,
....
};
And passing this in rzg2l_irqc_init() and rzfive_irqc_init(), see below
return rzg2l_irqc_init_helper(node, parent, & rzg2l_irqc_chip);
return rzg2l_irqc_init_helper(node, parent, & rzfive_irqc_chip);
> .irq_disable = rzg2l_irqc_irq_disable,
> .irq_enable = rzg2l_irqc_irq_enable,
> .irq_get_irqchip_state = irq_chip_get_parent_state,
> @@ -401,7 +504,16 @@ static int rzg2l_irqc_parse_interrupts(struct rzg2l_irqc_priv *priv,
> return 0;
> }
>
> -static int rzg2l_irqc_init(struct device_node *node, struct device_node *parent)
> +static const struct rzg2l_irqc_of_data rzg2l_irqc_mask_supported_data = {
> + .mask_supported = true,
> +};
> +
> +static const struct rzg2l_irqc_of_data rzg2l_irqc_default_data = {
> + .mask_supported = false,
> +};
> +
> +static int rzg2l_irqc_init(struct device_node *node, struct device_node *parent,
> + const struct rzg2l_irqc_of_data *of_data)
Maybe rename this as rzg2l_irqc_init_helper()
> {
> struct irq_domain *irq_domain, *parent_domain;
> struct platform_device *pdev;
> @@ -422,6 +534,8 @@ static int rzg2l_irqc_init(struct device_node *node, struct device_node
> *parent)
> if (!rzg2l_irqc_data)
> return -ENOMEM;
>
> + rzg2l_irqc_data->data = of_data;
> +
> rzg2l_irqc_data->base = devm_of_iomap(&pdev->dev, pdev->dev.of_node, 0, NULL);
> if (IS_ERR(rzg2l_irqc_data->base))
> return PTR_ERR(rzg2l_irqc_data->base); @@ -472,8 +586,21 @@ static int
> rzg2l_irqc_init(struct device_node *node, struct device_node *parent)
> return ret;
> }
>
> +static int __init rzg2l_irqc_default_init(struct device_node *node,
> + struct device_node *parent)
> +{
> + return rzg2l_irqc_init(node, parent, &rzg2l_irqc_default_data); }
> +
> +static int __init rzg2l_irqc_mask_supported_init(struct device_node *node,
> + struct device_node *parent)
> +{
> + return rzg2l_irqc_init(node, parent, &rzg2l_irqc_mask_supported_data);
> +}
> +
> IRQCHIP_PLATFORM_DRIVER_BEGIN(rzg2l_irqc)
> -IRQCHIP_MATCH("renesas,rzg2l-irqc", rzg2l_irqc_init)
Retain this name
> +IRQCHIP_MATCH("renesas,rzg2l-irqc", rzg2l_irqc_default_init)
> +IRQCHIP_MATCH("renesas,r9a07g043f-irqc",
> +rzg2l_irqc_mask_supported_init)
Maybe rename this as rzfive_irqc_init ??
Cheers,
Biju
> IRQCHIP_PLATFORM_DRIVER_END(rzg2l_irqc)
> MODULE_AUTHOR("Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>");
> MODULE_DESCRIPTION("Renesas RZ/G2L IRQC Driver");
> --
> 2.34.1
>
^ permalink raw reply
* Re: [PATCH v2] arm64: dts: ti: k3-j722s-evm: Enable eMMC support
From: Francesco Dolcini @ 2024-04-04 7:45 UTC (permalink / raw)
To: Michael Walle
Cc: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-arm-kernel, devicetree,
linux-kernel
In-Reply-To: <20240403102302.3934932-1-mwalle@kernel.org>
Hello Michael,
On Wed, Apr 03, 2024 at 12:23:02PM +0200, Michael Walle wrote:
> The J722S EVM has an on-board eMMC. Enable the SDHC interface for it.
> There is no pinmuxing required because the interface has dedicated pins.
>
> Signed-off-by: Michael Walle <mwalle@kernel.org>
> ---
> v2:
> - move status="okay" last
> ---
> arch/arm64/boot/dts/ti/k3-j722s-evm.dts | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/ti/k3-j722s-evm.dts b/arch/arm64/boot/dts/ti/k3-j722s-evm.dts
> index cee3a8661d5e..6b148da2bcdc 100644
> --- a/arch/arm64/boot/dts/ti/k3-j722s-evm.dts
> +++ b/arch/arm64/boot/dts/ti/k3-j722s-evm.dts
> @@ -369,6 +369,13 @@ partition@3fc0000 {
>
> };
>
> +&sdhci0 {
> + ti,driver-strength-ohm = <50>;
According to the latest DTS coding style guidelines this needs to be
just before status.
https://docs.kernel.org/devicetree/bindings/dts-coding-style.html#order-of-properties-in-device-node
Yes, we would need a checker, I know and I agree. At least now we moved
out of the tribal knowledge way of working with every maintainer having
slightly different expectation on this topic ... one step at a time :-)
> + disable-wp;
> + bootph-all;
> + status = "okay";
> +};
Francesco
^ permalink raw reply
* Re: [RESEND v7 19/37] dt-bindings: interrupt-controller: renesas,sh7751-irl-ext: Add json-schema
From: Rob Herring @ 2024-04-04 7:45 UTC (permalink / raw)
To: Yoshinori Sato
Cc: Andrew Morton, Michael Turquette, Laurent Pinchart, linux-ide,
Bjorn Helgaas, Lee Jones, linux-kernel, Sam Ravnborg,
Stephen Boyd, linux-sh, linux-renesas-soc, Thomas Gleixner,
Sergey Shtylyov, Krzysztof Kozlowski, Linus Walleij,
Krzysztof Wilczyński, devicetree, Helge Deller, dri-devel,
Jonathan Corbet, Biju Das, Guenter Roeck, Daniel Lezcano,
Damien Le Moal, Hyeonggon Yoo, Anup Patel, Maxime Ripard,
Chris Morgan, Jiri Slaby, Uwe Kleine-König,
Thomas Zimmermann, Javier Martinez Canillas, David Rientjes,
Azeem Shaikh, Conor Dooley, Arnd Bergmann, Rich Felker,
linux-fbdev, Stephen Rothwell, John Paul Adrian Glaubitz,
Daniel Vetter, linux-serial, linux-pci, Niklas Cassel,
Sebastian Reichel, Max Filippov, Manikanta Guntupalli, Guo Ren,
Jacky Huang, linux-clk, David Airlie, Magnus Damm,
Geert Uytterhoeven, Maarten Lankhorst, Herve Codina,
Vlastimil Babka, Greg Kroah-Hartman, Shawn Guo, Heiko Stuebner,
Baoquan He, Kefeng Wang, Lorenzo Pieralisi
In-Reply-To: <8d8dec2d75890f3a14632c9606c332fb11d89a95.1712207606.git.ysato@users.sourceforge.jp>
On Thu, 04 Apr 2024 14:14:30 +0900, Yoshinori Sato wrote:
> Renesas SH7751 external interrupt encoder json-schema.
>
> Signed-off-by: Yoshinori Sato <ysato@users.sourceforge.jp>
> ---
> .../renesas,sh7751-irl-ext.yaml | 57 +++++++++++++++++++
> 1 file changed, 57 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/interrupt-controller/renesas,sh7751-irl-ext.yaml
>
My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/interrupt-controller/renesas,sh7751-irl-ext.example.dtb: interrupt-controller@a4000000: #interrupt-cells:0:0: 2 was expected
from schema $id: http://devicetree.org/schemas/interrupt-controller/renesas,sh7751-irl-ext.yaml#
doc reference errors (make refcheckdocs):
See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/8d8dec2d75890f3a14632c9606c332fb11d89a95.1712207606.git.ysato@users.sourceforge.jp
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
^ permalink raw reply
* Re: [PATCH 4/4] clk: en7523: add EN7581 support
From: Lorenzo Bianconi @ 2024-04-04 7:55 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: linux-clk, mturquette, sboyd, linux-arm-kernel, robh+dt,
krzysztof.kozlowski+dt, conor+dt, nbd, john, devicetree, dd,
catalin.marinas, will, upstream, lorenzo.bianconi83,
angelogioacchino.delregno
In-Reply-To: <95d194ed-86fe-45df-88f1-ae460eb36eaf@linaro.org>
[-- Attachment #1: Type: text/plain, Size: 1781 bytes --]
> On 03/04/2024 18:20, Lorenzo Bianconi wrote:
> > Introduce EN7581 clock support to clk-en7523 driver.
> >
> > Tested-by: Zhengping Zhang <zhengping.zhang@airoha.com>
> > Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
>
>
> > + return 0;
> > +}
> > +
> > static int en7523_clk_probe(struct platform_device *pdev)
> > {
> > struct device_node *node = pdev->dev.of_node;
> > @@ -306,6 +413,12 @@ static int en7523_clk_probe(struct platform_device *pdev)
> > if (IS_ERR(np_base))
> > return PTR_ERR(np_base);
> >
> > + if (of_device_is_compatible(node, "airoha,en7581-scu")) {
>
> Having matching and compatible comparisons inside various code is
> discouraged. Does not scale. Use driver/match data to store some sort of
> flags and check for the flag or some other parameter. The best if
> compatible appears once and only once: in of_device_id.
ack, I will fix it.
Regards,
Lorenzo
>
> > + r = en7581_clk_hw_init(pdev, base, np_base);
> > + if (r)
> > + return r;
> > + }
> > +
> > clk_data = devm_kzalloc(&pdev->dev,
> > struct_size(clk_data, hws, EN7523_NUM_CLOCKS),
> > GFP_KERNEL);
> > @@ -329,8 +442,15 @@ static const struct clk_ops en7523_pcie_ops = {
> > .unprepare = en7523_pci_unprepare,
> > };
> >
> > +static const struct clk_ops en7581_pcie_ops = {
> > + .is_enabled = en7581_pci_is_enabled,
> > + .prepare = en7581_pci_prepare,
> > + .unprepare = en7581_pci_unprepare,
> > +};
> > +
> > static const struct of_device_id of_match_clk_en7523[] = {
> > { .compatible = "airoha,en7523-scu", .data = &en7523_pcie_ops },
> > + { .compatible = "airoha,en7581-scu", .data = &en7581_pcie_ops },
> > { /* sentinel */ }
> > };
> >
>
> Best regards,
> Krzysztof
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox