* [PATCH v2 1/2] phy: rockchip-inno-usb2: correct clk_ops callback
From: Doug Anderson @ 2016-11-14 18:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479106911-16049-2-git-send-email-wulf@rock-chips.com>
William
On Sun, Nov 13, 2016 at 11:01 PM, William Wu <wulf@rock-chips.com> wrote:
> Since we needs to delay ~1ms to wait for 480MHz output clock
> of USB2 PHY to become stable after turn on it, the delay time
> is pretty long for something that's supposed to be "atomic"
> like a clk_enable(). Consider that clk_enable() will disable
> interrupt and that a 1ms interrupt latency is not sensible.
>
> The 480MHz output clock should be handled in prepare callbacks
> which support gate a clk if the operation may sleep.
>
> Signed-off-by: William Wu <wulf@rock-chips.com>
> ---
> drivers/phy/phy-rockchip-inno-usb2.c | 12 ++++++------
> 1 file changed, 6 insertions(+), 6 deletions(-)
Reviewed-by: Douglas Anderson <dianders@chromium.org>
^ permalink raw reply
* [PATCH v3 2/2] phy: rockchip-inno-usb2: correct 480MHz output clock stable time
From: Doug Anderson @ 2016-11-14 18:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479115631-20137-3-git-send-email-wulf@rock-chips.com>
William,
On Mon, Nov 14, 2016 at 1:27 AM, William Wu <wulf@rock-chips.com> wrote:
> We found that the system crashed due to 480MHz output clock of
> USB2 PHY was unstable after clock had been enabled by gpu module.
>
> Theoretically, 1 millisecond is a critical value for 480MHz
> output clock stable time, so we try to change the delay time
> to 1.2 millisecond to avoid this issue.
>
> And the commit ed907fb1d7c3 ("phy: rockchip-inno-usb2: correct
> clk_ops callback") used prepare callbacks instead of enable
> callbacks to support gate a clk if the operation may sleep. So
> we can switch from delay to sleep functions.
>
> Signed-off-by: William Wu <wulf@rock-chips.com>
> ---
> Changes in v3:
> - fix kbuild test error: too few arguments to function 'usleep_range'
>
> Changes in v2:
> - use usleep_range() function instead of mdelay()
>
> drivers/phy/phy-rockchip-inno-usb2.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/phy/phy-rockchip-inno-usb2.c b/drivers/phy/phy-rockchip-inno-usb2.c
> index 365e077..0e52b25 100644
> --- a/drivers/phy/phy-rockchip-inno-usb2.c
> +++ b/drivers/phy/phy-rockchip-inno-usb2.c
> @@ -166,7 +166,7 @@ static int rockchip_usb2phy_clk480m_prepare(struct clk_hw *hw)
> return ret;
>
> /* waitting for the clk become stable */
> - mdelay(1);
> + usleep_range(1200, 1300);
Sight nit that you could also fix the spelling from "waitting" to "waiting".
...but that's pre-existing, so:
Reviewed-by: Douglas Anderson <dianders@chromium.org>
^ permalink raw reply
* [PATCHv2 5/6] arm64: Use __pa_symbol for _end
From: Catalin Marinas @ 2016-11-14 18:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161103155106.GF25852@remoulade>
On Thu, Nov 03, 2016 at 03:51:07PM +0000, Mark Rutland wrote:
> On Wed, Nov 02, 2016 at 05:56:42PM -0600, Laura Abbott wrote:
> > On 11/02/2016 04:52 PM, Mark Rutland wrote:
> > >On Wed, Nov 02, 2016 at 03:00:53PM -0600, Laura Abbott wrote:
> > >>
> > >>__pa_symbol is technically the marco that should be used for kernel
> > >>symbols. Switch to this as a pre-requisite for DEBUG_VIRTUAL.
> > >
> > >Nit: s/marco/macro/
> > >
> > >I see there are some other uses of __pa() that look like they could/should be
> > >__pa_symbol(), e.g. in mark_rodata_ro().
> > >
> > >I guess strictly speaking those need to be updated to? Or is there a reason
> > >that we should not?
> >
> > If the concept of __pa_symbol is okay then yes I think all uses of __pa
> > should eventually be converted for consistency and debugging.
>
> I have no strong feelings either way about __pa_symbol(); I'm not clear on what
> the purpose of __pa_symbol() is specifically, but I'm happy even if it's just
> for consistency with other architectures.
At a quick grep, it seems to only be used by mips and x86 and a single
place in mm/memblock.c.
Since we haven't seen any issues on arm/arm64 without this macro, can we
not just continue to use __pa()?
Thanks.
--
Catalin
^ permalink raw reply
* [PATCH 1/2] pinctrl: bcm2835: Fix ints for GPIOs 28-31 & 46-53
From: Eric Anholt @ 2016-11-14 18:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <427a3d44-16aa-258c-8722-48d9c7ffb593@i2se.com>
Stefan Wahren <stefan.wahren@i2se.com> writes:
> Hi Linus,
>
> Am 14.11.2016 um 13:23 schrieb Linus Walleij:
>> From: Phil Elwell <phil@raspberrypi.org>
>>
>> Contrary to the documentation, the BCM2835 GPIO controller actually
>> has four interrupt lines - one each for the three IRQ groups and one
>> common. Confusingly, the GPIO interrupt groups don't correspond
>> directly with the GPIO control banks. Instead, GPIOs 0-27 generate IRQ
>> GPIO0, 28-45 IRQ GPIO1 and 46-53 IRQ GPIO2.
>>
>> Awkwardly, the GPIOs for IRQ GPIO1 straddle two 32-entry GPIO banks,
>> so split out a function to process the interrupts for a single GPIO
>> bank.
>>
>> Cc: Stefan Wahren <stefan.wahren@i2se.com>
>> Cc: Eric Anholt <eric@anholt.net>
>> Cc: Stephen Warren <swarren@wwwdotorg.org>
>> Signed-off-by: Phil Elwell <phil@raspberrypi.org>
>> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
>> ---
>> I want to apply this to cater for my GPIOLIB_IRQCHIP
>> refactorings.
>> ---
>> drivers/pinctrl/bcm/pinctrl-bcm2835.c | 51 ++++++++++++++++++++++++++---------
>> 1 file changed, 39 insertions(+), 12 deletions(-)
>>
>> diff --git a/drivers/pinctrl/bcm/pinctrl-bcm2835.c b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
>> index b2dd278f18b1..1d8fc104e26b 100644
>> --- a/drivers/pinctrl/bcm/pinctrl-bcm2835.c
>> +++ b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
>>
> ...
>> @@ -1076,6 +1102,7 @@ static struct platform_driver bcm2835_pinctrl_driver = {
>> .remove = bcm2835_pinctrl_remove,
>> .driver = {
>> .name = MODULE_NAME,
>> + .owner = THIS_MODULE,
>
> this is unnecessary. Please remove it.
>
> Thanks for submitting these patches
With that dropped,
Acked-by: Eric Anholt <eric@anholt.net>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161114/2938bc95/attachment.sig>
^ permalink raw reply
* [PATCH 2/2] pinctrl: bcm2835: Return pins to inputs when freed
From: Eric Anholt @ 2016-11-14 18:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479126214-20529-1-git-send-email-linus.walleij@linaro.org>
Linus Walleij <linus.walleij@linaro.org> writes:
> From: Phil Elwell <phil@raspberrypi.org>
>
> When dynamically unloading overlays, it is important that freed pins are
> restored to being inputs to prevent functions from being enabled in
> multiple places at once.
>
> Cc: Stefan Wahren <stefan.wahren@i2se.com>
> Cc: Eric Anholt <eric@anholt.net>
> Cc: Stephen Warren <swarren@wwwdotorg.org>
> Signed-off-by: Phil Elwell <phil@raspberrypi.org>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Eric Anholt <eric@anholt.net>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161114/9b3ddd85/attachment-0001.sig>
^ permalink raw reply
* [PATCH v7 04/16] drivers: iommu: make of_iommu_set/get_ops() DT agnostic
From: Robin Murphy @ 2016-11-14 18:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161114155222.GZ2078@8bytes.org>
On 14/11/16 15:52, Joerg Roedel wrote:
> On Mon, Nov 14, 2016 at 12:00:47PM +0000, Robin Murphy wrote:
>> If we've already made the decision to move away from bus ops, I don't
>> see that it makes sense to deliberately introduce new dependencies on
>> them. Besides, as it stands, this patch literally implements "tell the
>> iommu-core which hardware-iommus exist in the system and a seperate
>> iommu_ops ptr for each of them" straight off.
>
> Not sure which code you are looking at, but as I see it we have only
> per-device iommu-ops now (with this patch). That is different from
> having core-visible hardware-iommu instances where devices could link
> to.
The per-device IOMMU ops are already there since 57f98d2f61e1. This
patch generalises the other end, moving the "registering an IOMMU
instance" (i.e. iommu_fwentry) bit into the IOMMU core, from being
OF-specific. I'd be perfectly happy if we rename iommu_fwentry to
iommu_instance, fwnode_iommu_set_ops() to iommu_register_instance(), and
such if that makes the design intent clearer.
If you'd also prefer to replace iommu_fwspec::ops with an opaque
iommu_fwspec::iommu_instance pointer so that things are a bit more
centralised (and users are forced to go through the API rather then call
ops directly), I'd have no major objection either. My main point is that
we've been deliberately putting the relevant building blocks in place -
the of_iommu_{get,set}_ops stuff was designed from the start to
accommodate per-instance ops, via the ops pointer *being* the instance
token; the iommu_fwspec stuff is deliberately intended to provide
per-device ops on top of that. The raw functionality is either there in
iommu.c already, or moving there in patches already written, so if it
doesn't look right all we need to focus on is making it look right.
> Also the rest of iommu-core code still makes use of the per-bus ops. The
> per-device ops are only used for the of_xlate fn-ptr.
Hence my aforementioned patches intended for 4.10, directly following on
from introducing iommu_fwspec in 4.9:
http://www.mail-archive.com/iommu at lists.linux-foundation.org/msg14576.html
...the purpose being to provide a smooth transition from per-bus ops to
per-device, per-instance ops. Apply those and we're 90% of the way there
for OF-based IOMMU drivers (not that any of those actually need
per-instance ops, admittedly; I did prototype it for the ARM SMMU ages
ago, but it didn't seem worth the bother). Lorenzo's series broadens the
scope to ACPI-based systems and moves the generically-useful parts into
the core where we can easily build on them further if necessary. The
major remaining work is to convert external callers of the current
bus-dependent functions like iommu_domain_alloc(), iommu_present(), etc.
to device-based alternatives.
Robin.
^ permalink raw reply
* [PATCH] ARM: Drop fixed 200 Hz timer requirement from Exynos platforms
From: Krzysztof Kozlowski @ 2016-11-14 18:27 UTC (permalink / raw)
To: linux-arm-kernel
All Samsung platforms, including the Exynos, are selecting HZ_FIXED with
200 Hz. Unfortunately in case of multiplatform image this affects also
other platforms when Exynos is selected.
This looks like an very old legacy code, dating back to initial
upstreaming of S3C24xx. Probably it was required for s3c24xx timer
driver, which was removed in commit ad38bdd15d5b ("ARM: SAMSUNG: Remove
unused plat-samsung/time.c").
Since then, this fixed 200 Hz spread everywhere, including out-of-tree
Samsung kernels (SoC vendor's and Tizen's). I believe this choice
was rather an effect of coincidence instead of conscious choice. In
fact Exynos can work with different timers.
Few perf mem and sched tests on Odroid XU3 board (Exynos5422, 4x Cortex
A7, 4x Cortex A15) show no regressions when switching from 200 Hz to
other values.
Reported-by: Lee Jones <lee.jones@linaro.org>
Reported-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
Testing on other Exynos platforms would be appreciated.
---
arch/arm/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index b5d529fdffab..0d10e45f9175 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1497,7 +1497,7 @@ source kernel/Kconfig.preempt
config HZ_FIXED
int
default 200 if ARCH_EBSA110 || ARCH_S3C24XX || \
- ARCH_S5PV210 || ARCH_EXYNOS4
+ ARCH_S5PV210
default 128 if SOC_AT91RM9200
default 0
--
2.7.4
^ permalink raw reply related
* [PATCH v2] staging: vc04_services: rework ioctl code path
From: Michael Zoran @ 2016-11-14 18:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161111134646.GI28701@mwanda>
On Mon, 2016-11-14 at 12:48 +0300, Dan Carpenter wrote:
> On Thu, Nov 10, 2016 at 10:15:31PM -0800, Michael Zoran wrote:
> > +static void *
> > +vchiq_ioctl_kmalloc(struct vchiq_ioctl_call_context *ctxt, size_t
> > size)
> > +{
> > + void *mem;
> > +
> > + if (!ctxt->stackmem_used && size < sizeof(ctxt->stackmem))
> > {
> > + ctxt->stackmem_used = true;
> > + return ctxt->stackmem;
> > + }
> > +
> > + mem = kmalloc(size + sizeof(void *), GFP_KERNEL);
>
> This is a potential integer overflow leading to corruption.??I don't
> understand why we need this complicated memory management anyway...
>
You could be right. This patch was very large and it hasn't received
the review that it probably should get. Also the checkpatch.pl
utility is complaining about obsolete kernel functionality that the old
code had and I really don't have the time to redo.
Perhaps the entire patch should be removed from consideration until I
can possibly work out a V3?
> > + if (!mem)
> > + return NULL;
> > +
> > + *(void **)mem = ctxt->prev_kmalloc;
> > + ctxt->prev_kmalloc = mem;
> > +
> > + return mem + sizeof(void *);
> > +}
>
> regards,
> dan carpenter
^ permalink raw reply
* [PATCH] ARM64: dts: meson-gxbb-vega-s95: Add SD/SDIO/MMC and PWM nodes
From: Kevin Hilman @ 2016-11-14 18:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161112130719.24995-1-martin.blumenstingl@googlemail.com>
Martin Blumenstingl <martin.blumenstingl@googlemail.com> writes:
> All boards from the Tronsmart Vega S95 series are sharing similar MMC
> based hardware.
> sd_emmc_a is used to connect a Broadcom based SDIO wifi card (supported
> by the brcmfmac driver). The 32.768KHz LPO clock for the wifi chip is
> generated by PWM_E.
> sd_emmc_b is routed to the SD-card. Unlike p20x there is no GPIO
> regulator, meaning it only supports 3.3V (which seems to be hard-wired).
> The eMMC chip is connected to sd_emmc_c and is implemented similar to
> the meson-gxbb-p20x boards (meaning that hard-wired fixed regulators
> are used).
>
> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Applied to v4.10/dt64.
Kevin
^ permalink raw reply
* [GIT PULL] arm: mediatek: dts changes for v4.10
From: Matthias Brugger @ 2016-11-14 18:36 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd and Olof,
although late, please pull the following changes.
Thanks,
Matthias
---
The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
are available in the git repository at:
https://github.com/mbgg/linux-mediatek.git tags/v4.9-next-dts
for you to fetch changes up to 28d6e3647bd7c869bfc251f9a7e283d78cef5fc5:
arm: dts: mt2701: Use real clock for UARTs (2016-11-11 15:25:09 +0100)
----------------------------------------------------------------
- Add bindings for mtk-scpsys for mt2701
- Add clocks for auxadc on mt8173-evb
- Add nodes needed by clock controller for mt2701
- Use clocks from the clock controller for the uart of mt2701
----------------------------------------------------------------
Erin Lo (1):
arm: dts: mt2701: Use real clock for UARTs
James Liao (1):
arm: dts: mt2701: Add clock controller device nodes
Matthias Brugger (1):
arm64: dts: mt8173: Fix auxadc node
Shunli Wang (1):
soc: mediatek: Add MT2701 power dt-bindings
.../devicetree/bindings/soc/mediatek/scpsys.txt | 13 +++---
arch/arm/boot/dts/mt2701.dtsi | 50
+++++++++++++++++++---
arch/arm64/boot/dts/mediatek/mt8173.dtsi | 3 ++
include/dt-bindings/power/mt2701-power.h | 27 ++++++++++++
4 files changed, 83 insertions(+), 10 deletions(-)
create mode 100644 include/dt-bindings/power/mt2701-power.h
^ permalink raw reply
* [PATCH/RESEND] recordmcount: arm: Implement make_nop
From: Steven Rostedt @ 2016-11-14 18:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161018200707.36e549ee@gandalf.local.home>
On Tue, 18 Oct 2016 20:07:07 -0400
Steven Rostedt <rostedt@goodmis.org> wrote:
> On Tue, 18 Oct 2016 16:42:00 -0700
> Stephen Boyd <sboyd@codeaurora.org> wrote:
>
> > In similar spirit to x86 and arm64 support, add a make_nop_arm()
> > to replace calls to mcount with a nop in sections that aren't
> > traced.
> >
> > Cc: Russell King <linux@arm.linux.org.uk>
> > Acked-by: Rabin Vincent <rabin@rab.in>
> > Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
>
> I can take this if I can get an ack from the ARM maintainers.
Any ARM maintainer want to ack this, or take it in their tree if they
haven't already?
-- Steve
^ permalink raw reply
* [GIT PULL] arm: mediatek: kconfig changes for v4.10
From: Matthias Brugger @ 2016-11-14 18:37 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd and Olof,
although late, please pull the following changes.
Thanks,
Matthias
---
The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
are available in the git repository at:
https://github.com/mbgg/linux-mediatek.git tags/v4.9-next-kconfig
for you to fetch changes up to 494975c9cc00f69bf71de0991dcebda9b2911aa0:
ARM: mediatek: clean up mach-mediatek/Makefile (2016-10-31 15:26:23
-0600)
----------------------------------------------------------------
- clean up mach-mediatek Makefile as kbuild only descends into the folder if
ARCH_MEDIATEK is enabled
----------------------------------------------------------------
Masahiro Yamada (1):
ARM: mediatek: clean up mach-mediatek/Makefile
arch/arm/mach-mediatek/Makefile | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
^ permalink raw reply
* [GIT PULL] arm: mediatek: soc changes for v4.10
From: Matthias Brugger @ 2016-11-14 18:39 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd and Olof,
Although a bit late, please take the following changes into account.
Thanks a lot,
Matthias
---
The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
are available in the git repository at:
https://github.com/mbgg/linux-mediatek.git tags/v4.9-next-soc
for you to fetch changes up to 112ef1882e12094c823937f9d72f2f598db02df7:
soc: mediatek: Add MT2701 scpsys driver (2016-10-31 00:58:58 +0100)
----------------------------------------------------------------
- prepare mtk-scpsys to for multi soc support
- add support for mt2701 to mtk-scpsys
----------------------------------------------------------------
James Liao (1):
soc: mediatek: Refine scpsys to support multiple platform
Shunli Wang (1):
soc: mediatek: Add MT2701 scpsys driver
drivers/soc/mediatek/Kconfig | 2 +-
drivers/soc/mediatek/mtk-scpsys.c | 465
++++++++++++++++++++++++++------------
2 files changed, 327 insertions(+), 140 deletions(-)
^ permalink raw reply
* [GIT PULL] ARM: at91: dt for 4.10
From: Alexandre Belloni @ 2016-11-14 18:39 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd, Olof
at91 DT changes for 4.10, I don't expect much more this cycle.
The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux.git tags/at91-ab-4.10-dt1
for you to fetch changes up to b662a9dd8a1a03e6e2d61e74d3e7a08400edefb7:
ARM: dts: at91: replace gpio-key,wakeup with wakeup-source for sam9260ek (2016-11-14 17:04:24 +0100)
----------------------------------------------------------------
DT changes for 4.10:
- Many additions for sama5d2
- few non urgent fixes for sam9260ek, sama5d4 and sama5d2
----------------------------------------------------------------
Alexandre Belloni (4):
ARM: dts: at91: sama5d4: use proper sckc compatible
ARM: dts: at91: sama5d2: use correct sckc compatible
ARM: dts: at91: sama5d2: Add secumod node
ARM: dts: at91: sama5d2: Add securam node
Cyrille Pitchen (1):
ARM: dts: at91: sama5d2: enable FIFOs for high-speed i2c controllers
Marek Vasut (1):
ARM: dts: at91: sama5d4: Add new MA5D4EVK manufacturer compat
Peter Rosin (1):
dt-bindings: usb: atmel: fix a couple of copy-paste style typos
Sudeep Holla (1):
ARM: dts: at91: replace gpio-key,wakeup with wakeup-source for sam9260ek
Sylvain Rochet (1):
ARM: dts: at91: fixes dbgu pinctrl, set pullup on rx, clear pullup on tx
.../devicetree/bindings/usb/atmel-usb.txt | 10 ++---
arch/arm/boot/dts/at91-sama5d4_ma5d4.dtsi | 4 +-
arch/arm/boot/dts/at91-sama5d4_ma5d4evk.dts | 4 +-
arch/arm/boot/dts/at91rm9200.dtsi | 4 +-
arch/arm/boot/dts/at91sam9260.dtsi | 4 +-
arch/arm/boot/dts/at91sam9260ek.dts | 4 +-
arch/arm/boot/dts/at91sam9261.dtsi | 4 +-
arch/arm/boot/dts/at91sam9263.dtsi | 4 +-
arch/arm/boot/dts/at91sam9g45.dtsi | 4 +-
arch/arm/boot/dts/at91sam9n12.dtsi | 4 +-
arch/arm/boot/dts/at91sam9rl.dtsi | 4 +-
arch/arm/boot/dts/at91sam9x5.dtsi | 4 +-
arch/arm/boot/dts/sama5d2.dtsi | 47 ++++++++++++----------
arch/arm/boot/dts/sama5d3.dtsi | 4 +-
arch/arm/boot/dts/sama5d4.dtsi | 31 +++-----------
15 files changed, 60 insertions(+), 76 deletions(-)
--
Alexandre Belloni, 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: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161114/26c4f372/attachment.sig>
^ permalink raw reply
* [PATCH v2 1/2] mfd: pm8xxx: add support to pm8821
From: Stephen Boyd @ 2016-11-14 18:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479145933-9849-1-git-send-email-srinivas.kandagatla@linaro.org>
On 11/14/2016 09:52 AM, Srinivas Kandagatla wrote:
> diff --git a/drivers/mfd/qcom-pm8xxx.c b/drivers/mfd/qcom-pm8xxx.c
> index 7f9620e..dc347d3 100644
> --- a/drivers/mfd/qcom-pm8xxx.c
> +++ b/drivers/mfd/qcom-pm8xxx.c
> +
> +static void pm8821_irq_handler(struct irq_desc *desc)
> +{
> + struct pm_irq_chip *chip = irq_desc_get_handler_data(desc);
> + struct irq_chip *irq_chip = irq_desc_get_chip(desc);
> + unsigned int master;
> + int ret;
> +
> + chained_irq_enter(irq_chip, desc);
> + ret = regmap_read(chip->regmap,
> + PM8821_SSBI_REG_ADDR_IRQ_MASTER0, &master);
> + if (ret) {
> + pr_err("Failed to re:Qad master 0 ret=%d\n", ret);
Hm? vi?
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH/RESEND] recordmcount: arm: Implement make_nop
From: Russell King - ARM Linux @ 2016-11-14 18:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161114133641.09b1abfb@gandalf.local.home>
On Mon, Nov 14, 2016 at 01:36:41PM -0500, Steven Rostedt wrote:
> On Tue, 18 Oct 2016 20:07:07 -0400
> Steven Rostedt <rostedt@goodmis.org> wrote:
>
> > On Tue, 18 Oct 2016 16:42:00 -0700
> > Stephen Boyd <sboyd@codeaurora.org> wrote:
> >
> > > In similar spirit to x86 and arm64 support, add a make_nop_arm()
> > > to replace calls to mcount with a nop in sections that aren't
> > > traced.
> > >
> > > Cc: Russell King <linux@arm.linux.org.uk>
> > > Acked-by: Rabin Vincent <rabin@rab.in>
> > > Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
> >
> > I can take this if I can get an ack from the ARM maintainers.
>
> Any ARM maintainer want to ack this, or take it in their tree if they
> haven't already?
Assuming it's been tested:
Acked-by: Russell King <rmk+kernel@armlinux.org.uk>
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCHv2 5/6] arm64: Use __pa_symbol for _end
From: Laura Abbott @ 2016-11-14 18:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161114181937.GG3096@e104818-lin.cambridge.arm.com>
On 11/14/2016 10:19 AM, Catalin Marinas wrote:
> On Thu, Nov 03, 2016 at 03:51:07PM +0000, Mark Rutland wrote:
>> On Wed, Nov 02, 2016 at 05:56:42PM -0600, Laura Abbott wrote:
>>> On 11/02/2016 04:52 PM, Mark Rutland wrote:
>>>> On Wed, Nov 02, 2016 at 03:00:53PM -0600, Laura Abbott wrote:
>>>>>
>>>>> __pa_symbol is technically the marco that should be used for kernel
>>>>> symbols. Switch to this as a pre-requisite for DEBUG_VIRTUAL.
>>>>
>>>> Nit: s/marco/macro/
>>>>
>>>> I see there are some other uses of __pa() that look like they could/should be
>>>> __pa_symbol(), e.g. in mark_rodata_ro().
>>>>
>>>> I guess strictly speaking those need to be updated to? Or is there a reason
>>>> that we should not?
>>>
>>> If the concept of __pa_symbol is okay then yes I think all uses of __pa
>>> should eventually be converted for consistency and debugging.
>>
>> I have no strong feelings either way about __pa_symbol(); I'm not clear on what
>> the purpose of __pa_symbol() is specifically, but I'm happy even if it's just
>> for consistency with other architectures.
>
> At a quick grep, it seems to only be used by mips and x86 and a single
> place in mm/memblock.c.
>
> Since we haven't seen any issues on arm/arm64 without this macro, can we
> not just continue to use __pa()?
Technically yes but if it's introduced it may be confusing why it's being
used some places but not others. Maybe the bounds in the debug virtual check
should just be adjusted so we don't need __pa_symbol along with a nice fat
comment explaining why.
>
> Thanks.
>
Thanks,
Laura
^ permalink raw reply
* [GIT PULL] ARM: at91: drivers for 4.10
From: Alexandre Belloni @ 2016-11-14 18:44 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd, Olof
A few fixes for the memory drivers and the support for the Secure SRAM
found on sama5d2.
The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux.git tags/at91-ab-4.10-drivers
for you to fetch changes up to 2ae2e28852f21ec9efc527c1f3ecc5f7c7e27e42:
misc: sram: add Atmel securam support (2016-11-07 23:43:28 +0100)
----------------------------------------------------------------
Drivers for 4.10:
- few fixes for the memory drivers
- minimal security module driver
- support for the Secure SRAM
----------------------------------------------------------------
Alexandre Belloni (4):
Documentation: dt: atmel-at91: Document secumod bindings
ARM: at91: add secumod register definitions
misc: sram: document new compatible
misc: sram: add Atmel securam support
Wei Yongjun (2):
memory: atmel-ebi: fix return value check in at91_ebi_dev_disable()
memory: atmel-sdramc: use builtin_platform_driver to simplify the code
.../devicetree/bindings/arm/atmel-at91.txt | 16 +++++++++
Documentation/devicetree/bindings/sram/sram.txt | 2 +-
drivers/memory/atmel-ebi.c | 2 +-
drivers/memory/atmel-sdramc.c | 6 +---
drivers/misc/sram.c | 42 ++++++++++++++++++----
include/soc/at91/atmel-secumod.h | 19 ++++++++++
6 files changed, 73 insertions(+), 14 deletions(-)
create mode 100644 include/soc/at91/atmel-secumod.h
--
Alexandre Belloni, 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: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161114/287d05f1/attachment-0001.sig>
^ permalink raw reply
* [PATCH RFC] mm: Add debug_virt_to_phys()
From: Laura Abbott @ 2016-11-14 18:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161112004449.30566-1-f.fainelli@gmail.com>
On 11/11/2016 04:44 PM, Florian Fainelli wrote:
> When CONFIG_DEBUG_VM is turned on, virt_to_phys() maps to
> debug_virt_to_phys() which helps catch vmalloc space addresses being
> passed. This is helpful in debugging bogus drivers that just assume
> linear mappings all over the place.
>
> For ARM, ARM64, Unicore32 and Microblaze, the architectures define
> __virt_to_phys() as being the functional implementation of the address
> translation, so we special case the debug stub to call into
> __virt_to_phys directly.
>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
> arch/arm/include/asm/memory.h | 4 ++++
> arch/arm64/include/asm/memory.h | 4 ++++
> include/asm-generic/memory_model.h | 4 ++++
> mm/debug.c | 15 +++++++++++++++
> 4 files changed, 27 insertions(+)
>
> diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
> index 76cbd9c674df..448dec9b8b00 100644
> --- a/arch/arm/include/asm/memory.h
> +++ b/arch/arm/include/asm/memory.h
> @@ -260,11 +260,15 @@ static inline unsigned long __phys_to_virt(phys_addr_t x)
> * translation for translating DMA addresses. Use the driver
> * DMA support - see dma-mapping.h.
> */
> +#ifndef CONFIG_DEBUG_VM
> #define virt_to_phys virt_to_phys
> static inline phys_addr_t virt_to_phys(const volatile void *x)
> {
> return __virt_to_phys((unsigned long)(x));
> }
> +#else
> +#define virt_to_phys debug_virt_to_phys
> +#endif
>
> #define phys_to_virt phys_to_virt
> static inline void *phys_to_virt(phys_addr_t x)
> diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
> index b71086d25195..c9e436b28523 100644
> --- a/arch/arm64/include/asm/memory.h
> +++ b/arch/arm64/include/asm/memory.h
> @@ -186,11 +186,15 @@ extern u64 kimage_voffset;
> * translation for translating DMA addresses. Use the driver
> * DMA support - see dma-mapping.h.
> */
> +#ifndef CONFIG_DEBUG_VM
> #define virt_to_phys virt_to_phys
> static inline phys_addr_t virt_to_phys(const volatile void *x)
> {
> return __virt_to_phys((unsigned long)(x));
> }
> +#else
> +#define virt_to_phys debug_virt_to_phys
> +#endif
>
> #define phys_to_virt phys_to_virt
> static inline void *phys_to_virt(phys_addr_t x)
> diff --git a/include/asm-generic/memory_model.h b/include/asm-generic/memory_model.h
> index 5148150cc80b..426085757258 100644
> --- a/include/asm-generic/memory_model.h
> +++ b/include/asm-generic/memory_model.h
> @@ -80,6 +80,10 @@
> #define page_to_pfn __page_to_pfn
> #define pfn_to_page __pfn_to_page
>
> +#ifdef CONFIG_DEBUG_VM
> +unsigned long debug_virt_to_phys(volatile void *address);
> +#endif /* CONFIG_DEBUG_VM */
> +
> #endif /* __ASSEMBLY__ */
>
> #endif
> diff --git a/mm/debug.c b/mm/debug.c
> index 9feb699c5d25..72b2ca9b11f4 100644
> --- a/mm/debug.c
> +++ b/mm/debug.c
> @@ -161,4 +161,19 @@ void dump_mm(const struct mm_struct *mm)
> );
> }
>
> +#include <asm/memory.h>
> +#include <linux/mm.h>
> +
> +unsigned long debug_virt_to_phys(volatile void *address)
> +{
> + BUG_ON(is_vmalloc_addr((const void *)address));
> +#if defined(CONFIG_ARM) || defined(CONFIG_ARM64) || defined(CONFIG_UNICORE32) || \
> + defined(CONFIG_MICROBLAZE)
> + return __virt_to_phys(address);
> +#else
> + return virt_to_phys(address);
> +#endif
> +}
> +EXPORT_SYMBOL(debug_virt_to_phys);
> +
> #endif /* CONFIG_DEBUG_VM */
>
is_vmalloc_addr is necessary but not sufficient. This misses
cases like module addresses. The x86 version (CONFIG_DEBUG_VIRTUAL)
bounds checks against the known linear map to catch all cases.
I'm for a generic approach to this if it can catch all cases
that an architecture specific version would catch.
Thanks,
Laura
^ permalink raw reply
* [PATCH resend] input: touchscreen: silead: Add regulator support
From: Dmitry Torokhov @ 2016-11-14 18:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161114144502.10595-2-hdegoede@redhat.com>
Hi Hans,
On Mon, Nov 14, 2016 at 03:45:02PM +0100, Hans de Goede wrote:
> On some tablets the touchscreen controller is powered by seperate
> regulators, add support for this.
>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> Acked-by: Rob Herring <robh@kernel.org>
> ---
> .../bindings/input/touchscreen/silead_gsl1680.txt | 2 +
> drivers/input/touchscreen/silead.c | 51 ++++++++++++++++++++--
> 2 files changed, 49 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/input/touchscreen/silead_gsl1680.txt b/Documentation/devicetree/bindings/input/touchscreen/silead_gsl1680.txt
> index e844c3f..b726823 100644
> --- a/Documentation/devicetree/bindings/input/touchscreen/silead_gsl1680.txt
> +++ b/Documentation/devicetree/bindings/input/touchscreen/silead_gsl1680.txt
> @@ -22,6 +22,8 @@ Optional properties:
> - touchscreen-inverted-y : See touchscreen.txt
> - touchscreen-swapped-x-y : See touchscreen.txt
> - silead,max-fingers : maximum number of fingers the touchscreen can detect
> +- vddio-supply : regulator phandle for controller VDDIO
> +- avdd-supply : regulator phandle for controller AVDD
>
> Example:
>
> diff --git a/drivers/input/touchscreen/silead.c b/drivers/input/touchscreen/silead.c
> index f502c84..c6a1ae9 100644
> --- a/drivers/input/touchscreen/silead.c
> +++ b/drivers/input/touchscreen/silead.c
> @@ -29,6 +29,7 @@
> #include <linux/input/touchscreen.h>
> #include <linux/pm.h>
> #include <linux/irq.h>
> +#include <linux/regulator/consumer.h>
>
> #include <asm/unaligned.h>
>
> @@ -72,6 +73,8 @@ enum silead_ts_power {
> struct silead_ts_data {
> struct i2c_client *client;
> struct gpio_desc *gpio_power;
> + struct regulator *vddio;
> + struct regulator *avdd;
> struct input_dev *input;
> char fw_name[64];
> struct touchscreen_properties prop;
> @@ -465,21 +468,52 @@ static int silead_ts_probe(struct i2c_client *client,
> if (client->irq <= 0)
> return -ENODEV;
>
> + data->vddio = devm_regulator_get_optional(dev, "vddio");
> + if (IS_ERR(data->vddio)) {
> + if (PTR_ERR(data->vddio) == -EPROBE_DEFER)
> + return -EPROBE_DEFER;
> + data->vddio = NULL;
Why do we ignore other errors? If there is an issue reported by
regulator framework we should net be ignoring it.
Unless regulator is truly optional (i.e. chip can work with some
functionality powered off) and not simply hidden (firmware takes care of
powering up system), we should not be using regulator_get_optional():
if regulator is absent from ACPI/DT/etc, regulator framework will supply
dummy regulator that you can enable/disable and not bothering checking
whether it is NULL or not.
Also, please consider using devm_regulator_bulk_get().
> + }
> +
> + data->avdd = devm_regulator_get_optional(dev, "avdd");
> + if (IS_ERR(data->avdd)) {
> + if (PTR_ERR(data->avdd) == -EPROBE_DEFER)
> + return -EPROBE_DEFER;
> + data->avdd = NULL;
> + }
> +
> + /*
> + * Enable regulators at probe and disable them at remove, we need
> + * to keep the chip powered otherwise it forgets its firmware.
> + */
> + if (data->vddio) {
> + error = regulator_enable(data->vddio);
> + if (error)
> + return error;
> + }
> +
> + if (data->avdd) {
> + error = regulator_enable(data->avdd);
> + if (error)
> + goto disable_vddio;
> + }
Use devm_add_action_or_reset() to work regulator_bulk_disable call into
devm stream. As it is you are leaving regulators on on unbind/remove.
> +
> /* Power GPIO pin */
> data->gpio_power = devm_gpiod_get_optional(dev, "power", GPIOD_OUT_LOW);
> if (IS_ERR(data->gpio_power)) {
> if (PTR_ERR(data->gpio_power) != -EPROBE_DEFER)
> dev_err(dev, "Shutdown GPIO request failed\n");
> - return PTR_ERR(data->gpio_power);
> + error = PTR_ERR(data->gpio_power);
> + goto disable_avdd;
> }
>
> error = silead_ts_setup(client);
> if (error)
> - return error;
> + goto disable_avdd;
>
> error = silead_ts_request_input_dev(data);
> if (error)
> - return error;
> + goto disable_avdd;
>
> error = devm_request_threaded_irq(dev, client->irq,
> NULL, silead_ts_threaded_irq_handler,
> @@ -487,10 +521,19 @@ static int silead_ts_probe(struct i2c_client *client,
> if (error) {
> if (error != -EPROBE_DEFER)
> dev_err(dev, "IRQ request failed %d\n", error);
> - return error;
> + goto disable_avdd;
> }
>
> return 0;
> +
> +disable_avdd:
> + if (data->avdd)
> + regulator_disable(data->avdd);
> +disable_vddio:
> + if (data->vddio)
> + regulator_disable(data->vddio);
> +
> + return error;
> }
>
> static int __maybe_unused silead_ts_suspend(struct device *dev)
> --
> 2.9.3
>
Thanks.
--
Dmitry
^ permalink raw reply
* [PATCH v2] input: bma150: Only claim to support the bma180 if the separate iio bma180 driver is not build
From: Dmitry Torokhov @ 2016-11-14 18:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161114131114.6053-1-hdegoede@redhat.com>
On Mon, Nov 14, 2016 at 02:11:14PM +0100, Hans de Goede wrote:
> commit ef3714fdbc8d ("Input: bma150 - extend chip detection for bma180"),
> adds bma180 chip-ids to the input bma150 driver, assuming that they are
> 100% compatible, but the bma180 is not compatible with the bma150 at all,
> it has 14 bits resolution instead of 10, and it has quite different
> control registers too.
>
> Treating the bma180 as a bma150 wrt its data registers will just result
> in throwing away the lowest 4 bits, which is not too bad. But the ctrl
> registers are a different story. Things happen to just work but supporting
> that certainly does not make treating the bma180 the same as the bma150
> right.
>
> Since some setups depend on the evdev interface the bma150 driver offers
> on top of the bma180, we cannot simply remove the bma180 ids.
>
> So this commit only removes the bma180 id when the bma180 iio driver,
> which does treat the bma180 properly, is enabled.
>
> Cc: Dr. H. Nikolaus Schaller <hns@goldelico.com>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Applied, thank you.
> ---
> Changes in v2:
> -Use IS_ENABLED(CONFIG_BMA180) instead of #ifdef CONFIG_BMA180
> ---
> drivers/input/misc/bma150.c | 9 ++++++++-
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/input/misc/bma150.c b/drivers/input/misc/bma150.c
> index b0d4453..2124390 100644
> --- a/drivers/input/misc/bma150.c
> +++ b/drivers/input/misc/bma150.c
> @@ -538,8 +538,13 @@ static int bma150_probe(struct i2c_client *client,
> return -EIO;
> }
>
> + /*
> + * Note if the IIO CONFIG_BMA180 driver is enabled we want to fail
> + * the probe for the bma180 as the iio driver is preferred.
> + */
> chip_id = i2c_smbus_read_byte_data(client, BMA150_CHIP_ID_REG);
> - if (chip_id != BMA150_CHIP_ID && chip_id != BMA180_CHIP_ID) {
> + if (chip_id != BMA150_CHIP_ID &&
> + (IS_ENABLED(CONFIG_BMA180) || chip_id != BMA180_CHIP_ID)) {
> dev_err(&client->dev, "BMA150 chip id error: %d\n", chip_id);
> return -EINVAL;
> }
> @@ -643,7 +648,9 @@ static UNIVERSAL_DEV_PM_OPS(bma150_pm, bma150_suspend, bma150_resume, NULL);
>
> static const struct i2c_device_id bma150_id[] = {
> { "bma150", 0 },
> +#if !IS_ENABLED(CONFIG_BMA180)
> { "bma180", 0 },
> +#endif
> { "smb380", 0 },
> { "bma023", 0 },
> { }
> --
> 2.9.3
>
--
Dmitry
^ permalink raw reply
* [PATCH v2 1/2] mfd: pm8xxx: add support to pm8821
From: Bjorn Andersson @ 2016-11-14 18:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479145933-9849-1-git-send-email-srinivas.kandagatla@linaro.org>
On Mon 14 Nov 09:52 PST 2016, Srinivas Kandagatla wrote:
> This patch adds support to PM8821 PMIC and interrupt support.
> PM8821 is companion device that supplements primary PMIC PM8921 IC.
>
> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
> Acked-by: Rob Herring <robh@kernel.org>
> ---
> Changes from v1:
> - Removed unnessary locking spotted by Bjorn
> - updated register naming to reflect PM8821
> - lot of cleanups suggested by Bjorn
> - rebased on top of Linus Walleij's pm8xxx namespace
> cleanup patch.
Looks good, just some minor style nits below.
>
> .../devicetree/bindings/mfd/qcom-pm8xxx.txt | 1 +
> drivers/mfd/qcom-pm8xxx.c | 247 ++++++++++++++++++++-
> 2 files changed, 238 insertions(+), 10 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/mfd/qcom-pm8xxx.txt b/Documentation/devicetree/bindings/mfd/qcom-pm8xxx.txt
> index 37a088f..8f1b4ec 100644
> --- a/Documentation/devicetree/bindings/mfd/qcom-pm8xxx.txt
> +++ b/Documentation/devicetree/bindings/mfd/qcom-pm8xxx.txt
> @@ -11,6 +11,7 @@ voltages and other various functionality to Qualcomm SoCs.
> Definition: must be one of:
> "qcom,pm8058"
> "qcom,pm8921"
> + "qcom,pm8821"
8 < 9, so move it one step up please.
>
> - #address-cells:
> Usage: required
> diff --git a/drivers/mfd/qcom-pm8xxx.c b/drivers/mfd/qcom-pm8xxx.c
[..]
> +#define PM8821_SSBI_REG_ADDR_IRQ_BASE 0x100
> +#define PM8821_SSBI_REG_ADDR_IRQ_MASTER0 (PM8821_SSBI_REG_ADDR_IRQ_BASE + 0x30)
> +#define PM8821_SSBI_REG_ADDR_IRQ_MASTER1 (PM8821_SSBI_REG_ADDR_IRQ_BASE + 0xb0)
> +#define PM8821_SSBI_REG(m, b, offset) \
> + ((m == 0) ? \
> + (PM8821_SSBI_REG_ADDR_IRQ_MASTER0 + b + offset) : \
> + (PM8821_SSBI_REG_ADDR_IRQ_MASTER1 + b + offset))
> +#define PM8821_SSBI_ADDR_IRQ_ROOT(m, b) PM8821_SSBI_REG(m, b, 0x0)
> +#define PM8821_SSBI_ADDR_IRQ_CLEAR(m, b) PM8821_SSBI_REG(m, b, 0x01)
> +#define PM8821_SSBI_ADDR_IRQ_MASK(m, b) PM8821_SSBI_REG(m, b, 0x08)
> +#define PM8821_SSBI_ADDR_IRQ_RT_STATUS(m, b) PM8821_SSBI_REG(m, b, 0x0f)
I like how this cleaned up the rest of the implementation.
[..]
> +static void pm8821_irq_block_handler(struct pm_irq_chip *chip,
> + int master, int block)
> +{
> + int pmirq, irq, i, ret;
> + unsigned int bits;
> +
> + ret = regmap_read(chip->regmap,
> + PM8821_SSBI_ADDR_IRQ_ROOT(master, block), &bits);
> + if (ret) {
> + pr_err("Failed reading %d block ret=%d", block, ret);
"Reading block %d failed ret=%d"
> + return;
> + }
> + if (!bits) {
> + pr_err("block bit set in master but no irqs: %d", block);
This seems more like a debug thing, either showing missbehaving hardware
or something odd in the driver. I think you should drop the print or
make it pr_debug().
> + return;
> + }
I would prefer that you just drop the entire if statement, it's just an
corner case optimization with a info print.
> +
> + /* Convert block offset to global block number */
> + block += (master * PM8821_BLOCKS_PER_MASTER) - 1;
> +
> + /* Check IRQ bits */
> + for (i = 0; i < 8; i++) {
> + if (bits & BIT(i)) {
> + pmirq = block * 8 + i;
> + irq = irq_find_mapping(chip->irqdomain, pmirq);
> + generic_handle_irq(irq);
> + }
> + }
> +
Empty line
> +}
> +
> +static inline void pm8821_irq_master_handler(struct pm_irq_chip *chip,
> + int master, u8 master_val)
> +{
> + int block;
> +
> + for (block = 1; block < 8; block++)
> + if (master_val & BIT(block))
> + pm8821_irq_block_handler(chip, master, block);
> +
Empty line
> +}
> +
> +static void pm8821_irq_handler(struct irq_desc *desc)
> +{
> + struct pm_irq_chip *chip = irq_desc_get_handler_data(desc);
> + struct irq_chip *irq_chip = irq_desc_get_chip(desc);
> + unsigned int master;
> + int ret;
> +
> + chained_irq_enter(irq_chip, desc);
> + ret = regmap_read(chip->regmap,
> + PM8821_SSBI_REG_ADDR_IRQ_MASTER0, &master);
> + if (ret) {
> + pr_err("Failed to re:Qad master 0 ret=%d\n", ret);
^
|
I see you're using vim :)
> + return;
> + }
> +
> + /* bits 1 through 7 marks the first 7 blocks in master 0*/
Indentation
> + if (master & GENMASK(7, 1))
> + pm8821_irq_master_handler(chip, 0, master);
> +
> + /* bit 0 marks if master 1 contains any bits */
Dito
> + if (!(master & BIT(0)))
> + goto done;
> +
> + ret = regmap_read(chip->regmap,
> + PM8821_SSBI_REG_ADDR_IRQ_MASTER1, &master);
> + if (ret) {
> + pr_err("Failed to read master 1 ret=%d\n", ret);
> + return;
"goto done;" so that we pass chained_irq_exit()
> + }
> +
> + pm8821_irq_master_handler(chip, 1, master);
> +
> +done:
> + chained_irq_exit(irq_chip, desc);
> +}
> +
[..]
> +static void pm8821_irq_mask_ack(struct irq_data *d)
> +{
> + struct pm_irq_chip *chip = irq_data_get_irq_chip_data(d);
> + unsigned int pmirq = irqd_to_hwirq(d);
> + u8 block, master;
> + int irq_bit, rc;
> +
> + block = pmirq / 8;
> + master = block / PM8821_BLOCKS_PER_MASTER;
> + irq_bit = pmirq % 8;
> + block %= PM8821_BLOCKS_PER_MASTER;
> +
> + rc = regmap_update_bits(chip->regmap,
> + PM8821_SSBI_ADDR_IRQ_MASK(master, block),
> + BIT(irq_bit), BIT(irq_bit));
> +
Empty line
> + if (rc) {
> + pr_err("Failed to read/write mask IRQ:%d rc=%d\n", pmirq, rc);
"Failed to mask IRQ %d rc=%d\n"
> + return;
> + }
> +
> + rc = regmap_update_bits(chip->regmap,
> + PM8821_SSBI_ADDR_IRQ_CLEAR(master, block),
> + BIT(irq_bit), BIT(irq_bit));
> +
Empty line
> + if (rc) {
> + pr_err("Failed to read/write IT_CLEAR IRQ:%d rc=%d\n",
> + pmirq, rc);
"Failed to clear IRQ %d rc=%d\n"
> + }
> +
Empty line
> +}
> +
> +static void pm8821_irq_unmask(struct irq_data *d)
> +{
> + struct pm_irq_chip *chip = irq_data_get_irq_chip_data(d);
> + unsigned int pmirq = irqd_to_hwirq(d);
> + int irq_bit, rc;
> + u8 block, master;
> +
> + block = pmirq / 8;
> + master = block / PM8821_BLOCKS_PER_MASTER;
> + irq_bit = pmirq % 8;
> + block %= PM8821_BLOCKS_PER_MASTER;
> +
> + rc = regmap_update_bits(chip->regmap,
> + PM8821_SSBI_ADDR_IRQ_MASK(master, block),
> + BIT(irq_bit), ~BIT(irq_bit));
> +
Empty line
> + if (rc)
> + pr_err("Failed to read/write unmask IRQ:%d rc=%d\n", pmirq, rc);
"Failed to unmask IRQ %d rc=%d\n"
> +
Empty line
> +}
> +
> +static int pm8821_irq_get_irqchip_state(struct irq_data *d,
> + enum irqchip_irq_state which,
> + bool *state)
> +{
> + struct pm_irq_chip *chip = irq_data_get_irq_chip_data(d);
> + int rc, pmirq = irqd_to_hwirq(d);
> + u8 block, irq_bit, master;
> + unsigned int bits;
> +
> + block = pmirq / 8;
> + master = block / PM8821_BLOCKS_PER_MASTER;
> + irq_bit = pmirq % 8;
> + block %= PM8821_BLOCKS_PER_MASTER;
> +
> + rc = regmap_read(chip->regmap,
> + PM8821_SSBI_ADDR_IRQ_RT_STATUS(master, block), &bits);
> + if (rc) {
> + pr_err("Failed Reading Status rc=%d\n", rc);
Odd capitalization, I suggest that you match it to the other functions
by:
"Reading status of IRQ %d failed rc=%d\n"
> + return rc;
> + }
> +
> + *state = !!(bits & BIT(irq_bit));
> +
> + return rc;
> +}
> +
[..]
>
> static int pm8xxx_probe(struct platform_device *pdev)
> {
> + const struct of_device_id *match;
> + const struct pm_irq_data *data;
> struct regmap *regmap;
> int irq, rc;
> unsigned int val;
> u32 rev;
> struct pm_irq_chip *chip;
> - unsigned int nirqs = PM8XXX_NR_IRQS;
> +
> + match = of_match_node(pm8xxx_id_table, pdev->dev.of_node);
> + if (!match) {
> + dev_err(&pdev->dev, "No matching driver data found\n");
> + return -EINVAL;
> + }
> +
> + data = match->data;
data = of_device_get_match_data(&pdev->dev); (from of_device.h)
Regards,
Bjorn
^ permalink raw reply
* [PATCH] ARM: davinci_all_defconfig: add missing options for systemd
From: Kevin Hilman @ 2016-11-14 19:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161114160146.20679-1-nsekhar@ti.com>
Sekhar Nori <nsekhar@ti.com> writes:
> Some kernel configuration options required for systemd
> support are missing in davinci_all_defconfig. Add them.
>
> This is based on recommendations in:
>
> http://cgit.freedesktop.org/systemd/systemd/tree/README
>
> Options which kernel enables by default (and will thus be removed
> upon next savedefconfig update) are not included.
>
> Tested on OMAP-L138 LCDK board with fully up to date armv5
> archlinux filesystem.
>
> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Acked-by: Kevin Hilman <khilman@baylibre.com>
^ permalink raw reply
* specifying order of /dev/mmcblk devices via device-tree?
From: Russell King - ARM Linux @ 2016-11-14 19:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJ+vNU26tx-1bLKNpzYJ0UCeFJ-SczZOca1dYdt5mCGDxAuKTQ@mail.gmail.com>
So, someone merged a patch which makes mmcblk devices follow the
host controller numbering.
Now my cubox-i fails to boot correctly because the SD card in the
_only_ SD card slot now gets called "mmcblk1" and not "mmcblk0".
USDHC1 is wired to the on-microsom WiFi, and never has anything
remotely near a SD card or eMMC present. So, this change is
confusing on these platforms.
Moreover, this is _going_ to break SolidRun distros if people upgrade
their kernels.
It may be appropriate for eMMC, but it's not appropriate everywhere.
This is a user visible _regression_ in 4.9-rc. Whoever did this,
please revert whatever change caused this, and next time limit it
to only eMMC.
Thanks.
On Fri, Oct 28, 2016 at 09:45:00AM -0700, Tim Harvey wrote:
> On Fri, Oct 28, 2016 at 8:37 AM, Mark Rutland <mark.rutland@arm.com> wrote:
> > On Fri, Oct 28, 2016 at 08:23:04AM -0700, Tim Harvey wrote:
> >> Greetings,
> >>
> >> I have an IMX6 board that has the following:
> >> sdhc1: mmc0: sdio radio
> >> sdhc2: mmc1: /dev/mmcblk1: microSD connector
> >> sdhc3: mmc2: /dev/mmcblk2: on-board eMMC
> >>
> >> I would like to have sdhc3 registered as /dev/mmcblk0 and sdhc2
> >> registered as /dev/mmcblk1 so that permanent storage is the first
> >> mmcblk device as I think this is more intuitive however currently
> >> these get instanced in the order they appear in the imx6qdl.dtsi
> >> device-tree configuration and are not able to be mapped the way I want
> >> them in my dts file.
> >>
> >> Is there a way, or if not is there a desire for a way, to specify the
> >> order of /dev/mmcblk devices via device-tree?
> >
> > As with many other devices, there is no standard way of controlling the
> > Linux enumeration (and given the ID space is shared with other dynamic
> > devices it's not something that could generally work).
> >
> > These should be refererd to by UUID if possible.
> >
> > If not, we could cosider adding a by-dt-path or something like that.
> >
> > Thanks,
> > Mark.
>
> Mark / Javier/ Fabio,
>
> Thanks - this is very useful.
>
> Yes, I agree that using UUID's is the way to go and now I see how that
> can be easily accessed via uboot 'part' command.
>
> Regards,
>
> Tim
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [RFC PATCH] ARM64: dts: Add support for Meson GXM
From: Kevin Hilman @ 2016-11-14 19:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161114094411.30199-1-narmstrong@baylibre.com>
Neil Armstrong <narmstrong@baylibre.com> writes:
> Following the Amlogic Linux kernel, it seem the only differences
> between the GXL and GXM SoCs are the CPU Clusters.
>
> Simply add a meson-gxm dtsi and reproduce the P23x to Q20x boards
> dts files since the S905D and S912 SoCs shares the same pinout
> and the P23x and Q20x boards are identical.
Since the P23x and Q20x boards are identical, should we just come up
with a singel dtsi for them all? e.g move the -p23x.dtsi to -pq2xx.dtsi
or something?
I don't think it's a big deal, but it does seem like we should avoid the
copy/paste wherever possible.
Kevin
^ 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