Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH net-next v5 4/5] dt-bindings: net: fsl: enetc: Add bindings for the central MDIO PCIe endpoint
From: Claudiu Manoil @ 2019-08-01 11:52 UTC (permalink / raw)
  To: David S . Miller
  Cc: andrew, devicetree, netdev, alexandru.marginean, linux-kernel,
	Li Yang, Rob Herring, linux-arm-kernel
In-Reply-To: <1564660373-4607-1-git-send-email-claudiu.manoil@nxp.com>

The on-chip PCIe root complex that integrates the ENETC ethernet
controllers also integrates a PCIe endpoint for the MDIO controller
providing for centralized control of the ENETC mdio bus.
Add bindings for this "central" MDIO Integrated PCIe Endpoint.

Signed-off-by: Claudiu Manoil <claudiu.manoil@nxp.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
---
v1 - none
v2 - none
v3 - fixed spelling (commit message mostly)
v4 - none
v4 - none

 .../devicetree/bindings/net/fsl-enetc.txt     | 42 +++++++++++++++++--
 1 file changed, 39 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/fsl-enetc.txt b/Documentation/devicetree/bindings/net/fsl-enetc.txt
index 25fc687419db..b7034ccbc1bd 100644
--- a/Documentation/devicetree/bindings/net/fsl-enetc.txt
+++ b/Documentation/devicetree/bindings/net/fsl-enetc.txt
@@ -11,7 +11,9 @@ Required properties:
 		  to parent node bindings.
 - compatible	: Should be "fsl,enetc".
 
-1) The ENETC external port is connected to a MDIO configurable phy:
+1. The ENETC external port is connected to a MDIO configurable phy
+
+1.1. Using the local ENETC Port MDIO interface
 
 In this case, the ENETC node should include a "mdio" sub-node
 that in turn should contain the "ethernet-phy" node describing the
@@ -47,8 +49,42 @@ Example:
 		};
 	};
 
-2) The ENETC port is an internal port or has a fixed-link external
-connection:
+1.2. Using the central MDIO PCIe endpoint device
+
+In this case, the mdio node should be defined as another PCIe
+endpoint node, at the same level with the ENETC port nodes.
+
+Required properties:
+
+- reg		: Specifies PCIe Device Number and Function
+		  Number of the ENETC endpoint device, according
+		  to parent node bindings.
+- compatible	: Should be "fsl,enetc-mdio".
+
+The remaining required mdio bus properties are standard, their bindings
+already defined in Documentation/devicetree/bindings/net/mdio.txt.
+
+Example:
+
+	ethernet@0,0 {
+		compatible = "fsl,enetc";
+		reg = <0x000000 0 0 0 0>;
+		phy-handle = <&sgmii_phy0>;
+		phy-connection-type = "sgmii";
+	};
+
+	mdio@0,3 {
+		compatible = "fsl,enetc-mdio";
+		reg = <0x000300 0 0 0 0>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		sgmii_phy0: ethernet-phy@2 {
+			reg = <0x2>;
+		};
+	};
+
+2. The ENETC port is an internal port or has a fixed-link external
+connection
 
 In this case, the ENETC port node defines a fixed link connection,
 as specified by Documentation/devicetree/bindings/net/fixed-link.txt.
-- 
2.17.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related

* [PATCH net-next v5 2/5] enetc: Clean up makefile
From: Claudiu Manoil @ 2019-08-01 11:52 UTC (permalink / raw)
  To: David S . Miller
  Cc: andrew, devicetree, netdev, alexandru.marginean, linux-kernel,
	Li Yang, Rob Herring, linux-arm-kernel
In-Reply-To: <1564660373-4607-1-git-send-email-claudiu.manoil@nxp.com>

Clean up overcomplicated makefile to make it more maintainable.
Basically, there's a set of common objects shared between
the PF and VF driver modules.  This can be implemented in a
simpler way, without conditionals, less repetition, allowing
also for easier updates in the future.

Signed-off-by: Claudiu Manoil <claudiu.manoil@nxp.com>
---
v5 - added this patch

 drivers/net/ethernet/freescale/enetc/Makefile | 18 ++++++------------
 1 file changed, 6 insertions(+), 12 deletions(-)

diff --git a/drivers/net/ethernet/freescale/enetc/Makefile b/drivers/net/ethernet/freescale/enetc/Makefile
index 7139e414dccf..164453a5dc1d 100644
--- a/drivers/net/ethernet/freescale/enetc/Makefile
+++ b/drivers/net/ethernet/freescale/enetc/Makefile
@@ -1,19 +1,13 @@
 # SPDX-License-Identifier: GPL-2.0
+
+common-objs := enetc.o enetc_cbdr.o enetc_ethtool.o
+
 obj-$(CONFIG_FSL_ENETC) += fsl-enetc.o
-fsl-enetc-$(CONFIG_FSL_ENETC) += enetc.o enetc_cbdr.o enetc_ethtool.o \
-				 enetc_mdio.o
+fsl-enetc-y := enetc_pf.o enetc_mdio.o $(common-objs)
 fsl-enetc-$(CONFIG_PCI_IOV) += enetc_msg.o
-fsl-enetc-objs := enetc_pf.o $(fsl-enetc-y)
 
 obj-$(CONFIG_FSL_ENETC_VF) += fsl-enetc-vf.o
-
-ifeq ($(CONFIG_FSL_ENETC)$(CONFIG_FSL_ENETC_VF), yy)
-fsl-enetc-vf-objs := enetc_vf.o
-else
-fsl-enetc-vf-$(CONFIG_FSL_ENETC_VF) += enetc.o enetc_cbdr.o \
-				       enetc_ethtool.o
-fsl-enetc-vf-objs := enetc_vf.o $(fsl-enetc-vf-y)
-endif
+fsl-enetc-vf-y := enetc_vf.o $(common-objs)
 
 obj-$(CONFIG_FSL_ENETC_PTP_CLOCK) += fsl-enetc-ptp.o
-fsl-enetc-ptp-$(CONFIG_FSL_ENETC_PTP_CLOCK) += enetc_ptp.o
+fsl-enetc-ptp-y := enetc_ptp.o
-- 
2.17.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related

* [PATCH net-next v5 0/5] enetc: Add mdio bus driver for the PCIe MDIO endpoint
From: Claudiu Manoil @ 2019-08-01 11:52 UTC (permalink / raw)
  To: David S . Miller
  Cc: andrew, devicetree, netdev, alexandru.marginean, linux-kernel,
	Li Yang, Rob Herring, linux-arm-kernel

First patch fixes a sparse issue and cleans up accessors to avoid
casting to __iomem.  The second one cleans up the Makefile, to make
it easier to add new entries.

Third patch just registers the PCIe endpoint device containing
the MDIO registers as a standalone MDIO bus driver, to provide
an alternative way to control the MDIO bus.  The same code used
by the ENETC ports (eth controllers) to manage MDIO via local
registers applies and is reused.

Bindings are provided for the new MDIO node, similarly to ENETC
port nodes bindings.

Last patch enables the ENETC port 1 and its RGMII PHY on the
LS1028A QDS board, where the MDIO muxing configuration relies
on the MDIO support provided in the first patch.

Changes since v0:
v1 - fixed mdio bus allocation
v2 - cleaned up accessors to avoid casting
v3 - fixed spelling (mostly commit message)
v4 - fixed err path check blunder
v5 - fixed loadble module build, provided separate kbuild module
     for the driver


Claudiu Manoil (5):
  enetc: Clean up local mdio bus allocation
  enetc: Clean up makefile
  enetc: Add mdio bus driver for the PCIe MDIO endpoint
  dt-bindings: net: fsl: enetc: Add bindings for the central MDIO PCIe
    endpoint
  arm64: dts: fsl: ls1028a: Enable eth port1 on the ls1028a QDS board

 .../devicetree/bindings/net/fsl-enetc.txt     |  42 +++++++-
 .../boot/dts/freescale/fsl-ls1028a-qds.dts    |  40 +++++++
 .../arm64/boot/dts/freescale/fsl-ls1028a.dtsi |   6 ++
 drivers/net/ethernet/freescale/enetc/Kconfig  |   9 ++
 drivers/net/ethernet/freescale/enetc/Makefile |  19 ++--
 .../net/ethernet/freescale/enetc/enetc_mdio.c |  97 ++++++++---------
 .../net/ethernet/freescale/enetc/enetc_mdio.h |  12 +++
 .../ethernet/freescale/enetc/enetc_pci_mdio.c | 101 ++++++++++++++++++
 .../net/ethernet/freescale/enetc/enetc_pf.c   |   5 +-
 9 files changed, 264 insertions(+), 67 deletions(-)
 create mode 100644 drivers/net/ethernet/freescale/enetc/enetc_mdio.h
 create mode 100644 drivers/net/ethernet/freescale/enetc/enetc_pci_mdio.c

-- 
2.17.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH] serial: imx: Avoid probe failure in case of missing gpiolib
From: Uwe Kleine-König @ 2019-08-01 11:50 UTC (permalink / raw)
  To: Schrempf Frieder
  Cc: linux-serial@vger.kernel.org, Greg Kroah-Hartman, Sascha Hauer,
	linux-kernel@vger.kernel.org, NXP Linux Team,
	Pengutronix Kernel Team, Jiri Slaby, Shawn Guo, Fabio Estevam,
	linux-arm-kernel@lists.infradead.org
In-Reply-To: <0174be55-5e40-8cc7-82c7-54f9de46f711@kontron.de>

Hello,

On Thu, Aug 01, 2019 at 10:59:54AM +0000, Schrempf Frieder wrote:
> So I would rather go with a variation of your second proposal and keep 
> the dummy implementation, but let it return NULL instead of an error 
> pointer, as all the mctrl_gpio_*() functions already seem to have a 
> check for gpios == NULL.
> 
> What do you think?

I'll gladly review a patch.

Best regads
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: Best representation for TDM devices
From: Mark Brown @ 2019-08-01 11:48 UTC (permalink / raw)
  To: Ali Burak Parım; +Cc: maxime.ripard, linux-arm-kernel
In-Reply-To: <CAMTEBE0mPY=44txPC2G+Cb=NqeH6Cqesar9Vkq0afXBv4dUWHQ@mail.gmail.com>


[-- Attachment #1.1: Type: text/plain, Size: 910 bytes --]

On Thu, Aug 01, 2019 at 01:43:06PM +0200, Ali Burak Parım wrote:
> On Thu, Jul 25, 2019 at 03:01:12PM +0200, Maxime Ripard wrote:

> > What is the actual hardware - what do the microphones physically look
> > like in the system, what functional role do they play?  My initial guess

> Hardware is a custom board I designed with 4 PDM output microphones
> and 2 adau7002 devices as the codec for PDM-to-PCM. We want to do
> signal processing with this board. Therefore having separate streams for
> each microphone is crucial to the application though I am not sure where
> we should implement this exactly.

What is this processing - are the streams from these microphones
logically related in any way (eg, is this a microphone array)?  There's
probably going to be some overlap in the input signals at least.  If you
need to for example correlate different microphones then that's
relevant.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH 2/2] perf/smmuv3: Validate groups for global filtering
From: Will Deacon @ 2019-08-01 11:45 UTC (permalink / raw)
  To: Robin Murphy; +Cc: mark.rutland, linux-arm-kernel, shameerali.kolothum.thodi
In-Reply-To: <e7584ab2-275a-98ce-d2d4-248815d6451c@arm.com>

On Thu, Aug 01, 2019 at 12:17:20PM +0100, Robin Murphy wrote:
> On 2019-08-01 11:56 am, Will Deacon wrote:
> > On Wed, Jul 31, 2019 at 02:37:42PM +0100, Robin Murphy wrote:
> > > With global filtering, it becomes possible for users to construct
> > > self-contradictory groups with conflicting filters. Make sure we
> > > cover that when initially validating events.
> > > 
> > > Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> > > ---
> > >   drivers/perf/arm_smmuv3_pmu.c | 16 ++++++++++++++++
> > >   1 file changed, 16 insertions(+)
> > > 
> > > diff --git a/drivers/perf/arm_smmuv3_pmu.c b/drivers/perf/arm_smmuv3_pmu.c
> > > index dd40df2ac895..e1e41d2fea94 100644
> > > --- a/drivers/perf/arm_smmuv3_pmu.c
> > > +++ b/drivers/perf/arm_smmuv3_pmu.c
> > > @@ -324,6 +324,8 @@ static int smmu_pmu_event_init(struct perf_event *event)
> > >   	struct device *dev = smmu_pmu->dev;
> > >   	struct perf_event *sibling;
> > >   	int group_num_events = 1;
> > > +	bool has_filter;
> > > +	u32 filter_span, filter_sid;
> > >   	u16 event_id;
> > >   	if (event->attr.type != event->pmu->type)
> > > @@ -354,6 +356,10 @@ static int smmu_pmu_event_init(struct perf_event *event)
> > >   		return -EINVAL;
> > >   	}
> > > +	has_filter = get_filter_enable(event);
> > > +	filter_span = get_filter_span(event);
> > > +	filter_sid = get_filter_stream_id(event);
> > > +
> > >   	for_each_sibling_event(sibling, event->group_leader) {
> > >   		if (sibling->pmu != event->pmu &&
> > >   		    !is_software_event(sibling)) {
> > > @@ -363,6 +369,16 @@ static int smmu_pmu_event_init(struct perf_event *event)
> > >   		if (++group_num_events >= smmu_pmu->num_counters)
> > >   			return -EINVAL;
> > > +
> > > +		if (smmu_pmu->global_filter) {
> > > +			if (has_filter != (bool)get_filter_enable(sibling))
> > > +				return -EINVAL;
> > > +
> > > +			if (has_filter &&
> > > +			    (filter_span != get_filter_span(sibling) ||
> > > +			    filter_sid != get_filter_stream_id (sibling)))
> > > +				return -EINVAL;
> > > +		}
> > 
> > Can we avoid duplicating the validation logic from
> > smmu_pmu_apply_event_filter() by adding the group to a fake PMU, like we
> > do for the CPU PMU and the DSU PMU? You'll probably need to do a bit
> > of surgery on 'struct smmu_pmu' to move out the bits you need, but I
> > think it would be better that way.
> 
> Given that apply_event_filter() includes the actual register writes, I have
> a strong feeling that down that road lies madness. However, on a second
> look, I see no reason not to factor out the global filter validation part
> for reuse, and in fact I think we can even save explicitly tracking
> global_filter_{span,sid} that way. I'll give it a try.

Oh yes, performing the actual register writes could be catastrophic!
All I'm trying to get to is a situation where we don't have to update both
the event_init() and smmu_pmu_get_event_idx() callchains if we gain
additional validation requirements in future.

> (and hopefully the promise of a respin will let us all overlook the obvious
> "forgot to update the condition when I changed my mind about the count"
> error in patch #1...)

I noticed it looked weird, but assumed I was being thick and then forgot
about it.

Will

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH 1/2] perf/smmuv3: Validate group size
From: Will Deacon @ 2019-08-01 11:32 UTC (permalink / raw)
  To: Robin Murphy; +Cc: mark.rutland, linux-arm-kernel, shameerali.kolothum.thodi
In-Reply-To: <7108cdcc6fdce8dd1cfd869849bd78d05bac870f.1564580090.git.robin.murphy@arm.com>

On Wed, Jul 31, 2019 at 02:37:41PM +0100, Robin Murphy wrote:
> Ensure that a group will actually fit into the available counters.
> 
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> ---
>  drivers/perf/arm_smmuv3_pmu.c | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/perf/arm_smmuv3_pmu.c b/drivers/perf/arm_smmuv3_pmu.c
> index da71c741cb46..dd40df2ac895 100644
> --- a/drivers/perf/arm_smmuv3_pmu.c
> +++ b/drivers/perf/arm_smmuv3_pmu.c
> @@ -323,6 +323,7 @@ static int smmu_pmu_event_init(struct perf_event *event)
>  	struct smmu_pmu *smmu_pmu = to_smmu_pmu(event->pmu);
>  	struct device *dev = smmu_pmu->dev;
>  	struct perf_event *sibling;
> +	int group_num_events = 1;
>  	u16 event_id;
>  
>  	if (event->attr.type != event->pmu->type)
> @@ -359,6 +360,9 @@ static int smmu_pmu_event_init(struct perf_event *event)
>  			dev_dbg(dev, "Can't create mixed PMU group\n");
>  			return -EINVAL;
>  		}
> +
> +		if (++group_num_events >= smmu_pmu->num_counters)
> +			return -EINVAL;

Did you forget to update the condition when you changed your mind about the
count?

;)

Will

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* [PATCH] mxsfb: allow attachment of display bridges
From: Ville Baillie @ 2019-08-01 11:18 UTC (permalink / raw)
  To: marex, stefan, airlied, daniel, shawnguo, s.hauer, kernel,
	festevam, linux-imx, dri-devel, linux-arm-kernel, linux-kernel

---
 drivers/gpu/drm/mxsfb/mxsfb_drv.c | 20 ++++++++++++++++----
 drivers/gpu/drm/mxsfb/mxsfb_drv.h |  1 +
 drivers/gpu/drm/mxsfb/mxsfb_out.c | 14 +++++++++++---
 3 files changed, 28 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
index 6fafc90da4ec..c19a7b7aa3a6 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
@@ -229,10 +229,22 @@ static int mxsfb_load(struct drm_device *drm, unsigned long flags)
 		goto err_vblank;
 	}
 
-	ret = drm_panel_attach(mxsfb->panel, &mxsfb->connector);
-	if (ret) {
-		dev_err(drm->dev, "Cannot connect panel\n");
-		goto err_vblank;
+	if (mxsfb->panel) {
+		ret = drm_panel_attach(mxsfb->panel, &mxsfb->connector);
+		if (ret) {
+			dev_err(drm->dev, "Cannot connect panel\n");
+			goto err_vblank;
+		}
+	} else if (mxsfb->bridge) {
+		ret = drm_bridge_attach(&mxsfb->pipe.encoder, mxsfb->bridge,
+				NULL);
+		if (ret) {
+			dev_err(drm->dev, "Cannot connect bridge\n");
+			goto err_vblank;
+		}
+	} else {
+		dev_err(drm->dev, "No panel or bridge\n");
+		return -EINVAL;
 	}
 
 	drm->mode_config.min_width	= MXSFB_MIN_XRES;
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.h b/drivers/gpu/drm/mxsfb/mxsfb_drv.h
index d975300dca05..436fe4bbb47a 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_drv.h
+++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.h
@@ -29,6 +29,7 @@ struct mxsfb_drm_private {
 	struct drm_simple_display_pipe	pipe;
 	struct drm_connector		connector;
 	struct drm_panel		*panel;
+	struct drm_bridge		*bridge;
 };
 
 int mxsfb_setup_crtc(struct drm_device *dev);
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_out.c b/drivers/gpu/drm/mxsfb/mxsfb_out.c
index 91e76f9cead6..77e03eb0fca6 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_out.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_out.c
@@ -78,9 +78,11 @@ int mxsfb_create_output(struct drm_device *drm)
 {
 	struct mxsfb_drm_private *mxsfb = drm->dev_private;
 	struct drm_panel *panel;
+	struct drm_bridge *bridge;
 	int ret;
 
-	ret = drm_of_find_panel_or_bridge(drm->dev->of_node, 0, 0, &panel, NULL);
+	ret = drm_of_find_panel_or_bridge(drm->dev->of_node, 0, 0, &panel,
+			&bridge);
 	if (ret)
 		return ret;
 
@@ -91,8 +93,14 @@ int mxsfb_create_output(struct drm_device *drm)
 	ret = drm_connector_init(drm, &mxsfb->connector,
 				 &mxsfb_panel_connector_funcs,
 				 DRM_MODE_CONNECTOR_Unknown);
-	if (!ret)
-		mxsfb->panel = panel;
+	if (!ret) {
+		if (panel)
+			mxsfb->panel = panel;
+		else if (bridge)
+			mxsfb->bridge = bridge;
+		else
+			return -EINVAL;
+	}
 
 	return ret;
 }
-- 
2.17.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related

* Re: [PATCH 2/2] perf/smmuv3: Validate groups for global filtering
From: Robin Murphy @ 2019-08-01 11:17 UTC (permalink / raw)
  To: Will Deacon; +Cc: mark.rutland, linux-arm-kernel, shameerali.kolothum.thodi
In-Reply-To: <20190801105607.aizjw4l7rvi7vnpw@willie-the-truck>

On 2019-08-01 11:56 am, Will Deacon wrote:
> On Wed, Jul 31, 2019 at 02:37:42PM +0100, Robin Murphy wrote:
>> With global filtering, it becomes possible for users to construct
>> self-contradictory groups with conflicting filters. Make sure we
>> cover that when initially validating events.
>>
>> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
>> ---
>>   drivers/perf/arm_smmuv3_pmu.c | 16 ++++++++++++++++
>>   1 file changed, 16 insertions(+)
>>
>> diff --git a/drivers/perf/arm_smmuv3_pmu.c b/drivers/perf/arm_smmuv3_pmu.c
>> index dd40df2ac895..e1e41d2fea94 100644
>> --- a/drivers/perf/arm_smmuv3_pmu.c
>> +++ b/drivers/perf/arm_smmuv3_pmu.c
>> @@ -324,6 +324,8 @@ static int smmu_pmu_event_init(struct perf_event *event)
>>   	struct device *dev = smmu_pmu->dev;
>>   	struct perf_event *sibling;
>>   	int group_num_events = 1;
>> +	bool has_filter;
>> +	u32 filter_span, filter_sid;
>>   	u16 event_id;
>>   
>>   	if (event->attr.type != event->pmu->type)
>> @@ -354,6 +356,10 @@ static int smmu_pmu_event_init(struct perf_event *event)
>>   		return -EINVAL;
>>   	}
>>   
>> +	has_filter = get_filter_enable(event);
>> +	filter_span = get_filter_span(event);
>> +	filter_sid = get_filter_stream_id(event);
>> +
>>   	for_each_sibling_event(sibling, event->group_leader) {
>>   		if (sibling->pmu != event->pmu &&
>>   		    !is_software_event(sibling)) {
>> @@ -363,6 +369,16 @@ static int smmu_pmu_event_init(struct perf_event *event)
>>   
>>   		if (++group_num_events >= smmu_pmu->num_counters)
>>   			return -EINVAL;
>> +
>> +		if (smmu_pmu->global_filter) {
>> +			if (has_filter != (bool)get_filter_enable(sibling))
>> +				return -EINVAL;
>> +
>> +			if (has_filter &&
>> +			    (filter_span != get_filter_span(sibling) ||
>> +			    filter_sid != get_filter_stream_id (sibling)))
>> +				return -EINVAL;
>> +		}
> 
> Can we avoid duplicating the validation logic from
> smmu_pmu_apply_event_filter() by adding the group to a fake PMU, like we
> do for the CPU PMU and the DSU PMU? You'll probably need to do a bit
> of surgery on 'struct smmu_pmu' to move out the bits you need, but I
> think it would be better that way.

Given that apply_event_filter() includes the actual register writes, I 
have a strong feeling that down that road lies madness. However, on a 
second look, I see no reason not to factor out the global filter 
validation part for reuse, and in fact I think we can even save 
explicitly tracking global_filter_{span,sid} that way. I'll give it a try.

Robin.

(and hopefully the promise of a respin will let us all overlook the 
obvious "forgot to update the condition when I changed my mind about the 
count" error in patch #1...)

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH] arm64: Relax ICC_PMR_EL1 accesses when ICC_CTLR_EL1.PMHE is clear
From: Will Deacon @ 2019-08-01 11:13 UTC (permalink / raw)
  To: Marc Zyngier
  Cc: Marc Zyngier, Suzuki K Poulose, Catalin Marinas, James Morse,
	Julien Thierry, huawei.libin, guohanjun, liwei391,
	linux-arm-kernel
In-Reply-To: <166cd7e1-4a4c-021b-eca6-f3f11fc4993d@arm.com>

On Thu, Aug 01, 2019 at 12:07:58PM +0100, Marc Zyngier wrote:
> On 01/08/2019 11:56, Julien Thierry wrote:
> > On Thu, 1 Aug 2019 at 11:51, Marc Zyngier <marc.zyngier@arm.com> wrote:
> >>
> >> On 01/08/2019 11:41, Will Deacon wrote:
> >>> On Tue, Jul 30, 2019 at 03:20:45PM +0100, Julien Thierry wrote:
> >>>> From: Marc Zyngier <marc.zyngier@arm.com>
> >>>>
> >>>> The GICv3 architecture specification is incredibly misleading when it
> >>>> comes to PMR and the requirement for a DSB. It turns out that this DSB
> >>>> is only required if the CPU interface sends an Upstream Control
> >>>> message to the redistributor in order to update the RD's view of PMR.
> >>>>
> >>>> This message is only sent when ICC_CTLR_EL1.PMHE is set, which isn't
> >>>> the case in Linux. It can still be set from EL3, so some special care
> >>>> is required. But the upshot is that in the (hopefuly large) majority
> >>>> of the cases, we can drop the DSB altogether.
> >>>>
> >>>> This requires yet another capability and some more runtime patching.
> >>>
> >>> Hmm, does this actually require explicit runtime patching, or can we make
> >>> things a bit simpler with a static key?
> >>
> >> The hunk in entry.S is the blocker, AFAICS. Do we have a way to express
> >> static keys in asm?
> >>
> > 
> > Not that I'm aware of. I could leave the alternative in entry.S and
> > use a static_key for the pmr_sync() macro.
> 
> I'm not sure that helps. It means we end-up with two mechanisms to keep
> in sync instead of a single one.

Yes, I missed the entry.S part initially.

> > Does it change much over all? I don't see the static key simplifying
> > things too much, but I don't mind using that instead.
> 
> The complexity is the same. The added benefit is that we can control it
> from the GIC code rather than the architecture code. But that's assuming
> we can do it all using a static key...

Well I think we should look at the numbers for static key + conditional
branch in entry.S. If entry is being hammered, the predictor should do
its job (ignoring Spectre-V2). If entry isn't being hammered, then it
shouldn't matter.

Will

_______________________________________________
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] arm64: Relax ICC_PMR_EL1 accesses when ICC_CTLR_EL1.PMHE is clear
From: Marc Zyngier @ 2019-08-01 11:07 UTC (permalink / raw)
  To: Julien Thierry
  Cc: Marc Zyngier, Will Deacon, Suzuki K Poulose, Catalin Marinas,
	James Morse, huawei.libin, guohanjun, liwei391, linux-arm-kernel
In-Reply-To: <CAA3o8kyYnek=7boO_szVoNvQks8DFGN5s37ROQKqwyWZQZiXZw@mail.gmail.com>

On 01/08/2019 11:56, Julien Thierry wrote:
> On Thu, 1 Aug 2019 at 11:51, Marc Zyngier <marc.zyngier@arm.com> wrote:
>>
>> On 01/08/2019 11:41, Will Deacon wrote:
>>> On Tue, Jul 30, 2019 at 03:20:45PM +0100, Julien Thierry wrote:
>>>> From: Marc Zyngier <marc.zyngier@arm.com>
>>>>
>>>> The GICv3 architecture specification is incredibly misleading when it
>>>> comes to PMR and the requirement for a DSB. It turns out that this DSB
>>>> is only required if the CPU interface sends an Upstream Control
>>>> message to the redistributor in order to update the RD's view of PMR.
>>>>
>>>> This message is only sent when ICC_CTLR_EL1.PMHE is set, which isn't
>>>> the case in Linux. It can still be set from EL3, so some special care
>>>> is required. But the upshot is that in the (hopefuly large) majority
>>>> of the cases, we can drop the DSB altogether.
>>>>
>>>> This requires yet another capability and some more runtime patching.
>>>
>>> Hmm, does this actually require explicit runtime patching, or can we make
>>> things a bit simpler with a static key?
>>
>> The hunk in entry.S is the blocker, AFAICS. Do we have a way to express
>> static keys in asm?
>>
> 
> Not that I'm aware of. I could leave the alternative in entry.S and
> use a static_key for the pmr_sync() macro.

I'm not sure that helps. It means we end-up with two mechanisms to keep
in sync instead of a single one.

> Does it change much over all? I don't see the static key simplifying
> things too much, but I don't mind using that instead.

The complexity is the same. The added benefit is that we can control it
from the GIC code rather than the architecture code. But that's assuming
we can do it all using a static key...

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* [PATCH v2 2/4] rtc: Add support for the MediaTek MT2712 RTC
From: Ran Bi @ 2019-08-01 11:01 UTC (permalink / raw)
  To: Alexandre Belloni, Rob Herring, Matthias Brugger
  Cc: Mark Rutland, Alessandro Zummo, Flora Fu, srv_heupstream,
	devicetree, Ran Bi, Greg Kroah-Hartman, Linus Walleij, Sean Wang,
	linux-kernel, YT Shen, linux-mediatek, Jonathan Cameron,
	Mauro Carvalho Chehab, Yingjoe Chen, Eddie Huang,
	David S . Miller, linux-arm-kernel, linux-rtc
In-Reply-To: <20190801110122.26834-1-ran.bi@mediatek.com>

This add support for the MediaTek MT2712 RTC. It was SoC based RTC, but
had different architecture compared with MT7622 RTC.

Signed-off-by: Ran Bi <ran.bi@mediatek.com>
---
 drivers/rtc/Kconfig      |  10 +
 drivers/rtc/Makefile     |   1 +
 drivers/rtc/rtc-mt2712.c | 444 +++++++++++++++++++++++++++++++++++++++
 3 files changed, 455 insertions(+)
 create mode 100644 drivers/rtc/rtc-mt2712.c

diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index e72f65b61176..977d0f480dc7 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -1772,6 +1772,16 @@ config RTC_DRV_MOXART
 	   This driver can also be built as a module. If so, the module
 	   will be called rtc-moxart
 
+config RTC_DRV_MT2712
+	tristate "MediaTek MT2712 SoC based RTC"
+	depends on ARCH_MEDIATEK || COMPILE_TEST
+	help
+	  This enables support for the real time clock built in the MediaTek
+	  SoCs for MT2712.
+
+	  This drive can also be built as a module. If so, the module
+	  will be called rtc-mt2712.
+
 config RTC_DRV_MT6397
 	tristate "MediaTek PMIC based RTC"
 	depends on MFD_MT6397 || (COMPILE_TEST && IRQ_DOMAIN)
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index 6b09c21dc1b6..7c6cf70af281 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -108,6 +108,7 @@ obj-$(CONFIG_RTC_DRV_MESON)	+= rtc-meson.o
 obj-$(CONFIG_RTC_DRV_MOXART)	+= rtc-moxart.o
 obj-$(CONFIG_RTC_DRV_MPC5121)	+= rtc-mpc5121.o
 obj-$(CONFIG_RTC_DRV_MSM6242)	+= rtc-msm6242.o
+obj-$(CONFIG_RTC_DRV_MT2712)	+= rtc-mt2712.o
 obj-$(CONFIG_RTC_DRV_MT6397)	+= rtc-mt6397.o
 obj-$(CONFIG_RTC_DRV_MT7622)	+= rtc-mt7622.o
 obj-$(CONFIG_RTC_DRV_MV)	+= rtc-mv.o
diff --git a/drivers/rtc/rtc-mt2712.c b/drivers/rtc/rtc-mt2712.c
new file mode 100644
index 000000000000..1eb71ca64c2c
--- /dev/null
+++ b/drivers/rtc/rtc-mt2712.c
@@ -0,0 +1,444 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2019 MediaTek Inc.
+ * Author: Ran Bi <ran.bi@mediatek.com>
+ */
+
+#include <linux/delay.h>
+#include <linux/init.h>
+#include <linux/io.h>
+#include <linux/irqdomain.h>
+#include <linux/module.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
+#include <linux/platform_device.h>
+#include <linux/rtc.h>
+
+#define MTK_RTC_DEV		KBUILD_MODNAME
+
+#define MT2712_BBPU		0x0000
+#define MT2712_BBPU_CLRPKY	BIT(4)
+#define MT2712_BBPU_RELOAD	BIT(5)
+#define MT2712_BBPU_CBUSY	BIT(6)
+#define MT2712_BBPU_KEY		(0x43 << 8)
+
+#define MT2712_IRQ_STA		0x0004
+#define MT2712_IRQ_STA_AL	BIT(0)
+#define MT2712_IRQ_STA_TC	BIT(1)
+
+#define MT2712_IRQ_EN		0x0008
+#define MT2712_IRQ_EN_AL	BIT(0)
+#define MT2712_IRQ_EN_TC	BIT(1)
+#define MT2712_IRQ_EN_ONESHOT	BIT(2)
+#define MT2712_IRQ_EN_ONESHOT_AL \
+				(MT2712_IRQ_EN_ONESHOT | MT2712_IRQ_EN_AL)
+
+#define MT2712_CII_EN		0x000c
+
+#define MT2712_AL_MASK		0x0010
+#define MT2712_AL_MASK_DOW	BIT(4)
+
+#define MT2712_TC_SEC		0x0014
+#define MT2712_TC_MIN		0x0018
+#define MT2712_TC_HOU		0x001c
+#define MT2712_TC_DOM		0x0020
+#define MT2712_TC_DOW		0x0024
+#define MT2712_TC_MTH		0x0028
+#define MT2712_TC_YEA		0x002c
+
+#define MT2712_AL_SEC		0x0030
+#define MT2712_AL_MIN		0x0034
+#define MT2712_AL_HOU		0x0038
+#define MT2712_AL_DOM		0x003c
+#define MT2712_AL_DOW		0x0040
+#define MT2712_AL_MTH		0x0044
+#define MT2712_AL_YEA		0x0048
+
+#define MT2712_SEC_MASK		0x003f
+#define MT2712_MIN_MASK		0x003f
+#define MT2712_HOU_MASK		0x001f
+#define MT2712_DOM_MASK		0x001f
+#define MT2712_DOW_MASK		0x0007
+#define MT2712_MTH_MASK		0x000f
+#define MT2712_YEA_MASK		0x007f
+
+#define MT2712_POWERKEY1	0x004c
+#define MT2712_POWERKEY2	0x0050
+#define MT2712_POWERKEY1_KEY	0xa357
+#define MT2712_POWERKEY2_KEY	0x67d2
+
+#define MT2712_CON0		0x005c
+#define MT2712_CON1		0x0060
+
+#define MT2712_PROT		0x0070
+#define MT2712_PROT_UNLOCK1	0x9136
+#define MT2712_PROT_UNLOCK2	0x586a
+
+#define MT2712_WRTGR		0x0078
+
+/* we map HW YEAR 0 to 2000 because 2000 is the leap year */
+#define MT2712_MIN_YEAR		2000
+#define MT2712_BASE_YEAR	1900
+#define MT2712_MIN_YEAR_OFFSET	(MT2712_MIN_YEAR - MT2712_BASE_YEAR)
+#define MT2712_MAX_YEAR_OFFSET	(MT2712_MIN_YEAR_OFFSET + 127)
+
+struct mt2712_rtc {
+	struct device		*dev;
+	struct rtc_device	*rtc_dev;
+	void __iomem		*base;
+	int			irq;
+	u8			irq_wake_enabled;
+};
+
+static inline u32 mt2712_readl(struct mt2712_rtc *rtc, u32 reg)
+{
+	return readl(rtc->base + reg);
+}
+
+static inline void mt2712_writel(struct mt2712_rtc *rtc, u32 reg, u32 val)
+{
+	writel(val, rtc->base + reg);
+}
+
+static void mt2712_rtc_write_trigger(struct mt2712_rtc *rtc)
+{
+	unsigned long timeout = jiffies + HZ/10;
+
+	mt2712_writel(rtc, MT2712_WRTGR, 1);
+	while (1) {
+		if (!(mt2712_readl(rtc, MT2712_BBPU) & MT2712_BBPU_CBUSY))
+			break;
+
+		if (time_after(jiffies, timeout)) {
+			dev_err(rtc->dev, "%s time out!\n", __func__);
+			break;
+		}
+		cpu_relax();
+	}
+}
+
+static void mt2712_rtc_writeif_unlock(struct mt2712_rtc *rtc)
+{
+	mt2712_writel(rtc, MT2712_PROT, MT2712_PROT_UNLOCK1);
+	mt2712_rtc_write_trigger(rtc);
+	mt2712_writel(rtc, MT2712_PROT, MT2712_PROT_UNLOCK2);
+	mt2712_rtc_write_trigger(rtc);
+}
+
+static irqreturn_t rtc_irq_handler_thread(int irq, void *data)
+{
+	struct mt2712_rtc *rtc = data;
+	u16 irqsta, irqen;
+
+	mutex_lock(&rtc->rtc_dev->ops_lock);
+
+	irqsta = mt2712_readl(rtc, MT2712_IRQ_STA);
+	if (irqsta & MT2712_IRQ_STA_AL) {
+		rtc_update_irq(rtc->rtc_dev, 1, RTC_IRQF | RTC_AF);
+		irqen = irqsta & ~MT2712_IRQ_EN_AL;
+
+		mt2712_writel(rtc, MT2712_IRQ_EN, irqen);
+		mt2712_rtc_write_trigger(rtc);
+
+		mutex_unlock(&rtc->rtc_dev->ops_lock);
+		return IRQ_HANDLED;
+	}
+
+	mutex_unlock(&rtc->rtc_dev->ops_lock);
+	return IRQ_NONE;
+}
+
+static void __mt2712_rtc_read_time(struct mt2712_rtc *rtc,
+				   struct rtc_time *tm, int *sec)
+{
+	tm->tm_sec  = mt2712_readl(rtc, MT2712_TC_SEC) & MT2712_SEC_MASK;
+	tm->tm_min  = mt2712_readl(rtc, MT2712_TC_MIN) & MT2712_MIN_MASK;
+	tm->tm_hour = mt2712_readl(rtc, MT2712_TC_HOU) & MT2712_HOU_MASK;
+	tm->tm_mday = mt2712_readl(rtc, MT2712_TC_DOM) & MT2712_DOM_MASK;
+	tm->tm_mon  = mt2712_readl(rtc, MT2712_TC_MTH) & MT2712_MTH_MASK;
+	tm->tm_year = mt2712_readl(rtc, MT2712_TC_YEA) & MT2712_YEA_MASK;
+
+	*sec = mt2712_readl(rtc, MT2712_TC_SEC) & MT2712_SEC_MASK;
+}
+
+static int mt2712_rtc_read_time(struct device *dev, struct rtc_time *tm)
+{
+	struct mt2712_rtc *rtc = dev_get_drvdata(dev);
+	int sec;
+
+	do {
+		__mt2712_rtc_read_time(rtc, tm, &sec);
+	} while (sec < tm->tm_sec);	/* SEC has carried */
+
+	/* HW register use 7 bits to store year data, minus
+	 * MT2712_MIN_YEAR_OFFSET brfore write year data to register, and plus
+	 * MT2712_MIN_YEAR_OFFSET back after read year from register
+	 */
+	tm->tm_year += MT2712_MIN_YEAR_OFFSET;
+
+	/* HW register start mon from one, but tm_mon start from zero. */
+	tm->tm_mon--;
+
+	if (rtc_valid_tm(tm)) {
+		dev_dbg(rtc->dev, "%s: invalid time %ptR\n", __func__, tm);
+		return -EINVAL;
+	}
+
+	return 0;
+}
+
+static int mt2712_rtc_set_time(struct device *dev, struct rtc_time *tm)
+{
+	struct mt2712_rtc *rtc = dev_get_drvdata(dev);
+
+	if (tm->tm_year > MT2712_MAX_YEAR_OFFSET) {
+		dev_dbg(rtc->dev, "Set year %d out of range. (%d - %d)\n",
+			1900 + tm->tm_year, 1900 + MT2712_MIN_YEAR_OFFSET,
+			1900 + MT2712_MAX_YEAR_OFFSET);
+		return -EINVAL;
+	}
+
+	tm->tm_year -= MT2712_MIN_YEAR_OFFSET;
+	tm->tm_mon++;
+
+	mt2712_writel(rtc, MT2712_TC_SEC, tm->tm_sec  & MT2712_SEC_MASK);
+	mt2712_writel(rtc, MT2712_TC_MIN, tm->tm_min  & MT2712_MIN_MASK);
+	mt2712_writel(rtc, MT2712_TC_HOU, tm->tm_hour & MT2712_HOU_MASK);
+	mt2712_writel(rtc, MT2712_TC_DOM, tm->tm_mday & MT2712_DOM_MASK);
+	mt2712_writel(rtc, MT2712_TC_MTH, tm->tm_mon  & MT2712_MTH_MASK);
+	mt2712_writel(rtc, MT2712_TC_YEA, tm->tm_year & MT2712_YEA_MASK);
+
+	mt2712_rtc_write_trigger(rtc);
+
+	return 0;
+}
+
+static int mt2712_rtc_read_alarm(struct device *dev, struct rtc_wkalrm *alm)
+{
+	struct mt2712_rtc *rtc = dev_get_drvdata(dev);
+	struct rtc_time *tm = &alm->time;
+	u16 irqen;
+
+	irqen = mt2712_readl(rtc, MT2712_IRQ_EN);
+	alm->enabled = !!(irqen & MT2712_IRQ_EN_AL);
+
+	tm->tm_sec  = mt2712_readl(rtc, MT2712_AL_SEC) & MT2712_SEC_MASK;
+	tm->tm_min  = mt2712_readl(rtc, MT2712_AL_MIN) & MT2712_MIN_MASK;
+	tm->tm_hour = mt2712_readl(rtc, MT2712_AL_HOU) & MT2712_HOU_MASK;
+	tm->tm_mday = mt2712_readl(rtc, MT2712_AL_DOM) & MT2712_DOM_MASK;
+	tm->tm_mon  = mt2712_readl(rtc, MT2712_AL_MTH) & MT2712_MTH_MASK;
+	tm->tm_year = mt2712_readl(rtc, MT2712_AL_YEA) & MT2712_YEA_MASK;
+
+	tm->tm_year += MT2712_MIN_YEAR_OFFSET;
+	tm->tm_mon--;
+
+	if (rtc_valid_tm(tm)) {
+		dev_dbg(rtc->dev, "%s: invalid alarm %ptR\n", __func__, tm);
+		return -EINVAL;
+	}
+
+	return 0;
+}
+
+static int mt2712_rtc_set_alarm(struct device *dev, struct rtc_wkalrm *alm)
+{
+	struct mt2712_rtc *rtc = dev_get_drvdata(dev);
+	struct rtc_time *tm = &alm->time;
+	u16 irqen;
+
+	if (tm->tm_year > MT2712_MAX_YEAR_OFFSET) {
+		dev_dbg(rtc->dev, "Set year %d out of range. (%d - %d)\n",
+			1900 + tm->tm_year, 1900 + MT2712_MIN_YEAR_OFFSET,
+			1900 + MT2712_MAX_YEAR_OFFSET);
+		return -EINVAL;
+	}
+
+	dev_dbg(rtc->dev, "set al time: %ptR, alm en: %d\n", tm, alm->enabled);
+
+	tm->tm_year -= MT2712_MIN_YEAR_OFFSET;
+	tm->tm_mon++;
+
+	irqen = mt2712_readl(rtc, MT2712_IRQ_EN) & ~(MT2712_IRQ_EN_ONESHOT_AL);
+	mt2712_writel(rtc, MT2712_IRQ_EN, irqen);
+	mt2712_rtc_write_trigger(rtc);
+
+	mt2712_writel(rtc, MT2712_AL_SEC,
+		      (mt2712_readl(rtc, MT2712_AL_SEC) & ~(MT2712_SEC_MASK)) |
+		      (tm->tm_sec  & MT2712_SEC_MASK));
+	mt2712_writel(rtc, MT2712_AL_MIN,
+		      (mt2712_readl(rtc, MT2712_AL_MIN) & ~(MT2712_MIN_MASK)) |
+		      (tm->tm_min  & MT2712_MIN_MASK));
+	mt2712_writel(rtc, MT2712_AL_HOU,
+		      (mt2712_readl(rtc, MT2712_AL_HOU) & ~(MT2712_HOU_MASK)) |
+		      (tm->tm_hour & MT2712_HOU_MASK));
+	mt2712_writel(rtc, MT2712_AL_DOM,
+		      (mt2712_readl(rtc, MT2712_AL_DOM) & ~(MT2712_DOM_MASK)) |
+		      (tm->tm_mday & MT2712_DOM_MASK));
+	mt2712_writel(rtc, MT2712_AL_MTH,
+		      (mt2712_readl(rtc, MT2712_AL_MTH) & ~(MT2712_MTH_MASK)) |
+		      (tm->tm_mon  & MT2712_MTH_MASK));
+	mt2712_writel(rtc, MT2712_AL_YEA,
+		      (mt2712_readl(rtc, MT2712_AL_YEA) & ~(MT2712_YEA_MASK)) |
+		      (tm->tm_year & MT2712_YEA_MASK));
+
+	mt2712_writel(rtc, MT2712_AL_MASK, MT2712_AL_MASK_DOW);	/* mask DOW */
+
+	if (alm->enabled) {
+		irqen = mt2712_readl(rtc, MT2712_IRQ_EN) |
+				     MT2712_IRQ_EN_ONESHOT_AL;
+		mt2712_writel(rtc, MT2712_IRQ_EN, irqen);
+	} else {
+		irqen = mt2712_readl(rtc, MT2712_IRQ_EN) &
+				     ~(MT2712_IRQ_EN_ONESHOT_AL);
+		mt2712_writel(rtc, MT2712_IRQ_EN, irqen);
+	}
+	mt2712_rtc_write_trigger(rtc);
+
+	return 0;
+}
+
+/* Init RTC register */
+static void mt2712_rtc_hw_init(struct mt2712_rtc *rtc)
+{
+	u32 p1, p2;
+
+	mt2712_writel(rtc, MT2712_BBPU, MT2712_BBPU_KEY | MT2712_BBPU_RELOAD);
+
+	mt2712_writel(rtc, MT2712_CII_EN, 0);
+	mt2712_writel(rtc, MT2712_AL_MASK, 0);
+	/* necessary before set MT2712_POWERKEY */
+	mt2712_writel(rtc, MT2712_CON0, 0x4848);
+	mt2712_writel(rtc, MT2712_CON1, 0x0048);
+
+	mt2712_rtc_write_trigger(rtc);
+
+	mt2712_readl(rtc, MT2712_IRQ_STA);	/* read clear */
+
+	p1 = mt2712_readl(rtc, MT2712_POWERKEY1);
+	p2 = mt2712_readl(rtc, MT2712_POWERKEY2);
+	if (p1 != MT2712_POWERKEY1_KEY || p2 != MT2712_POWERKEY2_KEY)
+		dev_dbg(rtc->dev, "powerkey not set (lost power)\n");
+
+	/* RTC need POWERKEY1/2 match, then goto normal work mode */
+	mt2712_writel(rtc, MT2712_POWERKEY1, MT2712_POWERKEY1_KEY);
+	mt2712_writel(rtc, MT2712_POWERKEY2, MT2712_POWERKEY2_KEY);
+	mt2712_rtc_write_trigger(rtc);
+
+	mt2712_rtc_writeif_unlock(rtc);
+}
+
+static const struct rtc_class_ops mt2712_rtc_ops = {
+	.read_time	= mt2712_rtc_read_time,
+	.set_time	= mt2712_rtc_set_time,
+	.read_alarm	= mt2712_rtc_read_alarm,
+	.set_alarm	= mt2712_rtc_set_alarm,
+};
+
+static int mt2712_rtc_probe(struct platform_device *pdev)
+{
+	struct resource *res;
+	struct mt2712_rtc *rtc;
+	int ret;
+
+	rtc = devm_kzalloc(&pdev->dev, sizeof(struct mt2712_rtc), GFP_KERNEL);
+	if (!rtc)
+		return -ENOMEM;
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	rtc->base = devm_ioremap_resource(&pdev->dev, res);
+	if (IS_ERR(rtc->base))
+		return PTR_ERR(rtc->base);
+
+	rtc->irq = platform_get_irq(pdev, 0);
+	if (rtc->irq < 0) {
+		dev_err(&pdev->dev, "No IRQ resource\n");
+		return rtc->irq;
+	}
+
+	rtc->dev = &pdev->dev;
+	platform_set_drvdata(pdev, rtc);
+
+	rtc->rtc_dev = devm_rtc_allocate_device(rtc->dev);
+	if (IS_ERR(rtc->rtc_dev))
+		return PTR_ERR(rtc->rtc_dev);
+
+	ret = devm_request_threaded_irq(&pdev->dev, rtc->irq, NULL,
+					rtc_irq_handler_thread,
+					IRQF_ONESHOT | IRQF_TRIGGER_LOW,
+					dev_name(rtc->dev), rtc);
+	if (ret) {
+		dev_err(&pdev->dev, "Failed to request alarm IRQ: %d: %d\n",
+			rtc->irq, ret);
+		return ret;
+	}
+
+	/* rtc hw init */
+	mt2712_rtc_hw_init(rtc);
+
+	device_init_wakeup(&pdev->dev, true);
+
+	rtc->rtc_dev->ops = &mt2712_rtc_ops;
+
+	ret = rtc_register_device(rtc->rtc_dev);
+	if (ret) {
+		dev_err(&pdev->dev, "register rtc device failed\n");
+		return ret;
+	}
+
+	return 0;
+}
+
+#ifdef CONFIG_PM_SLEEP
+static int mt2712_rtc_suspend(struct device *dev)
+{
+	int wake_status = 0;
+	struct mt2712_rtc *rtc = dev_get_drvdata(dev);
+
+	if (device_may_wakeup(dev)) {
+		wake_status = enable_irq_wake(rtc->irq);
+		if (!wake_status)
+			rtc->irq_wake_enabled = true;
+	}
+
+	return 0;
+}
+
+static int mt2712_rtc_resume(struct device *dev)
+{
+	int wake_status = 0;
+	struct mt2712_rtc *rtc = dev_get_drvdata(dev);
+
+	if (device_may_wakeup(dev) && rtc->irq_wake_enabled) {
+		wake_status = disable_irq_wake(rtc->irq);
+		if (!wake_status)
+			rtc->irq_wake_enabled = false;
+	}
+
+	return 0;
+}
+
+static SIMPLE_DEV_PM_OPS(mt2712_pm_ops, mt2712_rtc_suspend,
+			 mt2712_rtc_resume);
+#endif
+
+static const struct of_device_id mt2712_rtc_of_match[] = {
+	{ .compatible = "mediatek,mt2712-rtc", },
+	{ },
+};
+
+MODULE_DEVICE_TABLE(of, mt2712_rtc_of_match)
+
+static struct platform_driver mt2712_rtc_driver = {
+	.driver = {
+		.name = MTK_RTC_DEV,
+		.of_match_table = mt2712_rtc_of_match,
+		.pm = &mt2712_pm_ops,
+	},
+	.probe  = mt2712_rtc_probe,
+};
+
+module_platform_driver(mt2712_rtc_driver);
+
+MODULE_DESCRIPTION("MediaTek MT2712 SoC based RTC Driver");
+MODULE_AUTHOR("Ran Bi <ran.bi@mediatek.com>");
+MODULE_LICENSE("GPL");
-- 
2.21.0


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related

* [PATCH v2 1/4] bindings: rtc: add bindings for MT2712 RTC
From: Ran Bi @ 2019-08-01 11:01 UTC (permalink / raw)
  To: Alexandre Belloni, Rob Herring, Matthias Brugger
  Cc: Mark Rutland, Alessandro Zummo, Flora Fu, srv_heupstream,
	devicetree, Ran Bi, Greg Kroah-Hartman, Linus Walleij, Sean Wang,
	linux-kernel, YT Shen, linux-mediatek, Jonathan Cameron,
	Mauro Carvalho Chehab, Yingjoe Chen, Eddie Huang,
	David S . Miller, linux-arm-kernel, linux-rtc
In-Reply-To: <20190801110122.26834-1-ran.bi@mediatek.com>

Document the binding for MT2712 RTC implemented by rtc-mt2712.

Signed-off-by: Ran Bi <ran.bi@mediatek.com>
Reviewed-by: Rob Herring <robh@kernel.org>
---
 .../devicetree/bindings/rtc/rtc-mt2712.txt         | 14 ++++++++++++++
 1 file changed, 14 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/rtc/rtc-mt2712.txt

diff --git a/Documentation/devicetree/bindings/rtc/rtc-mt2712.txt b/Documentation/devicetree/bindings/rtc/rtc-mt2712.txt
new file mode 100644
index 000000000000..c33d87e5e753
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/rtc-mt2712.txt
@@ -0,0 +1,14 @@
+Device-Tree bindings for MediaTek SoC based RTC
+
+Required properties:
+- compatible	    : Should be "mediatek,mt2712-rtc" : for MT2712 SoC
+- reg 		    : Specifies base physical address and size of the registers;
+- interrupts	    : Should contain the interrupt for RTC alarm;
+
+Example:
+
+rtc: rtc@10011000 {
+	compatible = "mediatek,mt2712-rtc";
+	reg = <0 0x10011000 0 0x1000>;
+	interrupts = <GIC_SPI 239 IRQ_TYPE_LEVEL_LOW>;
+};
-- 
2.21.0


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related

* [PATCH v2 3/4] arm64: dts: add RTC nodes for MT2712
From: Ran Bi @ 2019-08-01 11:01 UTC (permalink / raw)
  To: Alexandre Belloni, Rob Herring, Matthias Brugger
  Cc: Mark Rutland, Alessandro Zummo, Flora Fu, srv_heupstream,
	devicetree, Ran Bi, Greg Kroah-Hartman, Linus Walleij, Sean Wang,
	linux-kernel, YT Shen, linux-mediatek, Jonathan Cameron,
	Mauro Carvalho Chehab, Yingjoe Chen, Eddie Huang,
	David S . Miller, linux-arm-kernel, linux-rtc
In-Reply-To: <20190801110122.26834-1-ran.bi@mediatek.com>

This patch add device node for MT2712 RTC.

Signed-off-by: Ran Bi <ran.bi@mediatek.com>
---
 arch/arm64/boot/dts/mediatek/mt2712e.dtsi | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt2712e.dtsi b/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
index 43307bad3f0d..31166c17c39a 100644
--- a/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
@@ -303,6 +303,12 @@
 		status = "disabled";
 	};
 
+	rtc: rtc@10011000 {
+		compatible = "mediatek,mt2712-rtc";
+		reg = <0 0x10011000 0 0x1000>;
+		interrupts = <GIC_SPI 239 IRQ_TYPE_LEVEL_LOW>;
+	};
+
 	spis1: spi@10013000 {
 		compatible = "mediatek,mt2712-spi-slave";
 		reg = <0 0x10013000 0 0x100>;
-- 
2.21.0


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related

* [PATCH v2 0/4] Add Support for MediaTek MT2712 RTC
From: Ran Bi @ 2019-08-01 11:01 UTC (permalink / raw)
  To: Alexandre Belloni, Rob Herring, Matthias Brugger
  Cc: Mark Rutland, Alessandro Zummo, Flora Fu, srv_heupstream,
	devicetree, Ran Bi, Greg Kroah-Hartman, Linus Walleij, Sean Wang,
	linux-kernel, YT Shen, linux-mediatek, Jonathan Cameron,
	Mauro Carvalho Chehab, Yingjoe Chen, Eddie Huang,
	David S . Miller, linux-arm-kernel, linux-rtc

This patchset add support to MT2712 RTC. MT2712 RTC is a SoC based RTC
with different architecture compared to MT7622 RTC.

Changes in V2:
1. change minimum year from 1968 to 2000
2. fix lock usage
3. stop to calculate useless day of week
4. stop to set default date after init
5. change the prefix of functions
6. use devm_request_threaded_irq() to replace request_threaded_irq()
7. add mt2712 rtc related files into MAINTAINERS

Ran Bi (4):
  bindings: rtc: add bindings for MT2712 RTC
  rtc: Add support for the MediaTek MT2712 RTC
  arm64: dts: add RTC nodes for MT2712
  MAINTAINERS: add MT2712 RTC files

 .../devicetree/bindings/rtc/rtc-mt2712.txt    |  14 +
 MAINTAINERS                                   |   2 +
 arch/arm64/boot/dts/mediatek/mt2712e.dtsi     |   6 +
 drivers/rtc/Kconfig                           |  10 +
 drivers/rtc/Makefile                          |   1 +
 drivers/rtc/rtc-mt2712.c                      | 444 ++++++++++++++++++
 6 files changed, 477 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/rtc/rtc-mt2712.txt
 create mode 100644 drivers/rtc/rtc-mt2712.c

-- 
2.21.0


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* [PATCH v2 4/4] MAINTAINERS: add MT2712 RTC files
From: Ran Bi @ 2019-08-01 11:01 UTC (permalink / raw)
  To: Alexandre Belloni, Rob Herring, Matthias Brugger
  Cc: Mark Rutland, Alessandro Zummo, Flora Fu, srv_heupstream,
	devicetree, Ran Bi, Greg Kroah-Hartman, Linus Walleij, Sean Wang,
	linux-kernel, YT Shen, linux-mediatek, Jonathan Cameron,
	Mauro Carvalho Chehab, Yingjoe Chen, Eddie Huang,
	David S . Miller, linux-arm-kernel, linux-rtc
In-Reply-To: <20190801110122.26834-1-ran.bi@mediatek.com>

This patch add MT2712 RTC related files to MAINTAINERS.

Signed-off-by: Ran Bi <ran.bi@mediatek.com>
---
 MAINTAINERS | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 783569e3c4b4..11f73a4c75eb 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1892,7 +1892,9 @@ M:	Sean Wang <sean.wang@mediatek.com>
 L:	linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
 L:	linux-mediatek@lists.infradead.org (moderated for non-subscribers)
 S:	Maintained
+F:	Documentation/devicetree/bindings/rtc/rtc-mt2712.txt
 F:	Documentation/devicetree/bindings/rtc/rtc-mt7622.txt
+F:	drivers/rtc/rtc-mt2712.c
 F:	drivers/rtc/rtc-mt6397.c
 F:	drivers/rtc/rtc-mt7622.c
 
-- 
2.21.0


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related

* Re: [PATCH] serial: imx: Avoid probe failure in case of missing gpiolib
From: Schrempf Frieder @ 2019-08-01 10:59 UTC (permalink / raw)
  To: Uwe Kleine-König
  Cc: linux-serial@vger.kernel.org, Greg Kroah-Hartman, Sascha Hauer,
	linux-kernel@vger.kernel.org, NXP Linux Team,
	Pengutronix Kernel Team, Jiri Slaby, Shawn Guo, Fabio Estevam,
	linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190801095529.dm3pvgts6cy6mbiq@pengutronix.de>

On 01.08.19 11:55, Uwe Kleine-König wrote:
> On Thu, Aug 01, 2019 at 09:28:33AM +0000, Schrempf Frieder wrote:
>> Hi Uwe,
>>
>> On 01.08.19 10:48, Uwe Kleine-König wrote:
>>> On Thu, Aug 01, 2019 at 08:18:05AM +0000, Schrempf Frieder wrote:
>>>> From: Frieder Schrempf <frieder.schrempf@kontron.de>
>>>>
>>>> If CONFIG_GPIOLIB is not enabled, mctrl_gpio_init() will return
>>>> -ENOSYS and cause the probing of the imx UART to fail. As the
>>>> GPIOs are optional, we should continue probing in this case.
>>>
>>> Is this really still the case? On which version did you hit this
>>> problem?
>>
>> Yes, I think it is. I used v5.2.5, that already has d99482673f95.
>>
>>>
>>> I would expect that is gone with
>>> d99482673f950817b30caf3fcdfb31179b050ce1 if not earlier.
>>
>> I think this is a different problem. If CONFIG_GPIOLIB is disabled,
>> mctrl_gpio_init() returns -ENOSYS unconditionally here: [1]. The
>> existing patch (d99482673f95) seems to handle the case when
>> CONFIG_GPIOLIB is enabled, but no or not all GPIOs are given in the dtb.
> 
> Ah, I see.
> 
> I don't think we should handle this on a per-driver basis. So my
> suggestion is to drop the dummy implementation for mctrl_gpio if GPIOLIB
> is disabled. Then the behaviour should be consistant with the gpio stuff
> returning NULL in this case. (Or alternatively adapt the dummy
> implementation to shortcut and behave identically.)

I get your point, but it seems a bit strange to go down all the way from 
the driver to mctrl_gpio_init_noauto() and into the loop just to return 
an empty struct mctrl_gpios to the driver that will be looped over again 
on each call of mctrl_gpio_*().

So I would rather go with a variation of your second proposal and keep 
the dummy implementation, but let it return NULL instead of an error 
pointer, as all the mctrl_gpio_*() functions already seem to have a 
check for gpios == NULL.

What do you think?

> 
> (Having said that I don't like gpiolib's behaviour of returning NULL for
> the optional calls if it's disabled, but having mctrl_gpio behave
> differently is worse.)
> 
>> The sh-sci.c driver has a similar check to skip this case: [2].
> 
> This should than be dropped, too.
> 
> Best regards
> Uwe
> 
>> [1]
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/tty/serial/serial_mctrl_gpio.h#n121
>> [2]
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/tty/serial/sh-sci.c#n3290
> 
_______________________________________________
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] arm64: Relax ICC_PMR_EL1 accesses when ICC_CTLR_EL1.PMHE is clear
From: Julien Thierry @ 2019-08-01 10:56 UTC (permalink / raw)
  To: Marc Zyngier
  Cc: Marc Zyngier, Will Deacon, Suzuki K Poulose, Catalin Marinas,
	James Morse, huawei.libin, guohanjun, liwei391, linux-arm-kernel
In-Reply-To: <a7aaf75d-af41-e162-8b78-84342be36907@arm.com>

On Thu, 1 Aug 2019 at 11:51, Marc Zyngier <marc.zyngier@arm.com> wrote:
>
> On 01/08/2019 11:41, Will Deacon wrote:
> > On Tue, Jul 30, 2019 at 03:20:45PM +0100, Julien Thierry wrote:
> >> From: Marc Zyngier <marc.zyngier@arm.com>
> >>
> >> The GICv3 architecture specification is incredibly misleading when it
> >> comes to PMR and the requirement for a DSB. It turns out that this DSB
> >> is only required if the CPU interface sends an Upstream Control
> >> message to the redistributor in order to update the RD's view of PMR.
> >>
> >> This message is only sent when ICC_CTLR_EL1.PMHE is set, which isn't
> >> the case in Linux. It can still be set from EL3, so some special care
> >> is required. But the upshot is that in the (hopefuly large) majority
> >> of the cases, we can drop the DSB altogether.
> >>
> >> This requires yet another capability and some more runtime patching.
> >
> > Hmm, does this actually require explicit runtime patching, or can we make
> > things a bit simpler with a static key?
>
> The hunk in entry.S is the blocker, AFAICS. Do we have a way to express
> static keys in asm?
>

Not that I'm aware of. I could leave the alternative in entry.S and
use a static_key for the pmr_sync() macro.

Does it change much over all? I don't see the static key simplifying
things too much, but I don't mind using that instead.

Cheers,

-- 
Julien Thierry

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH 2/2] perf/smmuv3: Validate groups for global filtering
From: Will Deacon @ 2019-08-01 10:56 UTC (permalink / raw)
  To: Robin Murphy; +Cc: mark.rutland, linux-arm-kernel, shameerali.kolothum.thodi
In-Reply-To: <1921604dc4cd820363ccf728ade6508e0987e082.1564580090.git.robin.murphy@arm.com>

On Wed, Jul 31, 2019 at 02:37:42PM +0100, Robin Murphy wrote:
> With global filtering, it becomes possible for users to construct
> self-contradictory groups with conflicting filters. Make sure we
> cover that when initially validating events.
> 
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> ---
>  drivers/perf/arm_smmuv3_pmu.c | 16 ++++++++++++++++
>  1 file changed, 16 insertions(+)
> 
> diff --git a/drivers/perf/arm_smmuv3_pmu.c b/drivers/perf/arm_smmuv3_pmu.c
> index dd40df2ac895..e1e41d2fea94 100644
> --- a/drivers/perf/arm_smmuv3_pmu.c
> +++ b/drivers/perf/arm_smmuv3_pmu.c
> @@ -324,6 +324,8 @@ static int smmu_pmu_event_init(struct perf_event *event)
>  	struct device *dev = smmu_pmu->dev;
>  	struct perf_event *sibling;
>  	int group_num_events = 1;
> +	bool has_filter;
> +	u32 filter_span, filter_sid;
>  	u16 event_id;
>  
>  	if (event->attr.type != event->pmu->type)
> @@ -354,6 +356,10 @@ static int smmu_pmu_event_init(struct perf_event *event)
>  		return -EINVAL;
>  	}
>  
> +	has_filter = get_filter_enable(event);
> +	filter_span = get_filter_span(event);
> +	filter_sid = get_filter_stream_id(event);
> +
>  	for_each_sibling_event(sibling, event->group_leader) {
>  		if (sibling->pmu != event->pmu &&
>  		    !is_software_event(sibling)) {
> @@ -363,6 +369,16 @@ static int smmu_pmu_event_init(struct perf_event *event)
>  
>  		if (++group_num_events >= smmu_pmu->num_counters)
>  			return -EINVAL;
> +
> +		if (smmu_pmu->global_filter) {
> +			if (has_filter != (bool)get_filter_enable(sibling))
> +				return -EINVAL;
> +
> +			if (has_filter &&
> +			    (filter_span != get_filter_span(sibling) ||
> +			    filter_sid != get_filter_stream_id (sibling)))
> +				return -EINVAL;
> +		}

Can we avoid duplicating the validation logic from
smmu_pmu_apply_event_filter() by adding the group to a fake PMU, like we
do for the CPU PMU and the DSU PMU? You'll probably need to do a bit
of surgery on 'struct smmu_pmu' to move out the bits you need, but I
think it would be better that way.

Will

_______________________________________________
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] arm64: Relax ICC_PMR_EL1 accesses when ICC_CTLR_EL1.PMHE is clear
From: Marc Zyngier @ 2019-08-01 10:51 UTC (permalink / raw)
  To: Will Deacon, Julien Thierry
  Cc: Suzuki K Poulose, Marc Zyngier, guohanjun, James Morse,
	huawei.libin, Catalin Marinas, liwei391, linux-arm-kernel
In-Reply-To: <20190801104119.quzlr5artm4s2sbc@willie-the-truck>

On 01/08/2019 11:41, Will Deacon wrote:
> On Tue, Jul 30, 2019 at 03:20:45PM +0100, Julien Thierry wrote:
>> From: Marc Zyngier <marc.zyngier@arm.com>
>>
>> The GICv3 architecture specification is incredibly misleading when it
>> comes to PMR and the requirement for a DSB. It turns out that this DSB
>> is only required if the CPU interface sends an Upstream Control
>> message to the redistributor in order to update the RD's view of PMR.
>>
>> This message is only sent when ICC_CTLR_EL1.PMHE is set, which isn't
>> the case in Linux. It can still be set from EL3, so some special care
>> is required. But the upshot is that in the (hopefuly large) majority
>> of the cases, we can drop the DSB altogether.
>>
>> This requires yet another capability and some more runtime patching.
> 
> Hmm, does this actually require explicit runtime patching, or can we make
> things a bit simpler with a static key?

The hunk in entry.S is the blocker, AFAICS. Do we have a way to express
static keys in asm?

	M.
-- 
Jazz is not dead. It just smells funny...

_______________________________________________
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] arm64: Relax ICC_PMR_EL1 accesses when ICC_CTLR_EL1.PMHE is clear
From: Will Deacon @ 2019-08-01 10:41 UTC (permalink / raw)
  To: Julien Thierry
  Cc: Marc Zyngier, Suzuki K Poulose, Marc Zyngier, Catalin Marinas,
	James Morse, huawei.libin, guohanjun, liwei391, linux-arm-kernel
In-Reply-To: <1564496445-53486-1-git-send-email-julien.thierry.kdev@gmail.com>

On Tue, Jul 30, 2019 at 03:20:45PM +0100, Julien Thierry wrote:
> From: Marc Zyngier <marc.zyngier@arm.com>
> 
> The GICv3 architecture specification is incredibly misleading when it
> comes to PMR and the requirement for a DSB. It turns out that this DSB
> is only required if the CPU interface sends an Upstream Control
> message to the redistributor in order to update the RD's view of PMR.
> 
> This message is only sent when ICC_CTLR_EL1.PMHE is set, which isn't
> the case in Linux. It can still be set from EL3, so some special care
> is required. But the upshot is that in the (hopefuly large) majority
> of the cases, we can drop the DSB altogether.
> 
> This requires yet another capability and some more runtime patching.

Hmm, does this actually require explicit runtime patching, or can we make
things a bit simpler with a static key?

Will

_______________________________________________
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 v2 0/6] Introduce TEE based Trusted Keys support
From: Janne Karhunen @ 2019-08-01 10:40 UTC (permalink / raw)
  To: Sumit Garg
  Cc: tee-dev @ lists . linaro . org, Daniel Thompson, Jonathan Corbet,
	jejb, Ard Biesheuvel, Linux Doc Mailing List, James Morris,
	Jarkko Sakkinen, Linux Kernel Mailing List, dhowells,
	linux-security-module, keyrings, Mimi Zohar, Casey Schaufler,
	linux-integrity, Jens Wiklander, linux-arm-kernel,
	Serge E. Hallyn
In-Reply-To: <CAFA6WYOwcO5-cyaJf3tMMAdyVHJo=BzmCWtsjA3S8aj5g-GZxQ@mail.gmail.com>

On Thu, Aug 1, 2019 at 1:00 PM Sumit Garg <sumit.garg@linaro.org> wrote:

> > > Here TEE isn't similar to a user-space crypto library. In our case TEE
> > > is based on ARM TrustZone which only allows TEE communications to be
> > > initiated from privileged mode. So why would you like to route
> > > communications via user-mode (which is less secure) when we have
> > > standardised TEE interface available in kernel?
> >
> > The physical access guards for reading/writing the involved critical
> > memory are identical as far as I know? Layered security is generally a
> > good thing, and the userspace pass actually adds a layer, so not sure
> > which is really safer?
>
> AFAIK, layered security is better in case we move from lower privilege
> level to higher privilege level rather than in reverse order.

You can look at this in many ways. Another way to look at it is that
the services should be provided with the least amount of permissions
required for the task. Further you can containerize something, the
better.

As for your PLATFORMS support: it is all nice, but there is no way to
convince op-tee or any other tee to be adopted by many real users.
Every serious user can and will do their own thing, or at very best,
buy it from someone who did their own thing and is trusted. There is
zero chance that samsung, huawei, apple, nsa, google, rambus, payment
system vendors, .. would actually share the tee (or probably even the
interfaces). It is just too vital and people do not trust each other
anymore :(

Anyway, enough about the topic from my side. I guess people will tell
what they want, I'm fine with any, and it is all progress from the
current state :)


--
Janne

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [Tee-dev] [RFC v2 0/6] Introduce TEE based Trusted Keys support
From: Sumit Garg @ 2019-08-01 10:27 UTC (permalink / raw)
  To: Janne Karhunen
  Cc: dhowells, Daniel Thompson, Rouven Czerwinski, Ard Biesheuvel,
	jejb, Jonathan Corbet, Linux Doc Mailing List,
	Linux Kernel Mailing List, Jarkko Sakkinen,
	tee-dev @ lists . linaro . org, linux-security-module, keyrings,
	Mimi Zohar, Casey Schaufler, linux-integrity, linux-arm-kernel,
	Serge E. Hallyn
In-Reply-To: <CAE=NcrbujsM8wYJXq+s=o5Vy1xY1b0uKYBGvp6UP5ex70HrB2Q@mail.gmail.com>

On Thu, 1 Aug 2019 at 14:00, Janne Karhunen <janne.karhunen@gmail.com> wrote:
>
> On Thu, Aug 1, 2019 at 10:58 AM Sumit Garg <sumit.garg@linaro.org> wrote:
>
> > > Anyway, just my .02c. I guess having any new support in the kernel for
> > > new trust sources is good and improvement from the current state. I
> > > can certainly make my stuff work with your setup as well, what ever
> > > people think is the best.
> >
> > Yes your implementation can very well fit under trusted keys
> > abstraction framework without creating a new keytype: "ext-trusted".
>
> The fundamental problem with the 'standardized kernel tee' still
> exists - it will never be generic in real life. Getting all this in
> the kernel will solve your problem and sell this particular product,
> but it is quite unlikely to help that many users. If the security is
> truly important to you, would you really trust any of this code to
> someone else? In this day and age, I really doubt many do.

There are already multiple platforms supported by OP-TEE [1] which
could benefit from this trusted keys interface.

> Everyone
> does their own thing, so this is why I really see all that as a
> userspace problem.
>

IMO, we should try to use standardized interfaces which are well
thought off rather than implementing your own.

[1] https://optee.readthedocs.io/general/platforms.html


-Sumit

>
> --
> Janne

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* [PATCH v3 3/3] ARM: dts: aspeed: Add Mihawk BMC platform
From: Ben Pai @ 2019-08-01 10:18 UTC (permalink / raw)
  To: robh+dt, mark.rutland, joel, andrew, devicetree, linux-arm-kernel,
	linux-aspeed, linux-kernel
  Cc: Ben Pai, wangat

The Mihawk BMC is an ASPEED ast2500 based BMC that is part of an
OpenPower Power9 server.

Signed-off-by: Ben Pai <Ben_Pai@wistron.com>
---
 arch/arm/boot/dts/Makefile                  |   1 +
 arch/arm/boot/dts/aspeed-bmc-opp-mihawk.dts | 902 ++++++++++++++++++++
 2 files changed, 903 insertions(+)
 create mode 100755 arch/arm/boot/dts/aspeed-bmc-opp-mihawk.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index eb6de52c1936..cdfe0f43ffd3 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -1275,6 +1275,7 @@ dtb-$(CONFIG_ARCH_ASPEED) += \
 	aspeed-bmc-lenovo-hr630.dtb \
 	aspeed-bmc-microsoft-olympus.dtb \
 	aspeed-bmc-opp-lanyang.dtb \
+	aspeed-bmc-opp-mihawk.dtb \
 	aspeed-bmc-opp-palmetto.dtb \
 	aspeed-bmc-opp-romulus.dtb \
 	aspeed-bmc-opp-swift.dtb \
diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-mihawk.dts b/arch/arm/boot/dts/aspeed-bmc-opp-mihawk.dts
new file mode 100755
index 000000000000..ca42057c0c1f
--- /dev/null
+++ b/arch/arm/boot/dts/aspeed-bmc-opp-mihawk.dts
@@ -0,0 +1,902 @@
+/dts-v1/;
+
+#include "aspeed-g5.dtsi"
+#include <dt-bindings/gpio/aspeed-gpio.h>
+#include <dt-bindings/leds/leds-pca955x.h>
+
+/ {
+	model = "Mihawk BMC";
+	compatible = "ibm,mihawk-bmc", "aspeed,ast2500";
+
+
+	chosen {
+		stdout-path = &uart5;
+		bootargs = "console=ttyS4,115200 earlyprintk";
+	};
+
+	memory@80000000 {
+		reg = <0x80000000 0x20000000>; /* address and size of RAM(512MB) */
+	};
+
+	reserved-memory {
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges;
+
+		flash_memory: region@98000000 {
+			no-map;
+			reg = <0x98000000 0x04000000>; /* 64M */
+		};
+
+		gfx_memory: framebuffer {
+			size = <0x01000000>;
+			alignment = <0x01000000>;
+			compatible = "shared-dma-pool";
+			reusable;
+		};
+
+		video_engine_memory: jpegbuffer {
+			size = <0x02000000>;	/* 32MM */
+			alignment = <0x01000000>;
+			compatible = "shared-dma-pool";
+			reusable;
+		};
+	};
+
+	gpio-keys {
+		compatible = "gpio-keys";
+
+		air-water {
+			label = "air-water";
+			gpios = <&gpio ASPEED_GPIO(F, 6) GPIO_ACTIVE_LOW>;
+			linux,code = <ASPEED_GPIO(F, 6)>;
+		};
+
+		checkstop {
+			label = "checkstop";
+			gpios = <&gpio ASPEED_GPIO(J, 2) GPIO_ACTIVE_LOW>;
+			linux,code = <ASPEED_GPIO(J, 2)>;
+		};
+
+		ps0-presence {
+			label = "ps0-presence";
+			gpios = <&gpio ASPEED_GPIO(Z, 2) GPIO_ACTIVE_LOW>;
+			linux,code = <ASPEED_GPIO(Z, 2)>;
+		};
+
+		ps1-presence {
+			label = "ps1-presence";
+			gpios = <&gpio ASPEED_GPIO(Z, 0) GPIO_ACTIVE_LOW>;
+			linux,code = <ASPEED_GPIO(Z, 0)>;
+		};
+		id-button {
+			label = "id-button";
+			gpios = <&gpio ASPEED_GPIO(F, 1) GPIO_ACTIVE_LOW>;
+			linux,code = <ASPEED_GPIO(F, 1)>;
+		};
+	};
+
+	gpio-keys-polled {
+		compatible = "gpio-keys-polled";
+		poll-interval = <1000>;
+
+		fan0-presence {
+			label = "fan0-presence";
+			gpios = <&pca9552 9 GPIO_ACTIVE_LOW>;
+			linux,code = <9>;
+		};
+
+		fan1-presence {
+			label = "fan1-presence";
+			gpios = <&pca9552 10 GPIO_ACTIVE_LOW>;
+			linux,code = <10>;
+		};
+
+		fan2-presence {
+			label = "fan2-presence";
+			gpios = <&pca9552 11 GPIO_ACTIVE_LOW>;
+			linux,code = <11>;
+		};
+
+		fan3-presence {
+			label = "fan3-presence";
+			gpios = <&pca9552 12 GPIO_ACTIVE_LOW>;
+			linux,code = <12>;
+		};
+
+		fan4-presence {
+			label = "fan4-presence";
+			gpios = <&pca9552 13 GPIO_ACTIVE_LOW>;
+			linux,code = <13>;
+		};
+
+		fan5-presence {
+			label = "fan5-presence";
+			gpios = <&pca9552 14 GPIO_ACTIVE_LOW>;
+			linux,code = <14>;
+		};
+	};
+
+	leds {
+		compatible = "gpio-leds";
+
+		fault {
+			retain-state-shutdown;
+			default-state = "keep";
+			gpios = <&gpio ASPEED_GPIO(AA, 0) GPIO_ACTIVE_LOW>;
+		};
+
+		power {
+			retain-state-shutdown;
+			default-state = "keep";
+			gpios = <&gpio ASPEED_GPIO(AA, 1) GPIO_ACTIVE_LOW>;
+		};
+
+		rear-id {
+			retain-state-shutdown;
+			default-state = "keep";
+			gpios = <&gpio ASPEED_GPIO(AA, 2) GPIO_ACTIVE_LOW>;
+		};
+
+		rear-g {
+			retain-state-shutdown;
+			default-state = "keep";
+			gpios = <&gpio ASPEED_GPIO(AA, 4) GPIO_ACTIVE_LOW>;
+		};
+
+		rear-ok {
+			retain-state-shutdown;
+			default-state = "keep";
+			gpios = <&gpio ASPEED_GPIO(Y, 0) GPIO_ACTIVE_LOW>;
+		};
+
+		fan0 {
+			retain-state-shutdown;
+			default-state = "keep";
+			gpios = <&pca9552 0 GPIO_ACTIVE_LOW>;
+		};
+
+		fan1 {
+			retain-state-shutdown;
+			default-state = "keep";
+			gpios = <&pca9552 1 GPIO_ACTIVE_LOW>;
+		};
+
+		fan2 {
+			retain-state-shutdown;
+			default-state = "keep";
+			gpios = <&pca9552 2 GPIO_ACTIVE_LOW>;
+		};
+
+		fan3 {
+			retain-state-shutdown;
+			default-state = "keep";
+			gpios = <&pca9552 3 GPIO_ACTIVE_LOW>;
+		};
+
+		fan4 {
+			retain-state-shutdown;
+			default-state = "keep";
+			gpios = <&pca9552 4 GPIO_ACTIVE_LOW>;
+		};
+
+		fan5 {
+			retain-state-shutdown;
+			default-state = "keep";
+			gpios = <&pca9552 5 GPIO_ACTIVE_LOW>;
+		};
+	};
+
+	fsi: gpio-fsi {
+		compatible = "fsi-master-gpio", "fsi-master";
+		#address-cells = <2>;
+		#size-cells = <0>;
+		no-gpio-delays;
+
+		clock-gpios = <&gpio ASPEED_GPIO(E, 6) GPIO_ACTIVE_HIGH>;
+		data-gpios = <&gpio ASPEED_GPIO(E, 7) GPIO_ACTIVE_HIGH>;
+		mux-gpios = <&gpio ASPEED_GPIO(E, 5) GPIO_ACTIVE_HIGH>;
+		enable-gpios = <&gpio ASPEED_GPIO(D, 0) GPIO_ACTIVE_HIGH>;
+		trans-gpios = <&gpio ASPEED_GPIO(R, 2) GPIO_ACTIVE_HIGH>;
+	};
+	iio-hwmon-12v {
+		compatible = "iio-hwmon";
+		io-channels = <&adc 0>;
+	};
+	
+	iio-hwmon-5v {
+		compatible = "iio-hwmon";
+		io-channels = <&adc 1>;
+	};
+	
+	iio-hwmon-3v {
+		compatible = "iio-hwmon";
+		io-channels = <&adc 2>;
+	};
+		
+	iio-hwmon-vdd0 {
+		compatible = "iio-hwmon";
+		io-channels = <&adc 3>;
+	};
+	
+	iio-hwmon-vdd1 {
+		compatible = "iio-hwmon";
+		io-channels = <&adc 4>;
+	};
+	
+	iio-hwmon-vcs0 {
+		compatible = "iio-hwmon";
+		io-channels = <&adc 5>;
+	};
+	
+	iio-hwmon-vcs1 {
+		compatible = "iio-hwmon";
+		io-channels = <&adc 6>;
+	};
+
+	iio-hwmon-vdn0 {
+		compatible = "iio-hwmon";
+		io-channels = <&adc 7>;
+	};
+	
+	iio-hwmon-vdn1 {
+		compatible = "iio-hwmon";
+		io-channels = <&adc 8>;
+	};
+	
+	iio-hwmon-vio0 {
+		compatible = "iio-hwmon";
+		io-channels = <&adc 9>;
+	};
+	
+	iio-hwmon-vio1 {
+		compatible = "iio-hwmon";
+		io-channels = <&adc 10>;
+	};
+	
+	iio-hwmon-vddra {
+		compatible = "iio-hwmon";
+		io-channels = <&adc 11>;
+	};
+	
+	iio-hwmon-vddrb {
+		compatible = "iio-hwmon";
+		io-channels = <&adc 13>;
+	};
+	
+	iio-hwmon-vddrc {
+		compatible = "iio-hwmon";
+		io-channels = <&adc 14>;
+	};
+	
+	iio-hwmon-vddrd {
+		compatible = "iio-hwmon";
+		io-channels = <&adc 15>;
+	};
+	
+	iio-hwmon-battery {
+		compatible = "iio-hwmon";
+		io-channels = <&adc 12>;
+	};
+};
+
+&pwm_tacho {
+	status = "okay";
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_pwm0_default &pinctrl_pwm1_default
+		&pinctrl_pwm2_default &pinctrl_pwm3_default
+		&pinctrl_pwm4_default &pinctrl_pwm5_default>;
+
+	fan@0 {
+		reg = <0x00>;
+		aspeed,fan-tach-ch = /bits/ 8 <0x00>;
+	};
+
+	fan@1 {
+		reg = <0x01>;
+		aspeed,fan-tach-ch = /bits/ 8 <0x01>;
+	};
+
+	fan@2 {
+		reg = <0x02>;
+		aspeed,fan-tach-ch = /bits/ 8 <0x02>;
+	};
+
+	fan@3 {
+		reg = <0x03>;
+		aspeed,fan-tach-ch = /bits/ 8 <0x03>;
+	};
+
+	fan@4 {
+		reg = <0x04>;
+		aspeed,fan-tach-ch = /bits/ 8 <0x04>;
+	};
+
+	fan@5 {
+		reg = <0x05>;
+		aspeed,fan-tach-ch = /bits/ 8 <0x05>;
+	};
+
+	fan@6 {
+		reg = <0x00>;
+		aspeed,fan-tach-ch = /bits/ 8 <0x06>;
+	};
+
+	fan@7 {
+		reg = <0x01>;
+		aspeed,fan-tach-ch = /bits/ 8 <0x07>;
+	};
+
+	fan@8 {
+		reg = <0x02>;
+		aspeed,fan-tach-ch = /bits/ 8 <0x08>;
+	};
+
+	fan@9 {
+		reg = <0x03>;
+		aspeed,fan-tach-ch = /bits/ 8 <0x09>;
+	};
+
+	fan@10 {
+		reg = <0x04>;
+		aspeed,fan-tach-ch = /bits/ 8 <0x0a>;
+	};
+
+	fan@11 {
+		reg = <0x05>;
+		aspeed,fan-tach-ch = /bits/ 8 <0x0b>;
+	};
+};
+
+&fmc {
+	status = "okay";
+	flash@0 {
+		status = "okay";
+		label = "bmc";
+		m25p,fast-read;
+		spi-max-frequency = <50000000>;
+		partitions {
+			#address-cells = < 1 >;
+			#size-cells = < 1 >;
+			compatible = "fixed-partitions";
+			u-boot@0 {
+				reg = < 0 0x60000 >;
+				label = "u-boot";
+			};
+			u-boot-env@60000 {
+				reg = < 0x60000 0x20000 >;
+				label = "u-boot-env";
+			};
+			obmc-ubi@80000 {
+				reg = < 0x80000 0x1F80000 >;
+				label = "obmc-ubi";
+			};
+		};
+	};
+	flash@1 {
+		status = "okay";
+		label = "alt-bmc";
+		m25p,fast-read;
+		spi-max-frequency = <50000000>;
+		partitions {
+			#address-cells = < 1 >;
+			#size-cells = < 1 >;
+			compatible = "fixed-partitions";
+			u-boot@0 {
+				reg = < 0 0x60000 >;
+				label = "alt-u-boot";
+			};
+			u-boot-env@60000 {
+				reg = < 0x60000 0x20000 >;
+				label = "alt-u-boot-env";
+			};
+			obmc-ubi@80000 {
+				reg = < 0x80000 0x1F80000 >;
+				label = "alt-obmc-ubi";
+			};
+		};
+	};
+};
+
+&spi1 {
+	status = "okay";
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_spi1_default>;
+
+	flash@0 {
+		status = "okay";
+		label = "pnor";
+		m25p,fast-read;
+		spi-max-frequency = <100000000>;
+	};
+};
+
+&lpc_ctrl {
+	status = "okay";
+	memory-region = <&flash_memory>;
+	flash = <&spi1>;
+};
+
+&uart1 {
+	/* Rear RS-232 connector */
+	status = "okay";
+
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_txd1_default
+			&pinctrl_rxd1_default
+			&pinctrl_nrts1_default
+			&pinctrl_ndtr1_default
+			&pinctrl_ndsr1_default
+			&pinctrl_ncts1_default
+			&pinctrl_ndcd1_default
+			&pinctrl_nri1_default>;
+};
+
+&uart2 {
+	/* APSS */
+	status = "okay";
+
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_txd2_default &pinctrl_rxd2_default>;
+};
+
+&uart5 {
+	status = "okay";
+};
+
+&mac0 {
+	status = "okay";
+
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_rmii1_default>;
+	use-ncsi;
+};
+
+&mac1 {
+	status = "okay";
+
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_rgmii2_default &pinctrl_mdio2_default>;
+};
+
+&i2c0 {
+	status = "disabled";
+};
+
+&i2c1 {
+	status = "disabled";
+};
+
+&i2c2 {
+	status = "okay";
+
+	/* SAMTEC P0 */
+	/* SAMTEC P1 */
+	
+};
+
+&i2c3 {
+	status = "okay";
+
+	/* APSS */
+	/* CPLD */
+
+	/* PCA9516 (repeater) ->
+	 *    CLK Buffer 9FGS9092
+	 *    CLK Buffer 9DBL0651BKILFT
+	 *    CLK Buffer 9DBL0651BKILFT
+	 *    Power Supply 0
+	 *    Power Supply 1
+	 *    PCA 9552 LED
+	 */
+	 
+	power-supply@58 {
+		compatible = "ibm,cffps1";
+		reg = <0x58>;
+	};
+
+	power-supply@5b {
+		compatible = "ibm,cffps1";
+		reg = <0x5b>;
+	};
+
+	pca9552: pca9552@60 {
+		compatible = "nxp,pca9552";
+		reg = <0x60>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+		gpio-controller;
+		#gpio-cells = <2>;
+
+		gpio@0 {
+			reg = <0>;
+			type = <PCA955X_TYPE_GPIO>;
+		};
+		gpio@1 {
+			reg = <1>;
+			type = <PCA955X_TYPE_GPIO>;
+		};
+		gpio@2 {
+			reg = <2>;
+			type = <PCA955X_TYPE_GPIO>;
+		};
+		gpio@3 {
+			reg = <3>;
+			type = <PCA955X_TYPE_GPIO>;
+		};
+		gpio@4 {
+			reg = <4>;
+			type = <PCA955X_TYPE_GPIO>;
+		};
+		gpio@5 {
+			reg = <5>;
+			type = <PCA955X_TYPE_GPIO>;
+		};
+		gpio@6 {
+			reg = <6>;
+			type = <PCA955X_TYPE_GPIO>;
+		};
+		gpio@7 {
+			reg = <7>;
+			type = <PCA955X_TYPE_GPIO>;
+		};
+		gpio@8 {
+			reg = <8>;
+			type = <PCA955X_TYPE_GPIO>;
+		};
+		gpio@9 {
+			reg = <9>;
+			type = <PCA955X_TYPE_GPIO>;
+		};
+		gpio@10 {
+			reg = <10>;
+			type = <PCA955X_TYPE_GPIO>;
+		};
+		gpio@11 {
+			reg = <11>;
+			type = <PCA955X_TYPE_GPIO>;
+		};
+		gpio@12 {
+			reg = <12>;
+			type = <PCA955X_TYPE_GPIO>;
+		};
+		gpio@13 {
+			reg = <13>;
+			type = <PCA955X_TYPE_GPIO>;
+		};
+		gpio@14 {
+			reg = <14>;
+			type = <PCA955X_TYPE_GPIO>;
+		};
+		gpio@15 {
+			reg = <15>;
+			type = <PCA955X_TYPE_GPIO>;
+		};
+
+	};
+
+};
+
+&i2c4 {
+	status = "okay";
+
+	/* CP0 VDD & VCS : IR35221 */
+	/* CP0 VDN : IR35221 */
+	/* CP0 VIO : IR38064 */
+        /* CP0 VDDR : PXM1330 */
+
+	ir35221@70 {
+		compatible = "infineon,ir35221";
+		reg = <0x70>;
+	};
+
+	ir35221@72 {
+		compatible = "infineon,ir35221";
+		reg = <0x72>;
+	};
+
+};
+
+&i2c5 {
+	status = "okay";
+	
+	/* CP0 VDD & VCS : IR35221 */
+	/* CP0 VDN : IR35221 */
+	/* CP0 VIO : IR38064 */
+        /* CP0 VDDR : PXM1330 */
+
+	ir35221@70 {
+		compatible = "infineon,ir35221";
+		reg = <0x70>;
+	};
+
+	ir35221@72 {
+		compatible = "infineon,ir35221";
+		reg = <0x72>;
+	};
+	
+};
+
+&i2c6 {
+	status = "okay";
+	
+	/* pca9548 -> NVMe1 to 8 */
+	
+	pca9548@70 {
+		compatible = "nxp,pca9548";
+		#address-cells = <1>;
+		#size-cells = <0>;
+		reg = <0x70>;
+	};
+	
+};
+
+&i2c7 {
+	status = "okay";
+	
+	/* pca9548 -> NVMe9 to 16 */
+	
+	pca9548@70 {
+		compatible = "nxp,pca9548";
+		#address-cells = <1>;
+		#size-cells = <0>;
+		reg = <0x70>;
+	};
+	
+};
+
+&i2c8 {
+	status = "okay";
+
+	eeprom@50 {
+		compatible = "atmel,24c64";
+		reg = <0x50>;
+	};
+};
+
+&i2c9 {
+	status = "okay";
+	
+	/* pca9545 Riser -> 
+	* 	PCIe x8  Slot3 
+	* 	PCIe x16 slot4 
+	* 	PCIe x8  slot5 
+	* 	I2C BMC RISER PCA9554
+	* 	BMC SCL/SDA PCA9554 
+	* 	PCA9554
+	*/
+	
+	/* pca9545 -> 
+	* 	PCIe x16 Slot1 
+	* 	PCIe x8  slot2 
+	* 	PEX8748 
+	*/
+
+	pca9545riser@70 {
+		compatible = "nxp,pca9545";
+		#address-cells = <1>;
+		#size-cells = <0>;
+		reg = <0x70>;
+
+		i2c-mux-idle-disconnect;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+	
+	pca9545@71 {
+		compatible = "nxp,pca9545";
+		#address-cells = <1>;
+		#size-cells = <0>;
+		reg = <0x71>;
+
+		i2c-mux-idle-disconnect;
+		interrupt-controller;
+		#interrupt-cells = <2>;	
+	};
+};
+
+&i2c10 {
+	status = "okay";
+	
+	/* pca9545 Riser -> 
+	* 	PCIe x8  Slot8 
+	* 	PCIe x16 slot9 
+	* 	PCIe x8  slot10 
+	* 	I2C BMC RISER PCA9554
+	* 	BMC SCL/SDA PCA9554 
+	* 	PCA9554
+	*/
+	
+	/* pca9545 -> 
+	* 	PCIe x16 Slot1 
+	* 	PCIe x8  slot2 
+	* 	PEX8748 
+	*/
+	
+	pca9545riser@70 {
+		compatible = "nxp,pca9545";
+		#address-cells = <1>;
+		#size-cells = <0>;
+		reg = <0x70>;
+
+		i2c-mux-idle-disconnect;
+		interrupt-controller;
+		#interrupt-cells = <2>;
+	};
+	
+	pca9545@71 {
+		compatible = "nxp,pca9545";
+		#address-cells = <1>;
+		#size-cells = <0>;
+		reg = <0x71>;
+
+		i2c-mux-idle-disconnect;
+		interrupt-controller;
+		#interrupt-cells = <2>;	
+	};
+};
+
+&i2c11 {
+	status = "okay";
+	
+	/* TPM */
+	/* RTC RX8900CE */
+	/* FPGA for power sequence */
+	/* TMP275A */
+	/* TMP275A */
+	/* EMC1462 */
+
+	tpm@57 {
+		compatible = "infineon,slb9645tt";
+		reg = <0x57>;
+	};
+	
+	rtc@32 {
+		compatible = "epson,rx8900";
+		reg = <0x32>;
+	};
+	
+	tmp275@48 {
+		compatible = "ti,tmp275";
+		reg = <0x48>;
+	};
+	
+	tmp275@49 {
+		compatible = "ti,tmp275";
+		reg = <0x49>;
+	};
+
+	/* chip emc1462 use emc1403 driver */
+	emc1403@4c {
+        	compatible = "smsc,emc1403";
+        	reg = <0x4c>;
+    	};
+
+};
+
+&i2c12 {
+	status = "okay";
+
+	/* pca9545 ->
+	*	SAS BP1
+	*	SAS BP2
+	*	NVMe BP
+	*	M.2 riser
+	*/
+	
+	pca9545@70 {
+		compatible = "nxp,pca9545";
+		#address-cells = <1>;
+		#size-cells = <0>;
+		reg = <0x70>;
+
+		interrupt-controller;
+		#interrupt-cells = <2>;
+		
+		i2c@0 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <0>;
+			
+			eeprom@50 {
+				compatible = "atmel,24c64";
+				reg = <0x50>;
+			};
+		};
+		
+		i2c@1 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <1>;
+			
+			eeprom@50 {
+				compatible = "atmel,24c64";
+				reg = <0x50>;
+			};
+		};
+		
+		i2c@2 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <2>;
+			
+			eeprom@50 {
+				compatible = "atmel,24c64";
+				reg = <0x50>;
+			};
+		};
+		
+		i2c@3 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			reg = <3>;
+			
+			tmp275@48 {
+				compatible = "ti,tmp275";
+				reg = <0x48>;
+			};
+		};
+		
+	};
+	
+};
+
+&i2c13 {
+	status = "okay";
+	
+	/* pca9548 ->
+	*	NVMe BP
+	*	NVMe HDD17 to 24
+	*/
+	
+	pca9548@70 {
+		compatible = "nxp,pca9548";
+		#address-cells = <1>;
+		#size-cells = <0>;
+		reg = <0x70>;
+	};	
+};
+
+&vuart {
+	status = "okay";
+};
+
+&gfx {
+	status = "okay";
+	memory-region = <&gfx_memory>;
+};
+
+&adc {
+	/* ADC pin default is ADC*/
+	status = "okay";
+};
+
+&wdt1 {
+	aspeed,reset-type = "none";
+	aspeed,external-signal;
+	aspeed,ext-push-pull;
+	aspeed,ext-active-high;
+
+	pinctrl-names = "default";
+	pinctrl-0 = <&pinctrl_wdtrst1_default>;
+};
+
+&wdt2 {
+	aspeed,alt-boot;
+};
+
+&ibt {
+	status = "okay";
+};
+
+&vhub {
+	status = "okay";
+};
+
+&video {
+	status = "okay";
+	memory-region = <&video_engine_memory>;
+};
+
+#include "ibm-power9-dual.dtsi"
+
-- 
2.17.1


---------------------------------------------------------------------------------------------------------------------------------------------------------------
This email contains confidential or legally privileged information and is for the sole use of its intended recipient. 
Any unauthorized review, use, copying or distribution of this email or the content of this email is strictly prohibited.
If you are not the intended recipient, you may reply to the sender and should delete this e-mail immediately.
---------------------------------------------------------------------------------------------------------------------------------------------------------------

_______________________________________________
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] firmware: imx: Add DSP IPC protocol interface
From: Daniel Baluta @ 2019-08-01 10:00 UTC (permalink / raw)
  To: Shawn Guo
  Cc: Aisheng Dong, Ulf Hansson, Anson Huang, Daniel Baluta, S.j. Wang,
	Linux Kernel Mailing List, Oleksij Rempel, dl-linux-imx,
	Pengutronix Kernel Team, Fabio Estevam, linux-arm-kernel
In-Reply-To: <20190723074633.GJ15632@dragon>

On Tue, Jul 23, 2019 at 10:47 AM Shawn Guo <shawnguo@kernel.org> wrote:
>
> On Tue, Jul 23, 2019 at 10:44:09AM +0300, Daniel Baluta wrote:
> > Just realized that for this patch I forgot to add [PATCH v3]. Shawn,
> > should I resend?
>
> No need.

Just sent v4 out there adding support for remove. Hope you can have some time
to have a look.

thanks,
daniel.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox