* RE: [PATCH V2 1/5] dt-bindings: fsl: scu: add scu power key binding
From: Anson Huang @ 2019-09-23 2:34 UTC (permalink / raw)
To: Pavel Machek
Cc: mark.rutland@arm.com, ulf.hansson@linaro.org, Jacky Bai,
catalin.marinas@arm.com, Peng Fan, stefan@agner.ch,
bjorn.andersson@linaro.org, Leonard Crestez, will@kernel.org,
festevam@gmail.com, yuehaibing@huawei.com,
marcin.juszkiewicz@linaro.org, jagan@amarulasolutions.com,
linux-input@vger.kernel.org, ronald@innovation.ch, dl-linux-imx,
devicetree@vger.kernel.org, arnd@arndb.de, s.hauer@pengutronix.de,
mripard@kernel.org, m.felsch@pengutronix.de, robh+dt@kernel.org,
tglx@linutronix.de, andriy.shevchenko@linux.intel.com,
Daniel Baluta, linux-arm-kernel@lists.infradead.org, Aisheng Dong,
Andy Duan, gregkh@linuxfoundation.org, dmitry.torokhov@gmail.com,
linux-kernel@vger.kernel.org, dinguyen@kernel.org,
kernel@pengutronix.de, olof@lixom.net, shawnguo@kernel.org
In-Reply-To: <20190922161415.GD1999@bug>
Hi, Pavel
> Subject: Re: [PATCH V2 1/5] dt-bindings: fsl: scu: add scu power key binding
>
> On Tue 2019-09-03 10:03:40, Anson Huang wrote:
> > NXP i.MX8QXP is an ARMv8 SoC with a Cortex-M4 core inside as system
> > controller, the system controller is in charge of system power, clock
> > and power key event etc. management, Linux kernel has to communicate
> > with system controller via MU (message unit) IPC to get power key
> > event, add binding doc for i.MX system controller power key driver.
> >
> > Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> > ---
> > Changes since V1:
> > - remove "wakeup-source" property, as it is NOT needed for SCU
> interrupt;
> > - remove "status" in example.
> > ---
> > .../devicetree/bindings/arm/freescale/fsl,scu.txt | 14
> ++++++++++++++
> > 1 file changed, 14 insertions(+)
> >
> > diff --git
> > a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> > b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> > index c149fad..f93e2e4 100644
> > --- a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> > +++ b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> > @@ -157,6 +157,15 @@ Required properties:
> > Optional properties:
> > - timeout-sec: contains the watchdog timeout in seconds.
> >
> > +Power key bindings based on SCU Message Protocol
> > +------------------------------------------------------------
> > +
> > +Required properties:
> > +- compatible: should be:
> > + "fsl,imx8qxp-sc-pwrkey"
> > + followed by "fsl,imx-sc-pwrkey";
> > +- linux,keycodes: See
> > +Documentation/devicetree/bindings/input/keys.txt
>
> Note you have keycode_s_ here, but keycode in the example and in the dts
> patch.
NOT quite understand your point, could you please provide more details?
Thanks,
Anson
_______________________________________________
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 2/5] input: keyboard: imx_sc: Add i.MX system controller key support
From: Anson Huang @ 2019-09-23 2:43 UTC (permalink / raw)
To: Pavel Machek
Cc: mark.rutland@arm.com, ulf.hansson@linaro.org, Jacky Bai,
catalin.marinas@arm.com, Peng Fan, stefan@agner.ch,
bjorn.andersson@linaro.org, Leonard Crestez, will@kernel.org,
festevam@gmail.com, yuehaibing@huawei.com,
marcin.juszkiewicz@linaro.org, cw00.choi@samsung.com,
jagan@amarulasolutions.com, linux-input@vger.kernel.org,
ronald@innovation.ch, dl-linux-imx, devicetree@vger.kernel.org,
arnd@arndb.de, s.hauer@pengutronix.de, mripard@kernel.org,
m.felsch@pengutronix.de, enric.balletbo@collabora.com,
robh+dt@kernel.org, andriy.shevchenko@linux.intel.com,
Daniel Baluta, linux-arm-kernel@lists.infradead.org, Aisheng Dong,
Andy Duan, Dmitry Torokhov, linux-kernel@vger.kernel.org,
dinguyen@kernel.org, kernel@pengutronix.de, olof@lixom.net,
shawnguo@kernel.org
In-Reply-To: <20190922161432.GE1999@bug>
Hi, Pavel
> Subject: Re: [PATCH V4 2/5] input: keyboard: imx_sc: Add i.MX system
> controller key support
>
> Hi!
>
> > > > + ret = imx_scu_call_rpc(priv->key_ipc_handle, &msg, true);
> > > > + if (ret) {
> > > > + dev_err(&input->dev, "read imx sc key failed, ret %d\n", ret);
> > > > + return;
> > > > + }
> > > > +
> > > > + state = (bool)msg.state;
> > > > +
> > > > + if (!state && !priv->keystate)
> > > > + state = true;
> > >
> > > This needs an explanation please.
> >
> > This is to handle the quick press of button, e.g., when button is
> > pressed and released very quickly, when the delay work is scheduled,
> > the button state read from SCU FW is actually a release state (0), the press
> state is (1), so the quick press/release will be ignored.
> >
> > However, after double check and test, I think this should be handled
> > by debounce time, if the button is pressed/release very quickly, the
> > event should be ignored, I will remove it and reduce the debounce time to
> 30mS, previous 100mS is too long, using 30mS as debounce time, I did NOT
> see similar issue no matter how quick I press/release the button.
>
> Are you sure this is expected behaviour?
>
> AFAIK microswitches can bounce when the button is pressed and released,
> but will not generate glitches when the button was not pressed, so even
> short presses are real and should be propagated...
Latest version of patch handle the quick press as below:
- When the button is pressed, the delayed work will be scheduled;
- In the delayed work, the button state will be read, once the state is different as previous
state, it will be propagated;
- If the state is a press state, another delayed work will be scheduled for handling release
event.
So there could be a small window of DEBOUNCE_TIME (30mS) between button press and the delayed
work scheduled for reading the button state, if the button is released in less than 30ms, then the
state read could be a release state which is same as previous state and it will be ignored.
Do you think in this case, we should also propagated the press event? If yes, then what about the
release event? Although from what I tested, no matter how quick I press the button, the driver
can always receive both the press and release event, as the 30mS is very short.
Thanks,
Anson
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [RFC PATCH v3 4/6] psci: Add hvc call service for ptp_kvm.
From: Jianyong Wu (Arm Technology China) @ 2019-09-23 3:19 UTC (permalink / raw)
To: Paolo Bonzini, Marc Zyngier, netdev@vger.kernel.org,
yangbo.lu@nxp.com, john.stultz@linaro.org, tglx@linutronix.de,
sean.j.christopherson@intel.com, richardcochran@gmail.com,
Mark Rutland, Will Deacon, Suzuki Poulose
Cc: Justin He (Arm Technology China), kvm@vger.kernel.org,
Steve Capper, linux-kernel@vger.kernel.org,
Kaly Xin (Arm Technology China), nd,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <56a5b885-62c8-c4ef-e2f8-e945c0eb700e@redhat.com>
Hi Marc, Paolo,
> -----Original Message-----
> From: Paolo Bonzini <pbonzini@redhat.com>
> Sent: Thursday, September 19, 2019 8:13 PM
> To: Marc Zyngier <maz@kernel.org>; Jianyong Wu (Arm Technology China)
> <Jianyong.Wu@arm.com>; netdev@vger.kernel.org; yangbo.lu@nxp.com;
> john.stultz@linaro.org; tglx@linutronix.de; sean.j.christopherson@intel.com;
> richardcochran@gmail.com; Mark Rutland <Mark.Rutland@arm.com>; Will
> Deacon <Will.Deacon@arm.com>; Suzuki Poulose
> <Suzuki.Poulose@arm.com>
> Cc: linux-kernel@vger.kernel.org; kvm@vger.kernel.org; Steve Capper
> <Steve.Capper@arm.com>; Kaly Xin (Arm Technology China)
> <Kaly.Xin@arm.com>; Justin He (Arm Technology China)
> <Justin.He@arm.com>; nd <nd@arm.com>; linux-arm-
> kernel@lists.infradead.org
> Subject: Re: [RFC PATCH v3 4/6] psci: Add hvc call service for ptp_kvm.
>
> On 19/09/19 13:39, Marc Zyngier wrote:
> >> I don't think it's ugly but more important, using tk->tkr_mono.clock
> >> is incorrect. See how the x86 code hardcodes &kvm_clock, it's the
> >> same for ARM.
> > Not really. The guest kernel is free to use any clocksource it wishes.
>
> Understood, in fact it's the same on x86.
>
> However, for PTP to work, the cycles value returned by the clocksource must
> match the one returned by the hypercall. So for ARM
> get_device_system_crosststamp must receive the arch timer clocksource, so
> that it will return -ENODEV if the active clocksource is anything else.
>
After day's reflection on this, I'm a little clear about this issue, let me clarify it.
I think there is three principles for this issue:
(1): guest and host can use different clocksouces as their current clocksouce at the same time
and we can't or it's not easy to probe that if they use the same one.
(2): the cycle value and the clocksouce which passed to get_device_system_crosststamp must be match.
(3): ptp_kvm target to increase the time sync precision so we should choose a high rate clocksource as ptp_kvm clocksource.
Base on (1) and (2) we can deduce that the ptp_kvm clocksource should be better a fixed one. So we can test if the cycle and
clocksource is match.
Base on (3) the arch_sys_timer should be chosen, as it's the best clocksource by far for arm.
Thanks
Jianyong Wu
> Paolo
>
> > In some cases, it is actually desirable (like these broken systems
> > that cannot use an in-kernel irqchip...). Maybe it is that on x86 the
> > guest only uses the kvm_clock, but that's a much harder sell on ARM.
> > The fact that ptp_kvm assumes that the clocksource is fixed doesn't
> > seem correct in that case.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] soc: ti: ti_sci_pm_domains: Store device id in platform device
From: Lokesh Vutla @ 2019-09-23 3:34 UTC (permalink / raw)
To: Nishanth Menon, Tero Kristo, Santosh Shilimkar
Cc: Lokesh Vutla, Sekhar Nori, Linux ARM Mailing List
Device ID that is passed from power-domains is used by peripheral
drivers for communicating with sysfw. Instead of individual drivers
traversing power-domains entry in DT node, store the device ID in
platform_device so that drivers can directly access it.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
---
drivers/soc/ti/ti_sci_pm_domains.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/soc/ti/ti_sci_pm_domains.c b/drivers/soc/ti/ti_sci_pm_domains.c
index 8c2a2f23982c..a124ac409124 100644
--- a/drivers/soc/ti/ti_sci_pm_domains.c
+++ b/drivers/soc/ti/ti_sci_pm_domains.c
@@ -116,6 +116,7 @@ static int ti_sci_pd_attach_dev(struct generic_pm_domain *domain,
struct of_phandle_args pd_args;
struct ti_sci_pm_domain *ti_sci_genpd = genpd_to_ti_sci_pd(domain);
const struct ti_sci_handle *ti_sci = ti_sci_genpd->ti_sci;
+ struct platform_device *pdev = to_platform_device(dev);
struct ti_sci_genpd_dev_data *sci_dev_data;
struct generic_pm_domain_data *genpd_data;
int idx, ret = 0;
@@ -129,6 +130,7 @@ static int ti_sci_pd_attach_dev(struct generic_pm_domain *domain,
return -EINVAL;
idx = pd_args.args[0];
+ pdev->id = idx;
/*
* Check the validity of the requested idx, if the index is not valid
--
2.22.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
* [RFC PATCH 0/2] irqchip/ti-sci-intr: Add support for INTR connecting to INTR
From: Lokesh Vutla @ 2019-09-23 4:24 UTC (permalink / raw)
To: Marc Zyngier; +Cc: Nishanth Menon, Lokesh Vutla, Linux ARM Mailing List
This series updates the driver and dt-bindings to accept INTR being a
parent to INTR and drop all the firmware related bindings.
Lokesh Vutla (2):
dt-bindings: irqchip: Update bindings to drop the usage of gic as
parent
irqchip/ti-sci-intr: Add support for INTR being a parent to INTR
.../interrupt-controller/ti,sci-intr.txt | 28 ++--
drivers/irqchip/irq-ti-sci-intr.c | 137 +++++++++++-------
2 files changed, 95 insertions(+), 70 deletions(-)
--
2.22.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [RFC PATCH 1/2] dt-bindings: irqchip: Update bindings to drop the usage of gic as parent
From: Lokesh Vutla @ 2019-09-23 4:24 UTC (permalink / raw)
To: Marc Zyngier; +Cc: Nishanth Menon, Lokesh Vutla, Linux ARM Mailing List
In-Reply-To: <20190923042405.26064-1-lokeshvutla@ti.com>
Drop the firmware related dt-bindings and use the hardware specified
interrupt numbers within Interrupt Router. This ensures interrupt router
DT node need not assume any interrupt parent type.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
---
.../interrupt-controller/ti,sci-intr.txt | 28 +++++++++----------
1 file changed, 13 insertions(+), 15 deletions(-)
diff --git a/Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.txt b/Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.txt
index 1a8718f8855d..de5de2a4b467 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.txt
+++ b/Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.txt
@@ -44,15 +44,14 @@ Required Properties:
4: If intr supports level triggered interrupts.
- interrupt-controller: Identifies the node as an interrupt controller
- #interrupt-cells: Specifies the number of cells needed to encode an
- interrupt source. The value should be 2.
- First cell should contain the TISCI device ID of source
- Second cell should contain the interrupt source offset
- within the device.
+ interrupt source. The value should be 1.
+ First cell should contain interrupt router input number
+ as specified by hardware.
+- power-domains: phandle pointing to the corresponding PM domain node
+ and an ID representing the device.
- ti,sci: Phandle to TI-SCI compatible System controller node.
-- ti,sci-dst-id: TISCI device ID of the destination IRQ controller.
-- ti,sci-rm-range-girq: Array of TISCI subtype ids representing the host irqs
- assigned to this interrupt router. Each subtype id
- corresponds to a range of host irqs.
+- interrupt-ranges: Ranges that convert the INTR output interrupt numbers to
+ parent's interrupt number.
For more details on TISCI IRQ resource management refer:
http://downloads.ti.com/tisci/esd/latest/2_tisci_msgs/rm/rm_irq.html
@@ -62,21 +61,20 @@ Example:
The following example demonstrates both interrupt router node and the consumer
node(main gpio) on the AM654 SoC:
-main_intr: interrupt-controller0 {
+main_gpio_intr: interrupt-controller0 {
compatible = "ti,sci-intr";
ti,intr-trigger-type = <1>;
interrupt-controller;
interrupt-parent = <&gic500>;
- #interrupt-cells = <2>;
+ power-domains = <&k3_pds 131 TI_SCI_PD_SHARED>;
+ #interrupt-cells = <1>;
ti,sci = <&dmsc>;
- ti,sci-dst-id = <56>;
- ti,sci-rm-range-girq = <0x1>;
+ interrupt-ranges = <0 360 32>;
};
main_gpio0: gpio@600000 {
...
- interrupt-parent = <&main_intr>;
- interrupts = <57 256>, <57 257>, <57 258>,
- <57 259>, <57 260>, <57 261>;
+ interrupt-parent = <&main_gpio_intr>;
+ interrupts = <192>, <193>, <194>, <195>, <196>, <197>;
...
};
--
2.22.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
* [RFC PATCH 2/2] irqchip/ti-sci-intr: Add support for INTR being a parent to INTR
From: Lokesh Vutla @ 2019-09-23 4:24 UTC (permalink / raw)
To: Marc Zyngier; +Cc: Nishanth Menon, Lokesh Vutla, Linux ARM Mailing List
In-Reply-To: <20190923042405.26064-1-lokeshvutla@ti.com>
Driver assumes that Interrupt parent to Interrupt router is always GIC.
This is not true always and a Interrupt Router can be a parent to
Interrupt Router. Update the driver to detect the parent and request the
parent irqs accordingly.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
---
drivers/irqchip/irq-ti-sci-intr.c | 137 ++++++++++++++++++------------
1 file changed, 82 insertions(+), 55 deletions(-)
diff --git a/drivers/irqchip/irq-ti-sci-intr.c b/drivers/irqchip/irq-ti-sci-intr.c
index 59d51a20bbd8..1d8aaa871798 100644
--- a/drivers/irqchip/irq-ti-sci-intr.c
+++ b/drivers/irqchip/irq-ti-sci-intr.c
@@ -17,29 +17,18 @@
#include <linux/of_irq.h>
#include <linux/soc/ti/ti_sci_protocol.h>
-#define TI_SCI_DEV_ID_MASK 0xffff
-#define TI_SCI_DEV_ID_SHIFT 16
-#define TI_SCI_IRQ_ID_MASK 0xffff
-#define TI_SCI_IRQ_ID_SHIFT 0
-#define HWIRQ_TO_DEVID(hwirq) (((hwirq) >> (TI_SCI_DEV_ID_SHIFT)) & \
- (TI_SCI_DEV_ID_MASK))
-#define HWIRQ_TO_IRQID(hwirq) ((hwirq) & (TI_SCI_IRQ_ID_MASK))
-#define TO_HWIRQ(dev, index) ((((dev) & TI_SCI_DEV_ID_MASK) << \
- TI_SCI_DEV_ID_SHIFT) | \
- ((index) & TI_SCI_IRQ_ID_MASK))
-
/**
* struct ti_sci_intr_irq_domain - Structure representing a TISCI based
* Interrupt Router IRQ domain.
* @sci: Pointer to TISCI handle
- * @dst_irq: TISCI resource pointer representing GIC irq controller.
- * @dst_id: TISCI device ID of the GIC irq controller.
+ * @out_irqs: TISCI resource pointer representing INTR irqs.
+ * @pdev: Pointer to platform device.
* @type: Specifies the trigger type supported by this Interrupt Router
*/
struct ti_sci_intr_irq_domain {
const struct ti_sci_handle *sci;
- struct ti_sci_resource *dst_irq;
- u32 dst_id;
+ struct ti_sci_resource *out_irqs;
+ struct platform_device *pdev;
u32 type;
};
@@ -70,15 +59,43 @@ static int ti_sci_intr_irq_domain_translate(struct irq_domain *domain,
{
struct ti_sci_intr_irq_domain *intr = domain->host_data;
- if (fwspec->param_count != 2)
+ if (fwspec->param_count != 1)
return -EINVAL;
- *hwirq = TO_HWIRQ(fwspec->param[0], fwspec->param[1]);
+ *hwirq = fwspec->param[0];
*type = intr->type;
return 0;
}
+static int ti_sci_intr_xlate_irq(struct ti_sci_intr_irq_domain *intr,
+ u32 irq, bool to_parent_hwirq)
+{
+ struct device_node *np = dev_of_node(&intr->pdev->dev);
+ u32 base, pbase, size, len;
+ const __be32 *range;
+
+ range = of_get_property(np, "interrupt-ranges", &len);
+ if (!range)
+ return irq;
+
+ for (len /= sizeof(*range); len >= 3; len -= 3) {
+ base = be32_to_cpu(*range++);
+ pbase = be32_to_cpu(*range++);
+ size = be32_to_cpu(*range++);
+
+ if (to_parent_hwirq) {
+ if (base <= irq && irq < base + size)
+ return irq - base + pbase;
+ } else {
+ if (pbase <= irq && irq < pbase + size)
+ return irq - pbase + base;
+ }
+ }
+
+ return -ENOENT;
+}
+
/**
* ti_sci_intr_irq_domain_free() - Free the specified IRQs from the domain.
* @domain: Domain to which the irqs belong
@@ -90,56 +107,72 @@ static void ti_sci_intr_irq_domain_free(struct irq_domain *domain,
{
struct ti_sci_intr_irq_domain *intr = domain->host_data;
struct irq_data *data, *parent_data;
- u16 dev_id, irq_index;
+ int out_irq;
parent_data = irq_domain_get_irq_data(domain->parent, virq);
+ out_irq = ti_sci_intr_xlate_irq(intr, parent_data->hwirq, false);
data = irq_domain_get_irq_data(domain, virq);
- irq_index = HWIRQ_TO_IRQID(data->hwirq);
- dev_id = HWIRQ_TO_DEVID(data->hwirq);
- intr->sci->ops.rm_irq_ops.free_irq(intr->sci, dev_id, irq_index,
- intr->dst_id, parent_data->hwirq);
- ti_sci_release_resource(intr->dst_irq, parent_data->hwirq);
+ intr->sci->ops.rm_irq_ops.free_irq(intr->sci,
+ intr->pdev->id, data->hwirq,
+ intr->pdev->id, out_irq);
+ ti_sci_release_resource(intr->out_irqs, out_irq);
irq_domain_free_irqs_parent(domain, virq, 1);
irq_domain_reset_irq_data(data);
}
/**
- * ti_sci_intr_alloc_gic_irq() - Allocate GIC specific IRQ
+ * ti_sci_intr_alloc_parent_irq() - Allocate parent IRQ
* @domain: Pointer to the interrupt router IRQ domain
* @virq: Corresponding Linux virtual IRQ number
* @hwirq: Corresponding hwirq for the IRQ within this IRQ domain
*
* Returns 0 if all went well else appropriate error pointer.
*/
-static int ti_sci_intr_alloc_gic_irq(struct irq_domain *domain,
- unsigned int virq, u32 hwirq)
+static int ti_sci_intr_alloc_parent_irq(struct irq_domain *domain,
+ unsigned int virq, u32 hwirq)
{
struct ti_sci_intr_irq_domain *intr = domain->host_data;
+ struct device_node *parent_node;
struct irq_fwspec fwspec;
- u16 dev_id, irq_index;
- u16 dst_irq;
- int err;
+ u16 out_irq, p_hwirq;
+ int err = 0;
- dev_id = HWIRQ_TO_DEVID(hwirq);
- irq_index = HWIRQ_TO_IRQID(hwirq);
-
- dst_irq = ti_sci_get_free_resource(intr->dst_irq);
- if (dst_irq == TI_SCI_RESOURCE_NULL)
+ out_irq = ti_sci_get_free_resource(intr->out_irqs);
+ if (out_irq == TI_SCI_RESOURCE_NULL)
return -EINVAL;
- fwspec.fwnode = domain->parent->fwnode;
- fwspec.param_count = 3;
- fwspec.param[0] = 0; /* SPI */
- fwspec.param[1] = dst_irq - 32; /* SPI offset */
- fwspec.param[2] = intr->type;
+ p_hwirq = ti_sci_intr_xlate_irq(intr, out_irq, true);
+ if (p_hwirq < 0)
+ goto err_irqs;
+
+ parent_node = of_irq_find_parent(dev_of_node(&intr->pdev->dev));
+ fwspec.fwnode = of_node_to_fwnode(parent_node);
+ if (of_property_read_u32(parent_node, "#interrupt-cells",
+ &fwspec.param_count))
+ goto err_irqs;
+
+ if (fwspec.param_count == 1) {
+ /* Parent is Interrupt Router */
+ fwspec.param[0] = p_hwirq;
+ } else if (fwspec.param_count == 3) {
+ /* Parent is GIC */
+ fwspec.param[0] = 0; /* SPI */
+ fwspec.param[1] = p_hwirq; /* SPI offset */
+ fwspec.param[2] = intr->type;
+ } else {
+ /* Invalid parent */
+ dev_err(&intr->pdev->dev, "Unknown IRQ parent to INTR\n");
+ goto err_irqs;
+ }
err = irq_domain_alloc_irqs_parent(domain, virq, 1, &fwspec);
if (err)
goto err_irqs;
- err = intr->sci->ops.rm_irq_ops.set_irq(intr->sci, dev_id, irq_index,
- intr->dst_id, dst_irq);
+ err = intr->sci->ops.rm_irq_ops.set_irq(intr->sci,
+ intr->pdev->id, hwirq,
+ intr->pdev->id, out_irq);
if (err)
goto err_msg;
@@ -148,7 +181,7 @@ static int ti_sci_intr_alloc_gic_irq(struct irq_domain *domain,
err_msg:
irq_domain_free_irqs_parent(domain, virq, 1);
err_irqs:
- ti_sci_release_resource(intr->dst_irq, dst_irq);
+ ti_sci_release_resource(intr->out_irqs, out_irq);
return err;
}
@@ -174,7 +207,7 @@ static int ti_sci_intr_irq_domain_alloc(struct irq_domain *domain,
if (err)
return err;
- err = ti_sci_intr_alloc_gic_irq(domain, virq, hwirq);
+ err = ti_sci_intr_alloc_parent_irq(domain, virq, hwirq);
if (err)
return err;
@@ -214,6 +247,7 @@ static int ti_sci_intr_irq_domain_probe(struct platform_device *pdev)
if (!intr)
return -ENOMEM;
+ intr->pdev = pdev;
ret = of_property_read_u32(dev_of_node(dev), "ti,intr-trigger-type",
&intr->type);
if (ret) {
@@ -230,19 +264,10 @@ static int ti_sci_intr_irq_domain_probe(struct platform_device *pdev)
return ret;
}
- ret = of_property_read_u32(dev_of_node(dev), "ti,sci-dst-id",
- &intr->dst_id);
- if (ret) {
- dev_err(dev, "missing 'ti,sci-dst-id' property\n");
- return -EINVAL;
- }
-
- intr->dst_irq = devm_ti_sci_get_of_resource(intr->sci, dev,
- intr->dst_id,
- "ti,sci-rm-range-girq");
- if (IS_ERR(intr->dst_irq)) {
+ intr->out_irqs = devm_ti_sci_get_irq_range(intr->sci, dev);
+ if (IS_ERR(intr->out_irqs)) {
dev_err(dev, "Destination irq resource allocation failed\n");
- return PTR_ERR(intr->dst_irq);
+ return PTR_ERR(intr->out_irqs);
}
domain = irq_domain_add_hierarchy(parent_domain, 0, 0, dev_of_node(dev),
@@ -252,6 +277,8 @@ static int ti_sci_intr_irq_domain_probe(struct platform_device *pdev)
return -ENOMEM;
}
+ dev_info(dev, "Interrupt Router %d domain created\n", pdev->id);
+
return 0;
}
--
2.22.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: [RFC PATCH v3 4/6] psci: Add hvc call service for ptp_kvm.
From: Jianyong Wu (Arm Technology China) @ 2019-09-23 4:57 UTC (permalink / raw)
To: Paolo Bonzini, netdev@vger.kernel.org, yangbo.lu@nxp.com,
john.stultz@linaro.org, tglx@linutronix.de,
sean.j.christopherson@intel.com, maz@kernel.org,
richardcochran@gmail.com, Mark Rutland, Will Deacon,
Suzuki Poulose
Cc: Justin He (Arm Technology China), kvm@vger.kernel.org,
Steve Capper, linux-kernel@vger.kernel.org,
Kaly Xin (Arm Technology China), nd,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <ef6ab8bd-41ad-88f8-9cfd-dc749ca65310@redhat.com>
Hi Paolo, Marc
> -----Original Message-----
> From: Paolo Bonzini <pbonzini@redhat.com>
> Sent: Thursday, September 19, 2019 7:07 PM
> To: Jianyong Wu (Arm Technology China) <Jianyong.Wu@arm.com>;
> netdev@vger.kernel.org; yangbo.lu@nxp.com; john.stultz@linaro.org;
> tglx@linutronix.de; sean.j.christopherson@intel.com; maz@kernel.org;
> richardcochran@gmail.com; Mark Rutland <Mark.Rutland@arm.com>; Will
> Deacon <Will.Deacon@arm.com>; Suzuki Poulose
> <Suzuki.Poulose@arm.com>
> Cc: linux-kernel@vger.kernel.org; kvm@vger.kernel.org; Steve Capper
> <Steve.Capper@arm.com>; Kaly Xin (Arm Technology China)
> <Kaly.Xin@arm.com>; Justin He (Arm Technology China)
> <Justin.He@arm.com>; nd <nd@arm.com>; linux-arm-
> kernel@lists.infradead.org
> Subject: Re: [RFC PATCH v3 4/6] psci: Add hvc call service for ptp_kvm.
>
> On 19/09/19 11:46, Jianyong Wu (Arm Technology China) wrote:
> >> On 18/09/19 11:57, Jianyong Wu (Arm Technology China) wrote:
> >>> Paolo Bonzini wrote:
> >>>> This is not Y2038-safe. Please use ktime_get_real_ts64 instead,
> >>>> and split the 64-bit seconds value between val[0] and val[1].
> >
> > Val[] should be long not u32 I think, so in arm64 I can avoid that
> > Y2038_safe, but also need rewrite for arm32.
>
> I don't think there's anything inherently wrong with u32 val[], and as you
> notice it lets you reuse code between arm and arm64. It's up to you and
> Marc to decide.
>
To compatible 32-bit, Integrates second value and nanosecond value as a nanosecond value then split it into val[0] and val[1] and split cycle value into val[2] and val[3],
In this way, time will overflow at Y2262.
WDYT?
Thanks
Jianyong Wu
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH V8 0/2] arm64/mm: Enable memory hot remove
From: Anshuman Khandual @ 2019-09-23 5:43 UTC (permalink / raw)
To: linux-mm, linux-kernel, linux-arm-kernel, akpm, catalin.marinas,
will
Cc: mark.rutland, mhocko, ira.weiny, david, mgorman, steve.capper,
Robin.Murphy, steven.price, broonie, cai, ard.biesheuvel, cpandya,
arunks, dan.j.williams, logang, valentin.schneider,
suzuki.poulose, osalvador
This series enables memory hot remove on arm64 after fixing a possible arm64
platform specific kernel page table race condition. This series is based on
linux-next (next-20190920).
Concurrent vmalloc() and hot-remove conflict:
As pointed out earlier on the v5 thread [2] there can be potential conflict
between concurrent vmalloc() and memory hot-remove operation. The problem here
is caused by inadequate locking in vmalloc() which protects installation of a
page table page but not the walk or the leaf entry modification.
Now free_empty_tables() and it's children functions take into account a maximum
possible range on which it operates as a floor-ceiling boundary. This along with
changed free_pxx_table() makes sure that no page table page is freed unless its
fully within the maximum possible range as decided by the caller.
Testing:
Memory hot remove has been tested on arm64 for 4K, 16K, 64K page config
options with all possible CONFIG_ARM64_VA_BITS and CONFIG_PGTABLE_LEVELS
combinations.
Changes in V8:
- Dropped the first patch (memblock_[free|remove] reorder) from the series which
is no longer needed for arm64 hot-remove enablement and was posted separately
as (https://patchwork.kernel.org/patch/11146361/)
- Dropped vmalloc-vmemmap detection and subsequent skipping of free_empty_tables()
- Changed free_empty_[pxx]_tables() functions which now accepts a possible maximum
floor-ceiling address range on which it operates. Also changed free_pxx_table()
functions to check against required alignment as well as maximum floor-ceiling
range as another prerequisite before freeing the page table page.
- Dropped remove_pagetable(), instead call it's constituent functions directly
Changes in V7: (https://lkml.org/lkml/2019/9/3/326)
- vmalloc_vmemmap_overlap gets evaluated early during boot for a given config
- free_empty_tables() gets conditionally called based on vmalloc_vmemmap_overlap
Changes in V6: (https://lkml.org/lkml/2019/7/15/36)
- Implemented most of the suggestions from Mark Rutland
- Added <linux/memory_hotplug.h> in ptdump
- remove_pagetable() now has two distinct passes over the kernel page table
- First pass unmap_hotplug_range() removes leaf level entries at all level
- Second pass free_empty_tables() removes empty page table pages
- Kernel page table lock has been dropped completely
- vmemmap_free() does not call freee_empty_tables() to avoid conflict with vmalloc()
- All address range scanning are converted to do {} while() loop
- Added 'unsigned long end' in __remove_pgd_mapping()
- Callers need not provide starting pointer argument to free_[pte|pmd|pud]_table()
- Drop the starting pointer argument from free_[pte|pmd|pud]_table() functions
- Fetching pxxp[i] in free_[pte|pmd|pud]_table() is wrapped around in READ_ONCE()
- free_[pte|pmd|pud]_table() now computes starting pointer inside the function
- Fixed TLB handling while freeing huge page section mappings at PMD or PUD level
- Added WARN_ON(!page) in free_hotplug_page_range()
- Added WARN_ON(![pm|pud]_table(pud|pmd)) when there is no section mapping
- [PATCH 1/3] mm/hotplug: Reorder memblock_[free|remove]() calls in try_remove_memory()
- Request earlier for separate merger (https://patchwork.kernel.org/patch/10986599/)
- s/__remove_memory/try_remove_memory in the subject line
- s/arch_remove_memory/memblock_[free|remove] in the subject line
- A small change in the commit message as re-order happens now for memblock remove
functions not for arch_remove_memory()
Changes in V5: (https://lkml.org/lkml/2019/5/29/218)
- Have some agreement [1] over using memory_hotplug_lock for arm64 ptdump
- Change 7ba36eccb3f8 ("arm64/mm: Inhibit huge-vmap with ptdump") already merged
- Dropped the above patch from this series
- Fixed indentation problem in arch_[add|remove]_memory() as per David
- Collected all new Acked-by tags
Changes in V4: (https://lkml.org/lkml/2019/5/20/19)
- Implemented most of the suggestions from Mark Rutland
- Interchanged patch [PATCH 2/4] <---> [PATCH 3/4] and updated commit message
- Moved CONFIG_PGTABLE_LEVELS inside free_[pud|pmd]_table()
- Used READ_ONCE() in missing instances while accessing page table entries
- s/p???_present()/p???_none() for checking valid kernel page table entries
- WARN_ON() when an entry is !p???_none() and !p???_present() at the same time
- Updated memory hot-remove commit message with additional details as suggested
- Rebased the series on 5.2-rc1 with hotplug changes from David and Michal Hocko
- Collected all new Acked-by tags
Changes in V3: (https://lkml.org/lkml/2019/5/14/197)
- Implemented most of the suggestions from Mark Rutland for remove_pagetable()
- Fixed applicable PGTABLE_LEVEL wrappers around pgtable page freeing functions
- Replaced 'direct' with 'sparse_vmap' in remove_pagetable() with inverted polarity
- Changed pointer names ('p' at end) and removed tmp from iterations
- Perform intermediate TLB invalidation while clearing pgtable entries
- Dropped flush_tlb_kernel_range() in remove_pagetable()
- Added flush_tlb_kernel_range() in remove_pte_table() instead
- Renamed page freeing functions for pgtable page and mapped pages
- Used page range size instead of order while freeing mapped or pgtable pages
- Removed all PageReserved() handling while freeing mapped or pgtable pages
- Replaced XXX_index() with XXX_offset() while walking the kernel page table
- Used READ_ONCE() while fetching individual pgtable entries
- Taken overall init_mm.page_table_lock instead of just while changing an entry
- Dropped previously added [pmd|pud]_index() which are not required anymore
- Added a new patch to protect kernel page table race condition for ptdump
- Added a new patch from Mark Rutland to prevent huge-vmap with ptdump
Changes in V2: (https://lkml.org/lkml/2019/4/14/5)
- Added all received review and ack tags
- Split the series from ZONE_DEVICE enablement for better review
- Moved memblock re-order patch to the front as per Robin Murphy
- Updated commit message on memblock re-order patch per Michal Hocko
- Dropped [pmd|pud]_large() definitions
- Used existing [pmd|pud]_sect() instead of earlier [pmd|pud]_large()
- Removed __meminit and __ref tags as per Oscar Salvador
- Dropped unnecessary 'ret' init in arch_add_memory() per Robin Murphy
- Skipped calling into pgtable_page_dtor() for linear mapping page table
pages and updated all relevant functions
Changes in V1: (https://lkml.org/lkml/2019/4/3/28)
References:
[1] https://lkml.org/lkml/2019/5/28/584
[2] https://lkml.org/lkml/2019/6/11/709
Anshuman Khandual (2):
arm64/mm: Hold memory hotplug lock while walking for kernel page table dump
arm64/mm: Enable memory hot remove
arch/arm64/Kconfig | 3 +
arch/arm64/include/asm/memory.h | 1 +
arch/arm64/mm/mmu.c | 305 ++++++++++++++++++++++++++++++++++++++--
arch/arm64/mm/ptdump_debugfs.c | 4 +
4 files changed, 304 insertions(+), 9 deletions(-)
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH V8 1/2] arm64/mm: Hold memory hotplug lock while walking for kernel page table dump
From: Anshuman Khandual @ 2019-09-23 5:43 UTC (permalink / raw)
To: linux-mm, linux-kernel, linux-arm-kernel, akpm, catalin.marinas,
will
Cc: mark.rutland, mhocko, ira.weiny, david, mgorman, steve.capper,
Robin.Murphy, steven.price, broonie, cai, ard.biesheuvel, cpandya,
arunks, dan.j.williams, logang, valentin.schneider,
suzuki.poulose, osalvador
In-Reply-To: <1569217425-23777-1-git-send-email-anshuman.khandual@arm.com>
The arm64 page table dump code can race with concurrent modification of the
kernel page tables. When a leaf entries are modified concurrently, the dump
code may log stale or inconsistent information for a VA range, but this is
otherwise not harmful.
When intermediate levels of table are freed, the dump code will continue to
use memory which has been freed and potentially reallocated for another
purpose. In such cases, the dump code may dereference bogus addresses,
leading to a number of potential problems.
Intermediate levels of table may by freed during memory hot-remove,
which will be enabled by a subsequent patch. To avoid racing with
this, take the memory hotplug lock when walking the kernel page table.
Acked-by: David Hildenbrand <david@redhat.com>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
---
arch/arm64/mm/ptdump_debugfs.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/mm/ptdump_debugfs.c b/arch/arm64/mm/ptdump_debugfs.c
index 064163f..b5eebc8 100644
--- a/arch/arm64/mm/ptdump_debugfs.c
+++ b/arch/arm64/mm/ptdump_debugfs.c
@@ -1,5 +1,6 @@
// SPDX-License-Identifier: GPL-2.0
#include <linux/debugfs.h>
+#include <linux/memory_hotplug.h>
#include <linux/seq_file.h>
#include <asm/ptdump.h>
@@ -7,7 +8,10 @@
static int ptdump_show(struct seq_file *m, void *v)
{
struct ptdump_info *info = m->private;
+
+ get_online_mems();
ptdump_walk_pgd(m, info);
+ put_online_mems();
return 0;
}
DEFINE_SHOW_ATTRIBUTE(ptdump);
--
2.7.4
_______________________________________________
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 V8 2/2] arm64/mm: Enable memory hot remove
From: Anshuman Khandual @ 2019-09-23 5:43 UTC (permalink / raw)
To: linux-mm, linux-kernel, linux-arm-kernel, akpm, catalin.marinas,
will
Cc: mark.rutland, mhocko, ira.weiny, david, mgorman, steve.capper,
Robin.Murphy, steven.price, broonie, cai, ard.biesheuvel, cpandya,
arunks, dan.j.williams, logang, valentin.schneider,
suzuki.poulose, osalvador
In-Reply-To: <1569217425-23777-1-git-send-email-anshuman.khandual@arm.com>
The arch code for hot-remove must tear down portions of the linear map and
vmemmap corresponding to memory being removed. In both cases the page
tables mapping these regions must be freed, and when sparse vmemmap is in
use the memory backing the vmemmap must also be freed.
This patch adds unmap_hotplug_range() and free_empty_tables() helpers which
can be used to tear down either region and calls it from vmemmap_free() and
___remove_pgd_mapping(). The sparse_vmap argument determines whether the
backing memory will be freed.
It makes two distinct passes over the kernel page table. In the first pass
with unmap_hotplug_range() it unmaps, invalidates applicable TLB cache and
frees backing memory if required (vmemmap) for each mapped leaf entry. In
the second pass with free_empty_tables() it looks for empty page table
sections whose page table page can be unmapped, TLB invalidated and freed.
While freeing intermediate level page table pages bail out if any of its
entries are still valid. This can happen for partially filled kernel page
table either from a previously attempted failed memory hot add or while
removing an address range which does not span the entire page table page
range.
The vmemmap region may share levels of table with the vmalloc region.
There can be conflicts between hot remove freeing page table pages with
a concurrent vmalloc() walking the kernel page table. This conflict can
not just be solved by taking the init_mm ptl because of existing locking
scheme in vmalloc(). So free_empty_tables() implements a floor and ceiling
method which is borrowed from user page table tear with free_pgd_range()
which skips freeing page table pages if intermediate address range is not
aligned or maximum floor-ceiling might not own the entire page table page.
While here update arch_add_memory() to handle __add_pages() failures by
just unmapping recently added kernel linear mapping. Now enable memory hot
remove on arm64 platforms by default with ARCH_ENABLE_MEMORY_HOTREMOVE.
This implementation is overall inspired from kernel page table tear down
procedure on X86 architecture and user page table tear down method.
Acked-by: Steve Capper <steve.capper@arm.com>
Acked-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
---
arch/arm64/Kconfig | 3 +
arch/arm64/include/asm/memory.h | 1 +
arch/arm64/mm/mmu.c | 305 ++++++++++++++++++++++++++++++++++++++--
3 files changed, 300 insertions(+), 9 deletions(-)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 41a9b42..511249f 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -274,6 +274,9 @@ config ZONE_DMA32
config ARCH_ENABLE_MEMORY_HOTPLUG
def_bool y
+config ARCH_ENABLE_MEMORY_HOTREMOVE
+ def_bool y
+
config SMP
def_bool y
diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
index b61b50b..615dcd0 100644
--- a/arch/arm64/include/asm/memory.h
+++ b/arch/arm64/include/asm/memory.h
@@ -54,6 +54,7 @@
#define MODULES_VADDR (BPF_JIT_REGION_END)
#define MODULES_VSIZE (SZ_128M)
#define VMEMMAP_START (-VMEMMAP_SIZE - SZ_2M)
+#define VMEMMAP_END (VMEMMAP_START + VMEMMAP_SIZE)
#define PCI_IO_END (VMEMMAP_START - SZ_2M)
#define PCI_IO_START (PCI_IO_END - PCI_IO_SIZE)
#define FIXADDR_TOP (PCI_IO_START - SZ_2M)
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 60c929f..6178837 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -725,6 +725,277 @@ int kern_addr_valid(unsigned long addr)
return pfn_valid(pte_pfn(pte));
}
+
+#ifdef CONFIG_MEMORY_HOTPLUG
+static void free_hotplug_page_range(struct page *page, size_t size)
+{
+ WARN_ON(!page || PageReserved(page));
+ free_pages((unsigned long)page_address(page), get_order(size));
+}
+
+static void free_hotplug_pgtable_page(struct page *page)
+{
+ free_hotplug_page_range(page, PAGE_SIZE);
+}
+
+static bool pgtable_range_aligned(unsigned long start, unsigned long end,
+ unsigned long floor, unsigned long ceiling,
+ unsigned long mask)
+{
+ start &= mask;
+ if (start < floor)
+ return false;
+
+ if (ceiling) {
+ ceiling &= mask;
+ if (!ceiling)
+ return false;
+ }
+
+ if (end - 1 > ceiling - 1)
+ return false;
+ return true;
+}
+
+static void free_pte_table(pmd_t *pmdp, unsigned long addr, unsigned long end,
+ unsigned long floor, unsigned long ceiling)
+{
+ struct page *page;
+ pte_t *ptep;
+ int i;
+
+ if (!pgtable_range_aligned(addr, end, floor, ceiling, PMD_MASK))
+ return;
+
+ ptep = pte_offset_kernel(pmdp, 0UL);
+ for (i = 0; i < PTRS_PER_PTE; i++) {
+ if (!pte_none(READ_ONCE(ptep[i])))
+ return;
+ }
+
+ page = pmd_page(READ_ONCE(*pmdp));
+ pmd_clear(pmdp);
+ __flush_tlb_kernel_pgtable(addr);
+ free_hotplug_pgtable_page(page);
+}
+
+static void free_pmd_table(pud_t *pudp, unsigned long addr, unsigned long end,
+ unsigned long floor, unsigned long ceiling)
+{
+ struct page *page;
+ pmd_t *pmdp;
+ int i;
+
+ if (CONFIG_PGTABLE_LEVELS <= 2)
+ return;
+
+ if (!pgtable_range_aligned(addr, end, floor, ceiling, PUD_MASK))
+ return;
+
+ pmdp = pmd_offset(pudp, 0UL);
+ for (i = 0; i < PTRS_PER_PMD; i++) {
+ if (!pmd_none(READ_ONCE(pmdp[i])))
+ return;
+ }
+
+ page = pud_page(READ_ONCE(*pudp));
+ pud_clear(pudp);
+ __flush_tlb_kernel_pgtable(addr);
+ free_hotplug_pgtable_page(page);
+}
+
+static void free_pud_table(pgd_t *pgdp, unsigned long addr, unsigned long end,
+ unsigned long floor, unsigned long ceiling)
+{
+ struct page *page;
+ pud_t *pudp;
+ int i;
+
+ if (CONFIG_PGTABLE_LEVELS <= 3)
+ return;
+
+ if (!pgtable_range_aligned(addr, end, floor, ceiling, PGDIR_MASK))
+ return;
+
+ pudp = pud_offset(pgdp, 0UL);
+ for (i = 0; i < PTRS_PER_PUD; i++) {
+ if (!pud_none(READ_ONCE(pudp[i])))
+ return;
+ }
+
+ page = pgd_page(READ_ONCE(*pgdp));
+ pgd_clear(pgdp);
+ __flush_tlb_kernel_pgtable(addr);
+ free_hotplug_pgtable_page(page);
+}
+
+static void unmap_hotplug_pte_range(pmd_t *pmdp, unsigned long addr,
+ unsigned long end, bool sparse_vmap)
+{
+ struct page *page;
+ pte_t *ptep, pte;
+
+ do {
+ ptep = pte_offset_kernel(pmdp, addr);
+ pte = READ_ONCE(*ptep);
+ if (pte_none(pte))
+ continue;
+
+ WARN_ON(!pte_present(pte));
+ page = sparse_vmap ? pte_page(pte) : NULL;
+ pte_clear(&init_mm, addr, ptep);
+ flush_tlb_kernel_range(addr, addr + PAGE_SIZE);
+ if (sparse_vmap)
+ free_hotplug_page_range(page, PAGE_SIZE);
+ } while (addr += PAGE_SIZE, addr < end);
+}
+
+static void unmap_hotplug_pmd_range(pud_t *pudp, unsigned long addr,
+ unsigned long end, bool sparse_vmap)
+{
+ unsigned long next;
+ struct page *page;
+ pmd_t *pmdp, pmd;
+
+ do {
+ next = pmd_addr_end(addr, end);
+ pmdp = pmd_offset(pudp, addr);
+ pmd = READ_ONCE(*pmdp);
+ if (pmd_none(pmd))
+ continue;
+
+ WARN_ON(!pmd_present(pmd));
+ if (pmd_sect(pmd)) {
+ page = sparse_vmap ? pmd_page(pmd) : NULL;
+ pmd_clear(pmdp);
+ flush_tlb_kernel_range(addr, next);
+ if (sparse_vmap)
+ free_hotplug_page_range(page, PMD_SIZE);
+ continue;
+ }
+ WARN_ON(!pmd_table(pmd));
+ unmap_hotplug_pte_range(pmdp, addr, next, sparse_vmap);
+ } while (addr = next, addr < end);
+}
+
+static void unmap_hotplug_pud_range(pgd_t *pgdp, unsigned long addr,
+ unsigned long end, bool sparse_vmap)
+{
+ unsigned long next;
+ struct page *page;
+ pud_t *pudp, pud;
+
+ do {
+ next = pud_addr_end(addr, end);
+ pudp = pud_offset(pgdp, addr);
+ pud = READ_ONCE(*pudp);
+ if (pud_none(pud))
+ continue;
+
+ WARN_ON(!pud_present(pud));
+ if (pud_sect(pud)) {
+ page = sparse_vmap ? pud_page(pud) : NULL;
+ pud_clear(pudp);
+ flush_tlb_kernel_range(addr, next);
+ if (sparse_vmap)
+ free_hotplug_page_range(page, PUD_SIZE);
+ continue;
+ }
+ WARN_ON(!pud_table(pud));
+ unmap_hotplug_pmd_range(pudp, addr, next, sparse_vmap);
+ } while (addr = next, addr < end);
+}
+
+static void unmap_hotplug_range(unsigned long addr, unsigned long end,
+ bool sparse_vmap)
+{
+ unsigned long next;
+ pgd_t *pgdp, pgd;
+
+ do {
+ next = pgd_addr_end(addr, end);
+ pgdp = pgd_offset_k(addr);
+ pgd = READ_ONCE(*pgdp);
+ if (pgd_none(pgd))
+ continue;
+
+ WARN_ON(!pgd_present(pgd));
+ unmap_hotplug_pud_range(pgdp, addr, next, sparse_vmap);
+ } while (addr = next, addr < end);
+}
+
+static void free_empty_pte_table(pmd_t *pmdp, unsigned long addr,
+ unsigned long end)
+{
+ pte_t *ptep, pte;
+
+ do {
+ ptep = pte_offset_kernel(pmdp, addr);
+ pte = READ_ONCE(*ptep);
+ WARN_ON(!pte_none(pte));
+ } while (addr += PAGE_SIZE, addr < end);
+}
+
+static void free_empty_pmd_table(pud_t *pudp, unsigned long addr,
+ unsigned long end, unsigned long floor,
+ unsigned long ceiling)
+{
+ unsigned long next;
+ pmd_t *pmdp, pmd;
+
+ do {
+ next = pmd_addr_end(addr, end);
+ pmdp = pmd_offset(pudp, addr);
+ pmd = READ_ONCE(*pmdp);
+ if (pmd_none(pmd))
+ continue;
+
+ WARN_ON(!pmd_present(pmd) || !pmd_table(pmd) || pmd_sect(pmd));
+ free_empty_pte_table(pmdp, addr, next);
+ free_pte_table(pmdp, addr, next, floor, ceiling);
+ } while (addr = next, addr < end);
+}
+
+static void free_empty_pud_table(pgd_t *pgdp, unsigned long addr,
+ unsigned long end, unsigned long floor,
+ unsigned long ceiling)
+{
+ unsigned long next;
+ pud_t *pudp, pud;
+
+ do {
+ next = pud_addr_end(addr, end);
+ pudp = pud_offset(pgdp, addr);
+ pud = READ_ONCE(*pudp);
+ if (pud_none(pud))
+ continue;
+
+ WARN_ON(!pud_present(pud) || !pud_table(pud) || pud_sect(pud));
+ free_empty_pmd_table(pudp, addr, next, floor, ceiling);
+ free_pmd_table(pudp, addr, next, floor, ceiling);
+ } while (addr = next, addr < end);
+}
+
+static void free_empty_tables(unsigned long addr, unsigned long end,
+ unsigned long floor, unsigned long ceiling)
+{
+ unsigned long next;
+ pgd_t *pgdp, pgd;
+
+ do {
+ next = pgd_addr_end(addr, end);
+ pgdp = pgd_offset_k(addr);
+ pgd = READ_ONCE(*pgdp);
+ if (pgd_none(pgd))
+ continue;
+
+ WARN_ON(!pgd_present(pgd));
+ free_empty_pud_table(pgdp, addr, next, floor, ceiling);
+ free_pud_table(pgdp, addr, next, floor, ceiling);
+ } while (addr = next, addr < end);
+}
+#endif
+
#ifdef CONFIG_SPARSEMEM_VMEMMAP
#if !ARM64_SWAPPER_USES_SECTION_MAPS
int __meminit vmemmap_populate(unsigned long start, unsigned long end, int node,
@@ -772,6 +1043,12 @@ int __meminit vmemmap_populate(unsigned long start, unsigned long end, int node,
void vmemmap_free(unsigned long start, unsigned long end,
struct vmem_altmap *altmap)
{
+#ifdef CONFIG_MEMORY_HOTPLUG
+ WARN_ON((start < VMEMMAP_START) || (end > VMEMMAP_END));
+
+ unmap_hotplug_range(start, end, true);
+ free_empty_tables(start, end, VMEMMAP_START, VMEMMAP_END);
+#endif
}
#endif /* CONFIG_SPARSEMEM_VMEMMAP */
@@ -1050,10 +1327,21 @@ int p4d_free_pud_page(p4d_t *p4d, unsigned long addr)
}
#ifdef CONFIG_MEMORY_HOTPLUG
+static void __remove_pgd_mapping(pgd_t *pgdir, unsigned long start, u64 size)
+{
+ unsigned long end = start + size;
+
+ WARN_ON(pgdir != init_mm.pgd);
+ WARN_ON((start < PAGE_OFFSET) || (end > PAGE_END));
+
+ unmap_hotplug_range(start, end, false);
+ free_empty_tables(start, end, PAGE_OFFSET, PAGE_END);
+}
+
int arch_add_memory(int nid, u64 start, u64 size,
struct mhp_restrictions *restrictions)
{
- int flags = 0;
+ int ret, flags = 0;
if (rodata_full || debug_pagealloc_enabled())
flags = NO_BLOCK_MAPPINGS | NO_CONT_MAPPINGS;
@@ -1061,9 +1349,14 @@ int arch_add_memory(int nid, u64 start, u64 size,
__create_pgd_mapping(swapper_pg_dir, start, __phys_to_virt(start),
size, PAGE_KERNEL, __pgd_pgtable_alloc, flags);
- return __add_pages(nid, start >> PAGE_SHIFT, size >> PAGE_SHIFT,
+ ret = __add_pages(nid, start >> PAGE_SHIFT, size >> PAGE_SHIFT,
restrictions);
+ if (ret)
+ __remove_pgd_mapping(swapper_pg_dir,
+ __phys_to_virt(start), size);
+ return ret;
}
+
void arch_remove_memory(int nid, u64 start, u64 size,
struct vmem_altmap *altmap)
{
@@ -1071,14 +1364,8 @@ void arch_remove_memory(int nid, u64 start, u64 size,
unsigned long nr_pages = size >> PAGE_SHIFT;
struct zone *zone;
- /*
- * FIXME: Cleanup page tables (also in arch_add_memory() in case
- * adding fails). Until then, this function should only be used
- * during memory hotplug (adding memory), not for memory
- * unplug. ARCH_ENABLE_MEMORY_HOTREMOVE must not be
- * unlocked yet.
- */
zone = page_zone(pfn_to_page(start_pfn));
__remove_pages(zone, start_pfn, nr_pages, altmap);
+ __remove_pgd_mapping(swapper_pg_dir, __phys_to_virt(start), size);
}
#endif
--
2.7.4
_______________________________________________
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 V3 2/2] mm/pgtable/debug: Add test validating architecture page table helpers
From: Anshuman Khandual @ 2019-09-23 6:27 UTC (permalink / raw)
To: kbuild test robot
Cc: Mark Rutland, linux-ia64, linux-sh, Tetsuo Handa, James Hogan,
Heiko Carstens, Michal Hocko, linux-mm, Paul Mackerras,
sparclinux, Dan Williams, linux-s390, Michael Ellerman, x86,
Russell King - ARM Linux, Matthew Wilcox, Steven Price,
Jason Gunthorpe, Gerald Schaefer, linux-snps-arc, kbuild-all,
Kees Cook, Vlastimil Babka, Mark Brown, Kirill A . Shutemov,
Thomas Gleixner, linux-arm-kernel, Christophe Leroy,
Sri Krishna chowdary, Masahiro Yamada, Greg Kroah-Hartman,
Ard Biesheuvel, Dave Hansen, linux-mips, Ralf Baechle,
linux-kernel, Peter Zijlstra, Mike Rapoport, Paul Burton,
Vineet Gupta, Martin Schwidefsky, Andrew Morton, linuxppc-dev,
David S. Miller
In-Reply-To: <20190921160049.GB13569@xsang-OptiPlex-9020>
On 09/21/2019 09:30 PM, kbuild test robot wrote:
> Hi Anshuman,
>
> Thank you for the patch! Yet something to improve:
>
> [auto build test ERROR on linus/master]
> [cannot apply to v5.3 next-20190919]
> [if your patch is applied to the wrong git tree, please drop us a note to help
> improve the system. BTW, we also suggest to use '--base' option to specify the
> base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
>
> url: https://github.com/0day-ci/linux/commits/Anshuman-Khandual/mm-debug-Add-tests-for-architecture-exported-page-table-helpers/20190920-143746
> config: ia64-allmodconfig (attached as .config)
> compiler: ia64-linux-gcc (GCC) 7.4.0
> reproduce:
> wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # save the attached .config to linux build tree
> GCC_VERSION=7.4.0 make.cross ARCH=ia64
> :::::: branch date: 3 hours ago
> :::::: commit date: 3 hours ago
>
> If you fix the issue, kindly add following tag
> Reported-by: kbuild test robot <lkp@intel.com>
>
> All error/warnings (new ones prefixed by >>):
>
> In file included from include/asm-generic/pgtable-nopud.h:8:0,
> from arch/ia64/include/asm/pgtable.h:591,
> from include/linux/mm.h:99,
> from include/linux/highmem.h:8,
> from mm/arch_pgtable_test.c:14:
> mm/arch_pgtable_test.c: In function 'pud_clear_tests':
>>> include/asm-generic/pgtable-nop4d-hack.h:47:32: error: implicit declaration of function '__pgd'; did you mean '__p4d'? [-Werror=implicit-function-declaration]
> #define __pud(x) ((pud_t) { __pgd(x) })
> ^
>>> mm/arch_pgtable_test.c:162:8: note: in expansion of macro '__pud'
> pud = __pud(pud_val(pud) | RANDOM_ORVALUE);
> ^~~~~
>>> include/asm-generic/pgtable-nop4d-hack.h:47:22: warning: missing braces around initializer [-Wmissing-braces]
> #define __pud(x) ((pud_t) { __pgd(x) })
> ^
>>> mm/arch_pgtable_test.c:162:8: note: in expansion of macro '__pud'
> pud = __pud(pud_val(pud) | RANDOM_ORVALUE);
> ^~~~~
> cc1: some warnings being treated as errors
>
> # https://github.com/0day-ci/linux/commit/49047f93b076974eefa5b019311bd3b734d61f8c
> git remote add linux-review https://github.com/0day-ci/linux
> git remote update linux-review
> git checkout 49047f93b076974eefa5b019311bd3b734d61f8c
> vim +47 include/asm-generic/pgtable-nop4d-hack.h
>
> 30ec842660bd0d Kirill A. Shutemov 2017-03-09 45
> 30ec842660bd0d Kirill A. Shutemov 2017-03-09 46 #define pud_val(x) (pgd_val((x).pgd))
> 30ec842660bd0d Kirill A. Shutemov 2017-03-09 @47 #define __pud(x) ((pud_t) { __pgd(x) })
I had mentioned about this build failure in the cover letter. The same
problem also exists on arm32 platform.
- Anshuman
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH V7 0/2] mailbox: arm: introduce smc triggered mailbox
From: Peng Fan @ 2019-09-23 6:36 UTC (permalink / raw)
To: robh+dt@kernel.org, mark.rutland@arm.com,
jassisinghbrar@gmail.com, sudeep.holla@arm.com,
andre.przywara@arm.com, f.fainelli@gmail.com
Cc: devicetree@vger.kernel.org, Peng Fan,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, dl-linux-imx
From: Peng Fan <peng.fan@nxp.com>
V7:
Typo fix
#mbox-cells changed to 0
Add a new header file arm-smccc-mbox.h
Use ARM_SMCCC_IS_64
Andre,
The function_id is still kept in arm_smccc_mbox_cmd, because arm,func-id
property is optional, so clients could pass function_id to mbox driver.
V6:
Switch to per-channel a mbox controller
Drop arm,num-chans, transports, method
Add arm,hvc-mbox compatible
Fix smc/hvc args, drop client id and use correct type.
https://patchwork.kernel.org/cover/11146641/
V5:
yaml fix
https://patchwork.kernel.org/cover/11117741/
V4:
yaml fix for num-chans in patch 1/2.
https://patchwork.kernel.org/cover/11116521/
V3:
Drop interrupt
Introduce transports for mem/reg usage
Add chan-id for mem usage
Convert to yaml format
https://patchwork.kernel.org/cover/11043541/
V2:
This is a modified version from Andre Przywara's patch series
https://lore.kernel.org/patchwork/cover/812997/.
The modification are mostly:
Introduce arm,num-chans
Introduce arm_smccc_mbox_cmd
txdone_poll and txdone_irq are both set to false
arm,func-ids are kept, but as an optional property.
Rewords SCPI to SCMI, because I am trying SCMI over SMC, not SCPI.
Introduce interrupts notification.
[1] is a draft implementation of i.MX8MM SCMI ATF implementation that
use smc as mailbox, power/clk is included, but only part of clk has been
implemented to work with hardware, power domain only supports get name
for now.
The traditional Linux mailbox mechanism uses some kind of dedicated hardware
IP to signal a condition to some other processing unit, typically a dedicated
management processor.
This mailbox feature is used for instance by the SCMI protocol to signal a
request for some action to be taken by the management processor.
However some SoCs does not have a dedicated management core to provide
those services. In order to service TEE and to avoid linux shutdown
power and clock that used by TEE, need let firmware to handle power
and clock, the firmware here is ARM Trusted Firmware that could also
run SCMI service.
The existing SCMI implementation uses a rather flexible shared memory
region to communicate commands and their parameters, it still requires a
mailbox to actually trigger the action.
This patch series provides a Linux mailbox compatible service which uses
smc calls to invoke firmware code, for instance taking care of SCMI requests.
The actual requests are still communicated using the standard SCMI way of
shared memory regions, but a dedicated mailbox hardware IP can be replaced via
this new driver.
This simple driver uses the architected SMC calling convention to trigger
firmware services, also allows for using "HVC" calls to call into hypervisors
or firmware layers running in the EL2 exception level.
Patch 1 contains the device tree binding documentation, patch 2 introduces
the actual mailbox driver.
Please note that this driver just provides a generic mailbox mechanism,
It could support synchronous TX/RX, or synchronous TX with asynchronous
RX. And while providing SCMI services was the reason for this exercise,
this driver is in no way bound to this use case, but can be used generically
where the OS wants to signal a mailbox condition to firmware or a
hypervisor.
Also the driver is in no way meant to replace any existing firmware
interface, but actually to complement existing interfaces.
[1] https://github.com/MrVan/arm-trusted-firmware/tree/scmi
Peng Fan (2):
dt-bindings: mailbox: add binding doc for the ARM SMC/HVC mailbox
mailbox: introduce ARM SMC based mailbox
.../devicetree/bindings/mailbox/arm-smc.yaml | 95 ++++++++++++
drivers/mailbox/Kconfig | 7 +
drivers/mailbox/Makefile | 2 +
drivers/mailbox/arm-smc-mailbox.c | 168 +++++++++++++++++++++
4 files changed, 272 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mailbox/arm-smc.yaml
create mode 100644 drivers/mailbox/arm-smc-mailbox.c
--
2.16.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH V7 1/2] dt-bindings: mailbox: add binding doc for the ARM SMC/HVC mailbox
From: Peng Fan @ 2019-09-23 6:37 UTC (permalink / raw)
To: robh+dt@kernel.org, mark.rutland@arm.com,
jassisinghbrar@gmail.com, sudeep.holla@arm.com,
andre.przywara@arm.com, f.fainelli@gmail.com
Cc: devicetree@vger.kernel.org, Peng Fan,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, dl-linux-imx
In-Reply-To: <1569220514-27903-1-git-send-email-peng.fan@nxp.com>
From: Peng Fan <peng.fan@nxp.com>
The ARM SMC/HVC mailbox binding describes a firmware interface to trigger
actions in software layers running in the EL2 or EL3 exception levels.
The term "ARM" here relates to the SMC instruction as part of the ARM
instruction set, not as a standard endorsed by ARM Ltd.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
.../devicetree/bindings/mailbox/arm-smc.yaml | 95 ++++++++++++++++++++++
1 file changed, 95 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mailbox/arm-smc.yaml
diff --git a/Documentation/devicetree/bindings/mailbox/arm-smc.yaml b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml
new file mode 100644
index 000000000000..8764ad2726b2
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml
@@ -0,0 +1,95 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mailbox/arm-smc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ARM SMC Mailbox Interface
+
+maintainers:
+ - Peng Fan <peng.fan@nxp.com>
+
+description: |
+ This mailbox uses the ARM smc (secure monitor call) or hvc (hypervisor
+ call) instruction to trigger a mailbox-connected activity in firmware,
+ executing on the very same core as the caller. The value of r0/w0/x0
+ the firmware returns after the smc call is delivered as a received
+ message to the mailbox framework, so synchronous communication can be
+ established. The exact meaning of the action the mailbox triggers as
+ well as the return value is defined by their users and is not subject
+ to this binding.
+
+ One example use case of this mailbox is the SCMI interface, which uses
+ shared memory to transfer commands and parameters, and a mailbox to
+ trigger a function call. This allows SoCs without a separate management
+ processor (or when such a processor is not available or used) to use
+ this standardized interface anyway.
+
+ This binding describes no hardware, but establishes a firmware interface.
+ Upon receiving an SMC using the described SMC function identifier, the
+ firmware is expected to trigger some mailbox connected functionality.
+ The communication follows the ARM SMC calling convention.
+ Firmware expects an SMC function identifier in r0 or w0. The supported
+ identifier are passed from consumers, or listed in the the arm,func-id
+ property as described below. The firmware can return one value in
+ the first SMC result register, it is expected to be an error value,
+ which shall be propagated to the mailbox client.
+
+ Any core which supports the SMC or HVC instruction can be used, as long
+ as a firmware component running in EL3 or EL2 is handling these calls.
+
+properties:
+ compatible:
+ oneOf:
+ - description:
+ For implementations using ARM SMC instruction.
+ const: arm,smc-mbox
+
+ - description:
+ For implementations using ARM HVC instruction.
+ const: arm,hvc-mbox
+
+ "#mbox-cells":
+ const: 0
+
+ arm,func-id:
+ description: |
+ An single 32-bit value specifying the function ID used by the mailbox.
+ The function ID follows the ARM SMC calling convention standard.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+required:
+ - compatible
+ - "#mbox-cells"
+
+examples:
+ - |
+ sram@93f000 {
+ compatible = "mmio-sram";
+ reg = <0x0 0x93f000 0x0 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x0 0x93f000 0x1000>;
+
+ cpu_scp_lpri: scp-shmem@0 {
+ compatible = "arm,scmi-shmem";
+ reg = <0x0 0x200>;
+ };
+ };
+
+ smc_tx_mbox: tx_mbox {
+ #mbox-cells = <0>;
+ compatible = "arm,smc-mbox";
+ arm,func-id = <0xc20000fe>;
+ };
+
+ firmware {
+ scmi {
+ compatible = "arm,scmi";
+ mboxes = <&smc_tx_mbox>;
+ mbox-names = "tx";
+ shmem = <&cpu_scp_lpri>;
+ };
+ };
+
+...
--
2.16.4
_______________________________________________
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 V7 2/2] mailbox: introduce ARM SMC based mailbox
From: Peng Fan @ 2019-09-23 6:37 UTC (permalink / raw)
To: robh+dt@kernel.org, mark.rutland@arm.com,
jassisinghbrar@gmail.com, sudeep.holla@arm.com,
andre.przywara@arm.com, f.fainelli@gmail.com
Cc: devicetree@vger.kernel.org, Peng Fan,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, dl-linux-imx
In-Reply-To: <1569220514-27903-1-git-send-email-peng.fan@nxp.com>
From: Peng Fan <peng.fan@nxp.com>
This mailbox driver implements a mailbox which signals transmitted data
via an ARM smc (secure monitor call) instruction. The mailbox receiver
is implemented in firmware and can synchronously return data when it
returns execution to the non-secure world again.
An asynchronous receive path is not implemented.
This allows the usage of a mailbox to trigger firmware actions on SoCs
which either don't have a separate management processor or on which such
a core is not available. A user of this mailbox could be the SCP
interface.
Modified from Andre Przywara's v2 patch
https://lore.kernel.org/patchwork/patch/812999/
Cc: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
drivers/mailbox/Kconfig | 7 ++
drivers/mailbox/Makefile | 2 +
drivers/mailbox/arm-smc-mailbox.c | 168 ++++++++++++++++++++++++++++++++++++++
3 files changed, 177 insertions(+)
create mode 100644 drivers/mailbox/arm-smc-mailbox.c
diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index ab4eb750bbdd..7707ee26251a 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -16,6 +16,13 @@ config ARM_MHU
The controller has 3 mailbox channels, the last of which can be
used in Secure mode only.
+config ARM_SMC_MBOX
+ tristate "Generic ARM smc mailbox"
+ depends on OF && HAVE_ARM_SMCCC
+ help
+ Generic mailbox driver which uses ARM smc calls to call into
+ firmware for triggering mailboxes.
+
config IMX_MBOX
tristate "i.MX Mailbox"
depends on ARCH_MXC || COMPILE_TEST
diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
index c22fad6f696b..93918a84c91b 100644
--- a/drivers/mailbox/Makefile
+++ b/drivers/mailbox/Makefile
@@ -7,6 +7,8 @@ obj-$(CONFIG_MAILBOX_TEST) += mailbox-test.o
obj-$(CONFIG_ARM_MHU) += arm_mhu.o
+obj-$(CONFIG_ARM_SMC_MBOX) += arm-smc-mailbox.o
+
obj-$(CONFIG_IMX_MBOX) += imx-mailbox.o
obj-$(CONFIG_ARMADA_37XX_RWTM_MBOX) += armada-37xx-rwtm-mailbox.o
diff --git a/drivers/mailbox/arm-smc-mailbox.c b/drivers/mailbox/arm-smc-mailbox.c
new file mode 100644
index 000000000000..664c8b4a0ed0
--- /dev/null
+++ b/drivers/mailbox/arm-smc-mailbox.c
@@ -0,0 +1,168 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2016,2017 ARM Ltd.
+ * Copyright 2019 NXP
+ */
+
+#include <linux/arm-smccc.h>
+#include <linux/device.h>
+#include <linux/kernel.h>
+#include <linux/interrupt.h>
+#include <linux/mailbox_controller.h>
+#include <linux/mailbox/arm-smccc-mbox.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+
+struct arm_smc_chan_data {
+ unsigned int function_id;
+};
+
+typedef unsigned long (smc_mbox_fn)(unsigned int, unsigned long,
+ unsigned long, unsigned long,
+ unsigned long, unsigned long,
+ unsigned long);
+static smc_mbox_fn *invoke_smc_mbox_fn;
+
+static int arm_smc_send_data(struct mbox_chan *link, void *data)
+{
+ struct arm_smc_chan_data *chan_data = link->con_priv;
+ struct arm_smccc_mbox_cmd *cmd = data;
+ unsigned long ret;
+ u32 function_id;
+
+ function_id = chan_data->function_id;
+ if (!function_id)
+ function_id = cmd->function_id;
+
+ if (ARM_SMCCC_IS_64(function_id)) {
+ ret = invoke_smc_mbox_fn(function_id, cmd->args_smccc64[0],
+ cmd->args_smccc64[1],
+ cmd->args_smccc64[2],
+ cmd->args_smccc64[3],
+ cmd->args_smccc64[4],
+ cmd->args_smccc64[5]);
+ } else {
+ ret = invoke_smc_mbox_fn(function_id, cmd->args_smccc32[0],
+ cmd->args_smccc32[1],
+ cmd->args_smccc32[2],
+ cmd->args_smccc32[3],
+ cmd->args_smccc32[4],
+ cmd->args_smccc32[5]);
+ }
+
+ mbox_chan_received_data(link, (void *)ret);
+
+ return 0;
+}
+
+static unsigned long __invoke_fn_hvc(unsigned int function_id,
+ unsigned long arg0, unsigned long arg1,
+ unsigned long arg2, unsigned long arg3,
+ unsigned long arg4, unsigned long arg5)
+{
+ struct arm_smccc_res res;
+
+ arm_smccc_hvc(function_id, arg0, arg1, arg2, arg3, arg4,
+ arg5, 0, &res);
+ return res.a0;
+}
+
+static unsigned long __invoke_fn_smc(unsigned int function_id,
+ unsigned long arg0, unsigned long arg1,
+ unsigned long arg2, unsigned long arg3,
+ unsigned long arg4, unsigned long arg5)
+{
+ struct arm_smccc_res res;
+
+ arm_smccc_smc(function_id, arg0, arg1, arg2, arg3, arg4,
+ arg5, 0, &res);
+ return res.a0;
+}
+
+static const struct mbox_chan_ops arm_smc_mbox_chan_ops = {
+ .send_data = arm_smc_send_data,
+};
+
+static struct mbox_chan *
+arm_smc_mbox_of_xlate(struct mbox_controller *mbox,
+ const struct of_phandle_args *sp)
+{
+ return mbox->chans;
+}
+
+static int arm_smc_mbox_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct mbox_controller *mbox;
+ struct arm_smc_chan_data *chan_data;
+ int ret;
+ u32 function_id = 0;
+
+ if (of_device_is_compatible(dev->of_node, "arm,smc-mbox"))
+ invoke_smc_mbox_fn = __invoke_fn_smc;
+ else
+ invoke_smc_mbox_fn = __invoke_fn_hvc;
+
+ mbox = devm_kzalloc(dev, sizeof(*mbox), GFP_KERNEL);
+ if (!mbox)
+ return -ENOMEM;
+
+ mbox->of_xlate = arm_smc_mbox_of_xlate;
+ mbox->num_chans = 1;
+ mbox->chans = devm_kzalloc(dev, sizeof(*mbox->chans), GFP_KERNEL);
+ if (!mbox->chans)
+ return -ENOMEM;
+
+ chan_data = devm_kzalloc(dev, sizeof(*chan_data), GFP_KERNEL);
+ if (!chan_data)
+ return -ENOMEM;
+
+ of_property_read_u32(dev->of_node, "arm,func-id", &function_id);
+ chan_data->function_id = function_id;
+
+ mbox->chans->con_priv = chan_data;
+
+ mbox->txdone_poll = false;
+ mbox->txdone_irq = false;
+ mbox->ops = &arm_smc_mbox_chan_ops;
+ mbox->dev = dev;
+
+ platform_set_drvdata(pdev, mbox);
+
+ ret = devm_mbox_controller_register(dev, mbox);
+ if (ret)
+ return ret;
+
+ dev_info(dev, "ARM SMC mailbox enabled.\n");
+
+ return ret;
+}
+
+static int arm_smc_mbox_remove(struct platform_device *pdev)
+{
+ struct mbox_controller *mbox = platform_get_drvdata(pdev);
+
+ mbox_controller_unregister(mbox);
+ return 0;
+}
+
+static const struct of_device_id arm_smc_mbox_of_match[] = {
+ { .compatible = "arm,smc-mbox", },
+ { .compatible = "arm,hvc-mbox", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, arm_smc_mbox_of_match);
+
+static struct platform_driver arm_smc_mbox_driver = {
+ .driver = {
+ .name = "arm-smc-mbox",
+ .of_match_table = arm_smc_mbox_of_match,
+ },
+ .probe = arm_smc_mbox_probe,
+ .remove = arm_smc_mbox_remove,
+};
+module_platform_driver(arm_smc_mbox_driver);
+
+MODULE_AUTHOR("Peng Fan <peng.fan@nxp.com>");
+MODULE_DESCRIPTION("Generic ARM smc mailbox driver");
+MODULE_LICENSE("GPL v2");
--
2.16.4
_______________________________________________
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] soc: ti: ti_sci_pm_domains: Store device id in platform device
From: Tero Kristo @ 2019-09-23 6:37 UTC (permalink / raw)
To: Lokesh Vutla, Nishanth Menon, Santosh Shilimkar
Cc: Sekhar Nori, Linux ARM Mailing List
In-Reply-To: <20190923033439.20070-1-lokeshvutla@ti.com>
On 23/09/2019 06:34, Lokesh Vutla wrote:
> Device ID that is passed from power-domains is used by peripheral
> drivers for communicating with sysfw. Instead of individual drivers
> traversing power-domains entry in DT node, store the device ID in
> platform_device so that drivers can directly access it.
Uhm, isn't this kind of wrong place to allocate the ID? The power domain
solution itself is a client also. In theory, someone could access the
pdev->id before this. pdev->id should be assigned by bus driver so that
it can be properly handled within platform_device_add.
-Tero
>
> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
> ---
> drivers/soc/ti/ti_sci_pm_domains.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/soc/ti/ti_sci_pm_domains.c b/drivers/soc/ti/ti_sci_pm_domains.c
> index 8c2a2f23982c..a124ac409124 100644
> --- a/drivers/soc/ti/ti_sci_pm_domains.c
> +++ b/drivers/soc/ti/ti_sci_pm_domains.c
> @@ -116,6 +116,7 @@ static int ti_sci_pd_attach_dev(struct generic_pm_domain *domain,
> struct of_phandle_args pd_args;
> struct ti_sci_pm_domain *ti_sci_genpd = genpd_to_ti_sci_pd(domain);
> const struct ti_sci_handle *ti_sci = ti_sci_genpd->ti_sci;
> + struct platform_device *pdev = to_platform_device(dev);
> struct ti_sci_genpd_dev_data *sci_dev_data;
> struct generic_pm_domain_data *genpd_data;
> int idx, ret = 0;
> @@ -129,6 +130,7 @@ static int ti_sci_pd_attach_dev(struct generic_pm_domain *domain,
> return -EINVAL;
>
> idx = pd_args.args[0];
> + pdev->id = idx;
>
> /*
> * Check the validity of the requested idx, if the index is not valid
>
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFT v3 4/8] ARM: dts: exynos: Remove MCT subnode for interrupt map on Exynos4210
From: Marek Szyprowski @ 2019-09-23 6:56 UTC (permalink / raw)
To: Krzysztof Kozlowski, Daniel Lezcano, Thomas Gleixner, Rob Herring,
Mark Rutland, Kukjin Kim, linux-kernel, devicetree,
linux-arm-kernel, linux-samsung-soc
Cc: Sylwester Nawrocki, Bartlomiej Zolnierkiewicz
In-Reply-To: <20190921170152.5033-4-krzk@kernel.org>
Hi Krzysztof,
On 21.09.2019 19:01, Krzysztof Kozlowski wrote:
> Multi Core Timer node has interrupts routed to two different parents -
> GIC and combiner. This was modeled with a interrupt-map within a
> subnode but can be expressed in an easier and more common way, directly
> in the node itself.
Maybe we should simply use 'interrupts-extended' based approach and
simplify mct node even more (get rid of interrupt-parent, interrupts,
size/address cells)?
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
>
> ---
>
> Not tested.
> ---
> arch/arm/boot/dts/exynos4210.dtsi | 16 ++++++----------
> 1 file changed, 6 insertions(+), 10 deletions(-)
>
> diff --git a/arch/arm/boot/dts/exynos4210.dtsi b/arch/arm/boot/dts/exynos4210.dtsi
> index 6d3f19562aab..38c49ab8c733 100644
> --- a/arch/arm/boot/dts/exynos4210.dtsi
> +++ b/arch/arm/boot/dts/exynos4210.dtsi
> @@ -109,23 +109,19 @@
> mct: timer@10050000 {
> compatible = "samsung,exynos4210-mct";
> reg = <0x10050000 0x800>;
> - interrupt-parent = <&mct_map>;
> - interrupts = <0>, <1>, <2>, <3>, <4>, <5>;
> clocks = <&clock CLK_FIN_PLL>, <&clock CLK_MCT>;
> clock-names = "fin_pll", "mct";
> -
> - mct_map: mct-map {
> - #interrupt-cells = <1>;
> - #address-cells = <0>;
> - #size-cells = <0>;
> - interrupt-map =
> - <0 &gic 0 57 IRQ_TYPE_LEVEL_HIGH>,
> + #address-cells = <0>;
> + #size-cells = <0>;
> + #interrupt-cells = <1>;
> + interrupt-parent = <&mct>;
> + interrupts = <0>, <1>, <2>, <3>, <4>, <5>;
> + interrupt-map = <0 &gic 0 57 IRQ_TYPE_LEVEL_HIGH>,
> <1 &gic 0 69 IRQ_TYPE_LEVEL_HIGH>,
> <2 &combiner 12 6>,
> <3 &combiner 12 7>,
> <4 &gic 0 42 IRQ_TYPE_LEVEL_HIGH>,
> <5 &gic 0 48 IRQ_TYPE_LEVEL_HIGH>;
> - };
> };
>
> watchdog: watchdog@10060000 {
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFT v3 4/8] ARM: dts: exynos: Remove MCT subnode for interrupt map on Exynos4210
From: Krzysztof Kozlowski @ 2019-09-23 7:13 UTC (permalink / raw)
To: Marek Szyprowski
Cc: Mark Rutland, devicetree, linux-samsung-soc,
Bartlomiej Zolnierkiewicz, Sylwester Nawrocki, Daniel Lezcano,
linux-kernel, Rob Herring, Kukjin Kim, Thomas Gleixner,
linux-arm-kernel
In-Reply-To: <c1d02aa3-b5f2-1c5b-0b7b-8749e7c0ce9a@samsung.com>
On Mon, Sep 23, 2019 at 08:56:46AM +0200, Marek Szyprowski wrote:
> Hi Krzysztof,
>
> On 21.09.2019 19:01, Krzysztof Kozlowski wrote:
> > Multi Core Timer node has interrupts routed to two different parents -
> > GIC and combiner. This was modeled with a interrupt-map within a
> > subnode but can be expressed in an easier and more common way, directly
> > in the node itself.
>
> Maybe we should simply use 'interrupts-extended' based approach and
> simplify mct node even more (get rid of interrupt-parent, interrupts,
> size/address cells)?
Indeed, that looks like the tool for this job. Thanks for hint, I'll try
it.
Best regards,
Krzysztof
_______________________________________________
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/3] pinctrl: meson-a1: add pinctrl driver for Meson A1 Soc
From: Qianggui Song @ 2019-09-23 7:29 UTC (permalink / raw)
To: Jerome Brunet
Cc: Mark Rutland, Hanjie Lin, Jianxin Pan, Neil Armstrong,
Martin Blumenstingl, Kevin Hilman, Linus Walleij, linux-kernel,
linux-gpio, Rob Herring, linux-arm-kernel, Carlo Caione,
linux-amlogic, Xingyu Chen
In-Reply-To: <1jk1a4b6c8.fsf@starbuckisacylon.baylibre.com>
On 2019/9/20 0:26, Jerome Brunet wrote:
> On Wed 18 Sep 2019 at 14:36, Qianggui Song <qianggui.song@amlogic.com> wrote:
>
>> On 2019/9/17 22:07, Jerome Brunet wrote:
>>>
>>> On Tue 17 Sep 2019 at 13:51, Qianggui Song <qianggui.song@amlogic.com> wrote:
>>>>>> diff --git a/drivers/pinctrl/meson/pinctrl-meson.c b/drivers/pinctrl/meson/pinctrl-meson.c
>>>>>> index 8bba9d0..885b89d 100644
>>>>>> --- a/drivers/pinctrl/meson/pinctrl-meson.c
>>>>>> +++ b/drivers/pinctrl/meson/pinctrl-meson.c
>>>>>> @@ -688,8 +688,12 @@ static int meson_pinctrl_parse_dt(struct meson_pinctrl *pc,
>>>>>>
>>>>>> pc->reg_ds = meson_map_resource(pc, gpio_np, "ds");
>>>>>> if (IS_ERR(pc->reg_ds)) {
>>>>>> - dev_dbg(pc->dev, "ds registers not found - skipping\n");
>>>>>> - pc->reg_ds = NULL;
>>>>>> + if (pc->data->reg_layout == A1_LAYOUT) {
>>>>>> + pc->reg_ds = pc->reg_pullen;
>>>>>
>>>>> IMO, this kind of ID based init fixup is not going to scale and will
>>>>> lead to something difficult to maintain in the end.
>>>>>
>>>>> The way the different register sets interract with each other is already
>>>>> pretty complex to follow.
>>>>>
>>>>> You could rework this in 2 different ways:
>>>>> #1 - Have the generic function parse all the register sets and have all
>>>>> drivers provide a specific (as in gxbb, gxl, axg, etc ...) function to :
>>>>> - Verify the expected sets have been provided
>>>>> - Make assignement fixup as above if necessary
>>>>>
>>>>> #2 - Rework the driver to have only one single register region
>>>>> I think one of your colleague previously mentionned this was not
>>>>> possible. It is still unclear to me why ...
>>>>>
>>>> Appreciate your advice. I have an idea based on #1, how about providing
>>>> only two dt parse function, one is for chips before A1(the old one),
>>>> another is for A1 and later chips that share the same layout. Assign
>>>> these two functions to their own driver.
>>>
>>> That's roughly the same thing as your initial proposition with function
>>> pointer instead of IDs ... IMO, this would still be a quick fix to
>>> address your immediate topic instead of dealing with the driver as
>>> whole, which is my concern here.
>>>
>> For #1. It would be like
>> generic_parse_dt()
>> {
>> 1. parse all register regions (mux gpio pull pull_en ds)
>>
>> 2. call specific function through function pointer in
>> meson_pinctrl_data.(each platform should have AO and EE two
>> specific functions for they are not the same)
>> {
>> do work you mentioned above
>> }
>> }
>> right ?
>> If that so, maybe there are a lot of duplicated codes
>
> Only if you make it so. Providing a callback and duplicating code are
> not the same thing
>
>> for most Socs share the same reg layout.
>
> That's not really accurate:
>
> So far they all have the "mux" and "gpio" region but
>
> gxbb, gxl, axg, meson8 EE:
> has: pull, pull-en
> remap: non
> unsupported: ds
>
> gxbb, gxl, axg, meson8 AO:
> has: pull
> remap: pull-en -> pull
> unsupported: ds
>
> g12 and sm1 EE:
> has: pull, pull-en, ds
> remap: none
>
> g12 and sm1 AO:
> has: ds
> remap: pull->gpio, pull_en->gpio
>
> And now a1 chip remaps "ds" to "pull_en" ...
>
> As said previouly all this is getting pretty difficult to follow and
> maintain. Adding a proper callback for each meson pinctrl would make the
> above explicit in the code ... which helps maintain thing, at least for
> a while ...
>
> Judging by the offsets between those regions, I still think one single
> region would make things a whole lot simpler. If it is not possible to
> map it with one single region, could you tell us why ? What non-pinctrl
> related device do we have there ?
>Here I mean duplicated is that m8/m8b/gxl/gxbb/axg use the same layout,
while g12a/b/sm1 are the same, so don't need to implement every Socs
parser functions just as I said below AXG type for m8/m8b/gxl/gxbb/axg,
g12a type for g12a/b/sm1, the last one is for a1. three types functions
(with ao and ee) can cover all platform. But I still consider that
providing an extra meson_a1_pasert_dt like function for a1 or later is
more simpler.
The reason why we can not use one single region for previous Socs, it'
that there is non-pinctrl related device for some Socs region.
Take an example for g12a:
#define PREG_PAD_GPIO0_EN_N (0xff634400 + (0x010 << 2))
#define PREG_PAD_GPIO0_O (0xff634400 + (0x011 << 2))
#define PREG_PAD_GPIO0_I (0xff634400 + (0x012 << 2))
...continue region...
#define PAD_PULL_UP_EN_REG5 (0xff634400 + (0x04d << 2))
... ETH/NAND/VPU/TIMER... a lot of no-pinctrl registers
#define PERIPHS_PIN_MUX_0 (0xff634400 + (0x0b0 << 2))
...continue region...
#define PERIPHS_PIN_MUX_F (0xff634400 + (0x0bf << 2))
...no use region...
#define EFUSE_CFG_LOCK (0xff634400 + (0x0c0 << 2))
...other EFUSE relative registers...
...no use region...
#define PAD_DS_REG0A (0xff634400 + (0x0d0 << 2))
...continue region for all ds...
#define PAD_DS_REG5A (0xff634400 + (0x0d6 << 2))
So from the above we can see there are lots of other registers between
gpio and ds register.When map gpio to ds region, they will bury a lot of
other registers.
>> So I guess five specific functions are
>> enough: AXG and before(ao,ee), G12A(ao,ee) and A1(will place them in
>> pinctrl_meson.c). Since m8 to AXG are the same register layout for both
>> ee and ao, G12A with new feature ds and new ao register layout.
>>
>> Or I misunderstood the #1 ?
>>>>>> + } else {
>>>>>> + dev_dbg(pc->dev, "ds registers not found - skipping\n");
>>>>>> + pc->reg_ds = NULL;
>>>>>> + }
>>>>>> }
>>>>>>
>>>>>> return 0;
>>>>>> diff --git a/drivers/pinctrl/meson/pinctrl-meson.h b/drivers/pinctrl/meson/pinctrl-meson.h
>>>>>> index c696f32..3d0c58d 100644
>>>>>> --- a/drivers/pinctrl/meson/pinctrl-meson.h
>>>>>> +++ b/drivers/pinctrl/meson/pinctrl-meson.h
>>>>>> @@ -80,6 +80,14 @@ enum meson_pinconf_drv {
>>>>>> };
>>>>>>
>>>>>> /**
>>>>>> + * enum meson_reg_layout - identify two types of reg layout
>>>>>> + */
>>>>>> +enum meson_reg_layout {
>>>>>> + LEGACY_LAYOUT,
>>>>>> + A1_LAYOUT,
>>>>>> +};
>>>>>> +
>>>>>> +/**
>>>>>> * struct meson bank
>>>>>> *
>>>>>> * @name: bank name
>>>>>> @@ -114,6 +122,7 @@ struct meson_pinctrl_data {
>>>>>> unsigned int num_banks;
>>>>>> const struct pinmux_ops *pmx_ops;
>>>>>> void *pmx_data;
>>>>>> + unsigned int reg_layout;
>>>>>> };
>>>>>>
>>>>>> struct meson_pinctrl {
>>>>>
>>>>> .
>>>>>
>>>
>>> .
>>>
>
> .
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH net] net: stmmac: selftests: Flow Control test can also run with ASYM Pause
From: Jose Abreu @ 2019-09-23 7:30 UTC (permalink / raw)
To: netdev
Cc: Jose Abreu, Joao Pinto, Alexandre Torgue, linux-kernel,
linux-stm32, Maxime Coquelin, Giuseppe Cavallaro, David S. Miller,
linux-arm-kernel
From: Jose Abreu <joabreu@synopsys.com>
The Flow Control selftest is also available with ASYM Pause. Lets add
this check to the test and fix eventual false positive failures.
Fixes: 091810dbded9 ("net: stmmac: Introduce selftests support")
Signed-off-by: Jose Abreu <Jose.Abreu@synopsys.com>
---
Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Cc: Alexandre Torgue <alexandre.torgue@st.com>
Cc: Jose Abreu <joabreu@synopsys.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
Cc: netdev@vger.kernel.org
Cc: linux-stm32@st-md-mailman.stormreply.com
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c
index 9c8d210b2d6a..5f66f6161629 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c
@@ -670,7 +670,7 @@ static int stmmac_test_flowctrl(struct stmmac_priv *priv)
unsigned int pkt_count;
int i, ret = 0;
- if (!phydev || !phydev->pause)
+ if (!phydev || (!phydev->pause && !phydev->asym_pause))
return -EOPNOTSUPP;
tpriv = kzalloc(sizeof(*tpriv), GFP_KERNEL);
--
2.7.4
_______________________________________________
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 net] net: stmmac: selftests: Flow Control test can also run with ASYM Pause
From: Jose Abreu @ 2019-09-23 7:32 UTC (permalink / raw)
To: Jakub Kicinski, Jose Abreu
Cc: Joao Pinto, Alexandre Torgue, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com, Maxime Coquelin,
Giuseppe Cavallaro, David S. Miller,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190922145642.55453135@cakuba.netronome.com>
From: Jakub Kicinski <jakub.kicinski@netronome.com>
Date: Sep/22/2019, 22:56:42 (UTC+00:00)
> On Thu, 19 Sep 2019 12:09:49 +0200, Jose Abreu wrote:
> > The Flow Control selftest is also available with ASYM Pause. Lets add
> > this check to the test and fix eventual false positive failures.
> >
> > Fixes: 091810dbded9 ("net: stmmac: Introduce selftests support")
> > Signed-off-by: Jose Abreu <joabreu@synopsys.com>
>
> Hi Jose!
>
> Thanks for the patch it looks good, seems like you posted it from
> a slightly different email address than was used for signoff:
>
> From: Jose Abreu <Jose.Abreu@synopsys.com>
> vs
> Signed-off-by: Jose Abreu <joabreu@synopsys.com>
>
> Could you please fix and repost? Automation may get upset otherwise.
Yeah that's my external vs. internal email messing around. Any of them
works though. I resent it using the external one. Can you please take a
look ?
---
Thanks,
Jose Miguel Abreu
_______________________________________________
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 0/5] net: ethernet: stmmac: some fixes and optimization
From: Christophe ROULLIER @ 2019-09-23 7:46 UTC (permalink / raw)
To: Jakub Kicinski
Cc: mark.rutland@arm.com, robh@kernel.org, Alexandre TORGUE,
devicetree@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com, joabreu@synopsys.com,
andrew@lunn.ch, mcoquelin.stm32@gmail.com, Peppe CAVALLARO,
davem@davemloft.net, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190922151257.51173d89@cakuba.netronome.com>
Hi Jakub, all,
It is not urgent, no problem to wait next merge window (release 5.5)
For patch 1 and 3, it is improvement/cleanup because now syscfg clock is
not mandatory (I put code backward compatible).
Regards,
Christophe
On 9/23/19 12:12 AM, Jakub Kicinski wrote:
> On Fri, 20 Sep 2019 07:38:12 +0200, Christophe Roullier wrote:
>> Some improvements (manage syscfg as optional clock, update slew rate of
>> ETH_MDIO pin, Enable gating of the MAC TX clock during TX low-power mode)
>> Fix warning build message when W=1
> There seems to be some new features/cleanups (or improvements as
> you say) here. Could you explain the negative impact not applying
> these changes will have? Patches 1 and 3 in particular.
>
> net-next is now closed [1], and will reopen some time after the merge
> window is over. For now we are only expecting fixes for the net tree.
>
> Could you (a) provide stronger motivation these changes are fixes; or
> (b) separate the fixes from improvements?
>
> Thank you!
>
> [1] https://www.kernel.org/doc/html/latest/networking/netdev-FAQ.html
_______________________________________________
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] net: stmmac: selftests: Flow Control test can also run with ASYM Pause
From: Jose Abreu @ 2019-09-23 7:47 UTC (permalink / raw)
To: Jose Abreu, netdev@vger.kernel.org
Cc: Joao Pinto, Alexandre Torgue, linux-kernel@vger.kernel.org,
David S. Miller, Maxime Coquelin, Giuseppe Cavallaro,
linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <da7e2fb08061b4b89332c0ef014e053f98832894.1569223775.git.Jose.Abreu@synopsys.com>
From: Jose Abreu <Jose.Abreu@synopsys.com>
Date: Sep/23/2019, 08:30:43 (UTC+00:00)
> From: Jose Abreu <joabreu@synopsys.com>
>
> The Flow Control selftest is also available with ASYM Pause. Lets add
> this check to the test and fix eventual false positive failures.
>
> Fixes: 091810dbded9 ("net: stmmac: Introduce selftests support")
> Signed-off-by: Jose Abreu <Jose.Abreu@synopsys.com>
Oops, "From:" and "Signed-off-by:" are still different. I'll amend this
and re-submit. Please disregard this one.
---
Thanks,
Jose Miguel Abreu
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH net v2] net: stmmac: selftests: Flow Control test can also run with ASYM Pause
From: Jose Abreu @ 2019-09-23 7:49 UTC (permalink / raw)
To: netdev
Cc: Jose Abreu, Joao Pinto, Alexandre Torgue, linux-kernel,
linux-stm32, Maxime Coquelin, Giuseppe Cavallaro, David S. Miller,
linux-arm-kernel
The Flow Control selftest is also available with ASYM Pause. Lets add
this check to the test and fix eventual false positive failures.
Fixes: 091810dbded9 ("net: stmmac: Introduce selftests support")
Signed-off-by: Jose Abreu <Jose.Abreu@synopsys.com>
---
Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Cc: Alexandre Torgue <alexandre.torgue@st.com>
Cc: Jose Abreu <joabreu@synopsys.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
Cc: netdev@vger.kernel.org
Cc: linux-stm32@st-md-mailman.stormreply.com
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c
index 9c8d210b2d6a..5f66f6161629 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c
@@ -670,7 +670,7 @@ static int stmmac_test_flowctrl(struct stmmac_priv *priv)
unsigned int pkt_count;
int i, ret = 0;
- if (!phydev || !phydev->pause)
+ if (!phydev || (!phydev->pause && !phydev->asym_pause))
return -EOPNOTSUPP;
tpriv = kzalloc(sizeof(*tpriv), GFP_KERNEL);
--
2.7.4
_______________________________________________
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 v2 2/2] crypto: sun4i-ss: enable pm_runtime
From: Corentin Labbe @ 2019-09-23 7:53 UTC (permalink / raw)
To: Maxime Ripard
Cc: herbert, linux-sunxi, linux-kernel, wens, linux-crypto, davem,
linux-arm-kernel
In-Reply-To: <20190919165559.e7xyapggcwp2ukdt@gilmour>
On Thu, Sep 19, 2019 at 06:55:59PM +0200, Maxime Ripard wrote:
> Hi,
>
> On Thu, Sep 19, 2019 at 07:10:35AM +0200, Corentin Labbe wrote:
> > This patch enables power management on the Security System.
> >
> > Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
> > ---
> > drivers/crypto/sunxi-ss/sun4i-ss-cipher.c | 9 +++
> > drivers/crypto/sunxi-ss/sun4i-ss-core.c | 94 +++++++++++++++++++----
> > drivers/crypto/sunxi-ss/sun4i-ss-hash.c | 12 +++
> > drivers/crypto/sunxi-ss/sun4i-ss-prng.c | 9 ++-
> > drivers/crypto/sunxi-ss/sun4i-ss.h | 2 +
> > 5 files changed, 110 insertions(+), 16 deletions(-)
> >
> > diff --git a/drivers/crypto/sunxi-ss/sun4i-ss-cipher.c b/drivers/crypto/sunxi-ss/sun4i-ss-cipher.c
> > index fa4b1b47822e..c9799cbe0530 100644
> > --- a/drivers/crypto/sunxi-ss/sun4i-ss-cipher.c
> > +++ b/drivers/crypto/sunxi-ss/sun4i-ss-cipher.c
> > @@ -480,6 +480,7 @@ int sun4i_ss_cipher_init(struct crypto_tfm *tfm)
> > struct sun4i_tfm_ctx *op = crypto_tfm_ctx(tfm);
> > struct sun4i_ss_alg_template *algt;
> > const char *name = crypto_tfm_alg_name(tfm);
> > + int err;
> >
> > memset(op, 0, sizeof(struct sun4i_tfm_ctx));
> >
> > @@ -497,13 +498,21 @@ int sun4i_ss_cipher_init(struct crypto_tfm *tfm)
> > return PTR_ERR(op->fallback_tfm);
> > }
> >
> > + err = pm_runtime_get_sync(op->ss->dev);
> > + if (err < 0)
> > + goto error_pm;
> > return 0;
>
> Newline here
>
> > +error_pm:
> > + crypto_free_sync_skcipher(op->fallback_tfm);
> > + return err;
> > }
> >
> > void sun4i_ss_cipher_exit(struct crypto_tfm *tfm)
> > {
> > struct sun4i_tfm_ctx *op = crypto_tfm_ctx(tfm);
> > +
> > crypto_free_sync_skcipher(op->fallback_tfm);
> > + pm_runtime_put(op->ss->dev);
> > }
> >
> > /* check and set the AES key, prepare the mode to be used */
> > diff --git a/drivers/crypto/sunxi-ss/sun4i-ss-core.c b/drivers/crypto/sunxi-ss/sun4i-ss-core.c
> > index 6c2db5d83b06..311c2653a9c3 100644
> > --- a/drivers/crypto/sunxi-ss/sun4i-ss-core.c
> > +++ b/drivers/crypto/sunxi-ss/sun4i-ss-core.c
> > @@ -44,7 +44,8 @@ static struct sun4i_ss_alg_template ss_algs[] = {
> > .cra_blocksize = MD5_HMAC_BLOCK_SIZE,
> > .cra_ctxsize = sizeof(struct sun4i_req_ctx),
> > .cra_module = THIS_MODULE,
> > - .cra_init = sun4i_hash_crainit
> > + .cra_init = sun4i_hash_crainit,
> > + .cra_exit = sun4i_hash_craexit
>
> You should add a comma at the end to prevent having to modify it again
>
> > }
> > }
> > }
> > @@ -70,7 +71,8 @@ static struct sun4i_ss_alg_template ss_algs[] = {
> > .cra_blocksize = SHA1_BLOCK_SIZE,
> > .cra_ctxsize = sizeof(struct sun4i_req_ctx),
> > .cra_module = THIS_MODULE,
> > - .cra_init = sun4i_hash_crainit
> > + .cra_init = sun4i_hash_crainit,
> > + .cra_exit = sun4i_hash_craexit
>
> Ditto
>
> > }
> > }
> > }
> > @@ -262,6 +264,61 @@ static int sun4i_ss_enable(struct sun4i_ss_ctx *ss)
> > return err;
> > }
> >
> > +/*
> > + * Power management strategy: The device is suspended unless a TFM exists for
> > + * one of the algorithms proposed by this driver.
> > + */
> > +#if defined(CONFIG_PM)
> > +static int sun4i_ss_pm_suspend(struct device *dev)
> > +{
> > + struct sun4i_ss_ctx *ss = dev_get_drvdata(dev);
> > +
> > + sun4i_ss_disable(ss);
> > + return 0;
> > +}
> > +
> > +static int sun4i_ss_pm_resume(struct device *dev)
> > +{
> > + struct sun4i_ss_ctx *ss = dev_get_drvdata(dev);
> > +
> > + return sun4i_ss_enable(ss);
> > +}
> > +#endif
> > +
>
> Why not just have the suspend and resume function and the enable /
> disable functions merged together, you're not using them directy as
> far as I can see.
>
> > +const struct dev_pm_ops sun4i_ss_pm_ops = {
> > + SET_RUNTIME_PM_OPS(sun4i_ss_pm_suspend, sun4i_ss_pm_resume, NULL)
> > +};
> > +
> > +/*
> > + * When power management is enabled, this function enables the PM and set the
> > + * device as suspended
> > + * When power management is disabled, this function just enables the device
> > + */
> > +static int sun4i_ss_pm_init(struct sun4i_ss_ctx *ss)
> > +{
> > + int err;
> > +
> > + pm_runtime_use_autosuspend(ss->dev);
> > + pm_runtime_set_autosuspend_delay(ss->dev, 2000);
> > +
> > + err = pm_runtime_set_suspended(ss->dev);
> > + if (err)
> > + return err;
> > + pm_runtime_enable(ss->dev);
> > +#if !defined(CONFIG_PM)
> > + err = sun4i_ss_enable(ss);
> > +#endif
> > + return err;
> > +}
>
> This looks nicer:
> https://elixir.bootlin.com/linux/latest/source/drivers/spi/spi-sun4i.c#L492
>
> Or, just make it depend on CONFIG_PM, we should probably do it anyway
> at the ARCH level anyway.
>
Hello
I usually prefer to give choice (PM vs not PM), but it simplify a lot the code to depend on PM, so I will go for it.
Thanks
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ 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