* [PATCH v3 00/20] arm64: Unmap the kernel whilst running in userspace (KPTI)
From: Ard Biesheuvel @ 2018-01-05 16:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180105160617.GC17349@kroah.com>
On 5 January 2018 at 16:06, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> On Thu, Jan 04, 2018 at 10:23:40AM -0800, Florian Fainelli wrote:
>> On 01/03/2018 10:50 PM, Greg Kroah-Hartman wrote:
>> > On Wed, Jan 03, 2018 at 09:17:26PM -0800, Florian Fainelli wrote:
>> >> On 12/11/2017 09:59 AM, Catalin Marinas wrote:
>> >>> On Wed, Dec 06, 2017 at 12:35:19PM +0000, Will Deacon wrote:
>> >>>> Patches are also pushed here:
>> >>>>
>> >>>> git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git kpti
>> >>>>
>> >>>> Feedback and testing welcome. At this point, I'd like to start thinking
>> >>>> about getting this merged for 4.16.
>> >>>
>> >>> For the record, the fixed up version was pushed by Will here:
>> >>>
>> >>> git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git kpti
>> >>>
>> >>> and I queued it for 4.16 in the arm64 for-next/core branch (same tree as
>> >>> above).
>> >>
>> >> Greg proposed the x86/KPTI patches for the stable-4.9.75 queue, is there
>> >> a plan to get the ARM64/KPTI patches backported towards stable trees as
>> >> well?
>> >
>> > Stable tree patches have to get into Linus's tree first before I can do
>> > anything :)
>> >
>> > Anyway, once that happens, yes, there is a plan, but it's a bit
>> > "different", and I'll talk about it once these are merged.
>>
>> Great, thanks! Bonus question, if someone is using any of the affected
>> devices in AArch32, should we be expecting to see ARM/Linux changes as
>> well, that is, is there a plan to come up with a kpti implementation for
>> ARM?
>
> I have not heard of anyone working on this for any arm32 platforms,
> as of this time, sorry.
>
> Which makes me worry about my android tv, glad I don't connect it to the
> network :(
>
The only ARM variant that is currently known to be affected by
Meltdown/variant 3 (which is what KPTI addresses) is the Cortex-A75,
which is a 64-bit core. That still means 32-bit guests running under
KVM will be affected, as well as a 32-bit kernel running on the bare
metal, but in practice, 32-bit ARM simply doesn't need KPTI. (My KASLR
patches for ARM are a bit in limbo atm, but those would benefit from
unmapping the kernel while running in userland as well)
As for variants 1/2 aka Spectre, I suppose ARM will need to implement
the same nospec/retpoline primitives that are being proposed for other
arches, but that work is not as fleshed out yet.
^ permalink raw reply
* [GIT PULL 3/5] i.MX device tree updates for 4.16
From: Arnd Bergmann @ 2018-01-05 16:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1514959040-9992-3-git-send-email-shawnguo@kernel.org>
On Wed, Jan 3, 2018 at 6:57 AM, Shawn Guo <shawnguo@kernel.org> wrote:
> The following changes since commit 50c4c4e268a2d7a3e58ebb698ac74da0de40ae36:
>
> Linux 4.15-rc3 (2017-12-10 17:56:26 -0800)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git tags/imx-dt-4.16
>
> for you to fetch changes up to 84a82ef70e1eb2a7a90bc19eed27cb27a8e4c54c:
>
> ARM: dts: imx7s: Avoid using label in unit address and reg (2017-12-27 10:52:39 +0800)
>
> ----------------------------------------------------------------
> i.MX device tree changes for 4.16:
> - A few random updates for vf610-zii board: correct switch EEPROM size,
> enable edma1, correct GPIO expander interrupt, add PHYs for switch2
> device.
> - LS1021A device tree updates: add reboot and QSPI device nodes, label
> USB controllers, specify interrupt-affinity for PMU, fix TMR_FIPER1
> setting, enable esdhc device, add Moxa UC-8410A board support.
> - A bunch of patches from Fabio: fix reg - unit address mismatches,
> remove leading zero in unit address, move regulators out of
> simple-bus, move nodes with no reg property out of bus, remove extra
> clock cell, add missing phy-cells to usb-nop-xceiv, etc.
> - A couple series from Hummingboard developers: re-organise device tree
> files for better handling various board versions, and then add the
> new hummingboard2 board support on top of that.
> - Disable AC'97 input pins pad and add support for powering off for
> imx6qdl-udoo board.
> - Convert from fbdev to drm bindings for imx6sx-sdb and imx6sl-evk
> board.
> - Add device tree for Variscite DART-MX6 SoM and Carrier-board support.
> - Add new board support of TS-4600 and TS-7970 from Technologic
> Systems.
> - A series from Stefan to update imx7-colibri device tree and then add
> new version of Toradex Colibri iMX7D board with eMMC support.
> - Other random updates on various board support.
Nice changelog, pulled into next/dt, thanks!
Arnd
^ permalink raw reply
* [linux-sunxi] [PATCH v2 3/6] ARM: sun4i: Convert to CCU
From: Kevin Hilman @ 2018-01-05 16:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOi56cX0Uw=jiAhNSZ8p8_1LPbd7zePkS5kTnMf+ua0v98zfVg@mail.gmail.com>
On Wed, Dec 13, 2017 at 11:46 AM, Kevin Hilman <khilman@baylibre.com> wrote:
> On Wed, Dec 13, 2017 at 9:13 AM, Priit Laes <plaes@plaes.org> wrote:
>> On Wed, Dec 13, 2017 at 05:09:33PM +0000, Priit Laes wrote:
>>> On Tue, Dec 12, 2017 at 01:24:52PM -0800, Kevin Hilman wrote:
>>> > On Tue, Dec 12, 2017 at 9:26 AM, Priit Laes <plaes@plaes.org> wrote:
>>> > > On Mon, Dec 11, 2017 at 02:22:30PM -0800, Kevin Hilman wrote:
>>> > >> On Sun, Mar 26, 2017 at 10:20 AM, Priit Laes <plaes@plaes.org> wrote:
>>> > >> > Convert sun4i-a10.dtsi to new CCU driver.
>>> > >> >
>>> > >> > Signed-off-by: Priit Laes <plaes@plaes.org>
>>> > >>
>>> > >> I finally got around to bisecting a mainline boot failure on
>>> > >> sun4i-a10-cubieboard that's been happening for quite a while. Based
>>> > >> on on kernelci.org, it showed up sometime during the v4.15 merge
>>> > >> window[1]. It bisected down to this commit (in mainline as commit
>>> > >> 41193869f2bdb585ce09bfdd16d9482aadd560ad).
>>> > >>
>>> > >> When it fails, there is no output on the serial console, so I don't
>>> > >> know exactly how it's failing, just that it no longer boots.
>>> > >
>>> > > We tried out latest 4.15 with various compilers and it works:
>>> > > - gcc version 7.1.1 20170622 (Red Hat Cross 7.1.1-3) (GCC) - A10 Gemei G9 tablet
>>> > > - gcc 7.2.0-debian - A10 Cubieboard
>>> >
>>> > And you can reproduce the bug with gcc5 or gcc6?
>>>
>>> Tried following commits on Gemei G9 (A10 tablet):
>>> * 4.15.0-rc3-00037-gd39a01eff9af - latest master
>>> * 4.14.0-rc1-00002-g41193869f2bd - the exact commit, causing the issue.
>>>
>>> With the same Linaro toolchain:
>>> (gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05))
>>
>> And I also tried the same dtb and zImage from kernelci page [1] and it works with
>> that too...
>>
>> https://storage.kernelci.org/mainline/master/v4.15-rc3/arm/sunxi_defconfig/
>
> Can you share a full boot-log (including all the u-boot output etc.)
> so I can see exactly how the kernel is being loaded? Especially the
> u-boot version?
>
> As $SUBJECT patch seems to be changing clocks around, perhaps this is
> an issue where some u-boot dependency is uncovered, and older versions
> of u-boot don't play well with this change.
Ping.
This is still failing in mainline, but passing int stable <= v4.14
Kevin
^ permalink raw reply
* [GIT PULL] ARM: mvebu: dt64 for v4.16 (#2) (version 2)
From: Gregory CLEMENT @ 2018-01-05 16:10 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
Here is the second pull request for dt64 for mvebu for v4.16 which
replace the previous one.
Indeed I had to push a fix which conflicted with the change done on the
armada-cp110 files. Resolving the conflict was not automatic, so I chose
to merge the mvebu/fixes branch in the mvebu/dt64 branch, as at the end
during the merge window for 4.16 the content of mvebu/fixes would have
been already merged in 4.15.
Gregory
The following changes since commit 4cada03801992d09ccceaf5f462e9dadb75a9613:
ARM64: dts: marvell: Add thermal support for A7K/A8K (2017-12-18 17:13:17 +0100)
are available in the Git repository at:
git://git.infradead.org/linux-mvebu.git tags/mvebu-dt64-4.16-2
for you to fetch changes up to 474c5885582c4a79c21bcf01ed98f98c935f1f4a:
arm64: dts: marvell: add Ethernet aliases (2018-01-05 17:02:45 +0100)
----------------------------------------------------------------
mvebu dt64 for 4.16 (part 2)
The main change here are the series of commits doing the Armada 7K/8K
CP110 DT de-duplication, they include the de-duplication itself and
small fixes in the device tree files.
Besides them there are 2 other patches:
- One adding the crypto support for Armada 37xx SoCs
- An other adding Ethernet aliases on A7K/A8K base boards
----------------------------------------------------------------
Antoine Tenart (1):
arm64: dts: marvell: armada-37xx: add a crypto node
Gregory CLEMENT (2):
ARM64: dts: marvell: armada-cp110: Fix clock resources for various node
Merge branch 'mvebu/fixes' into HEAD
Thomas Petazzoni (9):
ARM: dts: kirkwood: fix pin-muxing of MPP7 on OpenBlocks A7
arm64: dts: marvell: fix watchdog unit address in Armada AP806
arm64: dts: marvell: use lower case for unit address and reg property
arm64: dts: marvell: fix typos in comment describing the NAND controller
arm64: dts: marvell: fix compatible string list for Armada CP110 slave NAND
arm64: dts: marvell: use mvebu-icu.h where possible
arm64: dts: marvell: use aliases for SPI busses on Armada 7K/8K
arm64: dts: marvell: de-duplicate CP110 description
arm64: dts: marvell: replace cpm by cp0, cps by cp1
Yan Markman (1):
arm64: dts: marvell: add Ethernet aliases
arch/arm/boot/dts/kirkwood-openblocks_a7.dts | 10 +-
arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 14 +
arch/arm64/boot/dts/marvell/armada-7040-db.dts | 52 +--
arch/arm64/boot/dts/marvell/armada-70x0.dtsi | 37 +-
arch/arm64/boot/dts/marvell/armada-8020.dtsi | 2 +-
arch/arm64/boot/dts/marvell/armada-8040-db.dts | 87 ++--
arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts | 82 ++--
arch/arm64/boot/dts/marvell/armada-8040.dtsi | 2 +-
arch/arm64/boot/dts/marvell/armada-80x0.dtsi | 80 +++-
arch/arm64/boot/dts/marvell/armada-ap806.dtsi | 8 +-
arch/arm64/boot/dts/marvell/armada-common.dtsi | 10 +
.../boot/dts/marvell/armada-cp110-master.dtsi | 449 ---------------------
.../arm64/boot/dts/marvell/armada-cp110-slave.dtsi | 448 --------------------
arch/arm64/boot/dts/marvell/armada-cp110.dtsi | 424 +++++++++++++++++++
14 files changed, 678 insertions(+), 1027 deletions(-)
create mode 100644 arch/arm64/boot/dts/marvell/armada-common.dtsi
delete mode 100644 arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi
delete mode 100644 arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
create mode 100644 arch/arm64/boot/dts/marvell/armada-cp110.dtsi
^ permalink raw reply
* [GIT PULL] ARM: aspeed: dts changes for 4.16
From: Arnd Bergmann @ 2018-01-05 16:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACPK8XdOywvpyWqgOG6TVj4EwBqWA7yCmzaNqGQyvQJzPuseSg@mail.gmail.com>
On Wed, Jan 3, 2018 at 5:17 AM, Joel Stanley <joel@jms.id.au> wrote:
> ----------------------------------------------------------------
> ASPEED device tree updates for 4.16
>
> Clock driver support:
>
> Rework all platforms to use proper clock bindings. Linux should now boot
> upstream kernels on ast2400 and ast2500 platforms without out of tree
> patches.
>
> New systems:
>
> Witherspoon: OpenPower Power9 server manufactured by IBM that uses
> the ASPEED ast2500
> Zaius: OpenPower Power9 server manufactured by Invatech that uses the
> ASPEED ast2500
> Q71L: Intel Xeon server manufactured by Qanta that uses the ASPEED ast2400
>
> We also see updates to the Palmetto and Romulus systems to bring them in
> line with the functionality of those above.
>
> The systems take advantage of recently added drivers for LPC Snoop
> device and the PWM/Tachometer fan controller.
>
> OpenBMC flash layout:
>
> The flash layout used OpenBMC systems is added and the device trees now
> use it.
Pulled into next/dt, thanks!
Arnd
^ permalink raw reply
* [PATCH v3 00/20] arm64: Unmap the kernel whilst running in userspace (KPTI)
From: Greg Kroah-Hartman @ 2018-01-05 16:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <092a51ec-f856-2b51-5d47-8acbdc671031@gmail.com>
On Thu, Jan 04, 2018 at 10:23:40AM -0800, Florian Fainelli wrote:
> On 01/03/2018 10:50 PM, Greg Kroah-Hartman wrote:
> > On Wed, Jan 03, 2018 at 09:17:26PM -0800, Florian Fainelli wrote:
> >> On 12/11/2017 09:59 AM, Catalin Marinas wrote:
> >>> On Wed, Dec 06, 2017 at 12:35:19PM +0000, Will Deacon wrote:
> >>>> Patches are also pushed here:
> >>>>
> >>>> git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git kpti
> >>>>
> >>>> Feedback and testing welcome. At this point, I'd like to start thinking
> >>>> about getting this merged for 4.16.
> >>>
> >>> For the record, the fixed up version was pushed by Will here:
> >>>
> >>> git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git kpti
> >>>
> >>> and I queued it for 4.16 in the arm64 for-next/core branch (same tree as
> >>> above).
> >>
> >> Greg proposed the x86/KPTI patches for the stable-4.9.75 queue, is there
> >> a plan to get the ARM64/KPTI patches backported towards stable trees as
> >> well?
> >
> > Stable tree patches have to get into Linus's tree first before I can do
> > anything :)
> >
> > Anyway, once that happens, yes, there is a plan, but it's a bit
> > "different", and I'll talk about it once these are merged.
>
> Great, thanks! Bonus question, if someone is using any of the affected
> devices in AArch32, should we be expecting to see ARM/Linux changes as
> well, that is, is there a plan to come up with a kpti implementation for
> ARM?
I have not heard of anyone working on this for any arm32 platforms,
as of this time, sorry.
Which makes me worry about my android tv, glad I don't connect it to the
network :(
thanks,
greg k-h
^ permalink raw reply
* [PATCHv2] Device tree binding for Avago APDS990X light sensor
From: Rob Herring @ 2018-01-05 16:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180102124450.GA18659@amd>
On Tue, Jan 02, 2018 at 01:44:51PM +0100, Pavel Machek wrote:
> From: Filip Matijevi? <filip.matijevic.pz@gmail.com>
>
> This prepares binding for light sensor used in Nokia N9.
"dt-bindings: ..." is the preferred subject prefix.
>
> Signed-off-by: Filip Matijevi? <filip.matijevic.pz@gmail.com>
> Signed-off-by: Pavel Machek <pavel@ucw.cz>
>
> diff --git a/Documentation/devicetree/bindings/misc/avago-apds990x.txt b/Documentation/devicetree/bindings/misc/avago-apds990x.txt
> new file mode 100644
> index 0000000..480c0b1
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/misc/avago-apds990x.txt
Put this with other light sensors whether you use IIO or not:
bindings/iio/light/
> @@ -0,0 +1,41 @@
> +Avago APDS990X driver
Bindings aren't drivers.
> +
> +https://docs.broadcom.com/docs/AV02-2867EN
> +
> +Required properties:
> +- compatible: "avago,apds990x"
> +- reg: address on the I2C bus
> +- interrupts: external interrupt line number
> +- vdd-supply: power supply for VDD
> +- vled-supply: power supply for LEDA
> +- avago,ga: Glass attenuation
We already have "upisemi,glass-coef". Can we align on something common.
> +- avago,cf1: Clear channel factor 1
> +- avago,irf1: IR channel factor 1
> +- avago,cf2: Clear channel factor 2
> +- avago,irf2: IR channel factor 2
Perhaps 2 properties with 2 cells for factor 1 and 2.
> +- avago,df: Device factor
Units/range for all these?
> +- avago,pdrive: IR current, one of APDS_IRLED_CURR_XXXmA values
Don't we have standard current property for LEDs?
> +- avago,ppcount: Proximity pulse count
Is this standard for prox sensors?
> +
> +Example (Nokia N9):
> +
> + als_ps at 39 {
light-sensor at 39
> + compatible = "avago,apds990x";
> + reg = <0x39>;
> +
> + interrupt-parent = <&gpio3>;
> + interrupts = <19 (IRQ_TYPE_EDGE_FALLING | IRQ_TYPE_LEVEL_LOW)>; /* gpio_83 */
> +
> + vdd-supply = <&vaux1>;
> + vled-supply = <&vbat>;
> +
> + avago,ga = <168834>;
> + avago,cf1 = <4096>;
> + avago,irf1 = <7824>;
> + avago,cf2 = <877>;
> + avago,irf2 = <1575>;
> + avago,df = <52>;
> +
> + avago,pdrive = <0x2>; /* APDS_IRLED_CURR_25mA */
> + avago,ppcount = <5>;
> + };
>
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* [PATCH 10/12] clk: mediatek: switch to use dev_get_regmap() for MT7622 audsys
From: Rob Herring @ 2018-01-05 15:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cbdada9cdbafda2452fe171a81588ce5b0d4f688.1514881870.git.ryder.lee@mediatek.com>
On Tue, Jan 02, 2018 at 07:47:52PM +0800, Ryder Lee wrote:
> As the new audsys wrapper driver is in place, switch to use dev_get_regmap()
> to obtain the regmap from its parent.
>
> This patch also add missing clock data 'CLK_AUDIO_AFE_CONN'.
"also" is a keyword for this belonging in a separate patch.
>
> Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
> ---
> drivers/clk/mediatek/clk-mt7622-aud.c | 11 +++++++++--
> include/dt-bindings/clock/mt7622-clk.h | 3 ++-
> 2 files changed, 11 insertions(+), 3 deletions(-)
^ permalink raw reply
* [PATCH 06/12] mfd: add DT bindings for MedaiTek audio subsystem
From: Rob Herring @ 2018-01-05 15:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9ae24121a9cea18046428afd1d92c1b8601c0e05.1514881870.git.ryder.lee@mediatek.com>
On Tue, Jan 02, 2018 at 07:47:31PM +0800, Ryder Lee wrote:
> This patch adds documentation of the DT bindings for the MediaTek
> audio subsystem wrapper.
>
> Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
> ---
> .../devicetree/bindings/mfd/mtk-audsys.txt | 109 +++++++++++++++++++++
> 1 file changed, 109 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mfd/mtk-audsys.txt
>
> diff --git a/Documentation/devicetree/bindings/mfd/mtk-audsys.txt b/Documentation/devicetree/bindings/mfd/mtk-audsys.txt
> new file mode 100644
> index 0000000..7739580
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/mtk-audsys.txt
> @@ -0,0 +1,109 @@
> +MediaTek Audio Subsystem Wrapper
> +
> +Required properties:
> +- compatible: Should be "mediatek,mt2701-audsys-core".
> +- reg: Should contain the device's region location and size.
The example shows 2 regions. What are they?
> +- clocks: Must contain an entry for each entry in clock-names.
> + See ../clocks/clock-bindings.txt for details.
> +- clock-names: Should contain "infra_aud", "top_a1sys", "top_a2sys".
> +
> +Required subnodes are described in:
> +- ../sound/mt2701-afe-pcm.txt.
> +- ../arm/mediatek/mediatek,audsys.txt.
> +
> +Example:
> +
> + audio-subsystm at 11220000 {
> + compatible = "mediatek,mt2701-audsys-core";
> + reg = <0 0x11220000 0 0x2000>,
> + <0 0x112a0000 0 0x20000>;
> + clocks = <&infracfg CLK_INFRA_AUDIO>,
> + <&topckgen CLK_TOP_AUD_48K_TIMING>,
> + <&topckgen CLK_TOP_AUD_44K_TIMING>;
> + clock-names = "infra_aud", "top_a1sys", "top_a2sys";
> +
> + audsys: clock {
> + compatible = "mediatek,mt2701-audsys";
> + #clock-cells = <1>;
There's no need for a node here. Just put #clock-cells in the parent.
> + };
> +
> + afe: audio {
> + compatible = "mediatek,mt2701-audio";
No registers associated with this?
Looks to me like you are creating nodes just to instantiate drivers.
Describe h/w blocks. DT is not the only way to instantiate drivers.
> + interrupts = <GIC_SPI 104 IRQ_TYPE_LEVEL_LOW>,
> + <GIC_SPI 132 IRQ_TYPE_LEVEL_LOW>;
> + interrupt-names = "afe", "asys";
> + power-domains = <&scpsys MT2701_POWER_DOMAIN_IFR_MSC>;
> +
> + clocks = <&topckgen CLK_TOP_AUD_MUX1_SEL>,
> + <&topckgen CLK_TOP_AUD_MUX2_SEL>,
> + <&topckgen CLK_TOP_AUD_K1_SRC_SEL>,
> + <&topckgen CLK_TOP_AUD_K2_SRC_SEL>,
> + <&topckgen CLK_TOP_AUD_K3_SRC_SEL>,
> + <&topckgen CLK_TOP_AUD_K4_SRC_SEL>,
> + <&topckgen CLK_TOP_AUD_K1_SRC_DIV>,
> + <&topckgen CLK_TOP_AUD_K2_SRC_DIV>,
> + <&topckgen CLK_TOP_AUD_K3_SRC_DIV>,
> + <&topckgen CLK_TOP_AUD_K4_SRC_DIV>,
> + <&topckgen CLK_TOP_AUD_I2S1_MCLK>,
> + <&topckgen CLK_TOP_AUD_I2S2_MCLK>,
> + <&topckgen CLK_TOP_AUD_I2S3_MCLK>,
> + <&topckgen CLK_TOP_AUD_I2S4_MCLK>,
> + <&audsys CLK_AUD_I2SO1>,
> + <&audsys CLK_AUD_I2SO2>,
> + <&audsys CLK_AUD_I2SO3>,
> + <&audsys CLK_AUD_I2SO4>,
> + <&audsys CLK_AUD_I2SIN1>,
> + <&audsys CLK_AUD_I2SIN2>,
> + <&audsys CLK_AUD_I2SIN3>,
> + <&audsys CLK_AUD_I2SIN4>,
> + <&audsys CLK_AUD_ASRCO1>,
> + <&audsys CLK_AUD_ASRCO2>,
> + <&audsys CLK_AUD_ASRCO3>,
> + <&audsys CLK_AUD_ASRCO4>,
> + <&audsys CLK_AUD_AFE>,
> + <&audsys CLK_AUD_AFE_CONN>,
> + <&audsys CLK_AUD_A1SYS>,
> + <&audsys CLK_AUD_A2SYS>,
> + <&audsys CLK_AUD_AFE_MRGIF>;
> +
> + clock-names = "top_audio_mux1_sel",
> + "top_audio_mux2_sel",
> + "i2s0_src_sel",
> + "i2s1_src_sel",
> + "i2s2_src_sel",
> + "i2s3_src_sel",
> + "i2s0_src_div",
> + "i2s1_src_div",
> + "i2s2_src_div",
> + "i2s3_src_div",
> + "i2s0_mclk_en",
> + "i2s1_mclk_en",
> + "i2s2_mclk_en",
> + "i2s3_mclk_en",
> + "i2so0_hop_ck",
> + "i2so1_hop_ck",
> + "i2so2_hop_ck",
> + "i2so3_hop_ck",
> + "i2si0_hop_ck",
> + "i2si1_hop_ck",
> + "i2si2_hop_ck",
> + "i2si3_hop_ck",
> + "asrc0_out_ck",
> + "asrc1_out_ck",
> + "asrc2_out_ck",
> + "asrc3_out_ck",
> + "audio_afe_pd",
> + "audio_afe_conn_pd",
> + "audio_a1sys_pd",
> + "audio_a2sys_pd",
> + "audio_mrgif_pd";
> +
> + assigned-clocks = <&topckgen CLK_TOP_AUD_MUX1_SEL>,
> + <&topckgen CLK_TOP_AUD_MUX2_SEL>,
> + <&topckgen CLK_TOP_AUD_MUX1_DIV>,
> + <&topckgen CLK_TOP_AUD_MUX2_DIV>;
> + assigned-clock-parents = <&topckgen CLK_TOP_AUD1PLL_98M>,
> + <&topckgen CLK_TOP_AUD2PLL_90M>;
> + assigned-clock-rates = <0>, <0>, <49152000>, <45158400>;
> + };
> + };
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v3 1/6] media: rc: update sunxi-ir driver to get base clock frequency from devicetree
From: Sean Young @ 2018-01-05 15:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171219080747.4507-2-embed3d@gmail.com>
On Tue, Dec 19, 2017 at 09:07:42AM +0100, Philipp Rossak wrote:
> This patch updates the sunxi-ir driver to set the base clock frequency from
> devicetree.
>
> This is necessary since there are different ir receivers on the
> market, that operate with different frequencies. So this value could be
> set if the attached ir receiver needs a different base clock frequency,
> than the default 8 MHz.
>
> Signed-off-by: Philipp Rossak <embed3d@gmail.com>
Acked-by: Sean Young <sean@mess.org>
Sean
> ---
> drivers/media/rc/sunxi-cir.c | 19 +++++++++++--------
> 1 file changed, 11 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/media/rc/sunxi-cir.c b/drivers/media/rc/sunxi-cir.c
> index 97f367b446c4..f500cea228a9 100644
> --- a/drivers/media/rc/sunxi-cir.c
> +++ b/drivers/media/rc/sunxi-cir.c
> @@ -72,12 +72,8 @@
> /* CIR_REG register idle threshold */
> #define REG_CIR_ITHR(val) (((val) << 8) & (GENMASK(15, 8)))
>
> -/* Required frequency for IR0 or IR1 clock in CIR mode */
> +/* Required frequency for IR0 or IR1 clock in CIR mode (default) */
> #define SUNXI_IR_BASE_CLK 8000000
> -/* Frequency after IR internal divider */
> -#define SUNXI_IR_CLK (SUNXI_IR_BASE_CLK / 64)
> -/* Sample period in ns */
> -#define SUNXI_IR_SAMPLE (1000000000ul / SUNXI_IR_CLK)
> /* Noise threshold in samples */
> #define SUNXI_IR_RXNOISE 1
> /* Idle Threshold in samples */
> @@ -122,7 +118,8 @@ static irqreturn_t sunxi_ir_irq(int irqno, void *dev_id)
> /* for each bit in fifo */
> dt = readb(ir->base + SUNXI_IR_RXFIFO_REG);
> rawir.pulse = (dt & 0x80) != 0;
> - rawir.duration = ((dt & 0x7f) + 1) * SUNXI_IR_SAMPLE;
> + rawir.duration = ((dt & 0x7f) + 1) *
> + ir->rc->rx_resolution;
> ir_raw_event_store_with_filter(ir->rc, &rawir);
> }
> }
> @@ -148,6 +145,7 @@ static int sunxi_ir_probe(struct platform_device *pdev)
> struct device_node *dn = dev->of_node;
> struct resource *res;
> struct sunxi_ir *ir;
> + u32 b_clk_freq = SUNXI_IR_BASE_CLK;
>
> ir = devm_kzalloc(dev, sizeof(struct sunxi_ir), GFP_KERNEL);
> if (!ir)
> @@ -172,6 +170,9 @@ static int sunxi_ir_probe(struct platform_device *pdev)
> return PTR_ERR(ir->clk);
> }
>
> + /* Base clock frequency (optional) */
> + of_property_read_u32(dn, "clock-frequency", &b_clk_freq);
> +
> /* Reset (optional) */
> ir->rst = devm_reset_control_get_optional_exclusive(dev, NULL);
> if (IS_ERR(ir->rst))
> @@ -180,11 +181,12 @@ static int sunxi_ir_probe(struct platform_device *pdev)
> if (ret)
> return ret;
>
> - ret = clk_set_rate(ir->clk, SUNXI_IR_BASE_CLK);
> + ret = clk_set_rate(ir->clk, b_clk_freq);
> if (ret) {
> dev_err(dev, "set ir base clock failed!\n");
> goto exit_reset_assert;
> }
> + dev_dbg(dev, "set base clock frequency to %d Hz.\n", b_clk_freq);
>
> if (clk_prepare_enable(ir->apb_clk)) {
> dev_err(dev, "try to enable apb_ir_clk failed\n");
> @@ -225,7 +227,8 @@ static int sunxi_ir_probe(struct platform_device *pdev)
> ir->rc->map_name = ir->map_name ?: RC_MAP_EMPTY;
> ir->rc->dev.parent = dev;
> ir->rc->allowed_protocols = RC_PROTO_BIT_ALL_IR_DECODER;
> - ir->rc->rx_resolution = SUNXI_IR_SAMPLE;
> + /* Frequency after IR internal divider with sample period in ns */
> + ir->rc->rx_resolution = (1000000000ul / (b_clk_freq / 64));
> ir->rc->timeout = MS_TO_NS(SUNXI_IR_TIMEOUT);
> ir->rc->driver_name = SUNXI_IR_DEV;
>
> --
> 2.11.0
^ permalink raw reply
* [GIT PULL] ARM: mvebu: fixes for v4.15 (#1)
From: Gregory CLEMENT @ 2018-01-05 15:42 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
Here is the first pull request for fixes for mvebu for v4.15.
Gregory
The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:
Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)
are available in the Git repository at:
git://git.infradead.org/linux-mvebu.git tags/mvebu-fixes-4.15-1
for you to fetch changes up to fefb476bc7fdda4cb1e768493128c15a896f2c4e:
ARM64: dts: marvell: armada-cp110: Fix clock resources for various node (2018-01-05 16:04:53 +0100)
----------------------------------------------------------------
mvebu fixess for 4.15 (part 1)
2 device tree related fixes fixing 2 issues:
- broken pinctrl support since 4.11 on OpenBlocks A7
- implicit clock dependency making the kernel hang if the Xenon sdhci
module was loaded before the mvpp2 Ethernet support (for this one
the driver had to be fixed which was done in v4.14)
----------------------------------------------------------------
Gregory CLEMENT (1):
ARM64: dts: marvell: armada-cp110: Fix clock resources for various node
Thomas Petazzoni (1):
ARM: dts: kirkwood: fix pin-muxing of MPP7 on OpenBlocks A7
arch/arm/boot/dts/kirkwood-openblocks_a7.dts | 10 ++++++++--
arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi | 13 ++++++++-----
arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi | 9 ++++++---
3 files changed, 22 insertions(+), 10 deletions(-)
^ permalink raw reply
* [PATCH] ARM64: dts: marvell: armada-cp110: Fix clock resources for various node
From: Gregory CLEMENT @ 2018-01-05 15:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180105153055.12232-1-gregory.clement@free-electrons.com>
Hi,
On ven., janv. 05 2018, Gregory CLEMENT <gregory.clement@free-electrons.com> wrote:
> On the CP modules we found on Armada 7K/8K, many IP block actually also
> need a "logical" clock (from the bus). This patch add them which allows
> to fix some issues hanging the kernel:
>
> If Ethernet and sdhci driver are built as modules and sdhci was loaded
> first then the kernel hang.
>
> Fixes: bb16ea1742c8 ("mmc: sdhci-xenon: Fix clock resource by adding an
> optional bus clock")
> Cc: stable at vger.kernel.org
> Reported-by: Riku Voipio <riku.voipio@linaro.org>
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Applied on mvebu/fixes
Gregory
> ---
> arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi | 13 ++++++++-----
> arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi | 9 ++++++---
> 2 files changed, 14 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi b/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi
> index e3b64d03fbd8..9c7724e82aff 100644
> --- a/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi
> +++ b/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi
> @@ -63,8 +63,10 @@
> cpm_ethernet: ethernet at 0 {
> compatible = "marvell,armada-7k-pp22";
> reg = <0x0 0x100000>, <0x129000 0xb000>;
> - clocks = <&cpm_clk 1 3>, <&cpm_clk 1 9>, <&cpm_clk 1 5>;
> - clock-names = "pp_clk", "gop_clk", "mg_clk";
> + clocks = <&cpm_clk 1 3>, <&cpm_clk 1 9>,
> + <&cpm_clk 1 5>, <&cpm_clk 1 18>;
> + clock-names = "pp_clk", "gop_clk",
> + "mg_clk","axi_clk";
> marvell,system-controller = <&cpm_syscon0>;
> status = "disabled";
> dma-coherent;
> @@ -155,7 +157,8 @@
> #size-cells = <0>;
> compatible = "marvell,orion-mdio";
> reg = <0x12a200 0x10>;
> - clocks = <&cpm_clk 1 9>, <&cpm_clk 1 5>;
> + clocks = <&cpm_clk 1 9>, <&cpm_clk 1 5>,
> + <&cpm_clk 1 6>, <&cpm_clk 1 18>;
> status = "disabled";
> };
>
> @@ -338,8 +341,8 @@
> compatible = "marvell,armada-cp110-sdhci";
> reg = <0x780000 0x300>;
> interrupts = <ICU_GRP_NSR 27 IRQ_TYPE_LEVEL_HIGH>;
> - clock-names = "core";
> - clocks = <&cpm_clk 1 4>;
> + clock-names = "core","axi";
> + clocks = <&cpm_clk 1 4>, <&cpm_clk 1 18>;
> dma-coherent;
> status = "disabled";
> };
> diff --git a/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi b/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
> index 0d51096c69f8..87ac68b2cf37 100644
> --- a/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
> +++ b/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
> @@ -63,8 +63,10 @@
> cps_ethernet: ethernet at 0 {
> compatible = "marvell,armada-7k-pp22";
> reg = <0x0 0x100000>, <0x129000 0xb000>;
> - clocks = <&cps_clk 1 3>, <&cps_clk 1 9>, <&cps_clk 1 5>;
> - clock-names = "pp_clk", "gop_clk", "mg_clk";
> + clocks = <&cps_clk 1 3>, <&cps_clk 1 9>,
> + <&cps_clk 1 5>, <&cps_clk 1 18>;
> + clock-names = "pp_clk", "gop_clk",
> + "mg_clk", "axi_clk";
> marvell,system-controller = <&cps_syscon0>;
> status = "disabled";
> dma-coherent;
> @@ -155,7 +157,8 @@
> #size-cells = <0>;
> compatible = "marvell,orion-mdio";
> reg = <0x12a200 0x10>;
> - clocks = <&cps_clk 1 9>, <&cps_clk 1 5>;
> + clocks = <&cps_clk 1 9>, <&cps_clk 1 5>,
> + <&cps_clk 1 6>, <&cps_clk 1 18>;
> status = "disabled";
> };
>
> --
> 2.15.1
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH v3 2/2] dt-bindings: mailbox: Add Xilinx IPI Mailbox
From: Rob Herring @ 2018-01-05 15:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515109891-17133-3-git-send-email-jliang@xilinx.com>
On Thu, Jan 04, 2018 at 03:51:31PM -0800, Wendy Liang wrote:
> Xilinx ZynqMP IPI(Inter Processor Interrupt) is a hardware block
> in ZynqMP SoC used for the communication between various processor
> systems.
>
> Signed-off-by: Wendy Liang <jliang@xilinx.com>
> ---
> .../bindings/mailbox/xlnx,zynqmp-ipi-mailbox.txt | 104 +++++++++++++++++++++
> 1 file changed, 104 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mailbox/xlnx,zynqmp-ipi-mailbox.txt
Please add acks and reviewed-by's when posting new versions.
^ permalink raw reply
* [PATCH] ARM64: dts: marvell: armada-cp110: Fix clock resources for various node
From: Gregory CLEMENT @ 2018-01-05 15:30 UTC (permalink / raw)
To: linux-arm-kernel
On the CP modules we found on Armada 7K/8K, many IP block actually also
need a "logical" clock (from the bus). This patch add them which allows
to fix some issues hanging the kernel:
If Ethernet and sdhci driver are built as modules and sdhci was loaded
first then the kernel hang.
Fixes: bb16ea1742c8 ("mmc: sdhci-xenon: Fix clock resource by adding an
optional bus clock")
Cc: stable at vger.kernel.org
Reported-by: Riku Voipio <riku.voipio@linaro.org>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi | 13 ++++++++-----
arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi | 9 ++++++---
2 files changed, 14 insertions(+), 8 deletions(-)
diff --git a/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi b/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi
index e3b64d03fbd8..9c7724e82aff 100644
--- a/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi
@@ -63,8 +63,10 @@
cpm_ethernet: ethernet at 0 {
compatible = "marvell,armada-7k-pp22";
reg = <0x0 0x100000>, <0x129000 0xb000>;
- clocks = <&cpm_clk 1 3>, <&cpm_clk 1 9>, <&cpm_clk 1 5>;
- clock-names = "pp_clk", "gop_clk", "mg_clk";
+ clocks = <&cpm_clk 1 3>, <&cpm_clk 1 9>,
+ <&cpm_clk 1 5>, <&cpm_clk 1 18>;
+ clock-names = "pp_clk", "gop_clk",
+ "mg_clk","axi_clk";
marvell,system-controller = <&cpm_syscon0>;
status = "disabled";
dma-coherent;
@@ -155,7 +157,8 @@
#size-cells = <0>;
compatible = "marvell,orion-mdio";
reg = <0x12a200 0x10>;
- clocks = <&cpm_clk 1 9>, <&cpm_clk 1 5>;
+ clocks = <&cpm_clk 1 9>, <&cpm_clk 1 5>,
+ <&cpm_clk 1 6>, <&cpm_clk 1 18>;
status = "disabled";
};
@@ -338,8 +341,8 @@
compatible = "marvell,armada-cp110-sdhci";
reg = <0x780000 0x300>;
interrupts = <ICU_GRP_NSR 27 IRQ_TYPE_LEVEL_HIGH>;
- clock-names = "core";
- clocks = <&cpm_clk 1 4>;
+ clock-names = "core","axi";
+ clocks = <&cpm_clk 1 4>, <&cpm_clk 1 18>;
dma-coherent;
status = "disabled";
};
diff --git a/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi b/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
index 0d51096c69f8..87ac68b2cf37 100644
--- a/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
@@ -63,8 +63,10 @@
cps_ethernet: ethernet at 0 {
compatible = "marvell,armada-7k-pp22";
reg = <0x0 0x100000>, <0x129000 0xb000>;
- clocks = <&cps_clk 1 3>, <&cps_clk 1 9>, <&cps_clk 1 5>;
- clock-names = "pp_clk", "gop_clk", "mg_clk";
+ clocks = <&cps_clk 1 3>, <&cps_clk 1 9>,
+ <&cps_clk 1 5>, <&cps_clk 1 18>;
+ clock-names = "pp_clk", "gop_clk",
+ "mg_clk", "axi_clk";
marvell,system-controller = <&cps_syscon0>;
status = "disabled";
dma-coherent;
@@ -155,7 +157,8 @@
#size-cells = <0>;
compatible = "marvell,orion-mdio";
reg = <0x12a200 0x10>;
- clocks = <&cps_clk 1 9>, <&cps_clk 1 5>;
+ clocks = <&cps_clk 1 9>, <&cps_clk 1 5>,
+ <&cps_clk 1 6>, <&cps_clk 1 18>;
status = "disabled";
};
--
2.15.1
^ permalink raw reply related
* [PATCH 1/7] arm64: dts: marvell: use SPDX-License-Identifier for Armada SoCs
From: Andrew Lunn @ 2018-01-05 15:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87r2r49wxw.fsf@free-electrons.com>
On Fri, Jan 05, 2018 at 03:55:55PM +0100, Gregory CLEMENT wrote:
> Hi Andrew,
>
> On ven., janv. 05 2018, Andrew Lunn <andrew@lunn.ch> wrote:
>
> >> > The previous license was GPL-2.0+ or X11, not GPL-2.0+ or MIT. Any
> >> > reason to change from X11 to MIT ?
> >>
> >> As explained in the commit log:
> >> " the X11 license text [1] is explicitly for the X Consortium and has a
> >> couple of extra clauses. The MIT license text [2] is actually what the
> >> current DT files claim."
> >>
> >> Also as I wrote it was already discussed on the mainling lists (device
> >> tree one and LAKML) see:
> >> http://lists.infradead.org/pipermail/linux-arm-kernel/2017-February/489922.html
> >
> > Hi Gregory
> >
> > If i remember correctly, there was a reason for X11 over MIT. I think
> > Russell King looked into this. Maybe you can find the discussion on
> > the mailing list?
Hi Gregory
I'm meaning an older discussion, when we first started using dual
license. There was some discussion back then as to MIT vs X11.
That discussion could be relevant here.
What we need to be careful of is ensuring the changes you are making
here don't actually change the licenses. If the intent was to use
X11, and we actually state "X11 license" in the source code, we need
to be careful if we replace that with MIT.
Andrew
^ permalink raw reply
* [PATCH v3 0/6] arm: sunxi: IR support for A83T
From: Maxime Ripard @ 2018-01-05 14:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180105120253.zvwaz25scuk76bnt@gofer.mess.org>
Hi,
On Fri, Jan 05, 2018 at 12:02:53PM +0000, Sean Young wrote:
> On Tue, Dec 19, 2017 at 09:07:41AM +0100, Philipp Rossak wrote:
> > This patch series adds support for the sunxi A83T ir module and enhances
> > the sunxi-ir driver. Right now the base clock frequency for the ir driver
> > is a hard coded define and is set to 8 MHz.
> > This works for the most common ir receivers. On the Sinovoip Bananapi M3
> > the ir receiver needs, a 3 MHz base clock frequency to work without
> > problems with this driver.
> >
> > This patch series adds support for an optinal property that makes it able
> > to override the default base clock frequency and enables the ir interface
> > on the a83t and the Bananapi M3.
> >
> > changes since v2:
> > * reorder cir pin (alphabetical)
> > * fix typo in documentation
> >
> > changes since v1:
> > * fix typos, reword Documentation
> > * initialize 'b_clk_freq' to 'SUNXI_IR_BASE_CLK' & remove if statement
> > * change dev_info() to dev_dbg()
> > * change naming to cir* in dts/dtsi
> > * Added acked Ackedi-by to related patch
> > * use whole memory block instead of registers needed + fix for h3/h5
> >
> > changes since rfc:
> > * The property is now optinal. If the property is not available in
> > the dtb the driver uses the default base clock frequency.
> > * the driver prints out the the selected base clock frequency.
> > * changed devicetree property from base-clk-frequency to clock-frequency
> >
> > Regards,
> > Philipp
> >
> >
> > Philipp Rossak (6):
> > media: rc: update sunxi-ir driver to get base clock frequency from
> > devicetree
> > media: dt: bindings: Update binding documentation for sunxi IR
> > controller
> > arm: dts: sun8i: a83t: Add the cir pin for the A83T
> > arm: dts: sun8i: a83t: Add support for the cir interface
> > arm: dts: sun8i: a83t: bananapi-m3: Enable IR controller
> > arm: dts: sun8i: h3-h8: ir register size should be the whole memory
> > block
>
> I can take this series (through rc-core, i.e. linux-media), but I need an
> maintainer Acked-by: for the sun[x8]i dts changes (all four patches).
We'll merge them through our tree. We usually have a rather big number
of patches around, so we'd be better off avoiding conflicts :)
Philipp, can you resubmit the DTs as soon as -rc1 is out?
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180105/72beeaab/attachment.sig>
^ permalink raw reply
* [GIT PULL] TI DaVinci SoC support updates for v4.16
From: Sekhar Nori @ 2018-01-05 14:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180105070904.ckixnqva6qkbaukc@localhost>
Hi Olof,
On Friday 05 January 2018 12:39 PM, Olof Johansson wrote:
> On Sat, Dec 23, 2017 at 09:21:31PM +0530, Sekhar Nori wrote:
>> The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:
>>
>> Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)
>>
>> are available in the git repository at:
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git tags/davinci-for-v4.16/soc
>>
>> for you to fetch changes up to ed3c0c2b4fdcbe05194ee3f5e634ece3018d3b76:
>>
>> ARM: dts: da850-lcdk: Remove leading 0x and 0s from unit address (2017-12-23 15:46:25 +0530)
>>
>> ----------------------------------------------------------------
>> DaVinci SoC updates consisting of non-critical bug fixes including constifying
>> data structures, DT warning fixes for W=1 and code simplification.
>>
>> Also a defconfig update for DaVinci, enabling support for USB network adaptors.
>
> Hi,
>
> We usually don't mix DT and other updates (and sometimes we keep defconfig
> updates separate from SoC ones, but that's not needed here).
>
> Can you respin with DT separate? Feel free to just send-email the patch to us,
> or send a pull request with it if you prefer.
I sent a v2 pull request. I had two more patches that were ready to be
queued for which I was planning on sending another pull request anyway.
I added those in the v2.
Thanks,
Sekhar
^ permalink raw reply
* [PATCH v2 11/11] arm64: Implement branch predictor hardening for affected Cortex-A CPUs
From: Marc Zyngier @ 2018-01-05 14:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5A4F8FCD.3000903@arm.com>
On 05/01/18 14:46, James Morse wrote:
> Hi Marc, Will,
>
> (SOB-chain suggests a missing From: tag on this and patch 7)
>
> On 05/01/18 13:12, Will Deacon wrote:
>> Cortex-A57, A72, A73 and A75 are susceptible to branch predictor aliasing
>> and can theoretically be attacked by malicious code.
>>
>> This patch implements a PSCI-based mitigation for these CPUs when available.
>> The call into firmware will invalidate the branch predictor state, preventing
>> any malicious entries from affecting other victim contexts.
>>
>> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
>> Signed-off-by: Will Deacon <will.deacon@arm.com>
>
>> diff --git a/arch/arm64/kernel/bpi.S b/arch/arm64/kernel/bpi.S
>> index 06a931eb2673..2e9146534174 100644
>> --- a/arch/arm64/kernel/bpi.S
>> +++ b/arch/arm64/kernel/bpi.S
>> @@ -53,3 +53,27 @@ ENTRY(__bp_harden_hyp_vecs_start)
>> vectors __kvm_hyp_vector
>> .endr
>> ENTRY(__bp_harden_hyp_vecs_end)
>> +ENTRY(__psci_hyp_bp_inval_start)
>
>> + sub sp, sp, #(8 * 18)
>
> Where does 18 come from? Isn't this storing 9 sets of 16 bytes?
Or 18 registers of 8 bytes each.
>
>> + stp x16, x17, [sp, #(16 * 0)]
>> + stp x14, x15, [sp, #(16 * 1)]
>> + stp x12, x13, [sp, #(16 * 2)]
>> + stp x10, x11, [sp, #(16 * 3)]
>> + stp x8, x9, [sp, #(16 * 4)]
>> + stp x6, x7, [sp, #(16 * 5)]
>> + stp x4, x5, [sp, #(16 * 6)]
>> + stp x2, x3, [sp, #(16 * 7)]
>
>> + stp x0, x1, [sp, #(18 * 8)]
>
> 16->18 typo?
/me bashes head against keyboard, as this is likely to generate less
crap then me trying to write something half correct...
The fun part is that the Seattle box I booted yesterday with that crap
is still happily churning along. I guess I'm corrupting something that
really doesn't matter...
>
>
>> + mov x0, #0x84000000
>> + smc #0
>> + ldp x16, x17, [sp, #(16 * 0)]
>> + ldp x14, x15, [sp, #(16 * 1)]
>> + ldp x12, x13, [sp, #(16 * 2)]
>> + ldp x10, x11, [sp, #(16 * 3)]
>> + ldp x8, x9, [sp, #(16 * 4)]
>> + ldp x6, x7, [sp, #(16 * 5)]
>> + ldp x4, x5, [sp, #(16 * 6)]
>> + ldp x2, x3, [sp, #(16 * 7)]
>
>> + ldp x0, x1, [sp, #(18 * 8)]
>> + add sp, sp, #(8 * 18)
>
> (and here?)
Yup.
Thanks for pointing that out. I'll fetch a brown paper bag.
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH 00/13] replace print_symbol() with printk()-s
From: Sergey Senozhatsky @ 2018-01-05 14:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180105144239.i3pc6npgmoi4ddln@pathway.suse.cz>
On (01/05/18 15:42), Petr Mladek wrote:
[..]
> > oh, one more thing. one extra patch, which gets rid of
> > print_symbol()/__print_symbol().
>
> I am all for it. But I would postpone this removal to 4.17.
> The reason is rather ugly. 13th patch is already in arc tree.
> We would need to shuffle the patch or coordinate pull requests.
> I think that it is not worth it. There is no real hurry.
> I doubt that the would be any new user in the meantime.
>
> Best Regards,
> Petr
>
> PS: I have just pushed 12 patches into printk.git for-4.16 branch.
> I will merge this to linux-next branch on Monday. I will not
> be around the computer over the weekend...
OK. thanks!
-ss
^ permalink raw reply
* [PATCH 1/7] arm64: dts: marvell: use SPDX-License-Identifier for Armada SoCs
From: Gregory CLEMENT @ 2018-01-05 14:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180105143820.GB4038@lunn.ch>
Hi Andrew,
On ven., janv. 05 2018, Andrew Lunn <andrew@lunn.ch> wrote:
>> > The previous license was GPL-2.0+ or X11, not GPL-2.0+ or MIT. Any
>> > reason to change from X11 to MIT ?
>>
>> As explained in the commit log:
>> " the X11 license text [1] is explicitly for the X Consortium and has a
>> couple of extra clauses. The MIT license text [2] is actually what the
>> current DT files claim."
>>
>> Also as I wrote it was already discussed on the mainling lists (device
>> tree one and LAKML) see:
>> http://lists.infradead.org/pipermail/linux-arm-kernel/2017-February/489922.html
>
> Hi Gregory
>
> If i remember correctly, there was a reason for X11 over MIT. I think
> Russell King looked into this. Maybe you can find the discussion on
> the mailing list?
The point from Russell King was that "MIT license" was ambiguous. But
the text of the license we used was exactly the one named as MIT in
SPDX. That's the reason why using the MIT key word for SPDX would be the
wright things to do.
Note also that Here [1], Russell already gave his opinion about it. In
the thread the complain was more about the spdx itself that the
name of the license. And his main concerned was about not having the
license text available. But it should be resolved because all the
license text will be part of the kernel sources [2].
Thanks,
Gregory
[1]:
http://lists.infradead.org/pipermail/linux-arm-kernel/2017-February/490649.html
[2]:
https://lkml.org/lkml/2017/12/4/935
>
> Andrew
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [GIT PULL v2 2/2] TI DaVinci DT updates for v4.16
From: Sekhar Nori @ 2018-01-05 14:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180105145248.1994-1-nsekhar@ti.com>
The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:
Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git tags/davinci-for-v4.16/dt
for you to fetch changes up to 7669b122085018c1f64720d11c24ae6d2549193d:
ARM: dts: da850-lcdk: Remove leading 0x and 0s from unit address (2018-01-05 19:21:21 +0530)
----------------------------------------------------------------
A DT warning fix for W=1 warning message.
----------------------------------------------------------------
Mathieu Malaterre (1):
ARM: dts: da850-lcdk: Remove leading 0x and 0s from unit address
arch/arm/boot/dts/da850-lcdk.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
^ permalink raw reply
* [GIT PULL v2 1/2] TI DaVinci SoC support updates for v4.16
From: Sekhar Nori @ 2018-01-05 14:52 UTC (permalink / raw)
To: linux-arm-kernel
The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:
Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git tags/davinci-for-v4.16/soc-v2
for you to fetch changes up to 23bbeaef90ab7607d03428bbb708efe44f43c761:
ARM: davinci: constify gpio_led (2018-01-05 19:28:41 +0530)
----------------------------------------------------------------
DaVinci SoC updates consisting of non-critical bug fixes including constifying
data structures, removal of unnecessary newlines from gpio labels and code
simplification.
Also a defconfig update for DaVinci, enabling support for USB network adaptors.
----------------------------------------------------------------
Aparna Balasubramanian (1):
ARM: davinci_all_defconfig: enable support for USB network adaptors
Arvind Yadav (1):
ARM: davinci: constify gpio_led
Bhumika Goyal (2):
ARM: davinci: make argument to davinci_common_init() as const
ARM: davinci: make davinci_soc_info structures const
Julia Lawall (1):
ARM: davinci: drop unneeded newline
Vasyl Gomonovych (1):
ARM: davinci: Use PTR_ERR_OR_ZERO()
arch/arm/configs/davinci_all_defconfig | 1 +
arch/arm/mach-davinci/board-da850-evm.c | 4 ++--
arch/arm/mach-davinci/board-neuros-osd2.c | 2 +-
arch/arm/mach-davinci/common.c | 2 +-
arch/arm/mach-davinci/da830.c | 2 +-
arch/arm/mach-davinci/da850.c | 2 +-
arch/arm/mach-davinci/devices-da8xx.c | 4 ++--
arch/arm/mach-davinci/dm355.c | 2 +-
arch/arm/mach-davinci/dm365.c | 2 +-
arch/arm/mach-davinci/dm644x.c | 2 +-
arch/arm/mach-davinci/dm646x.c | 4 ++--
arch/arm/mach-davinci/include/mach/common.h | 2 +-
12 files changed, 15 insertions(+), 14 deletions(-)
^ permalink raw reply
* [PATCH v2 11/11] arm64: Implement branch predictor hardening for affected Cortex-A CPUs
From: James Morse @ 2018-01-05 14:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515157961-20963-12-git-send-email-will.deacon@arm.com>
Hi Marc, Will,
(SOB-chain suggests a missing From: tag on this and patch 7)
On 05/01/18 13:12, Will Deacon wrote:
> Cortex-A57, A72, A73 and A75 are susceptible to branch predictor aliasing
> and can theoretically be attacked by malicious code.
>
> This patch implements a PSCI-based mitigation for these CPUs when available.
> The call into firmware will invalidate the branch predictor state, preventing
> any malicious entries from affecting other victim contexts.
>
> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
> Signed-off-by: Will Deacon <will.deacon@arm.com>
> diff --git a/arch/arm64/kernel/bpi.S b/arch/arm64/kernel/bpi.S
> index 06a931eb2673..2e9146534174 100644
> --- a/arch/arm64/kernel/bpi.S
> +++ b/arch/arm64/kernel/bpi.S
> @@ -53,3 +53,27 @@ ENTRY(__bp_harden_hyp_vecs_start)
> vectors __kvm_hyp_vector
> .endr
> ENTRY(__bp_harden_hyp_vecs_end)
> +ENTRY(__psci_hyp_bp_inval_start)
> + sub sp, sp, #(8 * 18)
Where does 18 come from? Isn't this storing 9 sets of 16 bytes?
> + stp x16, x17, [sp, #(16 * 0)]
> + stp x14, x15, [sp, #(16 * 1)]
> + stp x12, x13, [sp, #(16 * 2)]
> + stp x10, x11, [sp, #(16 * 3)]
> + stp x8, x9, [sp, #(16 * 4)]
> + stp x6, x7, [sp, #(16 * 5)]
> + stp x4, x5, [sp, #(16 * 6)]
> + stp x2, x3, [sp, #(16 * 7)]
> + stp x0, x1, [sp, #(18 * 8)]
16->18 typo?
> + mov x0, #0x84000000
> + smc #0
> + ldp x16, x17, [sp, #(16 * 0)]
> + ldp x14, x15, [sp, #(16 * 1)]
> + ldp x12, x13, [sp, #(16 * 2)]
> + ldp x10, x11, [sp, #(16 * 3)]
> + ldp x8, x9, [sp, #(16 * 4)]
> + ldp x6, x7, [sp, #(16 * 5)]
> + ldp x4, x5, [sp, #(16 * 6)]
> + ldp x2, x3, [sp, #(16 * 7)]
> + ldp x0, x1, [sp, #(18 * 8)]
> + add sp, sp, #(8 * 18)
(and here?)
> +ENTRY(__psci_hyp_bp_inval_end)
Thanks,
James
^ permalink raw reply
* [PATCH 00/13] replace print_symbol() with printk()-s
From: Petr Mladek @ 2018-01-05 14:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180105102538.GC471@jagdpanzerIV>
On Fri 2018-01-05 19:25:38, Sergey Senozhatsky wrote:
> On (01/05/18 19:21), Sergey Senozhatsky wrote:
> > On (01/05/18 11:03), Petr Mladek wrote:
> > [..]
> > > Anyway, print_symbol() is an old weird API and it would be nice
> > > to eventually get rid of it. I could take this patches into
> > > printk.git.
> >
> > no objections from my side if the patch set will go through the printk tree.
> > shall we wait for ACKs or can we move on? do you plan to land it in 4.16?
> >
> > > Would you mind if I change the commit messages to something like?:
> > >
> > > print_symbol() is an old weird API. It has been
> > > obsoleted by printk() and %pS format specifier.
> >
> > I wouldn't. let's drop the "weird" part. other than that looks
> > good to me.
>
> oh, one more thing. one extra patch, which gets rid of
> print_symbol()/__print_symbol().
I am all for it. But I would postpone this removal to 4.17.
The reason is rather ugly. 13th patch is already in arc tree.
We would need to shuffle the patch or coordinate pull requests.
I think that it is not worth it. There is no real hurry.
I doubt that the would be any new user in the meantime.
Best Regards,
Petr
PS: I have just pushed 12 patches into printk.git for-4.16 branch.
I will merge this to linux-next branch on Monday. I will not
be around the computer over the weekend...
^ permalink raw reply
* [PATCH 1/7] arm64: dts: marvell: use SPDX-License-Identifier for Armada SoCs
From: Andrew Lunn @ 2018-01-05 14:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87vagga2nd.fsf@free-electrons.com>
> > The previous license was GPL-2.0+ or X11, not GPL-2.0+ or MIT. Any
> > reason to change from X11 to MIT ?
>
> As explained in the commit log:
> " the X11 license text [1] is explicitly for the X Consortium and has a
> couple of extra clauses. The MIT license text [2] is actually what the
> current DT files claim."
>
> Also as I wrote it was already discussed on the mainling lists (device
> tree one and LAKML) see:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2017-February/489922.html
Hi Gregory
If i remember correctly, there was a reason for X11 over MIT. I think
Russell King looked into this. Maybe you can find the discussion on
the mailing list?
Andrew
^ 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