* [PATCH 0/3] ASoC: mchp-i2s-mcc: Several fixes
From: Codrin Ciubotariu @ 2019-08-20 16:24 UTC (permalink / raw)
To: alsa-devel, linux-arm-kernel, linux-kernel
Cc: alexandre.belloni, tiwai, ludovic.desroches, broonie,
Codrin Ciubotariu, perex
This pathset fixes some issues detected while testing some more the
Microchip I2S multichannel controller. The first two patches fix some
issues that appear mostly when hw_free() and hw_params() callbacks
are called multiple times. The third patch fixes a problem caused
when the controller is in master mode and both capture and playback
are played at the same time.
All three patches have a "Fixes" tag. Although they are independent,
some conflicts might appear if they are not applied in the order
presented in this patchset. If so, please let me know so I can rebase
them.
Codrin Ciubotariu (3):
ASoC: mchp-i2s-mcc: Wait for RX/TX RDY only if controller is running
ASoC: mchp-i2s-mcc: Fix unprepare of GCLK
ASoC: mchp-i2s-mcc: Fix simultaneous capture and playback in master
mode
sound/soc/atmel/mchp-i2s-mcc.c | 111 +++++++++++++++++++--------------
1 file changed, 64 insertions(+), 47 deletions(-)
--
2.20.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 3/4] iommu/io-pgtable-arm: Rationalise TCR handling
From: Jordan Crouse @ 2019-08-20 16:23 UTC (permalink / raw)
To: Robin Murphy; +Cc: robdclark, joro, Will Deacon, iommu, linux-arm-kernel
In-Reply-To: <48ca6945-de73-116a-3230-84862ca9e60b@arm.com>
On Tue, Aug 20, 2019 at 04:25:56PM +0100, Robin Murphy wrote:
> On 20/08/2019 11:31, Will Deacon wrote:
> >On Mon, Aug 19, 2019 at 07:19:30PM +0100, Robin Murphy wrote:
> >>Although it's conceptually nice for the io_pgtable_cfg to provide a
> >>standard VMSA TCR value, the reality is that no VMSA-compliant IOMMU
> >>looks exactly like an Arm CPU, and they all have various other TCR
> >>controls which io-pgtable can't be expected to understand. Thus since
> >>there is an expectation that drivers will have to add to the given TCR
> >>value anyway, let's strip it down to just the essentials that are
> >>directly relevant to io-pgatble's inner workings - namely the address
> >>sizes, walk attributes, and where appropriate, format selection.
> >>
> >>Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> >>---
> >> drivers/iommu/arm-smmu-v3.c | 7 +------
> >> drivers/iommu/arm-smmu.c | 1 +
> >> drivers/iommu/arm-smmu.h | 2 ++
> >> drivers/iommu/io-pgtable-arm-v7s.c | 6 ++----
> >> drivers/iommu/io-pgtable-arm.c | 4 ----
> >> drivers/iommu/qcom_iommu.c | 2 +-
> >> 6 files changed, 7 insertions(+), 15 deletions(-)
> >
> >Hmm, so I'm a bit nervous about this one since I think we really should
> >be providing a TCR with EPD1 set if we're only giving you TTBR0. Relying
> >on the driver to do this worries me. See my comments on the next patch.
>
> The whole idea is that we already know we can't provide a *complete* TCR
> value (not least because anything above bit 31 is the wild west), thus
> there's really no point in io-pgtable trying to provide anything other than
> the parts it definitely controls. It makes sense to provide this partial TCR
> value "as if" for TTBR0, since that's the most common case, but ultimately
> io-pgatble doesn't know (or need to) which TTBR the caller intends to
> actually use for this table. Even if the caller *is* allocating it for
> TTBR0, io-pgtable doesn't know that they haven't got something live in TTBR1
> already, so it still wouldn't be in a position to make the EPD1 call either
> way.
>
> Ultimately, it's the IOMMU drivers who decide what they put in which TTBR,
> so it's the IOMMU drivers which have to take responsibility for EPD*. Sure
> you can worry about it, but you can equally worry about them them
> misprogramming the ASID or anything else...
I agree. If the driver *does* want to use TTBR1 then it gets a bit uglier to
realize that the io-pgtable set the bit and mask it off. To me it is a lot
clearer if this is done explicitly in the driver especially if the driver is
where we are making the choice to use either ttbr0 or ttbr1.
It would probably be easier to see in actual code, and I'll have a patch
shortly on top of this series.
Jordan
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: media: Add YAML schemas for the generic RC bindings
From: Sean Young @ 2019-08-20 16:22 UTC (permalink / raw)
To: Rob Herring
Cc: Mark Rutland, devicetree, linux-kernel@vger.kernel.org,
Maxime Ripard, Chen-Yu Tsai, Mauro Carvalho Chehab, Frank Rowand,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Linux Media Mailing List
In-Reply-To: <CAL_JsqJaH5wWCHScNZwN4jxqY5Q_UDZLnq+fghecBgYY752Lnw@mail.gmail.com>
On Tue, Aug 20, 2019 at 10:52:29AM -0500, Rob Herring wrote:
> On Tue, Aug 20, 2019 at 4:50 AM Maxime Ripard <mripard@kernel.org> wrote:
> > On Tue, Aug 20, 2019 at 09:15:26AM +0100, Sean Young wrote:
> > > On Mon, Aug 19, 2019 at 08:26:18PM +0200, Maxime Ripard wrote:
> > > > From: Maxime Ripard <maxime.ripard@bootlin.com>
> > > >
> > > > The RC controllers have a bunch of generic properties that are needed in a
> > > > device tree. Add a YAML schemas for those.
> > > >
> > > > Reviewed-by: Rob Herring <robh@kernel.org>
> > > > Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
> > >
> > > For the series (both 1/2 and 2.2):
> > >
> > > Reviewed-by: Sean Young <sean@mess.org>
> > >
> > > How's tree should this go through?
> >
> > Either yours or Rob's, I guess?
>
> Sean's because there are other changes to
> Documentation/devicetree/bindings/media/sunxi-ir.txt in -next.
Good point, I'll take them.
Thanks
Sean
_______________________________________________
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/6] dt-bindings: net: sun8i-a83t-emac: Add phy-io-supply property
From: Rob Herring @ 2019-08-20 16:20 UTC (permalink / raw)
To: Ondrej Jirman
Cc: Mark Rutland, devicetree, Alexandre Torgue, netdev,
linux-kernel@vger.kernel.org, Maxime Ripard, linux-stm32,
Chen-Yu Tsai, Jose Abreu, Maxime Coquelin, Giuseppe Cavallaro,
David S. Miller,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <20190820145343.29108-3-megous@megous.com>
On Tue, Aug 20, 2019 at 9:53 AM <megous@megous.com> wrote:
>
> From: Ondrej Jirman <megous@megous.com>
>
> Some PHYs require separate power supply for I/O pins in some modes
> of operation. Add phy-io-supply property, to allow enabling this
> power supply.
Perhaps since this is new, such phys should have *-supply in their nodes.
>
> Signed-off-by: Ondrej Jirman <megous@megous.com>
> ---
> .../devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml | 4 ++++
> 1 file changed, 4 insertions(+)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 3/6] net: stmmac: sun8i: Use devm_regulator_get for PHY regulator
From: Ondřej Jirman @ 2019-08-20 16:20 UTC (permalink / raw)
To: Andrew Lunn
Cc: Mark Rutland, Jose Abreu, Alexandre Torgue, devicetree, netdev,
linux-kernel, Maxime Ripard, linux-stm32, Chen-Yu Tsai,
Rob Herring, Maxime Coquelin, Giuseppe Cavallaro, David S. Miller,
linux-arm-kernel
In-Reply-To: <20190820155744.GN29991@lunn.ch>
Hi,
On Tue, Aug 20, 2019 at 05:57:44PM +0200, Andrew Lunn wrote:
> On Tue, Aug 20, 2019 at 05:47:14PM +0200, Ondřej Jirman wrote:
> > Hi Andrew,
> >
> > On Tue, Aug 20, 2019 at 05:39:39PM +0200, Andrew Lunn wrote:
> > > On Tue, Aug 20, 2019 at 04:53:40PM +0200, megous@megous.com wrote:
> > > > From: Ondrej Jirman <megous@megous.com>
> > > >
> > > > Use devm_regulator_get instead of devm_regulator_get_optional and rely
> > > > on dummy supply. This avoids NULL checks before regulator_enable/disable
> > > > calls.
> > >
> > > Hi Ondrej
> > >
> > > What do you mean by a dummy supply? I'm just trying to make sure you
> > > are not breaking backwards compatibility.
> >
> > Sorry, I mean dummy regulator. See:
> >
> > https://elixir.bootlin.com/linux/latest/source/drivers/regulator/core.c#L1874
> >
> > On systems that use DT (i.e. have_full_constraints() == true), when the
> > regulator is not found (ENODEV, not specified in DT), regulator_get will return
> > a fake dummy regulator that can be enabled/disabled, but doesn't do anything
> > real.
>
> Hi Ondrej
>
> But we also gain a new warning:
>
> dev_warn(dev,
> "%s supply %s not found, using dummy regulator\n",
> devname, id);
>
> This regulator is clearly optional, so there should not be a warning.
>
> Maybe you can add a new get_type, OPTIONAL_GET, which does not issue
> the warning, but does give back a dummy regulator.
We already had a info message. See my other e-mail with the dmesg output.
IMO, that warning is useful during development, and more informative than the
previous one.
regards,
o.
> Thanks
> Andrew
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
_______________________________________________
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/6] dt-bindings: net: sun8i-a83t-emac: Add phy-supply property
From: Rob Herring @ 2019-08-20 16:18 UTC (permalink / raw)
To: Ondrej Jirman
Cc: Mark Rutland, devicetree, Alexandre Torgue, netdev,
linux-kernel@vger.kernel.org, Maxime Ripard, linux-stm32,
Chen-Yu Tsai, Jose Abreu, Maxime Coquelin, Giuseppe Cavallaro,
David S. Miller,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <20190820145343.29108-2-megous@megous.com>
On Tue, Aug 20, 2019 at 9:53 AM <megous@megous.com> wrote:
>
> From: Ondrej Jirman <megous@megous.com>
>
> This is already supported by the driver, but is missing from the
> bindings.
Really, the supply for the phy should be in the phy's node...
>
> Signed-off-by: Ondrej Jirman <megous@megous.com>
> ---
> .../devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml | 4 ++++
> 1 file changed, 4 insertions(+)
Reviewed-by: Rob Herring <robh@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 5/6] dt-bindings: arm: amlogic: add SEI Robotics SEI610 bindings
From: Rob Herring @ 2019-08-20 16:16 UTC (permalink / raw)
To: Neil Armstrong
Cc: Kevin Hilman, devicetree, linux-kernel@vger.kernel.org,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
linux-amlogic
In-Reply-To: <20190820144052.18269-6-narmstrong@baylibre.com>
On Tue, Aug 20, 2019 at 9:41 AM Neil Armstrong <narmstrong@baylibre.com> wrote:
>
> Add the compatible for the Amlogic SM1 Based SEI610 board.
>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
> Documentation/devicetree/bindings/arm/amlogic.yaml | 2 ++
> 1 file changed, 2 insertions(+)
Reviewed-by: Rob Herring <robh@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 4/6] dt-bindings: arm: amlogic: add SM1 bindings
From: Rob Herring @ 2019-08-20 16:15 UTC (permalink / raw)
To: Neil Armstrong
Cc: Kevin Hilman, devicetree, linux-kernel@vger.kernel.org,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
linux-amlogic
In-Reply-To: <20190820144052.18269-5-narmstrong@baylibre.com>
On Tue, Aug 20, 2019 at 9:41 AM Neil Armstrong <narmstrong@baylibre.com> wrote:
>
> Add bindings for the new Amlogic SM1 SoC Family.
>
> It a derivative of the G12A SoC Family with :
> - Cortex-A55 core instead of A53
> - more power domains
> - a neural network co-processor
> - a CSI input and image processor
>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
> Documentation/devicetree/bindings/arm/amlogic.yaml | 3 +++
> 1 file changed, 3 insertions(+)
Reviewed-by: Rob Herring <robh@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] arm64: perf_event: Add missing header needed for smp_processor_id()
From: Will Deacon @ 2019-08-20 16:11 UTC (permalink / raw)
To: Mark Rutland
Cc: raph.gault+kdev, peterz, catalin.marinas, will.deacon,
linux-kernel, acme, Raphael Gault, mingo, linux-arm-kernel
In-Reply-To: <20190820160629.GD43412@lakrids.cambridge.arm.com>
On Tue, Aug 20, 2019 at 05:06:29PM +0100, Mark Rutland wrote:
> On Tue, Aug 20, 2019 at 04:57:45PM +0100, Raphael Gault wrote:
>
> It would be worth having a body for the commit message like:
>
> | in perf_event.c we use smp_processor_id(), but we haven't included
> | <linux/smp.h> where it is defined, and rely on this being pulled in
> | via a transitive include. Let's make this more robust by including
> | <linux.smp.h> explciitly.
>
> ... and with that, my Acked-by stands.
Queued for 5.4. with typo fixed above.
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 3/4] iommu/io-pgtable-arm: Rationalise TCR handling
From: Will Deacon @ 2019-08-20 16:07 UTC (permalink / raw)
To: Robin Murphy; +Cc: robdclark, joro, jcrouse, iommu, linux-arm-kernel
In-Reply-To: <48ca6945-de73-116a-3230-84862ca9e60b@arm.com>
On Tue, Aug 20, 2019 at 04:25:56PM +0100, Robin Murphy wrote:
> On 20/08/2019 11:31, Will Deacon wrote:
> > On Mon, Aug 19, 2019 at 07:19:30PM +0100, Robin Murphy wrote:
> > > Although it's conceptually nice for the io_pgtable_cfg to provide a
> > > standard VMSA TCR value, the reality is that no VMSA-compliant IOMMU
> > > looks exactly like an Arm CPU, and they all have various other TCR
> > > controls which io-pgtable can't be expected to understand. Thus since
> > > there is an expectation that drivers will have to add to the given TCR
> > > value anyway, let's strip it down to just the essentials that are
> > > directly relevant to io-pgatble's inner workings - namely the address
> > > sizes, walk attributes, and where appropriate, format selection.
> > >
> > > Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> > > ---
> > > drivers/iommu/arm-smmu-v3.c | 7 +------
> > > drivers/iommu/arm-smmu.c | 1 +
> > > drivers/iommu/arm-smmu.h | 2 ++
> > > drivers/iommu/io-pgtable-arm-v7s.c | 6 ++----
> > > drivers/iommu/io-pgtable-arm.c | 4 ----
> > > drivers/iommu/qcom_iommu.c | 2 +-
> > > 6 files changed, 7 insertions(+), 15 deletions(-)
> >
> > Hmm, so I'm a bit nervous about this one since I think we really should
> > be providing a TCR with EPD1 set if we're only giving you TTBR0. Relying
> > on the driver to do this worries me. See my comments on the next patch.
>
> The whole idea is that we already know we can't provide a *complete* TCR
> value (not least because anything above bit 31 is the wild west), thus
> there's really no point in io-pgtable trying to provide anything other than
> the parts it definitely controls. It makes sense to provide this partial TCR
> value "as if" for TTBR0, since that's the most common case, but ultimately
> io-pgatble doesn't know (or need to) which TTBR the caller intends to
> actually use for this table. Even if the caller *is* allocating it for
> TTBR0, io-pgtable doesn't know that they haven't got something live in TTBR1
> already, so it still wouldn't be in a position to make the EPD1 call either
> way.
Ok, but the driver can happily rewrite/ignore what it gets back. I suppose
an alternative would be scrapped the 'u64 tcr' and instead having a bunch
of named bitfields for the stuff we're actually providing, although I'd
still like EPDx to be in there.
> Ultimately, it's the IOMMU drivers who decide what they put in which TTBR,
> so it's the IOMMU drivers which have to take responsibility for EPD*. Sure
> you can worry about it, but you can equally worry about them them
> misprogramming the ASID or anything else...
I find the EPDx bits particularly dangerous because:
- They're easily overlooked
- Clobbering TTBR1 with 0x0 doesn't disable walks via TTBR1 as you might
reasonably expect
- If you do the above without EPD, the breakage will be subtle
and given that I don't see any real downsides to us providing a default TCR
value with EPD set appropriately, then I think we should do that. I'd be
happy to revisit the decision later on if it's getting the way of a real
use-case, but it feels like we're throwing the baby out with the bathwater
at the moment and I'd rather do this incrementally based on actual need.
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 v3] dt-bindings: arm: Convert Actions Semi bindings to jsonschema
From: Manivannan Sadhasivam @ 2019-08-20 16:06 UTC (permalink / raw)
To: Andreas Färber
Cc: Mark Rutland, Rob Herring, linux-kernel@vger.kernel.org,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
devicetree
In-Reply-To: <CAL_JsqJoQDkqZO_4XdaQymVW0cJDXVmAPh3uieRkBjoUXeWE1w@mail.gmail.com>
On Fri, Jun 14, 2019 at 01:33:47PM -0600, Rob Herring wrote:
> On Fri, Jun 14, 2019 at 11:07 AM Andreas Färber <afaerber@suse.de> wrote:
> >
> > Am 14.06.19 um 19:04 schrieb Manivannan Sadhasivam:
> > > On Thu, Jun 13, 2019 at 04:44:35PM -0600, Rob Herring wrote:
> > >> On Fri, May 17, 2019 at 10:32:23AM -0500, Rob Herring wrote:
> > >>> Convert Actions Semi SoC bindings to DT schema format using json-schema.
> > >>>
> > >>> Cc: "Andreas Färber" <afaerber@suse.de>
> > >>> Cc: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> > >>> Cc: Mark Rutland <mark.rutland@arm.com>
> > >>> Cc: linux-arm-kernel@lists.infradead.org
> > >>> Cc: devicetree@vger.kernel.org
> > >>> Signed-off-by: Rob Herring <robh@kernel.org>
> > >>> ---
> > >>> v3:
> > >>> - update MAINTAINERS
> > >>>
> > >>> .../devicetree/bindings/arm/actions.txt | 56 -------------------
> > >>> .../devicetree/bindings/arm/actions.yaml | 38 +++++++++++++
> > >>> MAINTAINERS | 2 +-
> > >>> 3 files changed, 39 insertions(+), 57 deletions(-)
> > >>> delete mode 100644 Documentation/devicetree/bindings/arm/actions.txt
> > >>> create mode 100644 Documentation/devicetree/bindings/arm/actions.yaml
> > >>
> > >> Ping. Please apply or modify this how you'd prefer. I'm not going to
> > >> keep respinning this.
> > >>
> > >
> > > Sorry for that Rob.
> >
> > Well, it was simply not clear whether we were supposed to or not. :)
>
> I thought 'To' you and a single patch should be clear enough.
>
> > > Andreas, are you going to take this patch? Else I'll pick it up (If you
> > > want me to do the PR for next cycle)
> >
> > I had checked that all previous changes to the .txt file were by myself,
> > so I would prefer if we not license it under GPLv2-only but under the
> > same dual-license (MIT/GPLv2+) as the DTs. That modification would need
> > Rob's approval then.
>
> That's fine and dual license is preferred. Can you adjust that when
> applying. Note that the preference for schema is (GPL-2.0 OR
> BSD-2-Clause), but MIT/GPLv2+ is fine by me.
Andreas, are you going to take this patch? Else, we can ask Rob to take
this through his tree as we don't have any queued patches for v5.4 yet.
Thanks,
Mani
>
> Rob
_______________________________________________
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: perf_event: Add missing header needed for smp_processor_id()
From: Mark Rutland @ 2019-08-20 16:06 UTC (permalink / raw)
To: Raphael Gault
Cc: raph.gault+kdev, peterz, catalin.marinas, will.deacon,
linux-kernel, acme, mingo, linux-arm-kernel
In-Reply-To: <20190820155745.20593-1-raphael.gault@arm.com>
On Tue, Aug 20, 2019 at 04:57:45PM +0100, Raphael Gault wrote:
It would be worth having a body for the commit message like:
| in perf_event.c we use smp_processor_id(), but we haven't included
| <linux/smp.h> where it is defined, and rely on this being pulled in
| via a transitive include. Let's make this more robust by including
| <linux.smp.h> explciitly.
... and with that, my Acked-by stands.
Thanks,
Mark.
> Acked-by: Mark Rutland <mark.rutland@arm.com>
> Signed-off-by: Raphael Gault <raphael.gault@arm.com>
> ---
> arch/arm64/kernel/perf_event.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c
> index 96e90e270042..24575c0a0065 100644
> --- a/arch/arm64/kernel/perf_event.c
> +++ b/arch/arm64/kernel/perf_event.c
> @@ -19,6 +19,7 @@
> #include <linux/of.h>
> #include <linux/perf/arm_pmu.h>
> #include <linux/platform_device.h>
> +#include <linux/smp.h>
>
> /* ARMv8 Cortex-A53 specific event types. */
> #define ARMV8_A53_PERFCTR_PREF_LINEFILL 0xC2
> --
> 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 v3 2/5] arm64: cpufeature: Add feature to detect heterogeneous systems
From: Mark Rutland @ 2019-08-20 16:03 UTC (permalink / raw)
To: Raphael Gault
Cc: raph.gault+kdev, peterz, catalin.marinas, will.deacon,
linux-kernel, acme, mingo, linux-arm-kernel
In-Reply-To: <8cf12008-cc86-3872-7358-2e837cf2498a@arm.com>
On Tue, Aug 20, 2019 at 04:55:24PM +0100, Raphael Gault wrote:
> Hi Mark,
>
> Thank you for your comments.
>
> On 8/20/19 4:49 PM, Mark Rutland wrote:
> > On Tue, Aug 20, 2019 at 04:23:17PM +0100, Mark Rutland wrote:
> > > Hi Raphael,
> > >
> > > On Fri, Aug 16, 2019 at 01:59:31PM +0100, Raphael Gault wrote:
> > > > This feature is required in order to enable PMU counters direct
> > > > access from userspace only when the system is homogeneous.
> > > > This feature checks the model of each CPU brought online and compares it
> > > > to the boot CPU. If it differs then it is heterogeneous.
> > >
> > > It would be worth noting that this patch prevents heterogeneous CPUs
> > > being brought online late if the system was uniform at boot time.
> >
> > Looking again, I think I'd misunderstood how
> > ARM64_CPUCAP_OPTIONAL_FOR_LATE_CPU was dealt with, but we do have a
> > problem in this area.
> >
> > [...]
> >
> > >
> > > > + .capability = ARM64_HAS_HETEROGENEOUS_PMU,
> > > > + .type = ARM64_CPUCAP_SCOPE_LOCAL_CPU | ARM64_CPUCAP_OPTIONAL_FOR_LATE_CPU,
> > > > + .matches = has_heterogeneous_pmu,
> > > > + },
> >
> > I had a quick chat with Will, and we concluded that we must permit late
> > onlining of heterogeneous CPUs here as people are likely to rely on
> > late CPU onlining on some heterogeneous systems.
> >
> > I think the above permits that, but that also means that we need some
> > support code to fail gracefully in that case (e.g. without sending
> > a SIGILL to unaware userspace code).
>
> I understand, however, I understood that ARM64_CPUCAP_OPTIONAL_FOR_LATE_CPU
> did not allow later CPU to be heterogeneous if the capability wasn't already
> enabled.
Yes, I think that you're right. IIUC the absence of
ARM64_CPUCAP_PERMITTED_FOR_LATE_CPU is what prevents that from
happening.
> Thus if as you say we need to allow the system to switch from
> homogeneous to heterogeneous, then I should change the type of this
> capability.
I'm afraid so!
I believe we need both ARM64_CPUCAP_OPTIONAL_FOR_LATE_CPU and
ARM64_CPUCAP_PERMITTED_FOR_LATE_CPU, so I guess we should be using
ARM64_CPUCAP_WEAK_LOCAL_CPU_FEATURE.
Does that sound right to you? ... or have I confused myself again?
Thanks,
Mark.
> > That means that we'll need the counter emulation code that you had in
> > previous versions of this patch (e.g. to handle potential UNDEFs when a
> > new CPU has fewer counters than the previously online CPUs).
> >
> > Further, I think the context switch (and event index) code needs to take
> > this cap into account, and disable direct access once the system becomes
> > heterogeneous.
>
> That is a good point indeed.
>
> Thanks,
>
> --
> Raphael Gault
_______________________________________________
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 4/4] iommu/io-pgtable-arm: Prepare for TTBR1 usage
From: Will Deacon @ 2019-08-20 15:58 UTC (permalink / raw)
To: Robin Murphy; +Cc: robdclark, joro, jcrouse, iommu, linux-arm-kernel
In-Reply-To: <469dc66a-2532-5f7f-cd8d-3fe13f6c279a@arm.com>
On Tue, Aug 20, 2019 at 03:51:45PM +0100, Robin Murphy wrote:
> On 20/08/2019 11:30, Will Deacon wrote:
> > On Mon, Aug 19, 2019 at 07:19:31PM +0100, Robin Murphy wrote:
> > > Now that callers are free to use a given table for TTBR1 if they wish
> > > (all they need do is shift the provided attributes when constructing
> > > their final TCR value), the only remaining impediment is the address
> > > validation on map/unmap. The fact that the LPAE address space split is
> > > symmetric makes this easy to accommodate - by simplifying the current
> > > range checks into explicit tests that address bits above IAS are all
> > > zero, it then follows straightforwardly to add the inverse test to
> > > allow the all-ones case as well.
> > >
> > > Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> > > ---
> > > drivers/iommu/io-pgtable-arm.c | 7 ++++---
> > > 1 file changed, 4 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
> > > index 09cb20671fbb..f39c50356351 100644
> > > --- a/drivers/iommu/io-pgtable-arm.c
> > > +++ b/drivers/iommu/io-pgtable-arm.c
> > > @@ -475,13 +475,13 @@ static int arm_lpae_map(struct io_pgtable_ops *ops, unsigned long iova,
> > > arm_lpae_iopte *ptep = data->pgd;
> > > int ret, lvl = ARM_LPAE_START_LVL(data);
> > > arm_lpae_iopte prot;
> > > + long iaext = (long)iova >> data->iop.cfg.ias;
> > > /* If no access, then nothing to do */
> > > if (!(iommu_prot & (IOMMU_READ | IOMMU_WRITE)))
> > > return 0;
> > > - if (WARN_ON(iova >= (1ULL << data->iop.cfg.ias) ||
> > > - paddr >= (1ULL << data->iop.cfg.oas)))
> > > + if (WARN_ON((iaext && ~iaext) || paddr >> data->iop.cfg.oas))
> >
> > I had to read that '&&' twice, but I see what you're doing now :)
> >
> > > return -ERANGE;
> >
> > This doesn't seem sufficient to prevent a mixture of TTBR1 and TTBR0
> > addresses from being mapped in the same TTBR. Perhaps we need a quirk for
> > TTBR1, which could then take care of setting EPDx appropriately?
>
> Right, that's the one downside of going for the minimalist "io-pgtable
> doesn't even have to know" approach. On reflection, though, in that paradigm
> it should probably be the caller's responsibility to convert TTBR1 addresses
> to preserve the "as if TTBR0" illusion anyway :/
Right, and I'd rather not push stuff into the caller for the common case.
It's not exactly onerous to support this in io-pgtable. It's also why I'd
still like to keep the EPDx in there, because the callers that care can
rewrite the stuff, but at least we provided a default.
> The advantage of not having a quirk is that it allows split address spaces
> to fit more closely with the aux_domain idea, i.e. we could allocate and
> initialise a domain without having to assume, or even care, whether it will
> end up attached as a primary or aux domain. It *might* even be potentially
> useful to have a domain attached to TTBR0 of one device's context and TTBR1
> of another's at the same time, although that's pretty niche.
That sounds pretty theoretical to me at the moment.
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] arm64: perf_event: Add missing header needed for smp_processor_id()
From: Raphael Gault @ 2019-08-20 15:57 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel
Cc: mark.rutland, raph.gault+kdev, peterz, catalin.marinas,
will.deacon, acme, Raphael Gault, mingo
Acked-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Raphael Gault <raphael.gault@arm.com>
---
arch/arm64/kernel/perf_event.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c
index 96e90e270042..24575c0a0065 100644
--- a/arch/arm64/kernel/perf_event.c
+++ b/arch/arm64/kernel/perf_event.c
@@ -19,6 +19,7 @@
#include <linux/of.h>
#include <linux/perf/arm_pmu.h>
#include <linux/platform_device.h>
+#include <linux/smp.h>
/* ARMv8 Cortex-A53 specific event types. */
#define ARMV8_A53_PERFCTR_PREF_LINEFILL 0xC2
--
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 3/6] net: stmmac: sun8i: Use devm_regulator_get for PHY regulator
From: Andrew Lunn @ 2019-08-20 15:57 UTC (permalink / raw)
To: David S. Miller, Rob Herring, Mark Rutland, Maxime Ripard,
Chen-Yu Tsai, Giuseppe Cavallaro, Alexandre Torgue, Jose Abreu,
Maxime Coquelin, devicetree, netdev, linux-kernel, linux-stm32,
linux-arm-kernel
In-Reply-To: <20190820154714.2rt4ctovil5ol3u2@core.my.home>
On Tue, Aug 20, 2019 at 05:47:14PM +0200, Ondřej Jirman wrote:
> Hi Andrew,
>
> On Tue, Aug 20, 2019 at 05:39:39PM +0200, Andrew Lunn wrote:
> > On Tue, Aug 20, 2019 at 04:53:40PM +0200, megous@megous.com wrote:
> > > From: Ondrej Jirman <megous@megous.com>
> > >
> > > Use devm_regulator_get instead of devm_regulator_get_optional and rely
> > > on dummy supply. This avoids NULL checks before regulator_enable/disable
> > > calls.
> >
> > Hi Ondrej
> >
> > What do you mean by a dummy supply? I'm just trying to make sure you
> > are not breaking backwards compatibility.
>
> Sorry, I mean dummy regulator. See:
>
> https://elixir.bootlin.com/linux/latest/source/drivers/regulator/core.c#L1874
>
> On systems that use DT (i.e. have_full_constraints() == true), when the
> regulator is not found (ENODEV, not specified in DT), regulator_get will return
> a fake dummy regulator that can be enabled/disabled, but doesn't do anything
> real.
Hi Ondrej
But we also gain a new warning:
dev_warn(dev,
"%s supply %s not found, using dummy regulator\n",
devname, id);
This regulator is clearly optional, so there should not be a warning.
Maybe you can add a new get_type, OPTIONAL_GET, which does not issue
the warning, but does give back a dummy regulator.
Thanks
Andrew
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 3/6] net: stmmac: sun8i: Use devm_regulator_get for PHY regulator
From: Ondřej Jirman @ 2019-08-20 15:56 UTC (permalink / raw)
To: Andrew Lunn
Cc: Mark Rutland, Jose Abreu, Alexandre Torgue, devicetree, netdev,
linux-kernel, Maxime Ripard, linux-stm32, Chen-Yu Tsai,
Rob Herring, Maxime Coquelin, Giuseppe Cavallaro, David S. Miller,
linux-arm-kernel
In-Reply-To: <20190820153939.GL29991@lunn.ch>
On Tue, Aug 20, 2019 at 05:39:39PM +0200, Andrew Lunn wrote:
> On Tue, Aug 20, 2019 at 04:53:40PM +0200, megous@megous.com wrote:
> > From: Ondrej Jirman <megous@megous.com>
> >
> > Use devm_regulator_get instead of devm_regulator_get_optional and rely
> > on dummy supply. This avoids NULL checks before regulator_enable/disable
> > calls.
>
> Hi Ondrej
>
> What do you mean by a dummy supply? I'm just trying to make sure you
> are not breaking backwards compatibility.
I have tested it on Orange Pi PC 2, that uses only phy-supply, but not
phy-io-supply, and the kernel now prints:
[ 1.410137] dwmac-sun8i 1c30000.ethernet: 1c30000.ethernet supply phy-io not found, using dummy regulator
I have also tested it on Orange Pi PC, that doesn't use external phy, and
instead of:
[ 1.081378] dwmac-sun8i 1c30000.ethernet: No regulator found
The kernel now prints:
[ 1.112752] dwmac-sun8i 1c30000.ethernet: 1c30000.ethernet supply phy not found, using dummy regulator
[ 1.112814] dwmac-sun8i 1c30000.ethernet: 1c30000.ethernet supply phy-io not found, using dummy regulator
Ethernet works in both cases, so that should cover all existing combinations. :)
regards,
Ondrej
> Thanks
> Andrew
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 2/5] arm64: cpufeature: Add feature to detect heterogeneous systems
From: Raphael Gault @ 2019-08-20 15:55 UTC (permalink / raw)
To: Mark Rutland
Cc: raph.gault+kdev, peterz, catalin.marinas, will.deacon,
linux-kernel, acme, mingo, linux-arm-kernel
In-Reply-To: <20190820154955.GB43412@lakrids.cambridge.arm.com>
Hi Mark,
Thank you for your comments.
On 8/20/19 4:49 PM, Mark Rutland wrote:
> On Tue, Aug 20, 2019 at 04:23:17PM +0100, Mark Rutland wrote:
>> Hi Raphael,
>>
>> On Fri, Aug 16, 2019 at 01:59:31PM +0100, Raphael Gault wrote:
>>> This feature is required in order to enable PMU counters direct
>>> access from userspace only when the system is homogeneous.
>>> This feature checks the model of each CPU brought online and compares it
>>> to the boot CPU. If it differs then it is heterogeneous.
>>
>> It would be worth noting that this patch prevents heterogeneous CPUs
>> being brought online late if the system was uniform at boot time.
>
> Looking again, I think I'd misunderstood how
> ARM64_CPUCAP_OPTIONAL_FOR_LATE_CPU was dealt with, but we do have a
> problem in this area.
>
> [...]
>
>>
>>> + .capability = ARM64_HAS_HETEROGENEOUS_PMU,
>>> + .type = ARM64_CPUCAP_SCOPE_LOCAL_CPU | ARM64_CPUCAP_OPTIONAL_FOR_LATE_CPU,
>>> + .matches = has_heterogeneous_pmu,
>>> + },
>
> I had a quick chat with Will, and we concluded that we must permit late
> onlining of heterogeneous CPUs here as people are likely to rely on
> late CPU onlining on some heterogeneous systems.
>
> I think the above permits that, but that also means that we need some
> support code to fail gracefully in that case (e.g. without sending
> a SIGILL to unaware userspace code).
I understand, however, I understood that
ARM64_CPUCAP_OPTIONAL_FOR_LATE_CPU did not allow later CPU to be
heterogeneous if the capability wasn't already enabled. Thus if as you
say we need to allow the system to switch from homogeneous to
heterogeneous, then I should change the type of this capability.
> That means that we'll need the counter emulation code that you had in
> previous versions of this patch (e.g. to handle potential UNDEFs when a
> new CPU has fewer counters than the previously online CPUs).
>
> Further, I think the context switch (and event index) code needs to take
> this cap into account, and disable direct access once the system becomes
> heterogeneous.
That is a good point indeed.
Thanks,
--
Raphael Gault
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 1/6] dt-bindings: watchdog: Add YAML schemas for the generic watchdog bindings
From: Guenter Roeck @ 2019-08-20 15:54 UTC (permalink / raw)
To: Maxime Ripard, wim
Cc: Mark Rutland, devicetree, Maxime Ripard, linux-kernel,
Chen-Yu Tsai, Rob Herring, Frank Rowand, linux-arm-kernel
In-Reply-To: <20190819182039.24892-1-mripard@kernel.org>
On 8/19/19 11:20 AM, Maxime Ripard wrote:
> From: Maxime Ripard <maxime.ripard@bootlin.com>
>
> The watchdogs have a bunch of generic properties that are needed in a
> device tree. Add a YAML schemas for those.
>
> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
What is the target subsystem for this series ? You didn't copy the watchdog
mailing list, so I assume it won't be the watchdog subsystem.
Thanks,
Guenter
>
> ---
>
> Changes from v1:
> - New patch
> ---
> .../bindings/watchdog/watchdog.yaml | 26 +++++++++++++++++++
> 1 file changed, 26 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/watchdog/watchdog.yaml
>
> diff --git a/Documentation/devicetree/bindings/watchdog/watchdog.yaml b/Documentation/devicetree/bindings/watchdog/watchdog.yaml
> new file mode 100644
> index 000000000000..187bf6cb62bf
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/watchdog/watchdog.yaml
> @@ -0,0 +1,26 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/watchdog/watchdog.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Watchdog Generic Bindings
> +
> +maintainers:
> + - Guenter Roeck <linux@roeck-us.net>
> + - Wim Van Sebroeck <wim@linux-watchdog.org>
> +
> +description: |
> + This document describes generic bindings which can be used to
> + describe watchdog devices in a device tree.
> +
> +properties:
> + $nodename:
> + pattern: "^watchdog(@.*|-[0-9a-f])?$"
> +
> + timeout-sec:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description:
> + Contains the watchdog timeout in seconds.
> +
> +...
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: media: Add YAML schemas for the generic RC bindings
From: Rob Herring @ 2019-08-20 15:52 UTC (permalink / raw)
To: Maxime Ripard
Cc: Mark Rutland, devicetree, Sean Young,
linux-kernel@vger.kernel.org, Chen-Yu Tsai, Mauro Carvalho Chehab,
Frank Rowand,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Linux Media Mailing List
In-Reply-To: <20190820095028.l74sfvipwjjla6kq@flea>
On Tue, Aug 20, 2019 at 4:50 AM Maxime Ripard <mripard@kernel.org> wrote:
>
> Hi Sean,
>
> On Tue, Aug 20, 2019 at 09:15:26AM +0100, Sean Young wrote:
> > On Mon, Aug 19, 2019 at 08:26:18PM +0200, Maxime Ripard wrote:
> > > From: Maxime Ripard <maxime.ripard@bootlin.com>
> > >
> > > The RC controllers have a bunch of generic properties that are needed in a
> > > device tree. Add a YAML schemas for those.
> > >
> > > Reviewed-by: Rob Herring <robh@kernel.org>
> > > Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
> >
> > For the series (both 1/2 and 2.2):
> >
> > Reviewed-by: Sean Young <sean@mess.org>
> >
> > How's tree should this go through?
>
> Either yours or Rob's, I guess?
Sean's because there are other changes to
Documentation/devicetree/bindings/media/sunxi-ir.txt in -next.
Rob
_______________________________________________
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/4] iommu/io-pgtable-arm: Rationalise TTBRn handling
From: Will Deacon @ 2019-08-20 15:50 UTC (permalink / raw)
To: Robin Murphy; +Cc: robdclark, joro, jcrouse, iommu, linux-arm-kernel
In-Reply-To: <e644e0f6-4588-56eb-a6e9-7b482e3d228d@arm.com>
On Tue, Aug 20, 2019 at 03:17:19PM +0100, Robin Murphy wrote:
> On 20/08/2019 11:19, Will Deacon wrote:
> > On Mon, Aug 19, 2019 at 07:19:29PM +0100, Robin Murphy wrote:
> > > TTBR1 values have so far been redundant since no users implement any
> > > support for split address spaces. Crucially, though, one of the main
> > > reasons for wanting to do so is to be able to manage each half entirely
> > > independently, e.g. context-switching one set of mappings without
> > > disturbing the other. Thus it seems unlikely that tying two tables
> > > together in a single io_pgtable_cfg would ever be particularly desirable
> > > or useful.
> > >
> > > Streamline the configs to just a single conceptual TTBR value
> > > representing the allocated table. This paves the way for future users to
> > > support split address spaces by simply allocating a table and dealing
> > > with the detailed TTBRn logistics themselves.
> > >
> > > Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> > > ---
> > > drivers/iommu/arm-smmu-v3.c | 2 +-
> > > drivers/iommu/arm-smmu.c | 9 ++++-----
> > > drivers/iommu/io-pgtable-arm-v7s.c | 16 +++++++---------
> > > drivers/iommu/io-pgtable-arm.c | 7 +++----
> > > drivers/iommu/ipmmu-vmsa.c | 2 +-
> > > drivers/iommu/msm_iommu.c | 4 ++--
> > > drivers/iommu/mtk_iommu.c | 4 ++--
> > > drivers/iommu/qcom_iommu.c | 3 +--
> > > include/linux/io-pgtable.h | 4 ++--
> > > 9 files changed, 23 insertions(+), 28 deletions(-)
> > >
> > > diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
> > > index 2a8db896d698..2e50cf49c3c4 100644
> > > --- a/drivers/iommu/arm-smmu-v3.c
> > > +++ b/drivers/iommu/arm-smmu-v3.c
> > > @@ -1722,7 +1722,7 @@ static int arm_smmu_domain_finalise_s1(struct arm_smmu_domain *smmu_domain,
> > > }
> > > cfg->cd.asid = (u16)asid;
> > > - cfg->cd.ttbr = pgtbl_cfg->arm_lpae_s1_cfg.ttbr[0];
> > > + cfg->cd.ttbr = pgtbl_cfg->arm_lpae_s1_cfg.ttbr;
> > > cfg->cd.tcr = pgtbl_cfg->arm_lpae_s1_cfg.tcr;
> > > cfg->cd.mair = pgtbl_cfg->arm_lpae_s1_cfg.mair;
> > > return 0;
> > > diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> > > index 184ca41e9de7..19030c4b5904 100644
> > > --- a/drivers/iommu/arm-smmu.c
> > > +++ b/drivers/iommu/arm-smmu.c
> > > @@ -473,13 +473,12 @@ static void arm_smmu_init_context_bank(struct arm_smmu_domain *smmu_domain,
> > > /* TTBRs */
> > > if (stage1) {
> > > if (cfg->fmt == ARM_SMMU_CTX_FMT_AARCH32_S) {
> > > - cb->ttbr[0] = pgtbl_cfg->arm_v7s_cfg.ttbr[0];
> > > - cb->ttbr[1] = pgtbl_cfg->arm_v7s_cfg.ttbr[1];
> > > + cb->ttbr[0] = pgtbl_cfg->arm_v7s_cfg.ttbr;
> > > + cb->ttbr[1] = 0;
> > > } else {
> > > - cb->ttbr[0] = pgtbl_cfg->arm_lpae_s1_cfg.ttbr[0];
> > > + cb->ttbr[0] = pgtbl_cfg->arm_lpae_s1_cfg.ttbr;
> > > cb->ttbr[0] |= FIELD_PREP(TTBRn_ASID, cfg->asid);
> > > - cb->ttbr[1] = pgtbl_cfg->arm_lpae_s1_cfg.ttbr[1];
> > > - cb->ttbr[1] |= FIELD_PREP(TTBRn_ASID, cfg->asid);
> > > + cb->ttbr[1] = FIELD_PREP(TTBRn_ASID, cfg->asid);
> >
> > Why do you continue to put the ASID in here?
>
> For the same reason we put it there before ;)
>
> Although I guess if TCR.A1 were ever to get flipped accidentally then we're
> still cool.
Hmm, but we don't do this for other drivers, so I'd be inclined to zap it
with 0 for consistency.
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 v2 2/2] watchdog: aspeed: Add support for AST2600
From: Guenter Roeck @ 2019-08-20 15:50 UTC (permalink / raw)
To: Joel Stanley
Cc: devicetree, Ryan Chen, linux-watchdog, linux-aspeed,
Andrew Jeffery, Rob Herring, Wim Van Sebroeck, linux-arm-kernel
In-Reply-To: <20190819051738.17370-3-joel@jms.id.au>
On Mon, Aug 19, 2019 at 02:47:38PM +0930, Joel Stanley wrote:
> From: Ryan Chen <ryan_chen@aspeedtech.com>
>
> The ast2600 can be supported by the same code as the ast2500.
>
> Signed-off-by: Ryan Chen <ryan_chen@aspeedtech.com>
> Signed-off-by: Joel Stanley <joel@jms.id.au>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
> ---
> v2:
> Reuse ast2500 config structure
> ---
> drivers/watchdog/aspeed_wdt.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/watchdog/aspeed_wdt.c b/drivers/watchdog/aspeed_wdt.c
> index cc71861e033a..5b64bc2e8788 100644
> --- a/drivers/watchdog/aspeed_wdt.c
> +++ b/drivers/watchdog/aspeed_wdt.c
> @@ -34,6 +34,7 @@ static const struct aspeed_wdt_config ast2500_config = {
> static const struct of_device_id aspeed_wdt_of_table[] = {
> { .compatible = "aspeed,ast2400-wdt", .data = &ast2400_config },
> { .compatible = "aspeed,ast2500-wdt", .data = &ast2500_config },
> + { .compatible = "aspeed,ast2600-wdt", .data = &ast2500_config },
> { },
> };
> MODULE_DEVICE_TABLE(of, aspeed_wdt_of_table);
> @@ -259,7 +260,8 @@ static int aspeed_wdt_probe(struct platform_device *pdev)
> set_bit(WDOG_HW_RUNNING, &wdt->wdd.status);
> }
>
> - if (of_device_is_compatible(np, "aspeed,ast2500-wdt")) {
> + if ((of_device_is_compatible(np, "aspeed,ast2500-wdt")) ||
> + (of_device_is_compatible(np, "aspeed,ast2600-wdt"))) {
> u32 reg = readl(wdt->base + WDT_RESET_WIDTH);
>
> reg &= config->ext_pulse_width_mask;
_______________________________________________
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 v3 2/5] arm64: cpufeature: Add feature to detect heterogeneous systems
From: Mark Rutland @ 2019-08-20 15:49 UTC (permalink / raw)
To: Raphael Gault
Cc: raph.gault+kdev, peterz, catalin.marinas, will.deacon,
linux-kernel, acme, mingo, linux-arm-kernel
In-Reply-To: <20190820152316.GA38082@lakrids.cambridge.arm.com>
On Tue, Aug 20, 2019 at 04:23:17PM +0100, Mark Rutland wrote:
> Hi Raphael,
>
> On Fri, Aug 16, 2019 at 01:59:31PM +0100, Raphael Gault wrote:
> > This feature is required in order to enable PMU counters direct
> > access from userspace only when the system is homogeneous.
> > This feature checks the model of each CPU brought online and compares it
> > to the boot CPU. If it differs then it is heterogeneous.
>
> It would be worth noting that this patch prevents heterogeneous CPUs
> being brought online late if the system was uniform at boot time.
Looking again, I think I'd misunderstood how
ARM64_CPUCAP_OPTIONAL_FOR_LATE_CPU was dealt with, but we do have a
problem in this area.
[...]
>
> > + .capability = ARM64_HAS_HETEROGENEOUS_PMU,
> > + .type = ARM64_CPUCAP_SCOPE_LOCAL_CPU | ARM64_CPUCAP_OPTIONAL_FOR_LATE_CPU,
> > + .matches = has_heterogeneous_pmu,
> > + },
I had a quick chat with Will, and we concluded that we must permit late
onlining of heterogeneous CPUs here as people are likely to rely on
late CPU onlining on some heterogeneous systems.
I think the above permits that, but that also means that we need some
support code to fail gracefully in that case (e.g. without sending
a SIGILL to unaware userspace code).
That means that we'll need the counter emulation code that you had in
previous versions of this patch (e.g. to handle potential UNDEFs when a
new CPU has fewer counters than the previously online CPUs).
Further, I think the context switch (and event index) code needs to take
this cap into account, and disable direct access once the system becomes
heterogeneous.
Thanks,
Mark.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH V2 2/4] watchdog: Add i.MX7ULP watchdog support
From: Guenter Roeck @ 2019-08-20 15:48 UTC (permalink / raw)
To: Anson.Huang
Cc: mark.rutland, devicetree, leonard.crestez, schnitzeltony,
linux-watchdog, otavio, festevam, s.hauer, jan.tuerk, linux,
linux-kernel, robh+dt, Linux-imx, kernel, u.kleine-koenig, wim,
shawnguo, linux-arm-kernel
In-Reply-To: <20190820153155.GA19394@roeck-us.net>
On Tue, Aug 20, 2019 at 08:31:55AM -0700, Guenter Roeck wrote:
> On Mon, Aug 12, 2019 at 04:53:19PM +0800, Anson.Huang@nxp.com wrote:
> > From: Anson Huang <Anson.Huang@nxp.com>
> >
> > The i.MX7ULP Watchdog Timer (WDOG) module is an independent timer
> > that is available for system use.
> > It provides a safety feature to ensure that software is executing
> > as planned and that the CPU is not stuck in an infinite loop or
> > executing unintended code. If the WDOG module is not serviced
> > (refreshed) within a certain period, it resets the MCU.
> >
> > Add driver support for i.MX7ULP watchdog.
> >
> > Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
>
> Reviewed-by: Guenter Roeck <linux@roeck-us.net>
>
Wait, I have to withdraw that.
With clk_prepare_enable(), you'll also need to call clk_disable_unprepare()
on remove. An easy way to do this and keep the code simple would be:
static void imx7ulp_wdt_clk_disable_unprepare(void *data)
{
clk_disable_unprepare(data);
}
static int imx7ulp_wdt_probe(...)
{
...
ret = clk_prepare_enable(imx7ulp_wdt->clk);
if (ret)
return ret;
ret = devm_add_action_or_reset(dev, imx7ulp_wdt_clk_disable_unprepare);
if (ret)
return ret;
...
Thanks,
Guenter
> > ---
> > Changes since V1:
> > - Add clock operation;
> > - Remove unneccsary error message when registering watchdog device failed;
> > - Use BIT() instead of hard code;
> > ---
> > drivers/watchdog/Kconfig | 13 +++
> > drivers/watchdog/Makefile | 1 +
> > drivers/watchdog/imx7ulp_wdt.c | 244 +++++++++++++++++++++++++++++++++++++++++
> > 3 files changed, 258 insertions(+)
> > create mode 100644 drivers/watchdog/imx7ulp_wdt.c
> >
> > diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
> > index 8188963..0884e53 100644
> > --- a/drivers/watchdog/Kconfig
> > +++ b/drivers/watchdog/Kconfig
> > @@ -740,6 +740,19 @@ config IMX_SC_WDT
> > To compile this driver as a module, choose M here: the
> > module will be called imx_sc_wdt.
> >
> > +config IMX7ULP_WDT
> > + tristate "IMX7ULP Watchdog"
> > + depends on ARCH_MXC || COMPILE_TEST
> > + select WATCHDOG_CORE
> > + help
> > + This is the driver for the hardware watchdog on the Freescale
> > + IMX7ULP and later processors. If you have one of these
> > + processors and wish to have watchdog support enabled,
> > + say Y, otherwise say N.
> > +
> > + To compile this driver as a module, choose M here: the
> > + module will be called imx7ulp_wdt.
> > +
> > config UX500_WATCHDOG
> > tristate "ST-Ericsson Ux500 watchdog"
> > depends on MFD_DB8500_PRCMU
> > diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
> > index 7caa920..7d32537 100644
> > --- a/drivers/watchdog/Makefile
> > +++ b/drivers/watchdog/Makefile
> > @@ -69,6 +69,7 @@ obj-$(CONFIG_TS4800_WATCHDOG) += ts4800_wdt.o
> > obj-$(CONFIG_TS72XX_WATCHDOG) += ts72xx_wdt.o
> > obj-$(CONFIG_IMX2_WDT) += imx2_wdt.o
> > obj-$(CONFIG_IMX_SC_WDT) += imx_sc_wdt.o
> > +obj-$(CONFIG_IMX7ULP_WDT) += imx7ulp_wdt.o
> > obj-$(CONFIG_UX500_WATCHDOG) += ux500_wdt.o
> > obj-$(CONFIG_RETU_WATCHDOG) += retu_wdt.o
> > obj-$(CONFIG_BCM2835_WDT) += bcm2835_wdt.o
> > diff --git a/drivers/watchdog/imx7ulp_wdt.c b/drivers/watchdog/imx7ulp_wdt.c
> > new file mode 100644
> > index 0000000..c20fba4
> > --- /dev/null
> > +++ b/drivers/watchdog/imx7ulp_wdt.c
> > @@ -0,0 +1,244 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright 2019 NXP.
> > + */
> > +
> > +#include <linux/clk.h>
> > +#include <linux/init.h>
> > +#include <linux/io.h>
> > +#include <linux/kernel.h>
> > +#include <linux/module.h>
> > +#include <linux/of.h>
> > +#include <linux/platform_device.h>
> > +#include <linux/reboot.h>
> > +#include <linux/watchdog.h>
> > +
> > +#define WDOG_CS 0x0
> > +#define WDOG_CS_CMD32EN BIT(13)
> > +#define WDOG_CS_ULK BIT(11)
> > +#define WDOG_CS_RCS BIT(10)
> > +#define WDOG_CS_EN BIT(7)
> > +#define WDOG_CS_UPDATE BIT(5)
> > +
> > +#define WDOG_CNT 0x4
> > +#define WDOG_TOVAL 0x8
> > +
> > +#define REFRESH_SEQ0 0xA602
> > +#define REFRESH_SEQ1 0xB480
> > +#define REFRESH ((REFRESH_SEQ1 << 16) | REFRESH_SEQ0)
> > +
> > +#define UNLOCK_SEQ0 0xC520
> > +#define UNLOCK_SEQ1 0xD928
> > +#define UNLOCK ((UNLOCK_SEQ1 << 16) | UNLOCK_SEQ0)
> > +
> > +#define DEFAULT_TIMEOUT 60
> > +#define MAX_TIMEOUT 128
> > +
> > +static bool nowayout = WATCHDOG_NOWAYOUT;
> > +module_param(nowayout, bool, 0000);
> > +MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once started (default="
> > + __MODULE_STRING(WATCHDOG_NOWAYOUT) ")");
> > +
> > +struct imx7ulp_wdt_device {
> > + struct notifier_block restart_handler;
> > + struct watchdog_device wdd;
> > + void __iomem *base;
> > + struct clk *clk;
> > + int rate;
> > +};
> > +
> > +static inline void imx7ulp_wdt_enable(void __iomem *base, bool enable)
> > +{
> > + u32 val = readl(base + WDOG_CS);
> > +
> > + writel(UNLOCK, base + WDOG_CNT);
> > + if (enable)
> > + writel(val | WDOG_CS_EN, base + WDOG_CS);
> > + else
> > + writel(val & ~WDOG_CS_EN, base + WDOG_CS);
> > +}
> > +
> > +static inline bool imx7ulp_wdt_is_enabled(void __iomem *base)
> > +{
> > + u32 val = readl(base + WDOG_CS);
> > +
> > + return val & WDOG_CS_EN;
> > +}
> > +
> > +static int imx7ulp_wdt_ping(struct watchdog_device *wdog)
> > +{
> > + struct imx7ulp_wdt_device *wdt = watchdog_get_drvdata(wdog);
> > +
> > + writel(REFRESH, wdt->base + WDOG_CNT);
> > +
> > + return 0;
> > +}
> > +
> > +static int imx7ulp_wdt_start(struct watchdog_device *wdog)
> > +{
> > + struct imx7ulp_wdt_device *wdt = watchdog_get_drvdata(wdog);
> > +
> > + imx7ulp_wdt_enable(wdt->base, true);
> > +
> > + return 0;
> > +}
> > +
> > +static int imx7ulp_wdt_stop(struct watchdog_device *wdog)
> > +{
> > + struct imx7ulp_wdt_device *wdt = watchdog_get_drvdata(wdog);
> > +
> > + imx7ulp_wdt_enable(wdt->base, false);
> > +
> > + return 0;
> > +}
> > +
> > +static int imx7ulp_wdt_set_timeout(struct watchdog_device *wdog,
> > + unsigned int timeout)
> > +{
> > + struct imx7ulp_wdt_device *wdt = watchdog_get_drvdata(wdog);
> > + u32 val = wdt->rate * timeout;
> > +
> > + writel(UNLOCK, wdt->base + WDOG_CNT);
> > + writel(val, wdt->base + WDOG_TOVAL);
> > +
> > + wdog->timeout = timeout;
> > +
> > + return 0;
> > +}
> > +
> > +static const struct watchdog_ops imx7ulp_wdt_ops = {
> > + .owner = THIS_MODULE,
> > + .start = imx7ulp_wdt_start,
> > + .stop = imx7ulp_wdt_stop,
> > + .ping = imx7ulp_wdt_ping,
> > + .set_timeout = imx7ulp_wdt_set_timeout,
> > +};
> > +
> > +static const struct watchdog_info imx7ulp_wdt_info = {
> > + .identity = "i.MX7ULP watchdog timer",
> > + .options = WDIOF_SETTIMEOUT | WDIOF_KEEPALIVEPING |
> > + WDIOF_MAGICCLOSE,
> > +};
> > +
> > +static inline void imx7ulp_wdt_init(void __iomem *base, unsigned int timeout)
> > +{
> > + u32 val;
> > +
> > + /* unlock the wdog for reconfiguration */
> > + writel_relaxed(UNLOCK_SEQ0, base + WDOG_CNT);
> > + writel_relaxed(UNLOCK_SEQ1, base + WDOG_CNT);
> > +
> > + /* set an initial timeout value in TOVAL */
> > + writel(timeout, base + WDOG_TOVAL);
> > + /* enable 32bit command sequence and reconfigure */
> > + val = BIT(13) | BIT(8) | BIT(5);
> > + writel(val, base + WDOG_CS);
> > +}
> > +
> > +static int imx7ulp_wdt_probe(struct platform_device *pdev)
> > +{
> > + struct imx7ulp_wdt_device *imx7ulp_wdt;
> > + struct device *dev = &pdev->dev;
> > + struct watchdog_device *wdog;
> > + int ret;
> > +
> > + imx7ulp_wdt = devm_kzalloc(dev, sizeof(*imx7ulp_wdt), GFP_KERNEL);
> > + if (!imx7ulp_wdt)
> > + return -ENOMEM;
> > +
> > + platform_set_drvdata(pdev, imx7ulp_wdt);
> > +
> > + imx7ulp_wdt->base = devm_platform_ioremap_resource(pdev, 0);
> > + if (IS_ERR(imx7ulp_wdt->base))
> > + return PTR_ERR(imx7ulp_wdt->base);
> > +
> > + imx7ulp_wdt->clk = devm_clk_get(dev, NULL);
> > + if (IS_ERR(imx7ulp_wdt->clk)) {
> > + dev_err(dev, "Failed to get watchdog clock\n");
> > + return PTR_ERR(imx7ulp_wdt->clk);
> > + }
> > +
> > + ret = clk_prepare_enable(imx7ulp_wdt->clk);
> > + if (ret)
> > + return ret;
> > +
> > + imx7ulp_wdt->rate = 1000;
> > + wdog = &imx7ulp_wdt->wdd;
> > + wdog->info = &imx7ulp_wdt_info;
> > + wdog->ops = &imx7ulp_wdt_ops;
> > + wdog->min_timeout = 1;
> > + wdog->max_timeout = MAX_TIMEOUT;
> > + wdog->parent = dev;
> > + wdog->timeout = DEFAULT_TIMEOUT;
> > +
> > + watchdog_init_timeout(wdog, 0, dev);
> > + watchdog_stop_on_reboot(wdog);
> > + watchdog_stop_on_unregister(wdog);
> > + watchdog_set_drvdata(wdog, imx7ulp_wdt);
> > + imx7ulp_wdt_init(imx7ulp_wdt->base, wdog->timeout * imx7ulp_wdt->rate);
> > +
> > + ret = devm_watchdog_register_device(dev, wdog);
> > + if (ret)
> > + goto disable_clk;
> > +
> > + return 0;
> > +
> > +disable_clk:
> > + clk_disable_unprepare(imx7ulp_wdt->clk);
> > +
> > + return ret;
> > +}
> > +
> > +static int __maybe_unused imx7ulp_wdt_suspend(struct device *dev)
> > +{
> > + struct imx7ulp_wdt_device *imx7ulp_wdt = dev_get_drvdata(dev);
> > +
> > + if (watchdog_active(&imx7ulp_wdt->wdd))
> > + imx7ulp_wdt_stop(&imx7ulp_wdt->wdd);
> > +
> > + clk_disable_unprepare(imx7ulp_wdt->clk);
> > +
> > + return 0;
> > +}
> > +
> > +static int __maybe_unused imx7ulp_wdt_resume(struct device *dev)
> > +{
> > + struct imx7ulp_wdt_device *imx7ulp_wdt = dev_get_drvdata(dev);
> > + u32 timeout = imx7ulp_wdt->wdd.timeout * imx7ulp_wdt->rate;
> > + int ret;
> > +
> > + ret = clk_prepare_enable(imx7ulp_wdt->clk);
> > + if (ret)
> > + return ret;
> > +
> > + if (imx7ulp_wdt_is_enabled(imx7ulp_wdt->base))
> > + imx7ulp_wdt_init(imx7ulp_wdt->base, timeout);
> > +
> > + if (watchdog_active(&imx7ulp_wdt->wdd))
> > + imx7ulp_wdt_start(&imx7ulp_wdt->wdd);
> > +
> > + return 0;
> > +}
> > +
> > +static SIMPLE_DEV_PM_OPS(imx7ulp_wdt_pm_ops, imx7ulp_wdt_suspend,
> > + imx7ulp_wdt_resume);
> > +
> > +static const struct of_device_id imx7ulp_wdt_dt_ids[] = {
> > + { .compatible = "fsl,imx7ulp-wdt", },
> > + { /* sentinel */ }
> > +};
> > +MODULE_DEVICE_TABLE(of, imx7ulp_wdt_dt_ids);
> > +
> > +static struct platform_driver imx7ulp_wdt_driver = {
> > + .probe = imx7ulp_wdt_probe,
> > + .driver = {
> > + .name = "imx7ulp-wdt",
> > + .pm = &imx7ulp_wdt_pm_ops,
> > + .of_match_table = imx7ulp_wdt_dt_ids,
> > + },
> > +};
> > +module_platform_driver(imx7ulp_wdt_driver);
> > +
> > +MODULE_AUTHOR("Anson Huang <Anson.Huang@nxp.com>");
> > +MODULE_DESCRIPTION("Freescale i.MX7ULP watchdog driver");
> > +MODULE_LICENSE("GPL v2");
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/3] serial: atmel: Don't check for mctrl_gpio_to_gpiod() returning error
From: Richard Genoud @ 2019-08-20 15:47 UTC (permalink / raw)
To: Uwe Kleine-König, Geert Uytterhoeven
Cc: Alexandre Belloni, Pengutronix Kernel Team, Geert Uytterhoeven,
open list:SERIAL DRIVERS, Richard Genoud, Greg Kroah-Hartman,
Sascha Hauer, Frieder Schrempf, Linux-Renesas, Ludovic Desroches,
NXP Linux Team, Fabio Estevam, Jiri Slaby, Shawn Guo, Linux ARM
In-Reply-To: <20190814110804.2ceo2upc3su7muup@pengutronix.de>
Le 14/08/2019 à 13:08, Uwe Kleine-König a écrit :
> On Wed, Aug 14, 2019 at 12:20:33PM +0200, Geert Uytterhoeven wrote:
>> Hi Uwe,
>>
>> On Wed, Aug 14, 2019 at 11:36 AM Uwe Kleine-König
>> <u.kleine-koenig@pengutronix.de> wrote:
>>> On Wed, Aug 14, 2019 at 11:29:22AM +0200, Geert Uytterhoeven wrote:
>>>> Since commit 1d267ea6539f2663 ("serial: mctrl-gpio: simplify init
>>>> routine"), mctrl_gpio_init() returns failure if the assignment to any
>>>> member of the gpio array results in an error pointer.
>>>> Since commit c359522194593815 ("serial: mctrl_gpio: Avoid probe failures
>>>> in case of missing gpiolib"), mctrl_gpio_to_gpiod() returns NULL in the
>>>> !CONFIG_GPIOLIB case.
>>>> Hence there is no longer a need to check for mctrl_gpio_to_gpiod()
>>>> returning an error value. A simple NULL check is sufficient.
>>>>
>>>> This follows the spirit of commit 445df7ff3fd1a0a9 ("serial: mctrl-gpio:
>>>> drop usages of IS_ERR_OR_NULL") in the mctrl-gpio core.
>>>>
>>>> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
>>>> ---
>>>> drivers/tty/serial/atmel_serial.c | 12 ++++--------
>>>> 1 file changed, 4 insertions(+), 8 deletions(-)
>>>>
>>>> diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
>>>> index 19a85d6fe3d20541..e9620a81166b7dc1 100644
>>>> --- a/drivers/tty/serial/atmel_serial.c
>>>> +++ b/drivers/tty/serial/atmel_serial.c
>>>> @@ -303,32 +303,28 @@ static unsigned int atmel_get_lines_status(struct uart_port *port)
>>>>
>>>> mctrl_gpio_get(atmel_port->gpios, &ret);
>>>>
>>>> - if (!IS_ERR_OR_NULL(mctrl_gpio_to_gpiod(atmel_port->gpios,
>>>> - UART_GPIO_CTS))) {
>>>> + if (mctrl_gpio_to_gpiod(atmel_port->gpios, UART_GPIO_CTS)) {
>>>> if (ret & TIOCM_CTS)
>>>> status &= ~ATMEL_US_CTS;
>>>> else
>>>> status |= ATMEL_US_CTS;
>>>> }
>>>
>>> The change is fine, but it seems the atmel driver doesn't use mctrl_gpio
>>> as expected (at least as expected by me). IMHO driving the hardware
>>> function of the CTS pin shouldn't be conditional on the presence of a
>>> cts-gpio. Is there a reason not to just drop the if completely?
>>
>> The above code returns the hardware status if CTS is not a GPIO, and
>> returns (overrides with) the GPIO status if CTS is a GPIO.
>> Isn't that correct, or am I missing something?
>
> I took a deeper look into this driver now. The task for
> atmel_get_lines_status() isn't to implement the get_mctrl() callback.
>
> Instead this is called in the irqhandler to set ATMEL_US_RI in a
> "pending" value that then later in atmel_handle_status() is translated
> to a "ring" event that is handled there.
>
> So the right cleanup would be to let atmel_get_lines_status() just be
>
> return atmel_uart_readl(port, ATMEL_US_CSR);
>
> . If something happend on the lines implemented as gpio the driver's irq
> function isn't called anyhow.
I'd like to give it a good test to be sure, and I'll get back to you.
Thanks,
Richard
_______________________________________________
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