* [PATCH v3 1/4] ARM: dts: aspeed: Add the AST2500 WDT with SCU register
From: Peter Yin @ 2024-03-26 15:00 UTC (permalink / raw)
To: patrick, Wim Van Sebroeck, Guenter Roeck, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Joel Stanley, Andrew Jeffery,
linux-watchdog, devicetree, linux-arm-kernel, linux-aspeed,
linux-kernel
In-Reply-To: <20240326150027.3015958-1-peteryin.openbmc@gmail.com>
The AST2500 WDT references the System Control Unit
register for its operation.
Signed-off-by: Peter Yin <peteryin.openbmc@gmail.com>
---
arch/arm/boot/dts/aspeed/aspeed-g5.dtsi | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/boot/dts/aspeed/aspeed-g5.dtsi b/arch/arm/boot/dts/aspeed/aspeed-g5.dtsi
index 04f98d1dbb97..5fd12c057c31 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-g5.dtsi
+++ b/arch/arm/boot/dts/aspeed/aspeed-g5.dtsi
@@ -410,12 +410,14 @@ wdt1: watchdog@1e785000 {
compatible = "aspeed,ast2500-wdt";
reg = <0x1e785000 0x20>;
clocks = <&syscon ASPEED_CLK_APB>;
+ aspeed,scu = <&syscon>;
};
wdt2: watchdog@1e785020 {
compatible = "aspeed,ast2500-wdt";
reg = <0x1e785020 0x20>;
clocks = <&syscon ASPEED_CLK_APB>;
+ aspeed,scu = <&syscon>;
};
wdt3: watchdog@1e785040 {
@@ -423,6 +425,7 @@ wdt3: watchdog@1e785040 {
reg = <0x1e785040 0x20>;
clocks = <&syscon ASPEED_CLK_APB>;
status = "disabled";
+ aspeed,scu = <&syscon>;
};
pwm_tacho: pwm-tacho-controller@1e786000 {
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v3 0/4] drivers: watchdog: ast2500 and ast2600 support bootstatus
From: Peter Yin @ 2024-03-26 15:00 UTC (permalink / raw)
To: patrick, Wim Van Sebroeck, Guenter Roeck, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Joel Stanley, Andrew Jeffery,
linux-watchdog, devicetree, linux-arm-kernel, linux-aspeed,
linux-kernel
Add WDIOF_EXTERN1 and WDIOF_CARDRESET bootstatus in ast2500/ast2600
Regarding the AST2600 specification, the WDTn Timeout Status Register
(WDT10) has bit 1 reserved. Bit 1 of the status register indicates
on ast2500 if the boot was from the second boot source.
It does not indicate that the most recent reset was triggered by
the watchdog. The code should just be changed to set WDIOF_CARDRESET
if bit 0 of the status register is set.
Include SCU register to veriy WDIOF_EXTERN1 in ast2600 SCU74 or
ast2500 SCU3C when bit1 is set.
v2 -> v3
- Fixed WDIOF_CARDRESET status bit check and added support
for WDIOF_EXTERN1 on ast2500 and ast2600.
v1 -> v2
- Add comment and support WDIOF_CARDRESET in ast2600
v1
- Patch 0001 - Add WDIOF_EXTERN1 bootstatus
---
Peter Yin (4):
ARM: dts: aspeed: Add the AST2500 WDT with SCU register
ARM: dts: aspeed: Add the AST2600 WDT with SCU register
dt-bindings: watchdog: aspeed-wdt: Add aspeed,scu
drivers: watchdog: ast2500 and ast2600 support bootstatus
.../bindings/watchdog/aspeed-wdt.txt | 4 ++
arch/arm/boot/dts/aspeed/aspeed-g5.dtsi | 3 ++
arch/arm/boot/dts/aspeed/aspeed-g6.dtsi | 4 ++
drivers/watchdog/aspeed_wdt.c | 53 +++++++++++++------
4 files changed, 48 insertions(+), 16 deletions(-)
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2] firmware: arm_ffa: fix ffa_notification_info_get()
From: Sudeep Holla @ 2024-03-26 14:50 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel, Jens Wiklander
Cc: Sudeep Holla, Marc Bonnici, Olivier Deprez, Lorenzo Pieralisi
In-Reply-To: <20240311110700.2367142-1-jens.wiklander@linaro.org>
On Mon, 11 Mar 2024 12:07:00 +0100, Jens Wiklander wrote:
> FFA_NOTIFICATION_INFO_GET retrieves information about pending
> notifications. Notifications can be either global or per VCPU. Global
> notifications are reported with the partition ID only in the list of
> endpoints with pending notifications. ffa_notification_info_get()
> incorrectly expect no ID at all for global notifications. Fix this by
> checking for 1 ID instead of 0.
>
> [...]
Applied to sudeep.holla/linux (for-next/ffa/fixes), thanks!
[1/1] firmware: arm_ffa: fix ffa_notification_info_get()
https://git.kernel.org/sudeep.holla/c/1a4bd2b128fb
--
Regards,
Sudeep
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] firmware: arm_scmi: Make raw debugfs entries non-seekable
From: Sudeep Holla @ 2024-03-26 14:49 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel, Cristian Marussi; +Cc: Sudeep Holla
In-Reply-To: <20240315140324.231830-1-cristian.marussi@arm.com>
On Fri, 15 Mar 2024 14:03:24 +0000, Cristian Marussi wrote:
> SCMI Raw debugfs entries are used to inject and snoop messages out of the
> SCMI core and, as such, the underlying virtual files have no reason to
> support seeking.
>
> Modify the related file_operations descriptors to be non-seekable.
>
>
> [...]
Applied to sudeep.holla/linux (for-next/scmi/fixes), thanks!
[1/1] firmware: arm_scmi: Make raw debugfs entries non-seekable
https://git.kernel.org/sudeep.holla/c/b70c7996d4ff
--
Regards,
Sudeep
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 3/4] arm64: dts: exynos: gs101: join lines close to 80 chars
From: Tudor Ambarus @ 2024-03-26 14:48 UTC (permalink / raw)
To: Alim Akhtar, peter.griffin, robh+dt, krzysztof.kozlowski+dt,
conor+dt
Cc: linux-arm-kernel, linux-samsung-soc, devicetree, linux-kernel,
andre.draszik, willmcvicker, kernel-team
In-Reply-To: <001801da7f6e$40545650$c0fd02f0$@samsung.com>
On 3/26/24 11:10, Alim Akhtar wrote:
> Hi Tudor
Hi, Alim!
>
>> -----Original Message-----
>> From: Tudor Ambarus <tudor.ambarus@linaro.org>
>> Sent: Tuesday, March 26, 2024 4:06 PM
>> To: peter.griffin@linaro.org; robh+dt@kernel.org;
>> krzysztof.kozlowski+dt@linaro.org; conor+dt@kernel.org
>> Cc: alim.akhtar@samsung.com; linux-arm-kernel@lists.infradead.org; linux-
>> samsung-soc@vger.kernel.org; devicetree@vger.kernel.org; linux-
>> kernel@vger.kernel.org; andre.draszik@linaro.org;
>> willmcvicker@google.com; kernel-team@android.com; Tudor Ambarus
>> <tudor.ambarus@linaro.org>
>> Subject: [PATCH v2 3/4] arm64: dts: exynos: gs101: join lines close to 80
> chars
>>
>> These lines fit 81 characters, which is pretty close to 80.
>> Join the lines.
>>
> Does this breaks checkpatch flow?
./scripts/checkpatch --strict does not complain
>
>> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
>> ---
> For better readability, this looks good.
>
> Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com>
Thank you for reviewing the series!
Cheers,
ta
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 00/12] kbuild: enable some -Wextra warnings by default
From: Arnd Bergmann @ 2024-03-26 14:47 UTC (permalink / raw)
To: linux-kbuild, Masahiro Yamada, Nathan Chancellor
Cc: Nicolas Schier, Arnd Bergmann, Bill Metzenthen, Thomas Gleixner,
x86, Damien Le Moal, Jean Delvare, Harry Wentland, Jani Nikula,
Sergey Shtylyov, Jakub Kicinski, Sudip Mukherjee, Andrew Jeffery,
Manoj N. Kumar, Martin K. Petersen, Alexei Starovoitov,
Steven Rostedt, Luis Chamberlain, Andrew Morton,
Greg Kroah-Hartman, linux-kernel, linux-ide, amd-gfx, dri-devel,
intel-gfx, nouveau, intel-xe, netdev, linux-renesas-soc,
linux-arm-kernel, linux-scsi, bpf, linux-trace-kernel,
linux-modules, linux-mm, llvm
From: Arnd Bergmann <arnd@arndb.de>
This is a follow-up on a couple of patch series I sent in the past,
enabling -Wextra (aside from stuff that is explicitly disabled),
-Wcast-function-pointer-strict and -Wrestrict.
I have tested these on 'defconfig' and 'allmodconfig' builds across
all architectures, as well as many 'randconfig' builds on x86, arm and
arm64. It would be nice to have all the Makefile.extrawarn changes in
v6.10, hopefully with the driver fixes going in before that through
the respective subsystem trees.
Arnd
Arnd Bergmann (12):
kbuild: make -Woverride-init warnings more consistent
[v3] parport: mfc3: avoid empty-body warning
kbuild: turn on -Wextra by default
kbuild: remove redundant extra warning flags
firmware: dmi-id: add a release callback function
nouveau: fix function cast warning
cxlflash: fix function pointer cast warnings
x86: math-emu: fix function cast warnings
kbuild: enable -Wcast-function-type-strict unconditionally
sata: sx4: fix pdc20621_get_from_dimm() on 64-bit
[v4] kallsyms: rework symbol lookup return codes
kbuild: turn on -Wrestrict by default
arch/x86/math-emu/fpu_etc.c | 9 +++--
arch/x86/math-emu/fpu_trig.c | 6 ++--
arch/x86/math-emu/reg_constant.c | 7 +++-
drivers/ata/sata_sx4.c | 6 ++--
drivers/firmware/dmi-id.c | 7 +++-
.../gpu/drm/amd/display/dc/dce110/Makefile | 2 +-
.../gpu/drm/amd/display/dc/dce112/Makefile | 2 +-
.../gpu/drm/amd/display/dc/dce120/Makefile | 2 +-
drivers/gpu/drm/amd/display/dc/dce60/Makefile | 2 +-
drivers/gpu/drm/amd/display/dc/dce80/Makefile | 2 +-
drivers/gpu/drm/i915/Makefile | 6 ++--
.../drm/nouveau/nvkm/subdev/bios/shadowof.c | 7 +++-
drivers/gpu/drm/xe/Makefile | 4 +--
drivers/net/ethernet/renesas/sh_eth.c | 2 +-
drivers/parport/parport_mfc3.c | 3 +-
drivers/pinctrl/aspeed/Makefile | 2 +-
drivers/scsi/cxlflash/lunmgt.c | 4 +--
drivers/scsi/cxlflash/main.c | 14 ++++----
drivers/scsi/cxlflash/superpipe.c | 34 +++++++++----------
drivers/scsi/cxlflash/superpipe.h | 11 +++---
drivers/scsi/cxlflash/vlun.c | 7 ++--
fs/proc/Makefile | 2 +-
include/linux/filter.h | 14 ++++----
include/linux/ftrace.h | 6 ++--
include/linux/module.h | 14 ++++----
kernel/bpf/Makefile | 2 +-
kernel/bpf/core.c | 7 ++--
kernel/kallsyms.c | 23 +++++++------
kernel/module/kallsyms.c | 26 +++++++-------
kernel/trace/ftrace.c | 13 +++----
mm/Makefile | 3 +-
scripts/Makefile.extrawarn | 33 ++++--------------
32 files changed, 134 insertions(+), 148 deletions(-)
--
2.39.2
Cc: Bill Metzenthen <billm@melbpc.org.au>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: x86@kernel.org
Cc: Damien Le Moal <dlemoal@kernel.org>
Cc: Jean Delvare <jdelvare@suse.com>
Cc: Harry Wentland <harry.wentland@amd.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Sergey Shtylyov <s.shtylyov@omp.ru>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
Cc: Andrew Jeffery <andrew@codeconstruct.com.au>
Cc: "Manoj N. Kumar" <manoj@linux.ibm.com>
Cc: "Martin K. Petersen" <martin.petersen@oracle.com>
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Luis Chamberlain <mcgrof@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Masahiro Yamada <masahiroy@kernel.org>
Cc: Nathan Chancellor <nathan@kernel.org>
Cc: Nicolas Schier <nicolas@fjasle.eu>
Cc: Greg Kroah-Hartman <gregkh@suse.de>
Cc: linux-kernel@vger.kernel.org
Cc: linux-ide@vger.kernel.org
Cc: amd-gfx@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Cc: intel-gfx@lists.freedesktop.org
Cc: nouveau@lists.freedesktop.org
Cc: intel-xe@lists.freedesktop.org
Cc: netdev@vger.kernel.org
Cc: linux-renesas-soc@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-scsi@vger.kernel.org
Cc: bpf@vger.kernel.org
Cc: linux-trace-kernel@vger.kernel.org
Cc: linux-modules@vger.kernel.org
Cc: linux-mm@kvack.org
Cc: linux-kbuild@vger.kernel.org
Cc: llvm@lists.linux.dev
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH -next] firmware: arm_scmi: Fix wrong fastchannel initialization
From: Sudeep Holla @ 2024-03-26 14:46 UTC (permalink / raw)
To: linux-kernel, Pierre Gondois
Cc: Sudeep Holla, kernel test robot, Dan Carpenter, Cristian Marussi,
linux-arm-kernel
In-Reply-To: <20240311090413.1710725-1-pierre.gondois@arm.com>
On Mon, 11 Mar 2024 10:04:12 +0100, Pierre Gondois wrote:
> Fastchannels are initialized with a bad index in:
> commit 2441caa84aac ("firmware: arm_scmi: Populate fast channel rate_limit")
> Fix this and provide a correct index.
>
>
Applied to sudeep.holla/linux (for-next/scmi/fixes), thanks!
[1/1] firmware: arm_scmi: Fix wrong fastchannel initialization
https://git.kernel.org/sudeep.holla/c/17f243adf165
--
Regards,
Sudeep
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v6] PCI: keystone: Fix pci_ops for AM654x SoC
From: Siddharth Vadapalli @ 2024-03-26 14:42 UTC (permalink / raw)
To: lpieralisi, kw, robh, bhelgaas, manivannan.sadhasivam,
fancer.lancer, u.kleine-koenig, cassel, dlemoal,
yoshihiro.shimoda.uh
Cc: linux-pci, linux-kernel, linux-arm-kernel, srk, s-vadapalli
In the process of converting .scan_bus() callbacks to .add_bus(), the
ks_pcie_v3_65_scan_bus() function was changed to ks_pcie_v3_65_add_bus().
The .scan_bus() method belonged to ks_pcie_host_ops which was specific
to controller version 3.65a, while the .add_bus() method had been added
to ks_pcie_ops which is shared between the controller versions 3.65a and
4.90a. Neither the older ks_pcie_v3_65_scan_bus() method, nor the newer
ks_pcie_v3_65_add_bus() method is applicable to the controller version
4.90a which is present in AM654x SoCs.
Thus, as a fix, move the contents of "ks_pcie_v3_65_add_bus()" to the
.msi_init callback "ks_pcie_msi_host_init()" which is specific to the
3.65a controller. Also, move the definitions of ks_pcie_set_dbi_mode()
and ks_pcie_clear_dbi_mode() above ks_pcie_msi_host_init() in order to
avoid forward declaration.
Fixes: 6ab15b5e7057 ("PCI: dwc: keystone: Convert .scan_bus() callback to use add_bus")
Suggested-by: Serge Semin <fancer.lancer@gmail.com>
Suggested-by: Bjorn Helgaas <helgaas@kernel.org>
Suggested-by: Niklas Cassel <cassel@kernel.org>
Reviewed-by: Niklas Cassel <cassel@kernel.org>
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
---
Hello,
This patch is based on linux-next tagged next-20240326.
v5:
https://lore.kernel.org/r/20240326111905.2369778-1-s-vadapalli@ti.com/
Changes since v5:
- Fixed indentation of comment as pointed out by:
Niklas Cassel <cassel@kernel.org>
at:
https://lore.kernel.org/r/ZgLUCqh12RMApzyr@x1-carbon/
- Collected Reviewed-by tag from:
Niklas Cassel <cassel@kernel.org>
Regards,
Siddharth.
drivers/pci/controller/dwc/pci-keystone.c | 136 ++++++++++------------
1 file changed, 60 insertions(+), 76 deletions(-)
diff --git a/drivers/pci/controller/dwc/pci-keystone.c b/drivers/pci/controller/dwc/pci-keystone.c
index 844de4418724..6cb3a4713009 100644
--- a/drivers/pci/controller/dwc/pci-keystone.c
+++ b/drivers/pci/controller/dwc/pci-keystone.c
@@ -245,8 +245,68 @@ static struct irq_chip ks_pcie_msi_irq_chip = {
.irq_unmask = ks_pcie_msi_unmask,
};
+/**
+ * ks_pcie_set_dbi_mode() - Set DBI mode to access overlaid BAR mask registers
+ * @ks_pcie: A pointer to the keystone_pcie structure which holds the KeyStone
+ * PCIe host controller driver information.
+ *
+ * Since modification of dbi_cs2 involves different clock domain, read the
+ * status back to ensure the transition is complete.
+ */
+static void ks_pcie_set_dbi_mode(struct keystone_pcie *ks_pcie)
+{
+ u32 val;
+
+ val = ks_pcie_app_readl(ks_pcie, CMD_STATUS);
+ val |= DBI_CS2;
+ ks_pcie_app_writel(ks_pcie, CMD_STATUS, val);
+
+ do {
+ val = ks_pcie_app_readl(ks_pcie, CMD_STATUS);
+ } while (!(val & DBI_CS2));
+}
+
+/**
+ * ks_pcie_clear_dbi_mode() - Disable DBI mode
+ * @ks_pcie: A pointer to the keystone_pcie structure which holds the KeyStone
+ * PCIe host controller driver information.
+ *
+ * Since modification of dbi_cs2 involves different clock domain, read the
+ * status back to ensure the transition is complete.
+ */
+static void ks_pcie_clear_dbi_mode(struct keystone_pcie *ks_pcie)
+{
+ u32 val;
+
+ val = ks_pcie_app_readl(ks_pcie, CMD_STATUS);
+ val &= ~DBI_CS2;
+ ks_pcie_app_writel(ks_pcie, CMD_STATUS, val);
+
+ do {
+ val = ks_pcie_app_readl(ks_pcie, CMD_STATUS);
+ } while (val & DBI_CS2);
+}
+
static int ks_pcie_msi_host_init(struct dw_pcie_rp *pp)
{
+ struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
+ struct keystone_pcie *ks_pcie = to_keystone_pcie(pci);
+
+ /* Configure and set up BAR0 */
+ ks_pcie_set_dbi_mode(ks_pcie);
+
+ /* Enable BAR0 */
+ dw_pcie_writel_dbi(pci, PCI_BASE_ADDRESS_0, 1);
+ dw_pcie_writel_dbi(pci, PCI_BASE_ADDRESS_0, SZ_4K - 1);
+
+ ks_pcie_clear_dbi_mode(ks_pcie);
+
+ /*
+ * For BAR0, just setting bus address for inbound writes (MSI) should
+ * be sufficient. Use physical address to avoid any conflicts.
+ */
+ dw_pcie_writel_dbi(pci, PCI_BASE_ADDRESS_0, ks_pcie->app.start);
+
pp->msi_irq_chip = &ks_pcie_msi_irq_chip;
return dw_pcie_allocate_domains(pp);
}
@@ -340,48 +400,6 @@ static const struct irq_domain_ops ks_pcie_intx_irq_domain_ops = {
.xlate = irq_domain_xlate_onetwocell,
};
-/**
- * ks_pcie_set_dbi_mode() - Set DBI mode to access overlaid BAR mask registers
- * @ks_pcie: A pointer to the keystone_pcie structure which holds the KeyStone
- * PCIe host controller driver information.
- *
- * Since modification of dbi_cs2 involves different clock domain, read the
- * status back to ensure the transition is complete.
- */
-static void ks_pcie_set_dbi_mode(struct keystone_pcie *ks_pcie)
-{
- u32 val;
-
- val = ks_pcie_app_readl(ks_pcie, CMD_STATUS);
- val |= DBI_CS2;
- ks_pcie_app_writel(ks_pcie, CMD_STATUS, val);
-
- do {
- val = ks_pcie_app_readl(ks_pcie, CMD_STATUS);
- } while (!(val & DBI_CS2));
-}
-
-/**
- * ks_pcie_clear_dbi_mode() - Disable DBI mode
- * @ks_pcie: A pointer to the keystone_pcie structure which holds the KeyStone
- * PCIe host controller driver information.
- *
- * Since modification of dbi_cs2 involves different clock domain, read the
- * status back to ensure the transition is complete.
- */
-static void ks_pcie_clear_dbi_mode(struct keystone_pcie *ks_pcie)
-{
- u32 val;
-
- val = ks_pcie_app_readl(ks_pcie, CMD_STATUS);
- val &= ~DBI_CS2;
- ks_pcie_app_writel(ks_pcie, CMD_STATUS, val);
-
- do {
- val = ks_pcie_app_readl(ks_pcie, CMD_STATUS);
- } while (val & DBI_CS2);
-}
-
static void ks_pcie_setup_rc_app_regs(struct keystone_pcie *ks_pcie)
{
u32 val;
@@ -445,44 +463,10 @@ static struct pci_ops ks_child_pcie_ops = {
.write = pci_generic_config_write,
};
-/**
- * ks_pcie_v3_65_add_bus() - keystone add_bus post initialization
- * @bus: A pointer to the PCI bus structure.
- *
- * This sets BAR0 to enable inbound access for MSI_IRQ register
- */
-static int ks_pcie_v3_65_add_bus(struct pci_bus *bus)
-{
- struct dw_pcie_rp *pp = bus->sysdata;
- struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
- struct keystone_pcie *ks_pcie = to_keystone_pcie(pci);
-
- if (!pci_is_root_bus(bus))
- return 0;
-
- /* Configure and set up BAR0 */
- ks_pcie_set_dbi_mode(ks_pcie);
-
- /* Enable BAR0 */
- dw_pcie_writel_dbi(pci, PCI_BASE_ADDRESS_0, 1);
- dw_pcie_writel_dbi(pci, PCI_BASE_ADDRESS_0, SZ_4K - 1);
-
- ks_pcie_clear_dbi_mode(ks_pcie);
-
- /*
- * For BAR0, just setting bus address for inbound writes (MSI) should
- * be sufficient. Use physical address to avoid any conflicts.
- */
- dw_pcie_writel_dbi(pci, PCI_BASE_ADDRESS_0, ks_pcie->app.start);
-
- return 0;
-}
-
static struct pci_ops ks_pcie_ops = {
.map_bus = dw_pcie_own_conf_map_bus,
.read = pci_generic_config_read,
.write = pci_generic_config_write,
- .add_bus = ks_pcie_v3_65_add_bus,
};
/**
--
2.40.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v4 1/2] dt-bindings: net: add phy-supply property for stm32
From: Christophe ROULLIER @ 2024-03-26 14:41 UTC (permalink / raw)
To: Andrew Lunn
Cc: David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Maxime Coquelin,
Alexandre Torgue, Richard Cochran, Jose Abreu, Liam Girdwood,
Mark Brown, Marek Vasut, netdev, devicetree, linux-stm32,
linux-arm-kernel, linux-kernel
In-Reply-To: <0e14ad5d-3c25-40ab-981a-fbc4e245fc94@lunn.ch>
On 3/26/24 14:58, Andrew Lunn wrote:
> On Tue, Mar 26, 2024 at 01:58:48PM +0100, Christophe Roullier wrote:
>> Phandle to a regulator that provides power to the PHY. This
>> regulator will be managed during the PHY power on/off sequence.
>>
>> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
>> Signed-off-by: Christophe Roullier <christophe.roullier@foss.st.com>
>> ---
>> Documentation/devicetree/bindings/net/stm32-dwmac.yaml | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/net/stm32-dwmac.yaml b/Documentation/devicetree/bindings/net/stm32-dwmac.yaml
>> index fc8c96b08d7dc..80937b28fa046 100644
>> --- a/Documentation/devicetree/bindings/net/stm32-dwmac.yaml
>> +++ b/Documentation/devicetree/bindings/net/stm32-dwmac.yaml
>> @@ -82,6 +82,9 @@ properties:
>> Should be phandle/offset pair. The phandle to the syscon node which
>> encompases the glue register, and the offset of the control register
>>
>> + phy-supply:
>> + description: PHY regulator
> ~/linux/drivers/net/ethernet/stmicro/stmmac$ grep regulator_get *
> dwmac-rk.c: bsp_priv->regulator = devm_regulator_get(dev, "phy");
> dwmac-sun8i.c: gmac->regulator = devm_regulator_get_optional(dev, "phy");
> dwmac-sunxi.c: gmac->regulator = devm_regulator_get_optional(dev, "phy");
>
> Maybe i'm missing something, but i don't see an actual implementation
> of this binding?
>
> Andrew
Hi Andrew,
You are right, my next step is to upstream support of Ethernet MP13 glue
and some update like Phy regulator support
(it is look like
https://lore.kernel.org/linux-arm-kernel/20230928122427.313271-9-christophe.roullier@foss.st.com/)
Regards,
Christophe
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 2/4] arm64: dts: exynos: gs101: order pinctrl-* props alphabetically
From: Tudor Ambarus @ 2024-03-26 14:39 UTC (permalink / raw)
To: André Draszik, peter.griffin, robh+dt,
krzysztof.kozlowski+dt, conor+dt
Cc: alim.akhtar, linux-arm-kernel, linux-samsung-soc, devicetree,
linux-kernel, willmcvicker, kernel-team
In-Reply-To: <9f2c715e671de0c083355bfbece703936e14045a.camel@linaro.org>
On 3/26/24 11:13, André Draszik wrote:
> Hi Tudor,
>
> On Tue, 2024-03-26 at 10:36 +0000, Tudor Ambarus wrote:
>> Reverse pinctrl-* lines, first pinctrl-0 then pinctrl-names. Move the
>> pinctrl-* properties after clocks so that we keep alphabetic order and
>> align with the other similar definitions.
>
> Krzysztof had requested to change not just the DTSI but all instances for GS101
> here:
> https://lore.kernel.org/all/98810c49-38e6-4402-bd47-05d8cbc99ef3@linaro.org/
>
ah, yes, makes sense. I saw you had your own patch doing the reverse,
I'll take yours and rebase on top.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v11 2/2] arm64: boot: Support Flat Image Tree
From: Masahiro Yamada @ 2024-03-26 14:38 UTC (permalink / raw)
To: Simon Glass
Cc: linux-arm-kernel, Ahmad Fatoum, Nicolas Schier, Catalin Marinas,
Jonathan Corbet, Nathan Chancellor, Nick Terrell, Will Deacon,
linux-doc, linux-kbuild, linux-kernel, workflows
In-Reply-To: <20240314042659.232142-3-sjg@chromium.org>
On Thu, Mar 14, 2024 at 1:28 PM Simon Glass <sjg@chromium.org> wrote:
>
> Add a script which produces a Flat Image Tree (FIT), a single file
> containing the built kernel and associated devicetree files.
> Compression defaults to gzip which gives a good balance of size and
> performance.
>
> The files compress from about 86MB to 24MB using this approach.
>
> The FIT can be used by bootloaders which support it, such as U-Boot
> and Linuxboot. It permits automatic selection of the correct
> devicetree, matching the compatible string of the running board with
> the closest compatible string in the FIT. There is no need for
> filenames or other workarounds.
>
> Add a 'make image.fit' build target for arm64, as well.
>
> The FIT can be examined using 'dumpimage -l'.
>
> This uses the 'dtbs-list' file but processes only .dtb files, ignoring
> the overlay .dtbo files.
>
> This features requires pylibfdt (use 'pip install libfdt'). It also
> requires compression utilities for the algorithm being used. Supported
> compression options are the same as the Image.xxx files. Use
> FIT_COMPRESSION to select an algorithm other than gzip.
>
> While FIT supports a ramdisk / initrd, no attempt is made to support
> this here, since it must be built separately from the Linux build.
>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
>
> Changes in v11:
> - Use dtbslist file in image.fit rule
> - Update cmd_fit rule as per Masahiro
> - Don't mention ignoring files without a .dtb prefix
> - Use argparse fromfile_prefix_chars feature
> - Add a -v option and use it for output (with make V=1)
> - rename srcdir to dtbs
> - Use -o for the output file instead of -f
>
> --- a/scripts/Makefile.lib
> +++ b/scripts/Makefile.lib
> @@ -504,6 +504,21 @@ quiet_cmd_uimage = UIMAGE $@
> -a $(UIMAGE_LOADADDR) -e $(UIMAGE_ENTRYADDR) \
> -n '$(UIMAGE_NAME)' -d $< $@
>
> +# Flat Image Tree (FIT)
> +# This allows for packaging of a kernel and all devicetrees files, using
> +# compression.
> +# ---------------------------------------------------------------------------
> +
> +MAKE_FIT := $(srctree)/scripts/make_fit.py
> +
> +# Use this to override the compression algorithm
> +FIT_COMPRESSION ?= gzip
> +
> +quiet_cmd_fit = FIT $@
> + cmd_fit = $(MAKE_FIT) -o $@ --arch $(UIMAGE_ARCH) --os linux \
> + --name '$(UIMAGE_NAME)' $(if $(V),-v) \
> + --compress $(FIT_COMPRESSION) -k $< @$(word 2,$^)
> +
A nit in your new code.
$(if $(V),-v) does not work for KBUILD_VERBOSE env variable.
It should be
$(if $(findstring 1,$(KBUILD_VERBOSE)),-v)
--
Best Regards
Masahiro Yamada
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [WIP 0/3] Memory model and atomic API in Rust
From: Dr. David Alan Gilbert @ 2024-03-26 14:35 UTC (permalink / raw)
To: Linus Torvalds
Cc: Kent Overstreet, Philipp Stanner, Boqun Feng, rust-for-linux,
linux-kernel, linux-arch, llvm, Miguel Ojeda, Alex Gaynor,
Wedson Almeida Filho, Gary Guo, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Alice Ryhl, Alan Stern,
Andrea Parri, Will Deacon, Peter Zijlstra, Nicholas Piggin,
David Howells, Jade Alglave, Luc Maranget, Paul E. McKenney,
Akira Yokosawa, Daniel Lustig, Joel Fernandes, Nathan Chancellor,
Nick Desaulniers, kent.overstreet, Greg Kroah-Hartman, elver,
Mark Rutland, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86, H. Peter Anvin, Catalin Marinas,
linux-arm-kernel, linux-fsdevel
In-Reply-To: <CAHk-=wjwxKD9CxYsf5x+K5fJbJa_JYZh1eKB4PT5cZJq1+foGw@mail.gmail.com>
* Linus Torvalds (torvalds@linux-foundation.org) wrote:
> On Mon, 25 Mar 2024 at 17:05, Dr. David Alan Gilbert <dave@treblig.org> wrote:
> >
> > Isn't one of the aims of the Rust/C++ idea that you can't forget to access
> > a shared piece of data atomically?
>
> If that is an aim, it's a really *bad* one.
>
> Really.
>
> It very much should never have been an aim, and I hope it wasn't. I
> think, and hope, that the source of the C++ and Rust bad decisions is
> cluelessness, not active malice.
Oh that hit a nerve :-)
> Take Rust - one big point of Rust is the whole "safe" thing, but it's
> very much not a straightjacket like Pascal was. There's a "safe" part
> to Rust, but equally importantly, there's also the "unsafe" part to
> Rust.
>
> The safe part is the one that most programmers are supposed to use.
> It's the one that allows you to not have to worry too much about
> things. It's the part that makes it much harder to screw up.
>
> But the *unsafe* part is what makes Rust powerful. It's the part that
> works behind the curtain. It's the part that may be needed to make the
> safe parts *work*.
>
> And yes, an application programmer might never actually need to use
> it, and in fact in many projects the rule might be that unsafe Rust is
> simply never even an option - but that doesn't mean that the unsafe
> parts don't exist.
>
> Because those unsafe parts are needed to make it all work in reality.
>
> And you should never EVER base your whole design around the "safe"
> part. Then you get a language that is a straight-jacket.
>
> So I'd very strongly argue that the core atomics should be done the
> "unsafe" way - allow people to specify exactly when they want exactly
> what access. Allow people to mix and match and have overlapping
> partial aliases, because if you implement things like locking, you
> *need* those partially aliasing accesses, and you need to make
> overlapping atomics where sometimes you access only one part of the
> field.
>
> And yes, that will be unsafe, and it might even be unportable, but
> it's exactly the kind of thing you need in order to avoid having to
> use assembly language to do your locking.
>
> And by all means, you should relegate that to the "unsafe corner" of
> the language. And maybe don't talk about the unsafe sharp edges in the
> first chapter of the book about the language.
>
> But you should _start_ the design of your language memory model around
> the unsafe "raw atomic access operations" model.
>
> Then you can use those strictly more powerful operations, and you
> create an object model *around* it.
>
> So you create safe objects like just an atomic counter. In *that*
> corner of the language, you have the "safe atomics" - they aren't the
> fundamental implementation, but they are the safe wrappers *around*
> the more powerful (but unsafe) core.
>
> With that "atomic counter" you cannot forget to do atomic accesses,
> because that safe corner of the world doesn't _have_ anything but the
> safe atomic accesses for every time you use the object.
>
> See? Having the capability to do powerful and maybe unsafe things does
> not force people to expose and use all that power. You can - and
> should - wrap the powerful model with safer and simpler interfaces.
I'd agree it's important to get the primitives right; but
I'd argue that from a design point of view it's probably better to keep
both in mind from early on; you need to create a safe interface which
people can actually use most of the time, otherwise you're not getting
any benefit; so yes get the bases right, but just keep a feel for how
they'll get encapsulated so most of the more boring code can be safe.
> This isn't something specific to atomics. Not even remotely. This is
> quite fundamental. You often literally _cannot_ do interesting things
> using only safe interfaces. You want safe memory allocations - but to
> actually write the allocator itself, you want to have all those unsafe
> escape methods - all those raw pointers with arbitrary arithmetic etc.
>
> And if you don't have unsafe escapes, you end up doing what so many
> languages did: the libraries are written in something more powerful
> like C, because C literally can do things that other languages
> *cannot* do.
Yeh that's fine, I'm not at all arguing against that; but it doesn't
mean you shouldn't keep an eye on how the safe side should look; even in the
kernel.
Get it right and those unsafe escapes shouldn't be needed too commonly;
get it wrong and you'll either have painful abstractions or end up with
unsafes shotgunned all over the place.
> Don't let people fool you with talk about Turing machines and similar
> smoke-and-mirror garbage. It's a bedtime story for first-year CS
> students. It's not true.
My infinitely long tape is still on back order.
Dave
> things. If your language doesn't have those unsafe escapes, your
> language is inherently weaker, and inherently worse for it.
>
> Linus
>
--
-----Open up your eyes, open up your mind, open up your code -------
/ Dr. David Alan Gilbert | Running GNU/Linux | Happy \
\ dave @ treblig.org | | In Hex /
\ _________________________|_____ http://www.treblig.org |_______/
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/3] KVM: arm64: Don't defer TLB invalidation when zapping table entries
From: Oliver Upton @ 2024-03-26 14:31 UTC (permalink / raw)
To: Will Deacon
Cc: kvmarm, linux-arm-kernel, Catalin Marinas, Gavin Shan,
Marc Zyngier, Mostafa Saleh, Quentin Perret,
Raghavendra Rao Ananta, Ryan Roberts, Shaoqin Huang,
Suzuki K Poulose, Zenghui Yu
In-Reply-To: <ZgKIides0YAA2j5Y@linux.dev>
On Tue, Mar 26, 2024 at 01:34:17AM -0700, Oliver Upton wrote:
> > }
> >
> > mm_ops->put_page(ctx->ptep);
>
> At least for the 'normal' MMU where we use RCU, this could be changed to
> ->free_unlinked_table() which would defer the freeing of memory til
> after the invalidation completes. But that still hoses pKVM's stage-2
> MMU freeing in-place.
How about this (untested) diff? I _think_ it should address the
invalidation issue while leaving the performance optimization in place
for a 'normal' stage-2.
diff --git a/arch/arm64/kvm/hyp/pgtable.c b/arch/arm64/kvm/hyp/pgtable.c
index 3fae5830f8d2..896fdc0d157d 100644
--- a/arch/arm64/kvm/hyp/pgtable.c
+++ b/arch/arm64/kvm/hyp/pgtable.c
@@ -872,14 +872,19 @@ static void stage2_make_pte(const struct kvm_pgtable_visit_ctx *ctx, kvm_pte_t n
static bool stage2_unmap_defer_tlb_flush(struct kvm_pgtable *pgt)
{
/*
- * If FEAT_TLBIRANGE is implemented, defer the individual
- * TLB invalidations until the entire walk is finished, and
- * then use the range-based TLBI instructions to do the
- * invalidations. Condition deferred TLB invalidation on the
- * system supporting FWB as the optimization is entirely
- * pointless when the unmap walker needs to perform CMOs.
+ * It is possible to use FEAT_TLBIRANGE to do TLB invalidations at the
+ * end of the walk if certain conditions are met:
+ *
+ * - The stage-2 is for a 'normal' VM (i.e. managed in the kernel
+ * context). RCU provides sufficient guarantees to ensure that all
+ * hardware and software references on the stage-2 page tables are
+ * relinquished before freeing a table page.
+ *
+ * - The system supports FEAT_FWB. Otherwise, KVM needs to do CMOs
+ * during the page table table walk.
*/
- return system_supports_tlb_range() && stage2_has_fwb(pgt);
+ return !is_hyp_code() && system_supports_tlb_range() &&
+ stage2_has_fwb(pgt);
}
static void stage2_unmap_put_pte(const struct kvm_pgtable_visit_ctx *ctx,
@@ -1163,7 +1168,7 @@ static int stage2_unmap_walker(const struct kvm_pgtable_visit_ctx *ctx,
kvm_granule_size(ctx->level));
if (childp)
- mm_ops->put_page(childp);
+ mm_ops->free_unlinked_table(childp, ctx->level);
return 0;
}
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v5] PCI: keystone: Fix pci_ops for AM654x SoC
From: Siddharth Vadapalli @ 2024-03-26 14:30 UTC (permalink / raw)
To: Niklas Cassel
Cc: Siddharth Vadapalli, lpieralisi, kw, robh, bhelgaas,
manivannan.sadhasivam, fancer.lancer, u.kleine-koenig, dlemoal,
yoshihiro.shimoda.uh, linux-pci, linux-kernel, linux-arm-kernel,
srk
In-Reply-To: <ZgLUCqh12RMApzyr@x1-carbon>
On Tue, Mar 26, 2024 at 02:56:26PM +0100, Niklas Cassel wrote:
> On Tue, Mar 26, 2024 at 04:49:05PM +0530, Siddharth Vadapalli wrote:
> > In the process of converting .scan_bus() callbacks to .add_bus(), the
> > ks_pcie_v3_65_scan_bus() function was changed to ks_pcie_v3_65_add_bus().
> > The .scan_bus() method belonged to ks_pcie_host_ops which was specific
> > to controller version 3.65a, while the .add_bus() method had been added
> > to ks_pcie_ops which is shared between the controller versions 3.65a and
> > 4.90a. Neither the older ks_pcie_v3_65_scan_bus() method, nor the newer
> > ks_pcie_v3_65_add_bus() method are applicable to the controller version
> > 4.90a which is present in AM654x SoCs.
> >
...
> > + } while (val & DBI_CS2);
> > +}
> > +
> > static int ks_pcie_msi_host_init(struct dw_pcie_rp *pp)
> > {
> > + struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
> > + struct keystone_pcie *ks_pcie = to_keystone_pcie(pci);
> > +
> > + /* Configure and set up BAR0 */
> > + ks_pcie_set_dbi_mode(ks_pcie);
> > +
> > + /* Enable BAR0 */
> > + dw_pcie_writel_dbi(pci, PCI_BASE_ADDRESS_0, 1);
> > + dw_pcie_writel_dbi(pci, PCI_BASE_ADDRESS_0, SZ_4K - 1);
> > +
> > + ks_pcie_clear_dbi_mode(ks_pcie);
> > +
> > + /*
> > + * For BAR0, just setting bus address for inbound writes (MSI) should
> > + * be sufficient. Use physical address to avoid any conflicts.
> > + */
>
> This comment seems to have wrong indentation.
> With that fixed:
>
> Reviewed-by: Niklas Cassel <cassel@kernel.org>
I will fix it and post the v6 patch.
Regards,
Siddharth.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH V2] arm64: dts: ti: k3-am625-beagleplay: Use mmc-pwrseq for wl18xx enable
From: Robert Nelson @ 2024-03-26 14:23 UTC (permalink / raw)
To: Nishanth Menon
Cc: Tero Kristo, Vignesh Raghavendra, Conor Dooley,
Krzysztof Kozlowski, Rob Herring, linux-kernel, devicetree,
linux-arm-kernel, Shengyu Qu, Sukrut Bellary,
Javier Martinez Canillas, Bill Mills
In-Reply-To: <20240325143511.2144768-1-nm@ti.com>
On Mon, Mar 25, 2024 at 9:35 AM Nishanth Menon <nm@ti.com> wrote:
>
> From: Sukrut Bellary <sukrut.bellary@linux.com>
>
> BeaglePlay SBC[1] has Texas Instrument's WL18xx WiFi chipset[2].
>
> Currently, WLAN_EN is configured as regulator and regulator-always-on.
> However, the timing and wlan_en sequencing is not correctly modelled.
>
> This causes the sdio access to fail during runtime-pm power operations
> saving or during system suspend/resume/hibernation/freeze operations.
> This is because the WLAN_EN line is not deasserted to low '0' to power
> down the WiFi. So during restore, the WiFi driver tries to load the FW
> without following correct power sequence. WLAN_EN => '1'/assert (high)
> to power-up the chipset.
>
> Use mmc-pwrseq-simple to drive TI's WiFi (WL18xx) chipset enable
> 'WLAN_EN'. mmc-pwrseq-simple provides power sequence flexibility with
> support for post power-on and power-off delays.
>
> Typical log signature that indicates this bug is:
> wl1271_sdio mmc2:0001:2: sdio write failed (-110)
>
> Followed by possibly a kernel warning (depending on firmware present):
> WARNING: CPU: 1 PID: 45 at drivers/net/wireless/ti/wlcore/sdio.c:123 wl12xx_sdio_raw_write+0xe4/0x168 [wlcore_sdio]
>
> [1] https://www.beagleboard.org/boards/beagleplay
> [2] https://www.ti.com/lit/ds/symlink/wl1807mod.pdf
>
> Fixes: f5a731f0787f ("arm64: dts: ti: Add k3-am625-beagleplay")
> Suggested-by: Shengyu Qu <wiagn233@outlook.com>
> Signed-off-by: Sukrut Bellary <sukrut.bellary@linux.com>
> Signed-off-by: Nishanth Menon <nm@ti.com>
Tested-by: Robert Nelson <robertcnelson@gmail.com>
With v6.9.0-rc1 on BeaglePlay..
debian@BeaglePlay-57:~$ uname -r
6.9.0-rc1-dirty
debian@BeaglePlay-57:~$ dmesg | grep wl
[ 12.621555] wlcore: wl18xx HW: 183x or 180x, PG 2.2 (ROM 0x11)
[ 12.623215] wlcore: WARNING Detected unconfigured mac address in
nvs, derive from fuse instead.
[ 12.623253] wlcore: WARNING This default nvs file can be removed
from the file system
[ 12.630813] wlcore: loaded
[ 13.061833] wlcore: using inverted interrupt logic: 2
[ 13.120366] wlcore: PHY firmware version: Rev 8.2.0.0.243
[ 13.218832] wlcore: firmware booted (Rev 8.9.0.0.83)
[ 13.795189] wlan0: no VHT support on 5 GHz, limiting to HT
[ 13.795232] wlan0: determined local STA to be HT, BW limited to 40 MHz
[ 13.795303] wlan0: determined AP ba:fb:e4:f5:7b:d2 to be HT
[ 13.799461] wlan0: connecting with HT mode, max bandwidth 40 MHz
[ 13.802189] wlan0: authenticate with ba:fb:e4:f5:7b:d2 (local
address=6c:30:2a:2a:84:f0)
[ 13.802246] wlan0: send auth to ba:fb:e4:f5:7b:d2 (try 1/3)
[ 13.873457] wlan0: authenticated
[ 13.873746] wlan0: no VHT support on 5 GHz, limiting to HT
[ 13.873764] wlan0: determined local STA to be HT, BW limited to 40 MHz
[ 13.875500] wlan0: associate with ba:fb:e4:f5:7b:d2 (try 1/3)
[ 13.881981] wlan0: RX AssocResp from ba:fb:e4:f5:7b:d2
(capab=0x1511 status=0 aid=3)
[ 13.889436] wlan0: associated
[ 13.889660] wlan0: Limiting TX power to 30 (30 - 0) dBm as
advertised by ba:fb:e4:f5:7b:d2
[ 13.990788] wlcore: Association completed.
--
Robert Nelson
https://rcn-ee.com/
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/3] remoteproc: Add Arm remoteproc driver
From: Mathieu Poirier @ 2024-03-26 14:20 UTC (permalink / raw)
To: Abdellatif El Khlifi
Cc: Sudeep Holla, Bjorn Andersson, Rob Herring, Liviu Dudau,
Lorenzo Pieralisi, Krzysztof Kozlowski, Conor Dooley, Drew.Reed,
Adam.Johnston, linux-arm-kernel, devicetree, linux-kernel,
linux-remoteproc
In-Reply-To: <20240325171339.GA368569@e130802.arm.com>
On Mon, 25 Mar 2024 at 11:13, Abdellatif El Khlifi
<abdellatif.elkhlifi@arm.com> wrote:
>
> Hi Mathieu,
>
> > > > > > > > > This is an initial patchset for allowing to turn on and off the remote processor.
> > > > > > > > > The FW is already loaded before the Corstone-1000 SoC is powered on and this
> > > > > > > > > is done through the FPGA board bootloader in case of the FPGA target. Or by the Corstone-1000 FVP model
> > > > > > > > > (emulator).
> > > > > > > > >
> > > > > > > > >From the above I take it that booting with a preloaded firmware is a
> > > > > > > > scenario that needs to be supported and not just a temporary stage.
> > > > > > >
> > > > > > > The current status of the Corstone-1000 SoC requires that there is
> > > > > > > a preloaded firmware for the external core. Preloading is done externally
> > > > > > > either through the FPGA bootloader or the emulator (FVP) before powering
> > > > > > > on the SoC.
> > > > > > >
> > > > > >
> > > > > > Ok
> > > > > >
> > > > > > > Corstone-1000 will be upgraded in a way that the A core running Linux is able
> > > > > > > to share memory with the remote core and also being able to access the remote
> > > > > > > core memory so Linux can copy the firmware to. This HW changes are still
> > > > > > > This is why this patchset is relying on a preloaded firmware. And it's the step 1
> > > > > > > of adding remoteproc support for Corstone.
> > > > > > >
> > > > > >
> > > > > > Ok, so there is a HW problem where A core and M core can't see each other's
> > > > > > memory, preventing the A core from copying the firmware image to the proper
> > > > > > location.
> > > > > >
> > > > > > When the HW is fixed, will there be a need to support scenarios where the
> > > > > > firmware image has been preloaded into memory?
> > > > >
> > > > > No, this scenario won't apply when we get the HW upgrade. No need for an
> > > > > external entity anymore. The firmware(s) will all be files in the linux filesystem.
> > > > >
> > > >
> > > > Very well. I am willing to continue with this driver but it does so little that
> > > > I wonder if it wouldn't simply be better to move forward with upstreaming when
> > > > the HW is fixed. The choice is yours.
> > > >
> > >
> > > I think Robin has raised few points that need clarification. I think it was
> > > done as part of DT binding patch. I share those concerns and I wanted to
> > > reaching to the same concerns by starting the questions I asked on corstone
> > > device tree changes.
> > >
> >
> > I also agree with Robin's point of view. Proceeding with an initial
> > driver with minimal functionality doesn't preclude having complete
> > bindings. But that said and as I pointed out, it might be better to
> > wait for the HW to be fixed before moving forward.
>
> We checked with the HW teams. The missing features will be implemented but
> this will take time.
>
> The foundation driver as it is right now is still valuable for people wanting to
> know how to power control Corstone external systems in a future proof manner
> (even in the incomplete state). We prefer to address all the review comments
> made so it can be merged. This includes making the DT binding as complete as
> possible as you advised. Then, once the HW is ready, I'll implement the comms
> and the FW reload part. Is that OK please ?
>
I'm in agreement with that plan as long as we agree the current
preloaded heuristic is temporary and is not a valid long term
scenario.
> Cheers,
> Abdellatif
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v7 0/4] arm64: dts: imx8qxp add asrc and sai
From: Frank Li @ 2024-03-26 14:14 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Shengjiu Wang
Cc: linux-sound, devicetree, imx, linux-arm-kernel, linux-kernel,
Conor Dooley
In-Reply-To: <20240318-asrc_8qxp-v7-0-01ce5264a761@nxp.com>
On Mon, Mar 18, 2024 at 03:00:06PM -0400, Frank Li wrote:
> Update binding doc to avoid warning.
> Change from v1 to v2
> - Fixed dts DTB_CHECK warning
>
> Signed-off-by: Frank Li <Frank.Li@nxp.com>
> ---
> Changes in v7:
> - Using rob method for dma-names
> - Drop conor acked tag form dma-names and interrupt patches
> - Fixed warning for interrupts
> - Pass dt_bindng check
>
> make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j8 dt_binding_check DT_SCHEMA_FILES=fsl,sai.yaml
> LINT Documentation/devicetree/bindings
> DTEX Documentation/devicetree/bindings/sound/fsl,sai.example.dts
> CHKDT Documentation/devicetree/bindings/processed-schema.json
> SCHEMA Documentation/devicetree/bindings/processed-schema.json
> DTC_CHK Documentation/devicetree/bindings/sound/fsl,sai.example.dtb
>
> make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j8 dt_binding_check DT_SCHEMA_FILES=fsl,spdif.yaml
> LINT Documentation/devicetree/bindings
> DTEX Documentation/devicetree/bindings/sound/fsl,spdif.example.dts
> CHKDT Documentation/devicetree/bindings/processed-schema.json
> SCHEMA Documentation/devicetree/bindings/processed-schema.json
> DTC_CHK Documentation/devicetree/bindings/sound/fsl,spdif.example.dtb
>
> make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j8 dt_binding_check DT_SCHEMA_FILES=fsl,imx-asrc.yaml
> LINT Documentation/devicetree/bindings
> DTEX Documentation/devicetree/bindings/sound/fsl,imx-asrc.example.dts
> CHKDT Documentation/devicetree/bindings/processed-schema.json
> SCHEMA Documentation/devicetree/bindings/processed-schema.json
> DTC_CHK Documentation/devicetree/bindings/sound/fsl,imx-asrc.example.dtb
>
> - Pass DTB_CHECK, below warning exist because binding doc still be txt.
>
> from schema $id: http://devicetree.org/schemas/dma/fsl,edma.yaml#
> arch/arm64/boot/dts/freescale/imx8dxl-evk.dtb: /bus@59000000/amix@59840000: failed to match any schema with compatible: ['fsl,imx8qm-audmix']
>
> - Link to v6: https://lore.kernel.org/r/20240308-asrc_8qxp-v6-0-e08f6d030e09@nxp.com
>
> Changes in v6:
> - Add interrupt description in binding doc according to rob suggestion
> - Link to v5: https://lore.kernel.org/r/20240307-asrc_8qxp-v5-0-db363740368d@nxp.com
>
> Changes in v5:
> - using rob's suggest logic after fix maxItems.
> - sort dts nodes.
> - remove spdif1. Add later when do 8qm upstream
> - Link to v4: https://lore.kernel.org/r/20240305-asrc_8qxp-v4-0-c61b98046591@nxp.com
>
> Changes in v4:
> Combine comments' from v2 and v3. I hope I address everythings.
>
> - Krzysztof's comments
> - add reson about why change
>
> - rob's comments
> using rob's suggest logic to restrict interrupt number
> but for dma-names, still need use oneOf to cover 3 case
> - [rx, tx]
> - [rx]
> - [tx]
>
> oneOf
> - items:
> - tx
> - rx
> - enums: [rx, tx]
>
> - Conor's comments
> - add power-domains required for imx8qxp and imx8qm
> - remove dmas descript, not allow use index to get dma-channel. Current
> no user using this method.
>
> - Link to v3: https://lore.kernel.org/r/20240228-asrc_8qxp-v3-0-d4d5935fd3aa@nxp.com
>
> Changes in v3:
> - Fixed dtschema/dtc warnings/errors:
> /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/sound/fsl,spdif.example.dtb: spdif@2004000: interrupts: [[0, 52, 4]] is too short
> from schema $id: http://devicetree.org/schemas/sound/fsl,spdif.yaml#
>
> - Link to v2: https://lore.kernel.org/r/20240227-asrc_8qxp-v2-0-521bcc7eb1c0@nxp.com
>
> ---
> Frank Li (4):
> ASoC: dt-bindings: fsl,imx-asrc/spdif: Add power-domains property
> ASoC: dt-bindings: fsl,imx-asrc: update max interrupt numbers
> ASoC: dt-bindings: fsl-sai: allow only one dma-names
@Mark Brown:
Could you please pick dt-bindings part? Reviewed by dt team.
Frank
> arm64: dts: imx8qxp: add asrc[0,1], esai0, spdif0 and sai[4,5]
>
> .../devicetree/bindings/sound/fsl,imx-asrc.yaml | 14 ++
> .../devicetree/bindings/sound/fsl,sai.yaml | 6 +-
> .../devicetree/bindings/sound/fsl,spdif.yaml | 35 ++-
> arch/arm64/boot/dts/freescale/imx8-ss-audio.dtsi | 267 +++++++++++++++++++++
> 4 files changed, 317 insertions(+), 5 deletions(-)
> ---
> base-commit: 8552c902efe7ef670b6961fb8885b67961aeb629
> change-id: 20240227-asrc_8qxp-25aa6783840f
>
> Best regards,
> --
> Frank Li <Frank.Li@nxp.com>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 1/2] dt-bindings: net: add phy-supply property for stm32
From: Andrew Lunn @ 2024-03-26 13:58 UTC (permalink / raw)
To: Christophe Roullier
Cc: David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Maxime Coquelin,
Alexandre Torgue, Richard Cochran, Jose Abreu, Liam Girdwood,
Mark Brown, Marek Vasut, netdev, devicetree, linux-stm32,
linux-arm-kernel, linux-kernel
In-Reply-To: <20240326125849.226765-2-christophe.roullier@foss.st.com>
On Tue, Mar 26, 2024 at 01:58:48PM +0100, Christophe Roullier wrote:
> Phandle to a regulator that provides power to the PHY. This
> regulator will be managed during the PHY power on/off sequence.
>
> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> Signed-off-by: Christophe Roullier <christophe.roullier@foss.st.com>
> ---
> Documentation/devicetree/bindings/net/stm32-dwmac.yaml | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/net/stm32-dwmac.yaml b/Documentation/devicetree/bindings/net/stm32-dwmac.yaml
> index fc8c96b08d7dc..80937b28fa046 100644
> --- a/Documentation/devicetree/bindings/net/stm32-dwmac.yaml
> +++ b/Documentation/devicetree/bindings/net/stm32-dwmac.yaml
> @@ -82,6 +82,9 @@ properties:
> Should be phandle/offset pair. The phandle to the syscon node which
> encompases the glue register, and the offset of the control register
>
> + phy-supply:
> + description: PHY regulator
~/linux/drivers/net/ethernet/stmicro/stmmac$ grep regulator_get *
dwmac-rk.c: bsp_priv->regulator = devm_regulator_get(dev, "phy");
dwmac-sun8i.c: gmac->regulator = devm_regulator_get_optional(dev, "phy");
dwmac-sunxi.c: gmac->regulator = devm_regulator_get_optional(dev, "phy");
Maybe i'm missing something, but i don't see an actual implementation
of this binding?
Andrew
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/2] soc: mediatek: pm-domains: support smi clamp protection
From: AngeloGioacchino Del Regno @ 2024-03-26 13:57 UTC (permalink / raw)
To: Yu-chang Lee (李禹璋), ulf.hansson@linaro.org,
matthias.bgg@gmail.com
Cc: linux-kernel@vger.kernel.org, linux-mediatek@lists.infradead.org,
linux-pm@vger.kernel.org, MandyJH Liu (劉人僖),
Project_Global_Chrome_Upstream_Group,
Xiufeng Li (李秀峰),
linux-arm-kernel@lists.infradead.org, Fan Chen (陳凡)
In-Reply-To: <c0086465922ec54bed17cee7b9e87d224240f21a.camel@mediatek.com>
Il 26/03/24 03:00, Yu-chang Lee (李禹璋) ha scritto:
> On Mon, 2024-03-25 at 14:05 +0100, AngeloGioacchino Del Regno wrote:
>> Il 25/03/24 13:19, yu-chang.lee ha scritto:
>>> In order to avoid power glitch, this patch use smi clamp
>>> to disable/enable smi common port.
>>>
>>> Signed-off-by: yu-chang.lee <yu-chang.lee@mediatek.com>
>>> ---
>>> drivers/pmdomain/mediatek/mt8188-pm-domains.h | 41 ++++-
>>> drivers/pmdomain/mediatek/mtk-pm-domains.c | 147
>>> ++++++++++++++----
>>> drivers/pmdomain/mediatek/mtk-pm-domains.h | 1 +
>>> 3 files changed, 156 insertions(+), 33 deletions(-)
>>>
>>> diff --git a/drivers/pmdomain/mediatek/mt8188-pm-domains.h
>>> b/drivers/pmdomain/mediatek/mt8188-pm-domains.h
>>> index 7bbba4d56a77..39f057dca92c 100644
>>> --- a/drivers/pmdomain/mediatek/mt8188-pm-domains.h
>>> +++ b/drivers/pmdomain/mediatek/mt8188-pm-domains.h
>>> @@ -573,6 +573,18 @@ static const struct scpsys_domain_data
>>> scpsys_domain_data_mt8188[] = {
>>> .pwr_sta2nd_offs = 0x170,
>>> .sram_pdn_bits = BIT(8),
>>> .sram_pdn_ack_bits = BIT(12),
>>> + .bp_cfg = {
>>> + BUS_PROT_WR(SMI,
>>> + MT8188_SMI_COMMON_SMI_CLAMP_DIP_TO_
>>> VDO0,
>>> + MT8188_SMI_COMMON_CLAMP_EN_SET,
>>> + MT8188_SMI_COMMON_CLAMP_EN_CLR,
>>> + MT8188_SMI_COMMON_CLAMP_EN_STA),
>>> + BUS_PROT_WR(SMI,
>>> + MT8188_SMI_COMMON_SMI_CLAMP_DIP_TO_
>>> VPP1,
>>> + MT8188_SMI_COMMON_CLAMP_EN_SET,
>>> + MT8188_SMI_COMMON_CLAMP_EN_CLR,
>>> + MT8188_SMI_COMMON_CLAMP_EN_STA),
>>> + },
>>> .reset_smi = {
>>> SMI_RESET_WR(MT8188_SMI_LARB10_RESET,
>>> MT8188_SMI_LARB10_RESET_ADDR),
>>> @@ -585,7 +597,7 @@ static const struct scpsys_domain_data
>>> scpsys_domain_data_mt8188[] = {
>>> SMI_RESET_WR(MT8188_SMI_LARB15_RESET,
>>> MT8188_SMI_LARB15_RESET_ADDR),
>>> },
>>> - .caps = MTK_SCPD_KEEP_DEFAULT_OFF,
>>> + .caps = MTK_SCPD_KEEP_DEFAULT_OFF |
>>> MTK_SCPD_CLAMP_PROTECTION,
>>> },
>>> [MT8188_POWER_DOMAIN_IPE] = {
>>> .name = "ipe",
>>> @@ -595,11 +607,18 @@ static const struct scpsys_domain_data
>>> scpsys_domain_data_mt8188[] = {
>>> .pwr_sta2nd_offs = 0x170,
>>> .sram_pdn_bits = BIT(8),
>>> .sram_pdn_ack_bits = BIT(12),
>>> + .bp_cfg = {
>>> + BUS_PROT_WR(SMI,
>>> + MT8188_SMI_COMMON_SMI_CLAMP_IPE_TO_
>>> VPP1,
>>> + MT8188_SMI_COMMON_CLAMP_EN_SET,
>>> + MT8188_SMI_COMMON_CLAMP_EN_CLR,
>>> + MT8188_SMI_COMMON_CLAMP_EN_STA),
>>> + },
>>> .reset_smi = {
>>> SMI_RESET_WR(MT8188_SMI_LARB12_RESET,
>>> MT8188_SMI_LARB12_RESET_ADDR),
>>> },
>>> - .caps = MTK_SCPD_KEEP_DEFAULT_OFF,
>>> + .caps = MTK_SCPD_KEEP_DEFAULT_OFF |
>>> MTK_SCPD_CLAMP_PROTECTION,
>>> },
>>> [MT8188_POWER_DOMAIN_CAM_VCORE] = {
>>> .name = "cam_vcore",
>>> @@ -676,13 +695,20 @@ static const struct scpsys_domain_data
>>> scpsys_domain_data_mt8188[] = {
>>> .pwr_sta2nd_offs = 0x170,
>>> .sram_pdn_bits = BIT(8),
>>> .sram_pdn_ack_bits = BIT(12),
>>> + .bp_cfg = {
>>> + BUS_PROT_WR(SMI,
>>> + MT8188_SMI_COMMON_SMI_CLAMP_IPE_TO_
>>> VPP1,
>>> + MT8188_SMI_COMMON_CLAMP_EN_SET,
>>> + MT8188_SMI_COMMON_CLAMP_EN_CLR,
>>> + MT8188_SMI_COMMON_CLAMP_EN_STA),
>>> + },
>>> .reset_smi = {
>>> SMI_RESET_WR(MT8188_SMI_LARB16A_RESET,
>>> MT8188_SMI_LARB16A_RESET_ADDR),
>>> SMI_RESET_WR(MT8188_SMI_LARB17A_RESET,
>>> MT8188_SMI_LARB17A_RESET_ADDR),
>>> },
>>> - .caps = MTK_SCPD_KEEP_DEFAULT_OFF,
>>> + .caps = MTK_SCPD_KEEP_DEFAULT_OFF |
>>> MTK_SCPD_CLAMP_PROTECTION,
>>> },
>>> [MT8188_POWER_DOMAIN_CAM_SUBB] = {
>>> .name = "cam_subb",
>>> @@ -692,13 +718,20 @@ static const struct scpsys_domain_data
>>> scpsys_domain_data_mt8188[] = {
>>> .pwr_sta2nd_offs = 0x170,
>>> .sram_pdn_bits = BIT(8),
>>> .sram_pdn_ack_bits = BIT(12),
>>> + .bp_cfg = {
>>> + BUS_PROT_WR(SMI,
>>> + MT8188_SMI_COMMON_SMI_CLAMP_CAM_SUB
>>> B_TO_VDO0,
>>> + MT8188_SMI_COMMON_CLAMP_EN_SET,
>>> + MT8188_SMI_COMMON_CLAMP_EN_CLR,
>>> + MT8188_SMI_COMMON_CLAMP_EN_STA),
>>> + },
>>> .reset_smi = {
>>> SMI_RESET_WR(MT8188_SMI_LARB16B_RESET,
>>> MT8188_SMI_LARB16B_RESET_ADDR),
>>> SMI_RESET_WR(MT8188_SMI_LARB17B_RESET,
>>> MT8188_SMI_LARB17B_RESET_ADDR),
>>> },
>>> - .caps = MTK_SCPD_KEEP_DEFAULT_OFF,
>>> + .caps = MTK_SCPD_KEEP_DEFAULT_OFF |
>>> MTK_SCPD_CLAMP_PROTECTION,
>>> },
>>> };
>>>
>>> diff --git a/drivers/pmdomain/mediatek/mtk-pm-domains.c
>>> b/drivers/pmdomain/mediatek/mtk-pm-domains.c
>>> index 9ab6fa105c8c..3c797e136c0e 100644
>>> --- a/drivers/pmdomain/mediatek/mtk-pm-domains.c
>>> +++ b/drivers/pmdomain/mediatek/mtk-pm-domains.c
>>> @@ -47,9 +47,10 @@ struct scpsys_domain {
>>> struct clk_bulk_data *subsys_clks;
>>> struct regmap *infracfg_nao;
>>> struct regmap *infracfg;
>>> - struct regmap *smi;
>>> + struct regmap **smi;
>>> struct regmap **larb;
>>> int num_larb;
>>> + int num_smi;
>>> struct regulator *supply;
>>> };
>>>
>>> @@ -122,29 +123,19 @@ static int scpsys_sram_disable(struct
>>> scpsys_domain *pd)
>>> MTK_POLL_TIMEOUT);
>>> }
>>>
>>> -static struct regmap *scpsys_bus_protect_get_regmap(struct
>>> scpsys_domain *pd,
>>> - const struct
>>> scpsys_bus_prot_data *bpd)
>>> -{
>>> - if (bpd->flags & BUS_PROT_COMPONENT_SMI)
>>> - return pd->smi;
>>> - else
>>> - return pd->infracfg;
>>> -}
>>> -
>>> static struct regmap *scpsys_bus_protect_get_sta_regmap(struct
>>> scpsys_domain *pd,
>>> const struct
>>> scpsys_bus_prot_data *bpd)
>>> {
>>> if (bpd->flags & BUS_PROT_STA_COMPONENT_INFRA_NAO)
>>> return pd->infracfg_nao;
>>> else
>>> - return scpsys_bus_protect_get_regmap(pd, bpd);
>>> + return pd->infracfg;
>>> }
>>>
>>> static int scpsys_bus_protect_clear(struct scpsys_domain *pd,
>>> - const struct scpsys_bus_prot_data
>>> *bpd)
>>> + const struct scpsys_bus_prot_data
>>> *bpd,
>>> + struct regmap *sta_regmap,
>>> struct regmap *regmap)
>>> {
>>> - struct regmap *sta_regmap =
>>> scpsys_bus_protect_get_sta_regmap(pd, bpd);
>>> - struct regmap *regmap = scpsys_bus_protect_get_regmap(pd, bpd);
>>> u32 sta_mask = bpd->bus_prot_sta_mask;
>>> u32 expected_ack;
>>> u32 val;
>>> @@ -165,10 +156,9 @@ static int scpsys_bus_protect_clear(struct
>>> scpsys_domain *pd,
>>> }
>>>
>>> static int scpsys_bus_protect_set(struct scpsys_domain *pd,
>>> - const struct scpsys_bus_prot_data
>>> *bpd)
>>> + const struct scpsys_bus_prot_data
>>> *bpd,
>>> + struct regmap *sta_regmap, struct
>>> regmap *regmap)
>>> {
>>> - struct regmap *sta_regmap =
>>> scpsys_bus_protect_get_sta_regmap(pd, bpd);
>>> - struct regmap *regmap = scpsys_bus_protect_get_regmap(pd, bpd);
>>> u32 sta_mask = bpd->bus_prot_sta_mask;
>>> u32 val;
>>>
>>> @@ -182,19 +172,32 @@ static int scpsys_bus_protect_set(struct
>>> scpsys_domain *pd,
>>> MTK_POLL_DELAY_US,
>>> MTK_POLL_TIMEOUT);
>>> }
>>>
>>> -static int scpsys_bus_protect_enable(struct scpsys_domain *pd)
>>> +static int _scpsys_clamp_bus_protection_enable(struct
>>> scpsys_domain *pd, bool is_smi)
>>> {
>>> + int smi_count = 0;
>>> +
>>> for (int i = 0; i < SPM_MAX_BUS_PROT_DATA; i++) {
>>> const struct scpsys_bus_prot_data *bpd = &pd->data-
>>>> bp_cfg[i];
>>> + struct regmap *sta_regmap, *regmap;
>>> + bool is_smi = bpd->flags & BUS_PROT_COMPONENT_SMI;
>>> int ret;
>>>
>>> if (!bpd->bus_prot_set_clr_mask)
>>> break;
>>>
>>> + if (is_smi) {
>>> + sta_regmap = pd->smi[smi_count];
>>> + regmap = pd->smi[smi_count];
>>> + smi_count++;
>>> + } else {
>>> + sta_regmap =
>>> scpsys_bus_protect_get_sta_regmap(pd, bpd);
>>> + regmap = pd->infracfg;
>>> + }
>>> +
>>> if (bpd->flags & BUS_PROT_INVERTED)
>>> - ret = scpsys_bus_protect_clear(pd, bpd);
>>> + ret = scpsys_bus_protect_clear(pd, bpd,
>>> sta_regmap, regmap);
>>> else
>>> - ret = scpsys_bus_protect_set(pd, bpd);
>>> + ret = scpsys_bus_protect_set(pd, bpd,
>>> sta_regmap, regmap);
>>> if (ret)
>>> return ret;
>>> }
>>> @@ -202,19 +205,32 @@ static int scpsys_bus_protect_enable(struct
>>> scpsys_domain *pd)
>>> return 0;
>>> }
>>>
>>> -static int scpsys_bus_protect_disable(struct scpsys_domain *pd)
>>> +static int _scpsys_clamp_bus_protection_disable(struct
>>> scpsys_domain *pd, bool is_smi)
>>> {
>>> + int smi_count = pd->num_smi - 1;
>>> +
>>> for (int i = SPM_MAX_BUS_PROT_DATA - 1; i >= 0; i--) {
>>> const struct scpsys_bus_prot_data *bpd = &pd->data-
>>>> bp_cfg[i];
>>> + struct regmap *sta_regmap, *regmap;
>>> + bool is_smi = bpd->flags & BUS_PROT_COMPONENT_SMI;
>>> int ret;
>>>
>>> if (!bpd->bus_prot_set_clr_mask)
>>> continue;
>>>
>>> + if (is_smi) {
>>> + sta_regmap = pd->smi[smi_count];
>>> + regmap = pd->smi[smi_count];
>>> + smi_count--;
>>> + } else {
>>> + sta_regmap =
>>> scpsys_bus_protect_get_sta_regmap(pd, bpd);
>>> + regmap = pd->infracfg;
>>> + }
>>> +
>>> if (bpd->flags & BUS_PROT_INVERTED)
>>> - ret = scpsys_bus_protect_set(pd, bpd);
>>> + ret = scpsys_bus_protect_set(pd, bpd,
>>> sta_regmap, regmap);
>>> else
>>> - ret = scpsys_bus_protect_clear(pd, bpd);
>>> + ret = scpsys_bus_protect_clear(pd, bpd,
>>> sta_regmap, regmap);
>>> if (ret)
>>> return ret;
>>> }
>>> @@ -222,6 +238,50 @@ static int scpsys_bus_protect_disable(struct
>>> scpsys_domain *pd)
>>> return 0;
>>> }
>>>
>>> +static int scpsys_clamp_protection(struct scpsys_domain *pd)
>>> +{
>>> + int ret;
>>> +
>>
>> You can directly call _scpsys_clamp_bus_protection_enable(), no need
>> for a helper.
>>
>>> + ret = _scpsys_clamp_bus_protection_enable(pd, true);
>>> + if (ret)
>>> + return ret;
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +static int scpsys_clamp_protection_disable(struct scpsys_domain
>>> *pd)
>>> +{
>>> + int ret;
>>> +
>>> + ret = _scpsys_clamp_bus_protection_disable(pd, true);
>>> + if (ret)
>>> + return ret;
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +static int scpsys_bus_protect_enable(struct scpsys_domain *pd)
>>
>> Unused function, please remove.
>
> I think this is used in scpsys_power_off function. Do you mean I
> should directly call _scpsys_clamp_bus_protection_disable?
>
Yes, please.
Cheers,
Angelo
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v5] PCI: keystone: Fix pci_ops for AM654x SoC
From: Niklas Cassel @ 2024-03-26 13:56 UTC (permalink / raw)
To: Siddharth Vadapalli
Cc: lpieralisi, kw, robh, bhelgaas, manivannan.sadhasivam,
fancer.lancer, u.kleine-koenig, dlemoal, yoshihiro.shimoda.uh,
linux-pci, linux-kernel, linux-arm-kernel, srk
In-Reply-To: <20240326111905.2369778-1-s-vadapalli@ti.com>
On Tue, Mar 26, 2024 at 04:49:05PM +0530, Siddharth Vadapalli wrote:
> In the process of converting .scan_bus() callbacks to .add_bus(), the
> ks_pcie_v3_65_scan_bus() function was changed to ks_pcie_v3_65_add_bus().
> The .scan_bus() method belonged to ks_pcie_host_ops which was specific
> to controller version 3.65a, while the .add_bus() method had been added
> to ks_pcie_ops which is shared between the controller versions 3.65a and
> 4.90a. Neither the older ks_pcie_v3_65_scan_bus() method, nor the newer
> ks_pcie_v3_65_add_bus() method are applicable to the controller version
> 4.90a which is present in AM654x SoCs.
>
> Thus, as a fix, move the contents of "ks_pcie_v3_65_add_bus()" to the
> .msi_init callback "ks_pcie_msi_host_init()" which is specific to the
> 3.65a controller. Also, move the definitions of ks_pcie_set_dbi_mode()
> and ks_pcie_clear_dbi_mode() above ks_pcie_msi_host_init() in order to
> avoid forward declaration.
>
> Fixes: 6ab15b5e7057 ("PCI: dwc: keystone: Convert .scan_bus() callback to use add_bus")
> Suggested-by: Serge Semin <fancer.lancer@gmail.com>
> Suggested-by: Bjorn Helgaas <helgaas@kernel.org>
> Suggested-by: Niklas Cassel <cassel@kernel.org>
> Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
> ---
>
> Hello,
>
> This patch is based on linux-next tagged next-20240326.
>
> v4:
> https://lore.kernel.org/r/20240325053722.1955433-1-s-vadapalli@ti.com/
> Changes since v4:
> - As suggested by Niklas Cassel <cassel@kernel.org> at:
> https://lore.kernel.org/r/ZgF_5fYsI5lOFjOv@ryzen/
> the contents of "ks_pcie_v3_65_add_bus()" have been moved to
> "ks_pcie_msi_host_init()" instead of "ks_pcie_host_init()". This
> avoids unnecessary checks for "!ks_pcie->is_am6" since
> "ks_pcie_msi_host_init()" is specific to the v3.65a controller version
> which corresponds to "!ks_pcie->is_am6".
> - Updated commit message to match the change in implementation.
> - Added "Suggested-by" tag of Niklas Cassel <cassel@kernel.org> based on:
> https://lore.kernel.org/r/ZgKaNrhoReJ0A525@x1-carbon/
> - Moved the definitions for ks_pcie_set_dbi_mode() and
> ks_pcie_clear_dbi_mode() above ks_pcie_msi_host_init().
>
> Regards,
> Siddharth.
>
> drivers/pci/controller/dwc/pci-keystone.c | 136 ++++++++++------------
> 1 file changed, 60 insertions(+), 76 deletions(-)
>
> diff --git a/drivers/pci/controller/dwc/pci-keystone.c b/drivers/pci/controller/dwc/pci-keystone.c
> index 844de4418724..c2252448d9e8 100644
> --- a/drivers/pci/controller/dwc/pci-keystone.c
> +++ b/drivers/pci/controller/dwc/pci-keystone.c
> @@ -245,8 +245,68 @@ static struct irq_chip ks_pcie_msi_irq_chip = {
> .irq_unmask = ks_pcie_msi_unmask,
> };
>
> +/**
> + * ks_pcie_set_dbi_mode() - Set DBI mode to access overlaid BAR mask registers
> + * @ks_pcie: A pointer to the keystone_pcie structure which holds the KeyStone
> + * PCIe host controller driver information.
> + *
> + * Since modification of dbi_cs2 involves different clock domain, read the
> + * status back to ensure the transition is complete.
> + */
> +static void ks_pcie_set_dbi_mode(struct keystone_pcie *ks_pcie)
> +{
> + u32 val;
> +
> + val = ks_pcie_app_readl(ks_pcie, CMD_STATUS);
> + val |= DBI_CS2;
> + ks_pcie_app_writel(ks_pcie, CMD_STATUS, val);
> +
> + do {
> + val = ks_pcie_app_readl(ks_pcie, CMD_STATUS);
> + } while (!(val & DBI_CS2));
> +}
> +
> +/**
> + * ks_pcie_clear_dbi_mode() - Disable DBI mode
> + * @ks_pcie: A pointer to the keystone_pcie structure which holds the KeyStone
> + * PCIe host controller driver information.
> + *
> + * Since modification of dbi_cs2 involves different clock domain, read the
> + * status back to ensure the transition is complete.
> + */
> +static void ks_pcie_clear_dbi_mode(struct keystone_pcie *ks_pcie)
> +{
> + u32 val;
> +
> + val = ks_pcie_app_readl(ks_pcie, CMD_STATUS);
> + val &= ~DBI_CS2;
> + ks_pcie_app_writel(ks_pcie, CMD_STATUS, val);
> +
> + do {
> + val = ks_pcie_app_readl(ks_pcie, CMD_STATUS);
> + } while (val & DBI_CS2);
> +}
> +
> static int ks_pcie_msi_host_init(struct dw_pcie_rp *pp)
> {
> + struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
> + struct keystone_pcie *ks_pcie = to_keystone_pcie(pci);
> +
> + /* Configure and set up BAR0 */
> + ks_pcie_set_dbi_mode(ks_pcie);
> +
> + /* Enable BAR0 */
> + dw_pcie_writel_dbi(pci, PCI_BASE_ADDRESS_0, 1);
> + dw_pcie_writel_dbi(pci, PCI_BASE_ADDRESS_0, SZ_4K - 1);
> +
> + ks_pcie_clear_dbi_mode(ks_pcie);
> +
> + /*
> + * For BAR0, just setting bus address for inbound writes (MSI) should
> + * be sufficient. Use physical address to avoid any conflicts.
> + */
This comment seems to have wrong indentation.
With that fixed:
Reviewed-by: Niklas Cassel <cassel@kernel.org>
> + dw_pcie_writel_dbi(pci, PCI_BASE_ADDRESS_0, ks_pcie->app.start);
> +
> pp->msi_irq_chip = &ks_pcie_msi_irq_chip;
> return dw_pcie_allocate_domains(pp);
> }
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] KVM: selftests: Fix __GUEST_ASSERT() format warnings in ARM's arch timer test
From: Oliver Upton @ 2024-03-26 13:50 UTC (permalink / raw)
To: Marc Zyngier, Sean Christopherson
Cc: Oliver Upton, linux-arm-kernel, kvmarm, linux-kernel
In-Reply-To: <20240314175116.2366301-1-seanjc@google.com>
On Thu, 14 Mar 2024 10:51:15 -0700, Sean Christopherson wrote:
> Use %x instead of %lx when printing uint32_t variables to fix format
> warnings in ARM's arch timer test.
>
> aarch64/arch_timer.c: In function ‘guest_run_stage’:
> aarch64/arch_timer.c:138:33: warning: format ‘%lx’ expects argument of type ‘long unsigned int’,
> but argument 6 has type ‘uint32_t’ {aka ‘unsigned int’} [-Wformat=]
> 138 | "config_iter + 1 = 0x%lx, irq_iter = 0x%lx.\n"
> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ......
> 141 | config_iter + 1, irq_iter);
> | ~~~~~~~~~~~~~~~
> | |
> | uint32_t {aka unsigned int}
>
> [...]
Applied to kvmarm/fixes, thanks!
[1/1] KVM: selftests: Fix __GUEST_ASSERT() format warnings in ARM's arch timer test
commit: 29b0075ed61cda250449f556fbe007a5c469440c
--
Best,
Oliver
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 3/3] KVM: arm64: Use TLBI_TTL_UNKNOWN in __kvm_tlb_flush_vmid_range()
From: Ryan Roberts @ 2024-03-26 13:48 UTC (permalink / raw)
To: Will Deacon, kvmarm
Cc: linux-arm-kernel, Catalin Marinas, Gavin Shan, Marc Zyngier,
Mostafa Saleh, Oliver Upton, Quentin Perret,
Raghavendra Rao Ananta, Shaoqin Huang, Suzuki K Poulose,
Zenghui Yu
In-Reply-To: <20240325185158.8565-4-will@kernel.org>
On 25/03/2024 18:51, Will Deacon wrote:
> Commit c910f2b65518 ("arm64/mm: Update tlb invalidation routines for
> FEAT_LPA2") updated the __tlbi_level() macro to take the target level
> as an argument, with TLBI_TTL_UNKNOWN (rather than 0) indicating that
> the caller cannot provide level information. Unfortunately, the two
> implementations of __kvm_tlb_flush_vmid_range() were not updated and so
> now ask for an level 0 invalidation if FEAT_LPA2 is implemented.
Ouch, sorry about this! I remember rebasing my change onto the KVM tlbi range
changes and having a few conflicts. Obviously I didn't do a good enough job of
reviewing the result and missed this new user.
>
> Fix the problem by passing TLBI_TTL_UNKNOWN instead of 0 as the level
> argument to __flush_s2_tlb_range_op() in __kvm_tlb_flush_vmid_range().
>
> Cc: Ryan Roberts <ryan.roberts@arm.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Oliver Upton <oliver.upton@linux.dev>
> Cc: Marc Zyngier <maz@kernel.org>
> Fixes: c910f2b65518 ("arm64/mm: Update tlb invalidation routines for FEAT_LPA2")
> Signed-off-by: Will Deacon <will@kernel.org>
Reviewed-by: Ryan Roberts <ryan.roberts@arm.com>
> ---
> arch/arm64/kvm/hyp/nvhe/tlb.c | 3 ++-
> arch/arm64/kvm/hyp/vhe/tlb.c | 3 ++-
> 2 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/kvm/hyp/nvhe/tlb.c b/arch/arm64/kvm/hyp/nvhe/tlb.c
> index a60fb13e2192..2fc68da4036d 100644
> --- a/arch/arm64/kvm/hyp/nvhe/tlb.c
> +++ b/arch/arm64/kvm/hyp/nvhe/tlb.c
> @@ -154,7 +154,8 @@ void __kvm_tlb_flush_vmid_range(struct kvm_s2_mmu *mmu,
> /* Switch to requested VMID */
> __tlb_switch_to_guest(mmu, &cxt, false);
>
> - __flush_s2_tlb_range_op(ipas2e1is, start, pages, stride, 0);
> + __flush_s2_tlb_range_op(ipas2e1is, start, pages, stride,
> + TLBI_TTL_UNKNOWN);
>
> dsb(ish);
> __tlbi(vmalle1is);
> diff --git a/arch/arm64/kvm/hyp/vhe/tlb.c b/arch/arm64/kvm/hyp/vhe/tlb.c
> index b32e2940df7d..1a60b95381e8 100644
> --- a/arch/arm64/kvm/hyp/vhe/tlb.c
> +++ b/arch/arm64/kvm/hyp/vhe/tlb.c
> @@ -171,7 +171,8 @@ void __kvm_tlb_flush_vmid_range(struct kvm_s2_mmu *mmu,
> /* Switch to requested VMID */
> __tlb_switch_to_guest(mmu, &cxt);
>
> - __flush_s2_tlb_range_op(ipas2e1is, start, pages, stride, 0);
> + __flush_s2_tlb_range_op(ipas2e1is, start, pages, stride,
> + TLBI_TTL_UNKNOWN);
>
> dsb(ish);
> __tlbi(vmalle1is);
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH net-next RESEND] net: axienet: Fix kernel doc warnings
From: Andrew Lunn @ 2024-03-26 13:42 UTC (permalink / raw)
To: Suraj Gupta
Cc: radhey.shyam.pandey, davem, edumazet, kuba, pabeni, michal.simek,
netdev, linux-arm-kernel, linux-kernel, git, harini.katakam
In-Reply-To: <20240326055347.8919-1-suraj.gupta2@amd.com>
On Tue, Mar 26, 2024 at 11:23:47AM +0530, Suraj Gupta wrote:
> Add description of mdio enable, mdio disable and mdio wait functions.
> Add description of skb pointer in axidma_bd data structure.
> Remove 'phy_node' description in axienet local data structure since
> it is not a valid struct member.
> Correct description of struct axienet_option.
>
> Fix below kernel-doc warnings in drivers/net/ethernet/xilinx/:
> 1) xilinx_axienet_mdio.c:1: warning: no structured comments found
> 2) xilinx_axienet.h:379: warning: Function parameter or struct member
> 'skb' not described in 'axidma_bd'
> 3) xilinx_axienet.h:538: warning: Excess struct member 'phy_node'
> description in 'axienet_local'
> 4) xilinx_axienet.h:1002: warning: expecting prototype for struct
> axiethernet_option. Prototype was for struct axienet_option instead
>
> Signed-off-by: Suraj Gupta <suraj.gupta2@amd.com>
> Reviewed-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
>
> ---
> Note: Earlier version didn't reached to mainline due to my email
> configuration issues. So again sending out with resend tag.
>
>
> drivers/net/ethernet/xilinx/xilinx_axienet.h | 4 ++--
> .../net/ethernet/xilinx/xilinx_axienet_mdio.c | 23 ++++++++++++++++---
> 2 files changed, 22 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/net/ethernet/xilinx/xilinx_axienet.h b/drivers/net/ethernet/xilinx/xilinx_axienet.h
> index 807ead678551..d0d1ae3b4e2c 100644
> --- a/drivers/net/ethernet/xilinx/xilinx_axienet.h
> +++ b/drivers/net/ethernet/xilinx/xilinx_axienet.h
> @@ -359,6 +359,7 @@
> * @app2: MM2S/S2MM User Application Field 2.
> * @app3: MM2S/S2MM User Application Field 3.
> * @app4: MM2S/S2MM User Application Field 4.
> + * @skb: Pointer to SKB transferred using DMA
There looks to be some sort of tab vs spaces issue here?
Andrew
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH RESEND net-next v6 2/7] net: phylink: add rxc_always_on flag to phylink_pcs
From: Romain Gantois @ 2024-03-26 13:32 UTC (permalink / raw)
To: Russell King, Andrew Lunn, Heiner Kallweit, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Alexandre Torgue,
Jose Abreu, Maxime Coquelin, Clément Léger
Cc: Maxime Chevallier, Miquel Raynal, Thomas Petazzoni, netdev,
linux-stm32, linux-arm-kernel, linux-renesas-soc,
Russell King (Oracle), Romain Gantois
In-Reply-To: <20240326-rxc_bugfix-v6-0-24a74e5c761f@bootlin.com>
Some MAC drivers (e.g. stmmac) require a continuous receive clock signal to
be generated by a PCS that is handled by a standalone PCS driver.
Such a PCS driver does not have access to a PHY device, thus cannot check
the PHY_F_RXC_ALWAYS_ON flag. They cannot check max_requires_rxc in the
phylink config either, since it is a private member. Therefore, a new flag
is needed to signal to the PCS that it should keep the RX clock signal up
at all times.
Co-developed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Signed-off-by: Romain Gantois <romain.gantois@bootlin.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
---
drivers/net/phy/phylink.c | 15 +++++++++++++++
include/linux/phylink.h | 38 ++++++++++++++++++++++++++++++++++++++
2 files changed, 53 insertions(+)
diff --git a/drivers/net/phy/phylink.c b/drivers/net/phy/phylink.c
index 2bb583543dea..84a97088dfc6 100644
--- a/drivers/net/phy/phylink.c
+++ b/drivers/net/phy/phylink.c
@@ -1042,6 +1042,21 @@ static void phylink_pcs_poll_start(struct phylink *pl)
mod_timer(&pl->link_poll, jiffies + HZ);
}
+int phylink_pcs_pre_init(struct phylink *pl, struct phylink_pcs *pcs)
+{
+ int ret = 0;
+
+ /* Signal to PCS driver that MAC requires RX clock for init */
+ if (pl->config->mac_requires_rxc)
+ pcs->rxc_always_on = true;
+
+ if (pcs->ops->pcs_pre_init)
+ ret = pcs->ops->pcs_pre_init(pcs);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(phylink_pcs_pre_init);
+
static void phylink_mac_config(struct phylink *pl,
const struct phylink_link_state *state)
{
diff --git a/include/linux/phylink.h b/include/linux/phylink.h
index fef8ae66b988..5ea6b2ad2396 100644
--- a/include/linux/phylink.h
+++ b/include/linux/phylink.h
@@ -396,6 +396,10 @@ struct phylink_pcs_ops;
* @phylink: pointer to &struct phylink_config
* @neg_mode: provide PCS neg mode via "mode" argument
* @poll: poll the PCS for link changes
+ * @rxc_always_on: The MAC driver requires the reference clock
+ * to always be on. Standalone PCS drivers which
+ * do not have access to a PHY device can check
+ * this instead of PHY_F_RXC_ALWAYS_ON.
*
* This structure is designed to be embedded within the PCS private data,
* and will be passed between phylink and the PCS.
@@ -408,6 +412,7 @@ struct phylink_pcs {
struct phylink *phylink;
bool neg_mode;
bool poll;
+ bool rxc_always_on;
};
/**
@@ -422,6 +427,8 @@ struct phylink_pcs {
* @pcs_an_restart: restart 802.3z BaseX autonegotiation.
* @pcs_link_up: program the PCS for the resolved link configuration
* (where necessary).
+ * @pcs_pre_init: configure PCS components necessary for MAC hardware
+ * initialization e.g. RX clock for stmmac.
*/
struct phylink_pcs_ops {
int (*pcs_validate)(struct phylink_pcs *pcs, unsigned long *supported,
@@ -441,6 +448,7 @@ struct phylink_pcs_ops {
void (*pcs_an_restart)(struct phylink_pcs *pcs);
void (*pcs_link_up)(struct phylink_pcs *pcs, unsigned int neg_mode,
phy_interface_t interface, int speed, int duplex);
+ int (*pcs_pre_init)(struct phylink_pcs *pcs);
};
#if 0 /* For kernel-doc purposes only. */
@@ -546,6 +554,34 @@ void pcs_an_restart(struct phylink_pcs *pcs);
*/
void pcs_link_up(struct phylink_pcs *pcs, unsigned int neg_mode,
phy_interface_t interface, int speed, int duplex);
+
+/**
+ * pcs_pre_init() - Configure PCS components necessary for MAC initialization
+ * @pcs: a pointer to a &struct phylink_pcs.
+ *
+ * This function can be called by MAC drivers through the
+ * phylink_pcs_pre_init() wrapper, before their hardware is initialized. It
+ * should not be called after the link is brought up, as reconfiguring the PCS
+ * at this point could break the link.
+ *
+ * Some MAC devices require specific hardware initialization to be performed by
+ * their associated PCS device before they can properly initialize their own
+ * hardware. An example of this is the initialization of stmmac controllers,
+ * which requires an active REF_CLK signal to be provided by the PHY/PCS.
+ *
+ * By calling phylink_pcs_pre_init(), MAC drivers can ensure that the PCS is
+ * setup in a way that allows for successful hardware initialization.
+ *
+ * The specific configuration performed by pcs_pre_init() is dependent on the
+ * model of PCS and the requirements of the MAC device attached to it. PCS
+ * driver authors should consider whether their target device is to be used in
+ * conjunction with a MAC device whose driver calls phylink_pcs_pre_init(). MAC
+ * driver authors should document their requirements for the PCS
+ * pre-initialization.
+ *
+ */
+int pcs_pre_init(struct phylink_pcs *pcs);
+
#endif
struct phylink *phylink_create(struct phylink_config *,
@@ -565,6 +601,8 @@ void phylink_disconnect_phy(struct phylink *);
void phylink_mac_change(struct phylink *, bool up);
void phylink_pcs_change(struct phylink_pcs *, bool up);
+int phylink_pcs_pre_init(struct phylink *pl, struct phylink_pcs *pcs);
+
void phylink_start(struct phylink *);
void phylink_stop(struct phylink *);
--
2.44.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH RESEND net-next v6 7/7] net: pcs: rzn1-miic: Init RX clock early if MAC requires it
From: Romain Gantois @ 2024-03-26 13:32 UTC (permalink / raw)
To: Russell King, Andrew Lunn, Heiner Kallweit, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Alexandre Torgue,
Jose Abreu, Maxime Coquelin, Clément Léger
Cc: Maxime Chevallier, Miquel Raynal, Thomas Petazzoni, netdev,
linux-stm32, linux-arm-kernel, linux-renesas-soc, Romain Gantois
In-Reply-To: <20240326-rxc_bugfix-v6-0-24a74e5c761f@bootlin.com>
The GMAC1 controller in the RZN1 IP requires the RX MII clock signal to be
started before it initializes its own hardware, thus before it calls
phylink_start.
Implement the pcs_pre_init() callback so that the RX clock signal can be
enabled early if necessary.
Reported-by: Clément Léger <clement.leger@bootlin.com>
Link: https://lore.kernel.org/linux-arm-kernel/20230116103926.276869-4-clement.leger@bootlin.com/
Signed-off-by: Romain Gantois <romain.gantois@bootlin.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
---
drivers/net/pcs/pcs-rzn1-miic.c | 28 ++++++++++++++++++++++++++++
1 file changed, 28 insertions(+)
diff --git a/drivers/net/pcs/pcs-rzn1-miic.c b/drivers/net/pcs/pcs-rzn1-miic.c
index 4bd66fdde367..d0a722d43368 100644
--- a/drivers/net/pcs/pcs-rzn1-miic.c
+++ b/drivers/net/pcs/pcs-rzn1-miic.c
@@ -279,10 +279,38 @@ static int miic_validate(struct phylink_pcs *pcs, unsigned long *supported,
return -EINVAL;
}
+static int miic_pre_init(struct phylink_pcs *pcs)
+{
+ struct miic_port *miic_port = phylink_pcs_to_miic_port(pcs);
+ struct miic *miic = miic_port->miic;
+ u32 val, mask;
+
+ /* Start RX clock if required */
+ if (pcs->rxc_always_on) {
+ /* In MII through mode, the clock signals will be driven by the
+ * external PHY, which might not be initialized yet. Set RMII
+ * as default mode to ensure that a reference clock signal is
+ * generated.
+ */
+ miic_port->interface = PHY_INTERFACE_MODE_RMII;
+
+ val = FIELD_PREP(MIIC_CONVCTRL_CONV_MODE, CONV_MODE_RMII) |
+ FIELD_PREP(MIIC_CONVCTRL_CONV_SPEED, CONV_MODE_100MBPS);
+ mask = MIIC_CONVCTRL_CONV_MODE | MIIC_CONVCTRL_CONV_SPEED;
+
+ miic_reg_rmw(miic, MIIC_CONVCTRL(miic_port->port), mask, val);
+
+ miic_converter_enable(miic, miic_port->port, 1);
+ }
+
+ return 0;
+}
+
static const struct phylink_pcs_ops miic_phylink_ops = {
.pcs_validate = miic_validate,
.pcs_config = miic_config,
.pcs_link_up = miic_link_up,
+ .pcs_pre_init = miic_pre_init,
};
struct phylink_pcs *miic_create(struct device *dev, struct device_node *np)
--
2.44.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
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