* [PATCH 1/1] dt-bindings: arm: document supported STM32 SoC family
From: Ludovic BARRE @ 2017-12-13 8:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171212231744.u4wtadrpaq3wp4sq@rob-hp-laptop>
hi Rob
Today there was no bindings documentation for STM32 SoC
already upstreamed. This patch adds initial list of STM32
existing in kernel.
The next serie adds just new soc and one compatible on STM32 list.
So, I think you could apply this patch.
BR
Ludo
On 12/13/2017 12:17 AM, Rob Herring wrote:
> On Tue, Dec 12, 2017 at 03:03:48PM -0600, Rob Herring wrote:
>> On Fri, Dec 08, 2017 at 02:56:34PM +0100, Ludovic Barre wrote:
>>> From: Ludovic Barre <ludovic.barre@st.com>
>>>
>>> This adds a list of supported STM32 SoC bindings.
>>>
>>> Signed-off-by: Gwenael Treuveur <gwenael.treuveur@st.com>
>>> Signed-off-by: Ludovic Barre <ludovic.barre@st.com>
>>> ---
>>> Documentation/devicetree/bindings/arm/stm32.txt | 9 +++++++++
>>> 1 file changed, 9 insertions(+)
>>> create mode 100644 Documentation/devicetree/bindings/arm/stm32.txt
>>
>> Applied, thanks.
>
> Now dropped as this will conflict with your other series. Send this with
> the other series or indicate who should apply.
>
> Reviewed-by: Rob Herring <robh@kernel.org>
>
> Rob
>
^ permalink raw reply
* Lithium battery protection was Re: [PATCH v4.14] Add support for bq27521 battery monitor
From: Pavel Machek @ 2017-12-13 8:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171208170610.gbmlsgm7xzh2zpyn@earth>
Hi!
> > >> This adds basic support for BQ27521 battery monitor, used in Nokia N9
> > >> and N950. In particular, battery voltage is important to be able to
> > >> tell when the battery is almost empty. Emptying battery on N950 is
> > >> pretty painful, as flasher needs to be used to recover phone in such
> > >> case.
> > >
> > > Sebastian, ping? This one should not be too controversial.
> >
> > Acked-by: Andrew F. Davis <afd@ti.com>
>
> Thanks, queued, I dropped the spurious change in twl.h and added the
> dt-binding from the previous patch version, that was lost somehow.
Thanks!
> > > If you could also apply the "shut down when battery is low", that
> > > would be nice.
>
> I only have one with values specific to N900 hardcoded in the
> driver. That one can't be applied for obvious reasons.
Well... the values are not really N900-specific. They should work well
on anything with lithium battery, because they basically depend only
on battery chemistry.
I guess I can simplify patch to work with battery voltage only --
that's what hardware battery protection does -- and make shutdown
voltage configurable ...?
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171213/5571e850/attachment.sig>
^ permalink raw reply
* [PATCH v2 3/4] thermal: armada: add support for CP110
From: Baruch Siach @ 2017-12-13 8:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87y3m9qjt2.fsf@free-electrons.com>
Hi Gregory,
On Mon, Dec 11, 2017 at 06:02:49PM +0100, Gregory CLEMENT wrote:
> On lun., d?c. 11 2017, Baruch Siach <baruch@tkos.co.il> wrote:
> > On Mon, Dec 11, 2017 at 04:09:32PM +0100, Miquel RAYNAL wrote:
> >> On Sun, 3 Dec 2017 13:11:23 +0200
> >> Baruch Siach <baruch@tkos.co.il> wrote:
> >>
> >> > The CP110 component is integrated in the Armada 8k and 7k lines of
> >> > processors.
> >> >
> >> > This patch also adds an option of offset to the MSB of the control
> >> > register. The existing DT binding for Armada 38x refers to a single
> >> > 32 bit control register. It turns out that this is actually only the
> >> > MSB of the control area. Changing the binding to fix that would break
> >> > existing DT files, so the Armada 38x binding is left as is.
> >> >
> >> > The new CP110 binding increases the size of the control area to 64
> >> > bits, thus moving the MSB to offset 4.
> >> >
> >> > Signed-off-by: Baruch Siach <baruch@tkos.co.il>
> >> > ---
> >> > v2: No change
> >> > ---
> >> > drivers/thermal/armada_thermal.c | 24 ++++++++++++++++++++++--
> >> > 1 file changed, 22 insertions(+), 2 deletions(-)
> >> >
> >> > diff --git a/drivers/thermal/armada_thermal.c
> >> > b/drivers/thermal/armada_thermal.c index 0eb82097571f..59b75f63945d
> >> > 100644 --- a/drivers/thermal/armada_thermal.c
> >> > +++ b/drivers/thermal/armada_thermal.c
> >> > @@ -73,6 +73,7 @@ struct armada_thermal_data {
> >> > unsigned int temp_shift;
> >> > unsigned int temp_mask;
> >> > unsigned int is_valid_shift;
> >> > + unsigned int control_msb_offset;
> >> > };
> >> >
> >> > static void armadaxp_init_sensor(struct platform_device *pdev,
> >> > @@ -142,12 +143,14 @@ static void armada375_init_sensor(struct
> >> > platform_device *pdev, static void armada380_init_sensor(struct
> >> > platform_device *pdev, struct armada_thermal_priv *priv)
> >> > {
> >> > - unsigned long reg = readl_relaxed(priv->control);
> >> > + void __iomem *control_msb =
> >> > + priv->control + priv->data->control_msb_offset;
> >> > + unsigned long reg = readl_relaxed(control_msb);
> >> >
> >> > /* Reset hardware once */
> >> > if (!(reg & A380_HW_RESET)) {
> >> > reg |= A380_HW_RESET;
> >> > - writel(reg, priv->control);
> >> > + writel(reg, control_msb);
> >> > mdelay(10);
> >> > }
> >> > }
> >> > @@ -266,6 +269,19 @@ static const struct armada_thermal_data
> >> > armada_ap806_data = { .signed_sample = true,
> >> > };
> >> >
> >> > +static const struct armada_thermal_data armada_cp110_data = {
> >> > + .is_valid = armada_is_valid,
> >> > + .init_sensor = armada380_init_sensor,
> >>
> >> I see the initialization for CP110 thermal IP is close to
> >> Armada-380's, but, as you point it in the commit log it is still
> >> different.
> >>
> >> I don't know what is the best way to handle this but until now each
> >> new compatible had his own ->init_sensor function, shouldn't we do
> >> the same here as changes are requested? This would naturally avoid the
> >> situation with Armada-380 bindings.
> >
> > I'm not sure I understand your suggestion.
> >
> > There is no difference between the CP110 and the Armada 38x, as far as I can
> > see. The only quirk is that the existing Armada 38x DT binding is wrong I that
> > the 'reg' property references the control MSB, while leaving the LSB
> > out. We
>
> Well I would not say it was wrong but more incomplete :)
>
> > can't change the Armada 38x binding without breaking existing DTs. The
> > 'control_msb_offset' field that this patch adds allows correct binding for
> > CP110, while keeping compatibility with the existing Armada 38x
> > binding.
>
> I am not against adding a new compatible string for CP110 but ot be
> honest the new binding for CP110 does not bring anything as you don't
> use at all the LSB register.
We don't use the LSB yet in mainline driver. But the vendor kernel uses it to
"change temperature band gap circuit curve" (quoting vendor kernel commit
4ff2d8a7d3 log). Chances are that we want to do this as well. But said commit
changed the DT binding in an incompatible way. We can't do that, and we both
agree on that.
> Actually, if on Armada 375 we initially mapped the LSB register it was
> to support an very early release of the SoC (stepping Z) and only for
> resetting its value. So I guess you started to write the AP860 part
> based on the Armada 375 and then found that we could map a more complete
> range of the registers.
>
> > How would a separate init_sensor routine improve things?
>
> So yes please do it, thanks to this you won't have to add the
> control_msb_offset member and can use a clean function. Moreover if in
> the future we see some usefulness for this LSB register then we could use
> the new compatible for the Armada 38x.
There are two separate issues here:
1. DT binding
2. init_sensor callback implementation
We both agree on #1. The A38x and CP110 need separate compatible strings. In
case we want to access the LSB control register on Armada 38x, we will need
yet another compatible string (marvell,armada380-v2-thermal maybe?).
As for #2, I'm all for sharing as much code as possible. I find the vendor
kernel approach of duplicating the init routines[1] unhelpful as it violates
the DRY principle. The differences between armada380_init_sensor() and
cp110_init_sensor() are minor. In my opinion, these differences should be
expressed explicitly in the armada_thermal_data, in a similar way to my
suggested control_msb_offset field. The vendor code hides these differences in
slight variations of duplicated code.
What is the advantage of a separate init routine?
baruch
[1] https://github.com/MarvellEmbeddedProcessors/linux-marvell/blob/linux-4.4.52-armada-17.10/drivers/thermal/armada_thermal.c
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
^ permalink raw reply
* [PATCH 2/3] ARM: dts: r8a7743: Add CMT SoC specific support
From: Simon Horman @ 2017-12-13 8:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513104579-6333-3-git-send-email-fabrizio.castro@bp.renesas.com>
On Tue, Dec 12, 2017 at 06:49:38PM +0000, Fabrizio Castro wrote:
> Add CMT[01] support to SoC DT.
>
> Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> Reviewed-by: Biju Das <biju.das@bp.renesas.com>
> ---
> arch/arm/boot/dts/r8a7743.dtsi | 30 ++++++++++++++++++++++++++++++
> 1 file changed, 30 insertions(+)
I was expecting the cmt nodes to be "disabled" in the SoC file
and then enabled selectively in board files. Am I missing something?
Otherwise this patch looks good to me.
> diff --git a/arch/arm/boot/dts/r8a7743.dtsi b/arch/arm/boot/dts/r8a7743.dtsi
> index 59860c8..0e2834a 100644
> --- a/arch/arm/boot/dts/r8a7743.dtsi
> +++ b/arch/arm/boot/dts/r8a7743.dtsi
> @@ -262,6 +262,36 @@
> IRQ_TYPE_LEVEL_LOW)>;
> };
>
> + cmt0: timer at ffca0000 {
> + compatible = "renesas,r8a7743-cmt0",
> + "renesas,rcar-gen2-cmt0";
> + reg = <0 0xffca0000 0 0x1004>;
> + interrupts = <GIC_SPI 142 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 143 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&cpg CPG_MOD 124>;
> + clock-names = "fck";
> + power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
> + resets = <&cpg 124>;
> + };
> +
> + cmt1: timer at e6130000 {
> + compatible = "renesas,r8a7743-cmt1",
> + "renesas,rcar-gen2-cmt1";
> + reg = <0 0xe6130000 0 0x1004>;
> + interrupts = <GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 124 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 125 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 126 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 127 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&cpg CPG_MOD 329>;
> + clock-names = "fck";
> + power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
> + resets = <&cpg 329>;
> + };
> +
> cpg: clock-controller at e6150000 {
> compatible = "renesas,r8a7743-cpg-mssr";
> reg = <0 0xe6150000 0 0x1000>;
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH 2/3] arm64: dts: renesas: r8a7796: move nodes which have no reg property out of bus
From: Geert Uytterhoeven @ 2017-12-13 8:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171213082531.ubbp2za2zupqfqk3@verge.net.au>
Hi Simon,
On Wed, Dec 13, 2017 at 9:25 AM, Simon Horman <horms@verge.net.au> wrote:
> For now I've applied the following:
>
> From: Simon Horman <horms+renesas@verge.net.au>
> Date: Tue, 12 Dec 2017 09:24:35 +0100
> Subject: [PATCH] arm64: dts: renesas: r8a7796: move nodes which have no reg
> property out of bus
>
> Move pmu_a5[73], timer and thermal-zones nodes from soc node to root node.
> The nodes that have been moved do not have any register properties and thus
> shouldn't be placed on the bus.
> index c1b0d0344329..e82b4db1ad1a 100644
> --- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
> @@ -154,6 +154,23 @@
> clock-frequency = <0>;
> };
>
> + pmu_a57 {
> + compatible = "arm,cortex-a57-pmu";
> + interrupts-extended = <&gic GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>,
> + <&gic GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-affinity = <&a57_0>,
> + <&a57_1>;
Merge?
> + };
> +
> + pmu_a53 {
> + compatible = "arm,cortex-a53-pmu";
> + interrupts-extended = <&gic GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>,
> + <&gic GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH>,
> + <&gic GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>,
> + <&gic GIC_SPI 87 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-affinity = <&a53_0>, <&a53_1>, <&a53_2>, <&a53_3>;
Thanks!
> + };
> @@ -2027,4 +1968,56 @@
> resets = <&cpg 822>;
> };
> };
> +
> + timer {
> + compatible = "arm,armv8-timer";
> + interrupts-extended = <&gic GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_LOW)>,
> + <&gic GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_LOW)>,
> + <&gic GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_LOW)>,
> + <&gic GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_LOW)>;
Much better!
Or even
> + interrupts-extended =
> + <&gic GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_LOW)>,
> + <&gic GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_LOW)>,
> + <&gic GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_LOW)>,
> + <&gic GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_LOW)>;
I don't care that much, it extends beyond 80 characters anyway.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [Patch v6 10/12] [media] v4l2: Add v4l2 control IDs for HEVC encoder
From: Smitha T Murthy @ 2017-12-13 8:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <10a80dd4-737d-2c96-1679-3b04cfc45a5d@samsung.com>
On Tue, 2017-12-12 at 10:46 +0100, Sylwester Nawrocki wrote:
> On 12/12/2017 03:34 AM, Smitha T Murthy wrote:
> >> s/Lay/Layer here and below
> >>
> > Ok I will change it.
>
> While it's fine to make such change for controls up to V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L6_QP...
>
> >>> + case V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L1_QP: return "HEVC Hierarchical Lay 1 QP";
> >>> + case V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L2_QP: return "HEVC Hierarchical Lay 2 QP";
> >>> + case V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L3_QP: return "HEVC Hierarchical Lay 3 QP";
> >>> + case V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L4_QP: return "HEVC Hierarchical Lay 4 QP";
> >>> + case V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L5_QP: return "HEVC Hierarchical Lay 5 QP";
> >>> + case V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L6_QP: return "HEVC Hierarchical Lay 6 QP";
>
> ...for the controls below we may need to replace "Lay" with "L."
> to make sure the length of the string don't exceed 31 characters
> (32 with terminating NULL). The names below seem to be 1 character
> too long and will be truncated when running VIDIOC_QUERY_CTRL ioctl.
>
Yes true, also to keep the uniformity I will change for all
V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L1_QP and
V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L0_BR "Lay" with "L".
> >>> + case V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L0_BR: return "HEVC Hierarchical Lay 0 Bit Rate";
> >>> + case V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L1_BR: return "HEVC Hierarchical Lay 1 Bit Rate";
> >>> + case V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L2_BR: return "HEVC Hierarchical Lay 2 Bit Rate";
> >>> + case V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L3_BR: return "HEVC Hierarchical Lay 3 Bit Rate";
> >>> + case V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L4_BR: return "HEVC Hierarchical Lay 4 Bit Rate";
> >>> + case V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L5_BR: return "HEVC Hierarchical Lay 5 Bit Rate";
> >>> + case V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L6_BR: return "HEVC Hierarchical Lay 6 Bit Rate";
>
> --
> Regards,
> Sylwester
>
Thank you for the review.
Regards,
Smitha
^ permalink raw reply
* [PATCH v5 0/4] ARM: ep93xx: ts72xx: Add support for BK3 board
From: Alexander Sverdlin @ 2017-12-13 8:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdbCeBCENDcRcYBKTXVNz6H3t=WKHYP8Uf3WJ=Wvtib1Jg@mail.gmail.com>
Hello Linus!
On Wed Dec 13 08:34:22 2017 Linus Walleij <linus.walleij@linaro.org> wrote:
> On Tue, Dec 12, 2017 at 12:36 AM, Lukasz Majewski <lukma@denx.de> wrote:
> Out of curiosity: Liebherr is obviously doing heavy-duty industrial
> control systems. Likewise Hartley is doing similar business over
> at Vision Engravings.
>
> Is the situation such that there is a whole bunch of industrial
> systems out there, in active use and needing future upgrades,
> that use the EP93xx?
That's definitely the case. I'm as well aware of several thousands of industrial devices which are expected to run 24/7 for the next 5 years at least. And they are updated from time to time.
> Arnd has been nudging me to do DT conversion for EP93xx
> so if there are many active industrial users of these
> I should prioritize it, because these things have 20+ years
> support cycles.
I'm not sure how important or necessary at all is to change anything in these legacy platforms.
> We also need to think about upholding support in GCC for
> ARMv4(t) for the foreseeable future if there is a big web of
> random deeply embedded systems out there that will need
> updates.
But we should definitely preserve at least what we have.
--
Alexander.
^ permalink raw reply
* [PATCH 3/3] arm64: dts: renesas: r8a7796: add reg properties to pciec[01] nodes
From: Simon Horman @ 2017-12-13 8:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdW6hPCT0J0PHvXkJos51=0QjWijebWZZ5C_cgKzNS5=6Q@mail.gmail.com>
On Tue, Dec 12, 2017 at 10:50:33AM +0100, Geert Uytterhoeven wrote:
> On Tue, Dec 12, 2017 at 9:24 AM, Simon Horman
> <horms+renesas@verge.net.au> wrote:
> > Add reg properties to pciec[01] placeholder nodes
> >
> > This is to stop the compiler complaining as follows:
> > $ make
> > ...
> > DTC arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dtb
> > arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dtb: Warning (unit_address_vs_reg): Node /soc/pcie at fe000000 has a unit name, but no reg property
> > arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dtb: Warning (unit_address_vs_reg): Node /soc/pcie at ee800000 has a unit name, but no reg property
> > arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dtb: Warning (simple_bus_reg): Node /soc/pcie at fe000000 missing or empty reg/ranges property
> > arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dtb: Warning (simple_bus_reg): Node /soc/pcie at ee800000 missing or empty reg/ranges property
> > DTC arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dtb
> > arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dtb: Warning (unit_address_vs_reg): Node /soc/pcie at fe000000 has a unit name, but no reg property
> > arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dtb: Warning (unit_address_vs_reg): Node /soc/pcie at ee800000 has a unit name, but no reg property
> > arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dtb: Warning (simple_bus_reg): Node /soc/pcie at fe000000 missing or empty reg/ranges property
> > arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dtb: Warning (simple_bus_reg): Node /soc/pcie at ee800000 missing or empty reg/ranges property
> > DTC arch/arm64/boot/dts/renesas/r8a7796-m3ulcb-kf.dtb
> > arch/arm64/boot/dts/renesas/r8a7796-m3ulcb-kf.dtb: Warning (unit_address_vs_reg): Node /soc/pcie at fe000000 has a unit name, but no reg property
> > arch/arm64/boot/dts/renesas/r8a7796-m3ulcb-kf.dtb: Warning (unit_address_vs_reg): Node /soc/pcie at ee800000 has a unit name, but no reg property
> > arch/arm64/boot/dts/renesas/r8a7796-m3ulcb-kf.dtb: Warning (simple_bus_reg): Node /soc/pcie at fe000000 missing or empty reg/ranges property
> > arch/arm64/boot/dts/renesas/r8a7796-m3ulcb-kf.dtb: Warning (simple_bus_reg): Node /soc/pcie at ee800000 missing or empty reg/ranges property
> > DTC arch/arm64/boot/dts/renesas/r8a7796-salvator-xs.dtb
> > arch/arm64/boot/dts/renesas/r8a7796-salvator-xs.dtb: Warning (unit_address_vs_reg): Node /soc/pcie at fe000000 has a unit name, but no reg property
> > arch/arm64/boot/dts/renesas/r8a7796-salvator-xs.dtb: Warning (unit_address_vs_reg): Node /soc/pcie at ee800000 has a unit name, but no reg property
> > arch/arm64/boot/dts/renesas/r8a7796-salvator-xs.dtb: Warning (simple_bus_reg): Node /soc/pcie at fe000000 missing or empty reg/ranges property
> > arch/arm64/boot/dts/renesas/r8a7796-salvator-xs.dtb: Warning (simple_bus_reg): Node /soc/pcie at ee800000 missing or empty reg/ranges property
> >
> > Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Thanks, applied.
^ permalink raw reply
* [PATCH 2/3] arm64: dts: renesas: r8a7796: move nodes which have no reg property out of bus
From: Simon Horman @ 2017-12-13 8:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdVx-cEHwV+mBcZfM903DrkxjyNqOiT6KQvm5fNUpcW2Ww@mail.gmail.com>
On Tue, Dec 12, 2017 at 10:44:53AM +0100, Geert Uytterhoeven wrote:
> Hi Simon,
>
> On Tue, Dec 12, 2017 at 9:24 AM, Simon Horman
> <horms+renesas@verge.net.au> wrote:
> > Move pmu_a5[73], timer and thermal-zones nodes from soc node to root node.
> > The nodes that have been moved do not have any register properties and thus
> > shouldn't be placed on the bus.
>
> [...]
>
> > Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> but a few minor comments below...
>
> > --- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
> > +++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
> > @@ -154,6 +154,26 @@
> > clock-frequency = <0>;
> > };
> >
> > + pmu_a57 {
> > + compatible = "arm,cortex-a57-pmu";
> > + interrupts-extended = <&gic GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>,
> > + <&gic GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>;
> > + interrupt-affinity = <&a57_0>,
> > + <&a57_1>;
> > + };
> > +
> > + pmu_a53 {
> > + compatible = "arm,cortex-a53-pmu";
> > + interrupts-extended = <&gic GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>,
> > + <&gic GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH>,
> > + <&gic GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>,
> > + <&gic GIC_SPI 87 IRQ_TYPE_LEVEL_HIGH>;
> > + interrupt-affinity = <&a53_0>,
> > + <&a53_1>,
> > + <&a53_2>,
> > + <&a53_3>;
>
> Merge these 4 into a single line?
>
> > @@ -2027,4 +1971,64 @@
> > resets = <&cpg 822>;
> > };
> > };
> > +
> > + timer {
> > + compatible = "arm,armv8-timer";
> > + interrupts-extended = <&gic GIC_PPI 13
> > + (GIC_CPU_MASK_SIMPLE(6) |
> > + IRQ_TYPE_LEVEL_LOW)>,
> > + <&gic GIC_PPI 14
> > + (GIC_CPU_MASK_SIMPLE(6) |
> > + IRQ_TYPE_LEVEL_LOW)>,
> > + <&gic GIC_PPI 11
> > + (GIC_CPU_MASK_SIMPLE(6) |
> > + IRQ_TYPE_LEVEL_LOW)>,
> > + <&gic GIC_PPI 10
> > + (GIC_CPU_MASK_SIMPLE(6) |
> > + IRQ_TYPE_LEVEL_LOW)>;
>
> I think you can do a better job here, by trying not to break entries across
> multiple lines ;-)
>
> (Oops, we already have it this way in r8a7795.dtsi)
That can be fixed.
For now I've applied the following:
From: Simon Horman <horms+renesas@verge.net.au>
Date: Tue, 12 Dec 2017 09:24:35 +0100
Subject: [PATCH] arm64: dts: renesas: r8a7796: move nodes which have no reg
property out of bus
Move pmu_a5[73], timer and thermal-zones nodes from soc node to root node.
The nodes that have been moved do not have any register properties and thus
shouldn't be placed on the bus.
This problem is flagged by the compiler as follows:
$ make
...
DTC arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dtb
...
arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dtb: Warning (simple_bus_reg): Node /soc/timer missing or empty reg/ranges property
arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dtb: Warning (simple_bus_reg): Node /soc/pmu_a57 missing or empty reg/ranges property
arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dtb: Warning (simple_bus_reg): Node /soc/pmu_a53 missing or empty reg/ranges property
arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dtb: Warning (simple_bus_reg): Node /soc/thermal-zones missing or empty reg/ranges property
...
DTC arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dtb
...
arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dtb: Warning (simple_bus_reg): Node /soc/timer missing or empty reg/ranges property
arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dtb: Warning (simple_bus_reg): Node /soc/pmu_a57 missing or empty reg/ranges property
arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dtb: Warning (simple_bus_reg): Node /soc/pmu_a53 missing or empty reg/ranges property
arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dtb: Warning (simple_bus_reg): Node /soc/thermal-zones missing or empty reg/ranges property
...
DTC arch/arm64/boot/dts/renesas/r8a7796-m3ulcb-kf.dtb
...
arch/arm64/boot/dts/renesas/r8a7796-m3ulcb-kf.dtb: Warning (simple_bus_reg): Node /soc/timer missing or empty reg/ranges property
arch/arm64/boot/dts/renesas/r8a7796-m3ulcb-kf.dtb: Warning (simple_bus_reg): Node /soc/pmu_a57 missing or empty reg/ranges property
arch/arm64/boot/dts/renesas/r8a7796-m3ulcb-kf.dtb: Warning (simple_bus_reg): Node /soc/pmu_a53 missing or empty reg/ranges property
arch/arm64/boot/dts/renesas/r8a7796-m3ulcb-kf.dtb: Warning (simple_bus_reg): Node /soc/thermal-zones missing or empty reg/ranges property
...
DTC arch/arm64/boot/dts/renesas/r8a7796-salvator-xs.dtb
...
arch/arm64/boot/dts/renesas/r8a7796-salvator-xs.dtb: Warning (simple_bus_reg): Node /soc/timer missing or empty reg/ranges property
arch/arm64/boot/dts/renesas/r8a7796-salvator-xs.dtb: Warning (simple_bus_reg): Node /soc/pmu_a57 missing or empty reg/ranges property
arch/arm64/boot/dts/renesas/r8a7796-salvator-xs.dtb: Warning (simple_bus_reg): Node /soc/pmu_a53 missing or empty reg/ranges property
arch/arm64/boot/dts/renesas/r8a7796-salvator-xs.dtb: Warning (simple_bus_reg): Node /soc/thermal-zones missing or empty reg/ranges property
...
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm64/boot/dts/renesas/r8a7796.dtsi | 145 +++++++++++++++----------------
1 file changed, 69 insertions(+), 76 deletions(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
index c1b0d0344329..e82b4db1ad1a 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
@@ -154,6 +154,23 @@
clock-frequency = <0>;
};
+ pmu_a57 {
+ compatible = "arm,cortex-a57-pmu";
+ interrupts-extended = <&gic GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>,
+ <&gic GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-affinity = <&a57_0>,
+ <&a57_1>;
+ };
+
+ pmu_a53 {
+ compatible = "arm,cortex-a53-pmu";
+ interrupts-extended = <&gic GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>,
+ <&gic GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH>,
+ <&gic GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>,
+ <&gic GIC_SPI 87 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-affinity = <&a53_0>, <&a53_1>, <&a53_2>, <&a53_3>;
+ };
+
psci {
compatible = "arm,psci-1.0", "arm,psci-0.2";
method = "smc";
@@ -190,18 +207,6 @@
resets = <&cpg 408>;
};
- timer {
- compatible = "arm,armv8-timer";
- interrupts = <GIC_PPI 13
- (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_LOW)>,
- <GIC_PPI 14
- (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_LOW)>,
- <GIC_PPI 11
- (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_LOW)>,
- <GIC_PPI 10
- (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_LOW)>;
- };
-
wdt0: watchdog at e6020000 {
compatible = "renesas,r8a7796-wdt",
"renesas,rcar-gen3-wdt";
@@ -337,26 +342,6 @@
reg = <0 0xe6060000 0 0x50c>;
};
- pmu_a57 {
- compatible = "arm,cortex-a57-pmu";
- interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-affinity = <&a57_0>,
- <&a57_1>;
- };
-
- pmu_a53 {
- compatible = "arm,cortex-a53-pmu";
- interrupts = <GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 87 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-affinity = <&a53_0>,
- <&a53_1>,
- <&a53_2>,
- <&a53_3>;
- };
-
ipmmu_vi0: mmu at febd0000 {
compatible = "renesas,ipmmu-r8a7796";
reg = <0 0xfebd0000 0 0x1000>;
@@ -1577,50 +1562,6 @@
status = "okay";
};
- thermal-zones {
- sensor_thermal1: sensor-thermal1 {
- polling-delay-passive = <250>;
- polling-delay = <1000>;
- thermal-sensors = <&tsc 0>;
-
- trips {
- sensor1_crit: sensor1-crit {
- temperature = <120000>;
- hysteresis = <2000>;
- type = "critical";
- };
- };
- };
-
- sensor_thermal2: sensor-thermal2 {
- polling-delay-passive = <250>;
- polling-delay = <1000>;
- thermal-sensors = <&tsc 1>;
-
- trips {
- sensor2_crit: sensor2-crit {
- temperature = <120000>;
- hysteresis = <2000>;
- type = "critical";
- };
- };
- };
-
- sensor_thermal3: sensor-thermal3 {
- polling-delay-passive = <250>;
- polling-delay = <1000>;
- thermal-sensors = <&tsc 2>;
-
- trips {
- sensor3_crit: sensor3-crit {
- temperature = <120000>;
- hysteresis = <2000>;
- type = "critical";
- };
- };
- };
- };
-
rcar_sound: sound at ec500000 {
/*
* #sound-dai-cells is required
@@ -2027,4 +1968,56 @@
resets = <&cpg 822>;
};
};
+
+ timer {
+ compatible = "arm,armv8-timer";
+ interrupts-extended = <&gic GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_LOW)>,
+ <&gic GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_LOW)>,
+ <&gic GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_LOW)>,
+ <&gic GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(6) | IRQ_TYPE_LEVEL_LOW)>;
+ };
+
+ thermal-zones {
+ sensor_thermal1: sensor-thermal1 {
+ polling-delay-passive = <250>;
+ polling-delay = <1000>;
+ thermal-sensors = <&tsc 0>;
+
+ trips {
+ sensor1_crit: sensor1-crit {
+ temperature = <120000>;
+ hysteresis = <2000>;
+ type = "critical";
+ };
+ };
+ };
+
+ sensor_thermal2: sensor-thermal2 {
+ polling-delay-passive = <250>;
+ polling-delay = <1000>;
+ thermal-sensors = <&tsc 1>;
+
+ trips {
+ sensor2_crit: sensor2-crit {
+ temperature = <120000>;
+ hysteresis = <2000>;
+ type = "critical";
+ };
+ };
+ };
+
+ sensor_thermal3: sensor-thermal3 {
+ polling-delay-passive = <250>;
+ polling-delay = <1000>;
+ thermal-sensors = <&tsc 2>;
+
+ trips {
+ sensor3_crit: sensor3-crit {
+ temperature = <120000>;
+ hysteresis = <2000>;
+ type = "critical";
+ };
+ };
+ };
+ };
};
--
2.11.0
^ permalink raw reply related
* [PATCH 1/3] arm64: dts: renesas: r8a7796: sort subnodes of root node alphabetically
From: Simon Horman @ 2017-12-13 8:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdW8OJ91FrbUV98iSNd6S3GcLg0b4qRjn2vhtjs7amg++g@mail.gmail.com>
On Tue, Dec 12, 2017 at 10:30:34AM +0100, Geert Uytterhoeven wrote:
> On Tue, Dec 12, 2017 at 9:24 AM, Simon Horman
> <horms+renesas@verge.net.au> wrote:
> > Sort root sub-nodes alphabetically for allow for easier maintenance
> > of this file.
> >
> > Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Thanks, applied.
^ permalink raw reply
* [PATCH 1/3] arm64: dts: renesas: r8a7796: sort subnodes of root node alphabetically
From: Simon Horman @ 2017-12-13 8:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdW8OJ91FrbUV98iSNd6S3GcLg0b4qRjn2vhtjs7amg++g@mail.gmail.com>
On Tue, Dec 12, 2017 at 10:30:34AM +0100, Geert Uytterhoeven wrote:
> On Tue, Dec 12, 2017 at 9:24 AM, Simon Horman
> <horms+renesas@verge.net.au> wrote:
> > Sort root sub-nodes alphabetically for allow for easier maintenance
> > of this file.
> >
> > Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Thanks, applied.
^ permalink raw reply
* [PATCH] arm64: dts: renesas: r8a7795: sort subnodes of root node alphabetically
From: Simon Horman @ 2017-12-13 8:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdXRxSjcR9nTfUeD-Xo2pJp2p=d3WEd9as3VQxP69frwbQ@mail.gmail.com>
On Tue, Dec 12, 2017 at 10:45:58AM +0100, Geert Uytterhoeven wrote:
> On Tue, Dec 12, 2017 at 9:27 AM, Simon Horman
> <horms+renesas@verge.net.au> wrote:
> > Sort root sub-nodes alphabetically for allow for easier maintenance
> > of this file.
> >
> > Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Thanks, applied.
^ permalink raw reply
* [PATCH] dt-bindings: pinctrl: stm32: fix copyright and adopt SPDX identifier
From: Linus Walleij @ 2017-12-13 8:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512748391-22004-1-git-send-email-alexandre.torgue@st.com>
On Fri, Dec 8, 2017 at 4:53 PM, Alexandre Torgue
<alexandre.torgue@st.com> wrote:
> Add missing copyright and add SPDX identifier.
>
> Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH V3 09/29] drm/i915: deprecate pci_get_bus_and_slot()
From: Joonas Lahtinen @ 2017-12-13 8:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <055279d0-5e1b-621c-af8e-4c2704d54e8c@codeaurora.org>
On Tue, 2017-12-12 at 19:07 -0500, Sinan Kaya wrote:
> On 12/12/2017 9:04 AM, Joonas Lahtinen wrote:
> > Hi,
> >
> > I sent this individual i915 patch to our CI, and it is passing on
> > all platforms:
> >
> > https://patchwork.freedesktop.org/series/34822/
> >
> > Is it ok if I merge this to drm-tip already?
>
> As long as you have this change in your tree, it should be safe.
>
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/include/linux/pci.h?id=7912af5c835bd86f2b0347a480e0f40e2fab30d0
>
We don't yet.
Rodrigo, can you please pull the above patch in once we get a
backmerge?
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
^ permalink raw reply
* [PATCH] firmware: ti_sci: Use %zu for size_t print format
From: Lokesh Vutla @ 2017-12-13 7:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171202102012.354-1-nm@ti.com>
On Saturday 02 December 2017 03:50 PM, Nishanth Menon wrote:
> mbox_msg->len is of type size_t and %d is incorrect format. Instead
> use %zu for handling size_t correctly.
>
> Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Thanks and regards,
Lokesh
^ permalink raw reply
* [PATCH 1/1] arm: sunxi: Add alternative pins for spi0
From: Stefan Mavrodiev @ 2017-12-13 7:44 UTC (permalink / raw)
To: linux-arm-kernel
Allwinner A10/A13/A20 SoCs have pinmux for spi0
on port C. The patch adds these pins in the respective
dts includes.
Signed-off-by: Stefan Mavrodiev <stefan@olimex.com>
---
arch/arm/boot/dts/sun4i-a10.dtsi | 10 ++++++++++
arch/arm/boot/dts/sun5i.dtsi | 10 ++++++++++
arch/arm/boot/dts/sun7i-a20.dtsi | 10 ++++++++++
3 files changed, 30 insertions(+)
diff --git a/arch/arm/boot/dts/sun4i-a10.dtsi b/arch/arm/boot/dts/sun4i-a10.dtsi
index 5840f5c..d835741 100644
--- a/arch/arm/boot/dts/sun4i-a10.dtsi
+++ b/arch/arm/boot/dts/sun4i-a10.dtsi
@@ -705,11 +705,21 @@
bias-pull-up;
};
+ spi0_pc_pins: spi0-pc-pins {
+ pins = "PC0", "PC1", "PC2";
+ function = "spi0";
+ };
+
spi0_pi_pins: spi0-pi-pins {
pins = "PI11", "PI12", "PI13";
function = "spi0";
};
+ spi0_cs0_pc_pin: spi0-cs0-pc-pin {
+ pins = "PC23";
+ function = "spi0";
+ };
+
spi0_cs0_pi_pin: spi0-cs0-pi-pin {
pins = "PI10";
function = "spi0";
diff --git a/arch/arm/boot/dts/sun5i.dtsi b/arch/arm/boot/dts/sun5i.dtsi
index 07f2248..9290e26 100644
--- a/arch/arm/boot/dts/sun5i.dtsi
+++ b/arch/arm/boot/dts/sun5i.dtsi
@@ -492,6 +492,16 @@
function = "nand0";
};
+ spi0_pins_a: spi0 at 0 {
+ pins = "PC0", "PC1", "PC2";
+ function = "spi0";
+ };
+
+ spi0_cs0_pins_a: spi0-cs0 at 0 {
+ pins = "PC3";
+ function = "spi0";
+ };
+
spi2_pins_a: spi2 at 0 {
pins = "PE1", "PE2", "PE3";
function = "spi2";
diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
index 59655e4..6930527 100644
--- a/arch/arm/boot/dts/sun7i-a20.dtsi
+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
@@ -838,11 +838,21 @@
function = "spi0";
};
+ spi0_pins_b: spi0 at 1 {
+ pins = "PC0", "PC1", "PC2";
+ function = "spi0";
+ };
+
spi0_cs0_pins_a: spi0_cs0 at 0 {
pins = "PI10";
function = "spi0";
};
+ spi0_cs0_pins_b: spi0_cs0 at 1 {
+ pins = "PC23";
+ function = "spi0";
+ };
+
spi0_cs1_pins_a: spi0_cs1 at 0 {
pins = "PI14";
function = "spi0";
--
2.7.4
^ permalink raw reply related
* [PATCH v5 8/9] pinctrl: axp209: add support for AXP813 GPIOs
From: Linus Walleij @ 2017-12-13 7:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <96bc20e3-97ca-ae76-9e35-e6af644659c7@free-electrons.com>
On Fri, Dec 8, 2017 at 2:41 PM, Quentin Schulz
<quentin.schulz@free-electrons.com> wrote:
>> - pctl->desc = &axp20x_data;
>> + pctl->desc = (struct axp20x_pctrl_desc *)of_device_get_match_data(dev);
>> pctl->regmap = axp20x->regmap;
>> pctl->dev = &pdev->dev;
>>
>
> I am using pctl->desc before retrieving it, thus dereferencing from a
> null pointer.
>
> We just have to move
> pctl->chip.ngpio = pctl->desc->npins;
> after
> pctl->desc = (struct axp20x_pctrl_desc *)of_device_get_match_data(dev);
>
> Linus, I guess that I should send a patch to fix this or is there an
> other way not to have to apply such a small and dumb patch?
Just send a patch based on my pin control tree "devel" branch or
linux-next, it's cool.
Things like this happens all the time.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v5 0/4] ARM: ep93xx: ts72xx: Add support for BK3 board
From: Linus Walleij @ 2017-12-13 7:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211233625.5689-1-lukma@denx.de>
On Tue, Dec 12, 2017 at 12:36 AM, Lukasz Majewski <lukma@denx.de> wrote:
> This patch series adds support for Liebherr's BK3 board, being
> a derivative of TS72XX design.
All looks good.
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Out of curiosity: Liebherr is obviously doing heavy-duty industrial
control systems. Likewise Hartley is doing similar business over
at Vision Engravings.
Is the situation such that there is a whole bunch of industrial
systems out there, in active use and needing future upgrades,
that use the EP93xx?
Arnd has been nudging me to do DT conversion for EP93xx
so if there are many active industrial users of these
I should prioritize it, because these things have 20+ years
support cycles.
We also need to think about upholding support in GCC for
ARMv4(t) for the foreseeable future if there is a big web of
random deeply embedded systems out there that will need
updates.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH V8 7/7] dmaengine: qcom_hidma: Add identity register support
From: Sinan Kaya @ 2017-12-13 7:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513149653-19451-1-git-send-email-okaya@codeaurora.org>
The location for destination event channel register has been relocated from
offset 0x28 to 0x40. Update the code accordingly.
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
drivers/dma/qcom/hidma.c | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/dma/qcom/hidma.c b/drivers/dma/qcom/hidma.c
index c146c6d..963cc52 100644
--- a/drivers/dma/qcom/hidma.c
+++ b/drivers/dma/qcom/hidma.c
@@ -107,6 +107,7 @@ static void hidma_free(struct hidma_dev *dmadev)
enum hidma_cap {
HIDMA_MSI_CAP = 1,
+ HIDMA_IDENTITY_CAP,
};
/* process completed descriptors */
@@ -838,7 +839,10 @@ static int hidma_probe(struct platform_device *pdev)
if (!dmadev->nr_descriptors)
dmadev->nr_descriptors = HIDMA_NR_DEFAULT_DESC;
- dmadev->chidx = readl(dmadev->dev_trca + 0x28);
+ if (hidma_test_capability(&pdev->dev, HIDMA_IDENTITY_CAP))
+ dmadev->chidx = readl(dmadev->dev_trca + 0x40);
+ else
+ dmadev->chidx = readl(dmadev->dev_trca + 0x28);
/* Set DMA mask to 64 bits. */
rc = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64));
@@ -944,7 +948,7 @@ static int hidma_remove(struct platform_device *pdev)
static const struct acpi_device_id hidma_acpi_ids[] = {
{"QCOM8061"},
{"QCOM8062", HIDMA_MSI_CAP},
- {"QCOM8063", HIDMA_MSI_CAP},
+ {"QCOM8063", (HIDMA_MSI_CAP | HIDMA_IDENTITY_CAP)},
{},
};
MODULE_DEVICE_TABLE(acpi, hidma_acpi_ids);
@@ -953,7 +957,8 @@ static int hidma_remove(struct platform_device *pdev)
static const struct of_device_id hidma_match[] = {
{.compatible = "qcom,hidma-1.0",},
{.compatible = "qcom,hidma-1.1", .data = (void *)(HIDMA_MSI_CAP),},
- {.compatible = "qcom,hidma-1.2", .data = (void *)(HIDMA_MSI_CAP),},
+ {.compatible = "qcom,hidma-1.2",
+ .data = (void *)(HIDMA_MSI_CAP | HIDMA_IDENTITY_CAP),},
{},
};
MODULE_DEVICE_TABLE(of, hidma_match);
--
1.9.1
^ permalink raw reply related
* [PATCH V8 6/7] dmaengine: qcom_hidma: Add support for the new revision
From: Sinan Kaya @ 2017-12-13 7:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513149653-19451-1-git-send-email-okaya@codeaurora.org>
Add support for probing the newer HW and also organize MSI capable hardware
into an array for maintenance reasons.
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
drivers/dma/qcom/hidma.c | 34 +++++++++++++---------------------
1 file changed, 13 insertions(+), 21 deletions(-)
diff --git a/drivers/dma/qcom/hidma.c b/drivers/dma/qcom/hidma.c
index e366985..c146c6d 100644
--- a/drivers/dma/qcom/hidma.c
+++ b/drivers/dma/qcom/hidma.c
@@ -50,6 +50,7 @@
#include <linux/slab.h>
#include <linux/spinlock.h>
#include <linux/of_dma.h>
+#include <linux/of_device.h>
#include <linux/property.h>
#include <linux/delay.h>
#include <linux/acpi.h>
@@ -104,6 +105,9 @@ static void hidma_free(struct hidma_dev *dmadev)
module_param(nr_desc_prm, uint, 0644);
MODULE_PARM_DESC(nr_desc_prm, "number of descriptors (default: 0)");
+enum hidma_cap {
+ HIDMA_MSI_CAP = 1,
+};
/* process completed descriptors */
static void hidma_process_completed(struct hidma_chan *mchan)
@@ -736,25 +740,12 @@ static int hidma_request_msi(struct hidma_dev *dmadev,
#endif
}
-static bool hidma_msi_capable(struct device *dev)
+static bool hidma_test_capability(struct device *dev, enum hidma_cap test_cap)
{
- struct acpi_device *adev = ACPI_COMPANION(dev);
- const char *of_compat;
- int ret = -EINVAL;
-
- if (!adev || acpi_disabled) {
- ret = device_property_read_string(dev, "compatible",
- &of_compat);
- if (ret)
- return false;
+ enum hidma_cap cap;
- ret = strcmp(of_compat, "qcom,hidma-1.1");
- } else {
-#ifdef CONFIG_ACPI
- ret = strcmp(acpi_device_hid(adev), "QCOM8062");
-#endif
- }
- return ret == 0;
+ cap = (enum hidma_cap) device_get_match_data(dev);
+ return cap ? ((cap & test_cap) > 0) : 0;
}
static int hidma_probe(struct platform_device *pdev)
@@ -834,8 +825,7 @@ static int hidma_probe(struct platform_device *pdev)
* Determine the MSI capability of the platform. Old HW doesn't
* support MSI.
*/
- msi = hidma_msi_capable(&pdev->dev);
-
+ msi = hidma_test_capability(&pdev->dev, HIDMA_MSI_CAP);
device_property_read_u32(&pdev->dev, "desc-count",
&dmadev->nr_descriptors);
@@ -953,7 +943,8 @@ static int hidma_remove(struct platform_device *pdev)
#if IS_ENABLED(CONFIG_ACPI)
static const struct acpi_device_id hidma_acpi_ids[] = {
{"QCOM8061"},
- {"QCOM8062"},
+ {"QCOM8062", HIDMA_MSI_CAP},
+ {"QCOM8063", HIDMA_MSI_CAP},
{},
};
MODULE_DEVICE_TABLE(acpi, hidma_acpi_ids);
@@ -961,7 +952,8 @@ static int hidma_remove(struct platform_device *pdev)
static const struct of_device_id hidma_match[] = {
{.compatible = "qcom,hidma-1.0",},
- {.compatible = "qcom,hidma-1.1",},
+ {.compatible = "qcom,hidma-1.1", .data = (void *)(HIDMA_MSI_CAP),},
+ {.compatible = "qcom,hidma-1.2", .data = (void *)(HIDMA_MSI_CAP),},
{},
};
MODULE_DEVICE_TABLE(of, hidma_match);
--
1.9.1
^ permalink raw reply related
* [PATCH V8 5/7] ACPI: properties: Implement get_match_data() callback
From: Sinan Kaya @ 2017-12-13 7:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513149653-19451-1-git-send-email-okaya@codeaurora.org>
Now that we have a get_match_data() callback as part of the firmware node,
implement the ACPI specific piece for it.
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
---
drivers/acpi/property.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/acpi/property.c b/drivers/acpi/property.c
index e26ea20..466d150 100644
--- a/drivers/acpi/property.c
+++ b/drivers/acpi/property.c
@@ -1271,9 +1271,17 @@ static int acpi_fwnode_graph_parse_endpoint(const struct fwnode_handle *fwnode,
return 0;
}
+static void *
+acpi_fwnode_device_get_match_data(const struct fwnode_handle *fwnode,
+ const struct device *dev)
+{
+ return acpi_get_match_data(dev);
+}
+
#define DECLARE_ACPI_FWNODE_OPS(ops) \
const struct fwnode_operations ops = { \
.device_is_available = acpi_fwnode_device_is_available, \
+ .device_get_match_data = acpi_fwnode_device_get_match_data, \
.property_present = acpi_fwnode_property_present, \
.property_read_int_array = \
acpi_fwnode_property_read_int_array, \
--
1.9.1
^ permalink raw reply related
* [PATCH V8 4/7] OF: properties: Implement get_match_data() callback
From: Sinan Kaya @ 2017-12-13 7:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513149653-19451-1-git-send-email-okaya@codeaurora.org>
Now that we have a get_match_data() callback as part of the firmware node,
implement the OF specific piece for it.
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
Reviewed-by: Rob Herring <robh@kernel.org>
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
---
drivers/of/property.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/of/property.c b/drivers/of/property.c
index 8ad33a4..f25d363 100644
--- a/drivers/of/property.c
+++ b/drivers/of/property.c
@@ -981,10 +981,18 @@ static int of_fwnode_graph_parse_endpoint(const struct fwnode_handle *fwnode,
return 0;
}
+static void *
+of_fwnode_device_get_match_data(const struct fwnode_handle *fwnode,
+ const struct device *dev)
+{
+ return (void *)of_device_get_match_data(dev);
+}
+
const struct fwnode_operations of_fwnode_ops = {
.get = of_fwnode_get,
.put = of_fwnode_put,
.device_is_available = of_fwnode_device_is_available,
+ .device_get_match_data = of_fwnode_device_get_match_data,
.property_present = of_fwnode_property_present,
.property_read_int_array = of_fwnode_property_read_int_array,
.property_read_string_array = of_fwnode_property_read_string_array,
--
1.9.1
^ permalink raw reply related
* [PATCH V8 3/7] device property: Introduce a common API to fetch device match data
From: Sinan Kaya @ 2017-12-13 7:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513149653-19451-1-git-send-email-okaya@codeaurora.org>
There is an OF/ACPI function to obtain the driver data. We want to hide
OF/ACPI details from the device drivers and abstract following the device
family of functions.
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
Reviewed-by: Rob Herring <robh@kernel.org>
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
---
drivers/base/property.c | 7 +++++++
include/linux/fwnode.h | 4 ++++
include/linux/property.h | 2 ++
3 files changed, 13 insertions(+)
diff --git a/drivers/base/property.c b/drivers/base/property.c
index 851b1b6..09eaac9 100644
--- a/drivers/base/property.c
+++ b/drivers/base/property.c
@@ -1340,3 +1340,10 @@ int fwnode_graph_parse_endpoint(const struct fwnode_handle *fwnode,
return fwnode_call_int_op(fwnode, graph_parse_endpoint, endpoint);
}
EXPORT_SYMBOL(fwnode_graph_parse_endpoint);
+
+void *device_get_match_data(struct device *dev)
+{
+ return fwnode_call_ptr_op(dev_fwnode(dev), device_get_match_data,
+ dev);
+}
+EXPORT_SYMBOL_GPL(device_get_match_data);
diff --git a/include/linux/fwnode.h b/include/linux/fwnode.h
index 411a84c..4fa1a48 100644
--- a/include/linux/fwnode.h
+++ b/include/linux/fwnode.h
@@ -15,6 +15,7 @@
#include <linux/types.h>
struct fwnode_operations;
+struct device;
struct fwnode_handle {
struct fwnode_handle *secondary;
@@ -51,6 +52,7 @@ struct fwnode_reference_args {
* struct fwnode_operations - Operations for fwnode interface
* @get: Get a reference to an fwnode.
* @put: Put a reference to an fwnode.
+ * @device_get_match_data: Return the device driver match data.
* @property_present: Return true if a property is present.
* @property_read_integer_array: Read an array of integer properties. Return
* zero on success, a negative error code
@@ -71,6 +73,8 @@ struct fwnode_operations {
struct fwnode_handle *(*get)(struct fwnode_handle *fwnode);
void (*put)(struct fwnode_handle *fwnode);
bool (*device_is_available)(const struct fwnode_handle *fwnode);
+ void *(*device_get_match_data)(const struct fwnode_handle *fwnode,
+ const struct device *dev);
bool (*property_present)(const struct fwnode_handle *fwnode,
const char *propname);
int (*property_read_int_array)(const struct fwnode_handle *fwnode,
diff --git a/include/linux/property.h b/include/linux/property.h
index f6189a3..6653ed4 100644
--- a/include/linux/property.h
+++ b/include/linux/property.h
@@ -275,6 +275,8 @@ int device_add_properties(struct device *dev,
enum dev_dma_attr device_get_dma_attr(struct device *dev);
+void *device_get_match_data(struct device *dev);
+
int device_get_phy_mode(struct device *dev);
void *device_get_mac_address(struct device *dev, char *addr, int alen);
--
1.9.1
^ permalink raw reply related
* [PATCH V8 2/7] ACPI / bus: Introduce acpi_get_match_data() function
From: Sinan Kaya @ 2017-12-13 7:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513149653-19451-1-git-send-email-okaya@codeaurora.org>
OF has of_device_get_match_data() function to extract driver specific data
structure. Add a similar function for ACPI.
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---
drivers/acpi/bus.c | 18 ++++++++++++++++++
include/linux/acpi.h | 6 ++++++
2 files changed, 24 insertions(+)
diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
index 4d0979e..f87ed3b 100644
--- a/drivers/acpi/bus.c
+++ b/drivers/acpi/bus.c
@@ -785,6 +785,24 @@ const struct acpi_device_id *acpi_match_device(const struct acpi_device_id *ids,
}
EXPORT_SYMBOL_GPL(acpi_match_device);
+void *acpi_get_match_data(const struct device *dev)
+{
+ const struct acpi_device_id *match;
+
+ if (!dev->driver)
+ return NULL;
+
+ if (!dev->driver->acpi_match_table)
+ return NULL;
+
+ match = acpi_match_device(dev->driver->acpi_match_table, dev);
+ if (!match)
+ return NULL;
+
+ return (void *)match->driver_data;
+}
+EXPORT_SYMBOL_GPL(acpi_get_match_data);
+
int acpi_match_device_ids(struct acpi_device *device,
const struct acpi_device_id *ids)
{
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index dc1ebfe..9278737 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -584,6 +584,7 @@ extern int acpi_nvs_for_each_region(int (*func)(__u64, __u64, void *),
const struct acpi_device_id *acpi_match_device(const struct acpi_device_id *ids,
const struct device *dev);
+void *acpi_get_match_data(const struct device *dev);
extern bool acpi_driver_match_device(struct device *dev,
const struct device_driver *drv);
int acpi_device_uevent_modalias(struct device *, struct kobj_uevent_env *);
@@ -755,6 +756,11 @@ static inline const struct acpi_device_id *acpi_match_device(
return NULL;
}
+static inline void *acpi_get_match_data(const struct device *dev)
+{
+ return NULL;
+}
+
static inline bool acpi_driver_match_device(struct device *dev,
const struct device_driver *drv)
{
--
1.9.1
^ permalink raw reply related
* [PATCH V8 1/7] Documentation: DT: qcom_hidma: Bump HW revision for the bugfixed HW
From: Sinan Kaya @ 2017-12-13 7:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513149653-19451-1-git-send-email-okaya@codeaurora.org>
A new version of the HIDMA IP has been released with bug fixes. Bumping the
hardware version to differentiate from others.
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
Reviewed-by: Rob Herring <robh@kernel.org>
---
Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt b/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
index 55492c2..5d93d6d 100644
--- a/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
+++ b/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
@@ -47,8 +47,8 @@ When the OS is not in control of the management interface (i.e. it's a guest),
the channel nodes appear on their own, not under a management node.
Required properties:
-- compatible: must contain "qcom,hidma-1.0" for initial HW or "qcom,hidma-1.1"
-for MSI capable HW.
+- compatible: must contain "qcom,hidma-1.0" for initial HW or
+ "qcom,hidma-1.1"/"qcom,hidma-1.2" for MSI capable HW.
- reg: Addresses for the transfer and event channel
- interrupts: Should contain the event interrupt
- desc-count: Number of asynchronous requests this channel can handle
--
1.9.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox