* [PATCH 1/1] serial: stm32: add no_console_suspend support
From: Erwan Le Ray @ 2020-05-19 9:41 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby, Maxime Coquelin, Alexandre Torgue,
Sumit Semwal
Cc: linux-kernel, dri-devel, linaro-mm-sig, Erwan Le Ray,
linux-serial, Fabrice Gasnier, linux-stm32, linux-arm-kernel,
linux-media
In order to display console messages in low power mode, console pins
must be kept active after suspend call.
---
Initial patch "serial: stm32: add support for no_console_suspend" was part
of "STM32 usart power improvement" series, but as dependancy to
console_suspend pinctl state has been removed to fit with Rob comment [1],
this patch has no more dependancy with any other patch of this series.
[1] https://lkml.org/lkml/2019/7/9/451
Signed-off-by: Erwan Le Ray <erwan.leray@st.com>
diff --git a/drivers/tty/serial/stm32-usart.c b/drivers/tty/serial/stm32-usart.c
index 9cfcf355567a..5afd29162f6c 100644
--- a/drivers/tty/serial/stm32-usart.c
+++ b/drivers/tty/serial/stm32-usart.c
@@ -1425,7 +1425,18 @@ static int __maybe_unused stm32_serial_suspend(struct device *dev)
else
stm32_serial_enable_wakeup(port, false);
- pinctrl_pm_select_sleep_state(dev);
+ /*
+ * When "no_console_suspend" is enabled, keep the pinctrl default state
+ * and rely on bootloader stage to restore this state upon resume.
+ * Otherwise, apply the idle or sleep states depending on wakeup
+ * capabilities.
+ */
+ if (console_suspend_enabled || !uart_console(port)) {
+ if (device_may_wakeup(dev))
+ pinctrl_pm_select_idle_state(dev);
+ else
+ pinctrl_pm_select_sleep_state(dev);
+ }
return 0;
}
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH] drm/mediatek: mtk_hdmi: Remove debug messages for function calls
From: Enric Balletbo i Serra @ 2020-05-19 9:41 UTC (permalink / raw)
To: linux-kernel
Cc: Chun-Kuang Hu, drinkcat, Philipp Zabel, David Airlie, dri-devel,
linux-mediatek, Daniel Vetter, hsinyi, matthias.bgg,
Collabora Kernel ML, linux-arm-kernel
Equivalent information can be nowadays obtained using function tracer
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
---
drivers/gpu/drm/mediatek/mtk_hdmi.c | 12 +-----------
drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c | 4 ----
2 files changed, 1 insertion(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c b/drivers/gpu/drm/mediatek/mtk_hdmi.c
index b0555a7cb3b4..172d67294435 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
@@ -1634,8 +1634,6 @@ static int mtk_hdmi_audio_startup(struct device *dev, void *data)
{
struct mtk_hdmi *hdmi = dev_get_drvdata(dev);
- dev_dbg(dev, "%s\n", __func__);
-
mtk_hdmi_audio_enable(hdmi);
return 0;
@@ -1645,8 +1643,6 @@ static void mtk_hdmi_audio_shutdown(struct device *dev, void *data)
{
struct mtk_hdmi *hdmi = dev_get_drvdata(dev);
- dev_dbg(dev, "%s\n", __func__);
-
mtk_hdmi_audio_disable(hdmi);
}
@@ -1655,8 +1651,6 @@ mtk_hdmi_audio_digital_mute(struct device *dev, void *data, bool enable)
{
struct mtk_hdmi *hdmi = dev_get_drvdata(dev);
- dev_dbg(dev, "%s(%d)\n", __func__, enable);
-
if (enable)
mtk_hdmi_hw_aud_mute(hdmi);
else
@@ -1669,8 +1663,6 @@ static int mtk_hdmi_audio_get_eld(struct device *dev, void *data, uint8_t *buf,
{
struct mtk_hdmi *hdmi = dev_get_drvdata(dev);
- dev_dbg(dev, "%s\n", __func__);
-
memcpy(buf, hdmi->conn.eld, min(sizeof(hdmi->conn.eld), len));
return 0;
@@ -1770,7 +1762,6 @@ static int mtk_drm_hdmi_probe(struct platform_device *pdev)
goto err_bridge_remove;
}
- dev_dbg(dev, "mediatek hdmi probe success\n");
return 0;
err_bridge_remove:
@@ -1793,7 +1784,7 @@ static int mtk_hdmi_suspend(struct device *dev)
struct mtk_hdmi *hdmi = dev_get_drvdata(dev);
mtk_hdmi_clk_disable_audio(hdmi);
- dev_dbg(dev, "hdmi suspend success!\n");
+
return 0;
}
@@ -1808,7 +1799,6 @@ static int mtk_hdmi_resume(struct device *dev)
return ret;
}
- dev_dbg(dev, "hdmi resume success!\n");
return 0;
}
#endif
diff --git a/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c b/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
index b55f51675205..1c3575372230 100644
--- a/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
+++ b/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
@@ -159,8 +159,6 @@ static int mtk_hdmi_pll_prepare(struct clk_hw *hw)
{
struct mtk_hdmi_phy *hdmi_phy = to_mtk_hdmi_phy(hw);
- dev_dbg(hdmi_phy->dev, "%s\n", __func__);
-
mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON1, RG_HDMITX_PLL_AUTOK_EN);
mtk_hdmi_phy_set_bits(hdmi_phy, HDMI_CON0, RG_HDMITX_PLL_POSDIV);
mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON3, RG_HDMITX_MHLCK_EN);
@@ -178,8 +176,6 @@ static void mtk_hdmi_pll_unprepare(struct clk_hw *hw)
{
struct mtk_hdmi_phy *hdmi_phy = to_mtk_hdmi_phy(hw);
- dev_dbg(hdmi_phy->dev, "%s\n", __func__);
-
mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON1, RG_HDMITX_PLL_TXDIV_EN);
mtk_hdmi_phy_clear_bits(hdmi_phy, HDMI_CON1, RG_HDMITX_PLL_BIAS_LPF_EN);
usleep_range(100, 150);
--
2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH] drm/mediatek: mtk_mt8173_hdmi_phy: Remove unnused const variables
From: Enric Balletbo i Serra @ 2020-05-19 9:40 UTC (permalink / raw)
To: linux-kernel
Cc: Chun-Kuang Hu, drinkcat, Philipp Zabel, David Airlie, dri-devel,
linux-mediatek, Daniel Vetter, hsinyi, matthias.bgg,
Collabora Kernel ML, linux-arm-kernel
There are some `static const u8` variables that are not used, this
triggers a warning building with `make W=1`, it is safe to remove them,
so do it and make the compiler more happy.
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
---
.../gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c | 48 -------------------
1 file changed, 48 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c b/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
index 1c3575372230..827b93786fac 100644
--- a/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
+++ b/drivers/gpu/drm/mediatek/mtk_mt8173_hdmi_phy.c
@@ -107,54 +107,6 @@
#define RGS_HDMITX_5T1_EDG (0xf << 4)
#define RGS_HDMITX_PLUG_TST BIT(0)
-static const u8 PREDIV[3][4] = {
- {0x0, 0x0, 0x0, 0x0}, /* 27Mhz */
- {0x1, 0x1, 0x1, 0x1}, /* 74Mhz */
- {0x1, 0x1, 0x1, 0x1} /* 148Mhz */
-};
-
-static const u8 TXDIV[3][4] = {
- {0x3, 0x3, 0x3, 0x2}, /* 27Mhz */
- {0x2, 0x1, 0x1, 0x1}, /* 74Mhz */
- {0x1, 0x0, 0x0, 0x0} /* 148Mhz */
-};
-
-static const u8 FBKSEL[3][4] = {
- {0x1, 0x1, 0x1, 0x1}, /* 27Mhz */
- {0x1, 0x0, 0x1, 0x1}, /* 74Mhz */
- {0x1, 0x0, 0x1, 0x1} /* 148Mhz */
-};
-
-static const u8 FBKDIV[3][4] = {
- {19, 24, 29, 19}, /* 27Mhz */
- {19, 24, 14, 19}, /* 74Mhz */
- {19, 24, 14, 19} /* 148Mhz */
-};
-
-static const u8 DIVEN[3][4] = {
- {0x2, 0x1, 0x1, 0x2}, /* 27Mhz */
- {0x2, 0x2, 0x2, 0x2}, /* 74Mhz */
- {0x2, 0x2, 0x2, 0x2} /* 148Mhz */
-};
-
-static const u8 HTPLLBP[3][4] = {
- {0xc, 0xc, 0x8, 0xc}, /* 27Mhz */
- {0xc, 0xf, 0xf, 0xc}, /* 74Mhz */
- {0xc, 0xf, 0xf, 0xc} /* 148Mhz */
-};
-
-static const u8 HTPLLBC[3][4] = {
- {0x2, 0x3, 0x3, 0x2}, /* 27Mhz */
- {0x2, 0x3, 0x3, 0x2}, /* 74Mhz */
- {0x2, 0x3, 0x3, 0x2} /* 148Mhz */
-};
-
-static const u8 HTPLLBR[3][4] = {
- {0x1, 0x1, 0x0, 0x1}, /* 27Mhz */
- {0x1, 0x2, 0x2, 0x1}, /* 74Mhz */
- {0x1, 0x2, 0x2, 0x1} /* 148Mhz */
-};
-
static int mtk_hdmi_pll_prepare(struct clk_hw *hw)
{
struct mtk_hdmi_phy *hdmi_phy = to_mtk_hdmi_phy(hw);
--
2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCHv2 0/7] Support inhibiting input devices
From: Hans de Goede @ 2020-05-19 9:36 UTC (permalink / raw)
To: Andrzej Pietrasiewicz, linux-input, linux-acpi, linux-iio,
linux-arm-kernel, linux-samsung-soc, linux-tegra, patches,
ibm-acpi-devel, platform-driver-x86
Cc: Nick Dyer, Benjamin Tissoires, Laxman Dewangan,
Peter Meerwald-Stadler, kernel, Fabio Estevam, Lars-Peter Clausen,
Krzysztof Kozlowski, Jonathan Hunter, Kukjin Kim, NXP Linux Team,
Sylvain Lemieux, Len Brown, Peter Hutterer, Michael Hennerich,
Sascha Hauer, Henrique de Moraes Holschuh, Vladimir Zapolskiy,
Barry Song, Ferruh Yigit, Dmitry Torokhov, Rafael J . Wysocki,
Thierry Reding, Sangwon Jee, Pengutronix Kernel Team,
Hartmut Knaack, Shawn Guo, Jonathan Cameron
In-Reply-To: <2d224833-3a7e-bc7c-af15-1f803f466697@collabora.com>
Hi,
On 5/19/20 11:02 AM, Andrzej Pietrasiewicz wrote:
> Hi Hans, Hi Dmitry,
>
> W dniu 18.05.2020 o 16:23, Hans de Goede pisze:
>> Hi,
>
> <snip>
>
>>>>>>
>>>>>> So I wonder what this series actually adds for functionality for
>>>>>> userspace which can not already be achieved this way?
>>>>>>
>>>>>> I also noticed that you keep the device open (do not call the
>>>>>> input_device's close callback) when inhibited and just throw away
>>>>>
>>>>> I'm not sure if I understand you correctly, it is called:
>>>>>
>>>>> +static inline void input_stop(struct input_dev *dev)
>>>>> +{
>>>>> + if (dev->poller)
>>>>> + input_dev_poller_stop(dev->poller);
>>>>> + if (dev->close)
>>>>> + dev->close(dev);
>>>>> ^^^^^^^^^^^^^^^^
>>>>> +static int input_inhibit(struct input_dev *dev)
>>>>> +{
>>>>> + int ret = 0;
>>>>> +
>>>>> + mutex_lock(&dev->mutex);
>>>>> +
>>>>> + if (dev->inhibited)
>>>>> + goto out;
>>>>> +
>>>>> + if (dev->users) {
>>>>> + if (dev->inhibit) {
>>>>> + ret = dev->inhibit(dev);
>>>>> + if (ret)
>>>>> + goto out;
>>>>> + }
>>>>> + input_stop(dev);
>>>>> ^^^^^^^^^^^^^^^^
>>>>>
>>>>> It will not be called when dev->users is zero, but if it is zero,
>>>>> then nobody has opened the device yet so there is nothing to close.
>>>>
>>>> Ah, I missed that.
>>>>
>>>> So if the device implements the inhibit call back then on
>>>> inhibit it will get both the inhibit and close callback called?
>>>>
>>>
>>> That's right. And conversely, upon uninhibit open() and uninhibit()
>>> callbacks will be invoked. Please note that just as with open()/close(),
>>> providing inhibit()/uninhibit() is optional.
>>
>> Ack.
>>
>>>> And what happens if the last user goes away and the device
>>>> is not inhibited?
>>>
>>> close() is called as usually.
>>
>> But not inhibit, hmm, see below.
>>
>>>> I'm trying to understand here what the difference between the 2
>>>> is / what the goal of having a separate inhibit callback ?
>>>>
>>>
>>> Drivers have very different ideas about what it means to suspend/resume
>>> and open/close. The optional inhibit/uninhibit callbacks are meant for
>>> the drivers to know that it is this particular action going on.
>>
>> So the inhibit() callback triggers the "suspend" behavior ?
>> But shouldn't drivers which are capable of suspending the device
>> always do so on close() ?
>>
>> Since your current proposal also calls close() on inhibit() I
>> really see little difference between an inhibit() and the last
>> user of the device closing it and IMHO unless there is a good
>> reason to actually differentiate the 2 it would be better
>> to only stick with the existing close() and in cases where
>> that does not put the device in a low-power mode yet, fix
>> the existing close() callback to do the low-power mode
>> setting instead of adding a new callback.
>>
>>> For inhibit() there's one more argument: close() does not return a value,
>>> so its meaning is "do some last cleanup" and as such it is not allowed
>>> to fail - whatever its effect is, we must deem it successful. inhibit()
>>> does return a value and so it is allowed to fail.
>>
>> Well, we could make close() return an error and at least in the inhibit()
>> case propagate that to userspace. I wonder if userspace is going to
>> do anything useful with that error though...
>>
>> In my experience errors during cleanup/shutdown are best logged
>> (using dev_err) and otherwise ignored, so that we try to clean up
>> as much possible. Unless the very first step of the shutdown process
>> fails the device is going to be in some twilight zone state anyways
>> at this point we might as well try to cleanup as much as possible.
>
> What you say makes sense to me.
> @Dmitry?
>
>>
>>> All in all, it is up to the drivers to decide which callback they
>>> provide. Based on my work so far I would say that there are tens
>>> of simple cases where open() and close() are sufficient, out of total
>>> ~400 users of input_allocate_device():
>>>
>>> $ git grep "input_allocate_device(" | grep -v ^Documentation | \
>>> cut -f1 -d: | sort | uniq | wc
>>> 390 390 13496
>>
>> So can you explain a bit more about the cases where only having
>> open/close is not sufficient? So far I have the feeling that
>> those are all we need and that we really do not need separate
>> [un]inhibit callbacks.
>
> My primary concern was not being able to propagate inhibit() error
> to userspace, and then if we have inhibit(), uninhibit() should be
> there for completeness. If propagating the error to userspace can
> be neglected then yes, it seems open/close should be sufficient,
> even more because the real meaning of "open" is "prepare the device
> for generating input events".
>
> To validate the idea of not introducing inhibit()/uninhibit() callbacks
> to implement device inhibiting/uninhibiting let's look at
> drivers/input/mouse/elan_i2c_core.c (PATCH 7/7):
>
> static int elan_inhibit(struct input_dev *input)
> {
> [...]
>
> ret = mutex_lock_interruptible(&data->sysfs_mutex);
> if (ret)
> return ret;
>
> disable_irq(client->irq);
>
> ret = elan_disable_power(data);
> if (ret)
> enable_irq(client->irq);
> [...]
> }
>
> First, close() does not exist in this driver. Of course this can be
> fixed. Then it doesn't return a value. Then, if either taking the
> mutex or disabling the power fails, the close() is still deemed
> successful. Is it ok?
Note I also mentioned another solution for the error propagation,
which would require a big "flag day" commit adding "return 0"
to all existing close callbacks, but otherwise should work for your
purposes:
> Well, we could make close() return an error and at least in the inhibit()
> case propagate that to userspace. I wonder if userspace is going to
> do anything useful with that error though...
And I guess we could log an error that close failed in the old close() path
where we cannot propagate the error.
Also why the mutex_lock_interruptible() ? If you change that to
a normal mutex_lock() you loose one of the possible 2 error cases and
I doubt anyone is going to do a CTRL-C of the process doing the
inhibiting (or that that process starts a timer using a signal
to ensure the inhibit does not take to long or some such).
Regards,
Hans
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v6] ARM: boot: Obtain start of physical memory from DTB
From: Russell King - ARM Linux admin @ 2020-05-19 9:30 UTC (permalink / raw)
To: Lukasz Stelmach
Cc: Geert Uytterhoeven, Arnd Bergmann, Nicolas Pitre, Masahiro Yamada,
Bartlomiej Zolnierkiewicz, linux-kernel, linux-renesas-soc,
Chris Brandt, Uwe Kleine-König, Eric Miao, Dmitry Osipenko,
Ard Biesheuvel, linux-arm-kernel, Marek Szyprowski
In-Reply-To: <dleftjmu645mqn.fsf%l.stelmach@samsung.com>
On Tue, May 19, 2020 at 10:53:52AM +0200, Lukasz Stelmach wrote:
> It was <2020-04-29 śro 10:21>, when Geert Uytterhoeven wrote:
> > Currently, the start address of physical memory is obtained by masking
> > the program counter with a fixed mask of 0xf8000000. This mask value
> > was chosen as a balance between the requirements of different platforms.
> > However, this does require that the start address of physical memory is
> > a multiple of 128 MiB, precluding booting Linux on platforms where this
> > requirement is not fulfilled.
> >
> > Fix this limitation by obtaining the start address from the DTB instead,
> > if available (either explicitly passed, or appended to the kernel).
> > Fall back to the traditional method when needed.
> >
> > This allows to boot Linux on r7s9210/rza2mevb using the 64 MiB of SDRAM
> > on the RZA2MEVB sub board, which is located at 0x0C000000 (CS3 space),
> > i.e. not at a multiple of 128 MiB.
> >
> > Suggested-by: Nicolas Pitre <nico@fluxnic.net>
> > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> > Reviewed-by: Nicolas Pitre <nico@fluxnic.net>
> > Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
> > Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
> > Tested-by: Dmitry Osipenko <digetx@gmail.com>
> > ---
>
> [...]
>
> Apparently reading physical memory layout from DTB breaks crashdump
> kernels. A crashdump kernel is loaded into a region of memory, that is
> reserved in the original (i.e. to be crashed) kernel. The reserved
> region is large enough for the crashdump kernel to run completely inside
> it and don't modify anything outside it, just read and dump the remains
> of the crashed kernel. Using the information from DTB makes the
> decompressor place the kernel outside of the dedicated region.
>
> The log below shows that a zImage and DTB are loaded at 0x18eb8000 and
> 0x193f6000 (physical). The kernel is expected to run at 0x18008000, but
> it is decompressed to 0x00008000 (see r4 reported before jumping from
> within __enter_kernel).
Right, and it's important that the kernel decompresses to 0x18008000
so it doesn't overwrite memory that was being used by the crashing
kernel, and thus can create a true coredump image of the failed
kernel. Meanwhile, the DTB still needs to describe the full memory
layout so that we know where memory is located in order to coredump
it properly.
So, this is a flaw with this approach, and will need the commit to be
dropped yet again - this patch is fundamentally incompatible with the
way kexec's crashdump works.
Looking back at the history, we've been trying this approach since
February with four patches submitted to the patch system, and problems
eventually found with each of them. I think this shows that the way
the decompressor works out where to decompress the kernel to today is
relied upon all over the place, and changing it is always going to
cause problems. So, I don't think we /can/ change it without causing
a regression for someone.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 10.2Mbps down 587kbps up
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] arm64: vdso: Fix CFI info in sigreturn.
From: Dave Martin @ 2020-05-19 9:29 UTC (permalink / raw)
To: Daniel Kiss
Cc: Mark Rutland, Tamas Zsoldos, Vincenzo Frascino,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <AC859EC1-68DE-4E66-9CD6-D4D42F191D1D@arm.com>
On Mon, May 18, 2020 at 05:00:32PM +0000, Daniel Kiss wrote:
>
>
> > On 18 May 2020, at 17:59, Dave Martin <Dave.Martin@arm.com> wrote:
> >
> > On Fri, May 15, 2020 at 06:20:20PM +0200, dankis01 wrote:
> >> When the signal handler is called the registers set up as the return address
> >> points to the __kernel_rt_sigreturn. The NOP here is the placeholder of the
(Just to be clear about why I originally picked up on this, your
statement about the purpose of the NOP here seems to be an assumption.
Can you say how you reached this conclusion?)
> >> branch and link instruction that "calls" the signal handler. In case of a
> >> return address the unwinder identifies the location of the caller because
> >> in some cases the return address might not exist. Since the .cfi_startproc
> >> is after the NOP, it won't be associated with any location and the
> >> unwinder will stop walking.
> >>
> >> This change corrects the generated EHFrames only.
> >
> > This is a can of worms.
> >
> > Which unwinder are you look at, and what do other unwinders do? Are you
> > sure the unwinder is doing something valid? Is this a newly observed
> > problem, or has it happened forever?
> I run into this with LLVM’s unwinder.
> This combination was always broken.
OK, so we've narrowed the breakage down to one of two things ;)
I still don't see why there must be a valid instruction (or even mapped
memory) before lr. Examples include backtracing noreturn functions, and
backtracing the SIGSEGV when execution falls through into a non-executable
page.
So, sigreturn is just one example if this issue.
This is why I'm not sure the problem is well-understood. Adding a nop
into the __kernel_sigreturn unwind block may paper over this particular
instance, but what about the other similar scenarios?
>
> > Why should there be any instruction that "calls" the signal handler?
> It is just from the unwinder/user space point of view. Normally that instruction would set the return address,
> and some cases in the userspace no instruction is generated for the return address when the compiler knows
> it is unreachable.
>
> > In the case is a SIGSEGV the affected instruction is after the pc and
> > not before it; for an asynchronous signal and notion of a "calling"
> > instruction is nonsense.
> >
> >
> > Certainly I've seen correct unwinding through signal handlers with glibc
> > and gdb, but I hadn't tried everything…
> GDB recognise __kernel_rt_sigreturn to unwind it correctly, as I see it:
> https://github.com/bminor/binutils-gdb/blob/3580810c51bc17c947d0dd6a7f4eb399d7ca4619/gdb/i386-linux-tdep.c#L265
i386?
> >
> >>
> >> Signed-off-by: Daniel Kiss <daniel.kiss@arm.com>
> >> Signed-off-by: Tamas Zsoldos <tamas.zsoldos@arm.com>
> >> ---
> >> arch/arm64/kernel/vdso/sigreturn.S | 4 ++--
> >> 1 file changed, 2 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/arch/arm64/kernel/vdso/sigreturn.S b/arch/arm64/kernel/vdso/sigreturn.S
> >> index 12324863d5c2..5d50ee92faa4 100644
> >> --- a/arch/arm64/kernel/vdso/sigreturn.S
> >> +++ b/arch/arm64/kernel/vdso/sigreturn.S
> >> @@ -13,13 +13,13 @@
> >>
> >> .text
> >>
> >> - nop
> >> -SYM_FUNC_START(__kernel_rt_sigreturn)
> >> .cfi_startproc
> >> .cfi_signal_frame
> >> .cfi_def_cfa x29, 0
> >> .cfi_offset x29, 0 * 8
> >> .cfi_offset x30, 1 * 8
> >
> > Hmm, recovering x29,x30 like this will be wrong if the signal handler
> > munges sigcontext in the meantime (say, doing some kind of userspace
> > context switch).
> >
> > They should be pulled out of sigcontext instead really. AFAIK, that's
> > what ".cfi_signal_frame" is supposed to tell the unwinder. I'm not sure
> > why we have these additional, conflicting annotations here.
> The unwinder won’t find the “cfi_signal_frame” until it figures out the unwind entry.
>
> > Any ideas, Will?
> >
> > This probably isn't related to the bug here, but it would be good to
> > understand.
> >
> >> + nop /* placeholder for bl signalhandler */
> >
> > Will can correct me on this, but I seem to remember something about nop
> > being there for padding, so that there is a guaranteed gap between
> > unwind entries.
> >
> > I can't remember the precise reasoning, but there are some nasty edge
> > cases connected with the fact that the linker can place another random
> > unwind block from another .o immediately before this one.
[...]
Cheers
---Dave
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 07/10] spi: spi-dw-mchp: Add Sparx5 support
From: Lars Povlsen @ 2020-05-19 9:29 UTC (permalink / raw)
To: Mark Brown
Cc: devicetree, Alexandre Belloni, linux-kernel, linux-spi, SoC Team,
Microchip Linux Driver Support, linux-arm-kernel
In-Reply-To: <20200514102516.GD5127@sirena.org.uk>
[Sorry about the slight delay on getting back on this]
On 14/05/20 11:25, Mark Brown wrote:
> Date: Thu, 14 May 2020 11:25:16 +0100
> From: Mark Brown <broonie@kernel.org>
> To: Lars Povlsen <lars.povlsen@microchip.com>
> Cc: SoC Team <soc@kernel.org>, Microchip Linux Driver Support
> <UNGLinuxDriver@microchip.com>, linux-spi@vger.kernel.org,
> devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
> linux-arm-kernel@lists.infradead.org, Alexandre Belloni
> <alexandre.belloni@bootlin.com>
> Subject: Re: [PATCH 07/10] spi: spi-dw-mchp: Add Sparx5 support
> User-Agent: Mutt/1.10.1 (2018-07-13)
>
> On Wed, May 13, 2020 at 04:00:28PM +0200, Lars Povlsen wrote:
>
> > +static void dw_spi_mchp_set_cs_owner(struct dw_spi_mchp *dwsmchp,
> > + const struct dw_spi_mchp_props *props,
> > + u8 cs, u8 owner)
> > {
> > + u8 dummy = (owner == MSCC_IF_SI_OWNER_SIBM ?
> > + MSCC_IF_SI_OWNER_SIMC : MSCC_IF_SI_OWNER_SIBM);
>
> Please write normal conditional statements to improve legibility.
>
I will take your recommendation to heart.
> > +static void dw_spi_mchp_set_cs(struct spi_device *spi, bool nEnable)
> > +{
> > + bool enable = !nEnable; /* This keeps changing in the API... */
>
> No, it doesn't. The API has not changed for more than a decade.
>
I will remove the comment.
I think the comment was related to when we got bitten by the below
change, but alas.
commit ada9e3fcc175db4538f5b5e05abf5dedf626e550
Author: Charles Keepax <ckeepax@opensource.cirrus.com>
Date: Wed Nov 27 15:39:36 2019 +0000
spi: dw: Correct handling of native chipselect
This patch reverts commit 6e0a32d6f376 ("spi: dw: Fix default polarity
of native chipselect").
> > + } else if (props->ss_force_ena_off) {
> > + if (enable) {
> > + /* Ensure CS toggles, so start off all disabled */
> > + regmap_write(dwsmchp->syscon, props->ss_force_val_off,
> > + ~0);
>
> What's all this force_ena_off stuff about? The controller should not be
> making decisions about management of the chip select, this will break
> users.
>
Our controller is not using DMA, but the FIFO interface. And as the DW
controller drops CS when the FIFO runs empty, this will upset SPI
devices. The "ss_force" is something the HW designes put on top to
"override" the CS. We could of course use the GPIO's specifically to
overcome this - but the "boot" CS 0 is a builtin CS, with no
underlying GPIO.
Add to this that the HW dept decided to add *2* physical SPI busses to
the same controller. That we also need to switch between. And ensure
CS gets dropped correctly before changing tracks...
Long story, lot of grief...
> > + if (pdev->dev.of_node) {
> > + int i;
> > +
> > + for (i = 0; i < dws->num_cs; i++) {
> > + int cs_gpio = of_get_named_gpio(pdev->dev.of_node,
> > + "cs-gpios", i);
> > +
> > + if (cs_gpio == -EPROBE_DEFER) {
> > + ret = cs_gpio;
> > + goto out;
> > + }
> > +
> > + if (gpio_is_valid(cs_gpio)) {
> > + ret = devm_gpio_request(&pdev->dev, cs_gpio,
> > + dev_name(&pdev->dev));
> > + if (ret)
> > + goto out;
>
> Set use_gpio_descriptors and let the core manage the GPIO.
Good suggestion, just the ticket!
And thank you very much for your time & comments.
---Lars
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] iomm/arm-smmu: Add stall implementation hook
From: Sai Prakash Ranjan @ 2020-05-19 9:26 UTC (permalink / raw)
To: Will Deacon
Cc: linux-arm-msm, Joerg Roedel,
list@263.net:IOMMU DRIVERS , Joerg Roedel <joro@8bytes.org>, ,
Linux Kernel Mailing List, Rob Clark, Robin Murphy,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <20200518154522.GN32394@willie-the-truck>
Hi Will,
On 2020-05-18 21:15, Will Deacon wrote:
> On Mon, May 11, 2020 at 11:30:08AM -0600, Jordan Crouse wrote:
>> On Fri, May 08, 2020 at 08:40:40AM -0700, Rob Clark wrote:
>> > On Fri, May 8, 2020 at 8:32 AM Rob Clark <robdclark@gmail.com> wrote:
>> > >
>> > > On Thu, May 7, 2020 at 5:54 AM Will Deacon <will@kernel.org> wrote:
>> > > >
>> > > > On Thu, May 07, 2020 at 11:55:54AM +0100, Robin Murphy wrote:
>> > > > > On 2020-05-07 11:14 am, Sai Prakash Ranjan wrote:
>> > > > > > On 2020-04-22 01:50, Sai Prakash Ranjan wrote:
>> > > > > > > Add stall implementation hook to enable stalling
>> > > > > > > faults on QCOM platforms which supports it without
>> > > > > > > causing any kind of hardware mishaps. Without this
>> > > > > > > on QCOM platforms, GPU faults can cause unrelated
>> > > > > > > GPU memory accesses to return zeroes. This has the
>> > > > > > > unfortunate result of command-stream reads from CP
>> > > > > > > getting invalid data, causing a cascade of fail.
>> > > > >
>> > > > > I think this came up before, but something about this rationale doesn't add
>> > > > > up - we're not *using* stalls at all, we're still terminating faulting
>> > > > > transactions unconditionally; we're just using CFCFG to terminate them with
>> > > > > a slight delay, rather than immediately. It's really not clear how or why
>> > > > > that makes a difference. Is it a GPU bug? Or an SMMU bug? Is this reliable
>> > > > > (or even a documented workaround for something), or might things start
>> > > > > blowing up again if any other behaviour subtly changes? I'm not dead set
>> > > > > against adding this, but I'd *really* like to have a lot more confidence in
>> > > > > it.
>> > > >
>> > > > Rob mentioned something about the "bus returning zeroes" before, but I agree
>> > > > that we need more information so that we can reason about this and maintain
>> > > > the code as the driver continues to change. That needs to be a comment in
>> > > > the driver, and I don't think "but android seems to work" is a good enough
>> > > > justification. There was some interaction with HUPCF as well.
>> > >
>> > > The issue is that there are multiple parallel memory accesses
>> > > happening at the same time, for example CP (the cmdstream processor)
>> > > will be reading ahead and setting things up for the next draw or
>> > > compute grid, in parallel with some memory accesses from the shader
>> > > which could trigger a fault. (And with faults triggered by something
>> > > in the shader, there are *many* shader threads running in parallel so
>> > > those tend to generate a big number of faults at the same time.)
>> > >
>> > > We need either CFCFG or HUPCF, otherwise what I have observed is that
>> > > while the fault happens, CP's memory access will start returning
>> > > zero's instead of valid cmdstream data, which triggers a GPU hang. I
>> > > can't say whether this is something unique to qcom's implementation of
>> > > the smmu spec or not.
>> > >
>> > > *Often* a fault is the result of the usermode gl/vk/cl driver bug,
>> > > although I don't think that is an argument against fixing this in the
>> > > smmu driver.. I've been carrying around a local patch to set HUPCF for
>> > > *years* because debugging usermode driver issues is so much harder
>> > > without. But there are some APIs where faults can be caused by the
>> > > user's app on top of the usermode driver.
>> > >
>> >
>> > Also, I'll add to that, a big wish of mine is to have stall with the
>> > ability to resume later from a wq context. That would enable me to
>> > hook in the gpu crash dump handling for faults, which would make
>> > debugging these sorts of issues much easier. I think I posted a
>> > prototype of this quite some time back, which would schedule a worker
>> > on the first fault (since there are cases where you see 1000's of
>> > faults at once), which grabbed some information about the currently
>> > executing submit and some gpu registers to indicate *where* in the
>> > submit (a single submit could have 100's or 1000's of draws), and then
>> > resumed the iommu cb.
>> >
>> > (This would ofc eventually be useful for svm type things.. I expect
>> > we'll eventually care about that too.)
>>
>> Rob is right about HUPCF. Due to the parallel nature of the command
>> processor
>> there is always a very good chance that a CP access is somewhere in
>> the bus so
>> any pagefault is usually a death sentence. The GPU context bank would
>> always
>> want HUPCF set to 1.
>
> So this sounds like an erratum to me, and I'm happy to set HUPCF if we
> detect the broken implementation. However, it will need an entry in
> Documentation/arm64/silicon-errata.rst and a decent comment in the
> driver
> to explain what we're doing and why.
>
AFAIK there is no erratum documented internally for this behaviour and
this
exists from MSM8996 SoC time and errata usually don't survive this long
across generation of SoCs and there is no point for us in disguising it.
Is it OK if we clearly mention it as the "design limitation" or some
other
term which we can agree upon along with the description which Rob and
Jordan
provided for setting HUPCF in the driver when we add the set_hupcf
callback?
Thanks,
Sai
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
member
of Code Aurora Forum, hosted by The Linux Foundation
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 01/20] dt-bindings: arm: gic: Allow combining arm,gic-400 compatible strings
From: André Przywara @ 2020-05-19 9:19 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Mark Rutland, Rob Herring, Lorenzo Pieralisi,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Marc Zyngier, Liviu Dudau, Sudeep Holla, Linux ARM
In-Reply-To: <CAMuHMdXkHF3ioOVzDZQARiO2i1z8rVjdN_Q0VggaVD4Ln7J+Dw@mail.gmail.com>
On 19/05/2020 08:39, Geert Uytterhoeven wrote:
Hi Geert,
> On Wed, May 13, 2020 at 12:31 PM Andre Przywara <andre.przywara@arm.com> wrote:
>> The arm,gic-400 compatible is probably the best matching string for the
>> GIC in most modern SoCs, but was only introduced later into the kernel.
>> For historic reasons and to keep compatibility, some SoC DTs were thus
>> using a combination of this name and one of the older strings, which
>> currently the binding denies.
>>
>> Add a stanza to the DT binding to allow "arm,gic-400", followed by
>> either "arm,cortex-a15-gic" or "arm,cortex-a7-gic". This fixes binding
>> compliance for quite some SoC .dtsi files in the kernel tree.
>>
>> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
>
> Thanks for your patch, I was just looking into this issue ;-)
>
>> --- a/Documentation/devicetree/bindings/interrupt-controller/arm,gic.yaml
>> +++ b/Documentation/devicetree/bindings/interrupt-controller/arm,gic.yaml
>> @@ -39,6 +39,12 @@ properties:
>> - qcom,msm-8660-qgic
>> - qcom,msm-qgic2
>>
>> + - items:
>> + - const: arm,gic-400
>> + - enum:
>> + - arm,cortex-a15-gic
>> + - arm,cortex-a7-gic
>> +
>> - items:
>> - const: arm,arm1176jzf-devchip-gic
>> - const: arm,arm11mp-gic
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/r9a06g032.dtsi#n177
> has them in the other order.
>
> What do you think is the preferred solution: reverting the order, or dropping
> one or the other?
Reverting the order would be the right thing. Theoretically this might
change what the drivers match against, but there should be no difference
between those strings anyway. And certainly Linux does not care which of
the many strings it sees.
The proper order is not really obvious here, but the cortex-a{15,7}-gic
names serve as the missing "arm,gic-v2" generic fallback string here, I
think just for historical reasons.
Cheers,
Andre.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH -next] iommu/sun50i: Fix return value check in sun50i_iommu_probe()
From: Maxime Ripard @ 2020-05-19 9:19 UTC (permalink / raw)
To: Wei Yongjun
Cc: Joerg Roedel, kernel-janitors, Chen-Yu Tsai, linux-kernel,
Hulk Robot, iommu, Philipp Zabel, linux-arm-kernel
In-Reply-To: <20200519091857.134170-1-weiyongjun1@huawei.com>
[-- Attachment #1.1: Type: text/plain, Size: 472 bytes --]
On Tue, May 19, 2020 at 09:18:57AM +0000, Wei Yongjun wrote:
> In case of error, the function devm_platform_ioremap_resource() returns
> ERR_PTR() not NULL. The NULL test in the return value check must be
> replaced with IS_ERR().
>
> Fixes: 4100b8c229b3 ("iommu: Add Allwinner H6 IOMMU driver")
> Reported-by: Hulk Robot <hulkci@huawei.com>
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Acked-by: Maxime Ripard <mripard@kernel.org>
Thanks!
Maxime
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH -next] iommu/sun50i: Fix return value check in sun50i_iommu_probe()
From: Wei Yongjun @ 2020-05-19 9:18 UTC (permalink / raw)
To: Joerg Roedel, Maxime Ripard, Chen-Yu Tsai, Philipp Zabel,
Maxime Ripard
Cc: kernel-janitors, linux-kernel, Hulk Robot, iommu, Wei Yongjun,
linux-arm-kernel
In case of error, the function devm_platform_ioremap_resource() returns
ERR_PTR() not NULL. The NULL test in the return value check must be
replaced with IS_ERR().
Fixes: 4100b8c229b3 ("iommu: Add Allwinner H6 IOMMU driver")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
---
drivers/iommu/sun50i-iommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/sun50i-iommu.c b/drivers/iommu/sun50i-iommu.c
index 9c763d4a8e2a..1fa09ddcebd4 100644
--- a/drivers/iommu/sun50i-iommu.c
+++ b/drivers/iommu/sun50i-iommu.c
@@ -941,7 +941,7 @@ static int sun50i_iommu_probe(struct platform_device *pdev)
}
iommu->base = devm_platform_ioremap_resource(pdev, 0);
- if (!iommu->base) {
+ if (IS_ERR(iommu->base)) {
ret = PTR_ERR(iommu->base);
goto err_free_group;
}
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v2 1/2] arm64: dts: rockchip: fix defines in pd_vio node for rk3399
From: Heiko Stuebner @ 2020-05-19 9:14 UTC (permalink / raw)
To: Johan Jonker
Cc: devicetree, Heiko Stuebner, linux-kernel, linux-rockchip, robh+dt,
linux-arm-kernel
In-Reply-To: <20200428203003.3318-1-jbx6244@gmail.com>
On Tue, 28 Apr 2020 22:30:02 +0200, Johan Jonker wrote:
> A test with the command below gives for example this error:
>
> arch/arm64/boot/dts/rockchip/rk3399-evb.dt.yaml: pd_vio@15:
> 'pd_tcpc0@RK3399_PD_TCPC0', 'pd_tcpc1@RK3399_PD_TCPC1'
> do not match any of the regexes:
> '.*-names$', '.*-supply$', '^#.*-cells$',
> '^#[a-zA-Z0-9,+\\-._]{0,63}$',
> '^[a-zA-Z][a-zA-Z0-9,+\\-._]{0,63}$',
> '^[a-zA-Z][a-zA-Z0-9,+\\-._]{0,63}@[0-9a-fA-F]+(,[0-9a-fA-F]+)*$',
> '^__.*__$', 'pinctrl-[0-9]+'
>
> [...]
Applied, thanks!
[1/1] arm64: dts: rockchip: fix pd_tcpc0 and pd_tcpc1 node position on rk3399
commit: 2b99e6196663199409540fb95798dba464e34343
Best regards,
--
Heiko Stuebner <heiko@sntech.de>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] coresight: dynamic-replicator: Fix handling of multiple connections
From: Sai Prakash Ranjan @ 2020-05-19 9:04 UTC (permalink / raw)
To: Mike Leach, Suzuki K Poulose, Mathieu Poirier
Cc: Russell King, linux-arm-msm, Linux Kernel Mailing List,
linux-arm-kernel, Stephen Boyd
In-Reply-To: <4bd741e342f8e2743197ed6105dacffa@codeaurora.org>
Hi Mike, Suzuki,
On 2020-05-16 15:34, Sai Prakash Ranjan wrote:
> Hi Mike, Suzuki
>
> [...]
>
>>>
>>> Please look at the CoreSight components specification 3.0 (ARM IHI
>>> 0029E) Section B2.1.2 which describes the Unique Component Identifier
>>> (UCI).
>>> As mentioned above this consists of a combination of bits from
>>> multiple registers, including PIDR4.
>>>
>>
>> Ok got it now, thanks for clearing the doubt. I will go ahead with
>> this method to identify QCOM impl and post a patch.
>>
>
> Looking some more into this, since we have this limitation only on
> specific replicator on very few QCOM SoCs, rather than having a blanket
> workaround for all QCOM, we were thinking it would be better to have
> this workaround based on a firmware property something like
> "qcom,replicator-loses-context" for those replicators with this
> limitation and then set the drvdata->check_idfilter_val based on
> this property.
>
Sorry for going back and forth on this one, but I think having a
firmware
property will clearly help us identify the issue on specific SoCs rather
than
wholesale workaround for all QCOM SoCs. For now, I will post a patch
based on
the property "qcom,replicator-loses-context", please feel free to yell
at me
if this is completely wrong and we can discuss it further in that patch.
Thanks,
Sai
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
member
of Code Aurora Forum, hosted by The Linux Foundation
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCHv2 0/7] Support inhibiting input devices
From: Andrzej Pietrasiewicz @ 2020-05-19 9:02 UTC (permalink / raw)
To: Hans de Goede, linux-input, linux-acpi, linux-iio,
linux-arm-kernel, linux-samsung-soc, linux-tegra, patches,
ibm-acpi-devel, platform-driver-x86
Cc: Nick Dyer, Benjamin Tissoires, Laxman Dewangan,
Peter Meerwald-Stadler, kernel, Fabio Estevam, Lars-Peter Clausen,
Krzysztof Kozlowski, Jonathan Hunter, Kukjin Kim, NXP Linux Team,
Sylvain Lemieux, Len Brown, Peter Hutterer, Michael Hennerich,
Sascha Hauer, Henrique de Moraes Holschuh, Vladimir Zapolskiy,
Barry Song, Ferruh Yigit, Dmitry Torokhov, Rafael J . Wysocki,
Thierry Reding, Sangwon Jee, Pengutronix Kernel Team,
Hartmut Knaack, Shawn Guo, Jonathan Cameron
In-Reply-To: <f674ba4f-bd83-0877-c730-5dc6ea09ae4b@redhat.com>
Hi Hans, Hi Dmitry,
W dniu 18.05.2020 o 16:23, Hans de Goede pisze:
> Hi,
<snip>
>>>>>
>>>>> So I wonder what this series actually adds for functionality for
>>>>> userspace which can not already be achieved this way?
>>>>>
>>>>> I also noticed that you keep the device open (do not call the
>>>>> input_device's close callback) when inhibited and just throw away
>>>>
>>>> I'm not sure if I understand you correctly, it is called:
>>>>
>>>> +static inline void input_stop(struct input_dev *dev)
>>>> +{
>>>> + if (dev->poller)
>>>> + input_dev_poller_stop(dev->poller);
>>>> + if (dev->close)
>>>> + dev->close(dev);
>>>> ^^^^^^^^^^^^^^^^
>>>> +static int input_inhibit(struct input_dev *dev)
>>>> +{
>>>> + int ret = 0;
>>>> +
>>>> + mutex_lock(&dev->mutex);
>>>> +
>>>> + if (dev->inhibited)
>>>> + goto out;
>>>> +
>>>> + if (dev->users) {
>>>> + if (dev->inhibit) {
>>>> + ret = dev->inhibit(dev);
>>>> + if (ret)
>>>> + goto out;
>>>> + }
>>>> + input_stop(dev);
>>>> ^^^^^^^^^^^^^^^^
>>>>
>>>> It will not be called when dev->users is zero, but if it is zero,
>>>> then nobody has opened the device yet so there is nothing to close.
>>>
>>> Ah, I missed that.
>>>
>>> So if the device implements the inhibit call back then on
>>> inhibit it will get both the inhibit and close callback called?
>>>
>>
>> That's right. And conversely, upon uninhibit open() and uninhibit()
>> callbacks will be invoked. Please note that just as with open()/close(),
>> providing inhibit()/uninhibit() is optional.
>
> Ack.
>
>>> And what happens if the last user goes away and the device
>>> is not inhibited?
>>
>> close() is called as usually.
>
> But not inhibit, hmm, see below.
>
>>> I'm trying to understand here what the difference between the 2
>>> is / what the goal of having a separate inhibit callback ?
>>>
>>
>> Drivers have very different ideas about what it means to suspend/resume
>> and open/close. The optional inhibit/uninhibit callbacks are meant for
>> the drivers to know that it is this particular action going on.
>
> So the inhibit() callback triggers the "suspend" behavior ?
> But shouldn't drivers which are capable of suspending the device
> always do so on close() ?
>
> Since your current proposal also calls close() on inhibit() I
> really see little difference between an inhibit() and the last
> user of the device closing it and IMHO unless there is a good
> reason to actually differentiate the 2 it would be better
> to only stick with the existing close() and in cases where
> that does not put the device in a low-power mode yet, fix
> the existing close() callback to do the low-power mode
> setting instead of adding a new callback.
>
>> For inhibit() there's one more argument: close() does not return a value,
>> so its meaning is "do some last cleanup" and as such it is not allowed
>> to fail - whatever its effect is, we must deem it successful. inhibit()
>> does return a value and so it is allowed to fail.
>
> Well, we could make close() return an error and at least in the inhibit()
> case propagate that to userspace. I wonder if userspace is going to
> do anything useful with that error though...
>
> In my experience errors during cleanup/shutdown are best logged
> (using dev_err) and otherwise ignored, so that we try to clean up
> as much possible. Unless the very first step of the shutdown process
> fails the device is going to be in some twilight zone state anyways
> at this point we might as well try to cleanup as much as possible.
What you say makes sense to me.
@Dmitry?
>
>> All in all, it is up to the drivers to decide which callback they
>> provide. Based on my work so far I would say that there are tens
>> of simple cases where open() and close() are sufficient, out of total
>> ~400 users of input_allocate_device():
>>
>> $ git grep "input_allocate_device(" | grep -v ^Documentation | \
>> cut -f1 -d: | sort | uniq | wc
>> 390 390 13496
>
> So can you explain a bit more about the cases where only having
> open/close is not sufficient? So far I have the feeling that
> those are all we need and that we really do not need separate
> [un]inhibit callbacks.
My primary concern was not being able to propagate inhibit() error
to userspace, and then if we have inhibit(), uninhibit() should be
there for completeness. If propagating the error to userspace can
be neglected then yes, it seems open/close should be sufficient,
even more because the real meaning of "open" is "prepare the device
for generating input events".
To validate the idea of not introducing inhibit()/uninhibit() callbacks
to implement device inhibiting/uninhibiting let's look at
drivers/input/mouse/elan_i2c_core.c (PATCH 7/7):
static int elan_inhibit(struct input_dev *input)
{
[...]
ret = mutex_lock_interruptible(&data->sysfs_mutex);
if (ret)
return ret;
disable_irq(client->irq);
ret = elan_disable_power(data);
if (ret)
enable_irq(client->irq);
[...]
}
First, close() does not exist in this driver. Of course this can be
fixed. Then it doesn't return a value. Then, if either taking the
mutex or disabling the power fails, the close() is still deemed
successful. Is it ok?
@Dmitry?
Regards,
Andrzej
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Possible race while masking IRQ on Allwinner A20
From: Jérôme Pouiller @ 2020-05-19 8:59 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: Marc Dorval, Chen-Yu Tsai, Maxime Ripard
Hello arm developers,
I have some trouble with integration of the wfx driver[1] on Allwinner
A20 platform.
The chip WF200 is connected to the SDIO bus. At the beginning, I tried
to use the IRQ provided by the SDIO bus. However, I have noticed I
received some IRQs twice. Since the IRQ line is multiplexed with the
data line, it is not very clear if it is a bug, or if the SDIO device
has to support that.
The chip WF200 allows to use a dedicated line for the IRQ (aka
"Out-Of-Band" IRQ). So I have enabled this feature with a edge triggered
IRQ. However, I missed some IRQs. Indeed, it seems that Allwinner use a
32KHz clock to sample the IRQs. It is not fast enough for us. I think it
explains why we miss some IRQs (using the attribute "input-debounce"[2],
I tried to enable the 24Mhz clock, but without success).
Nevermind, I tried to use a level triggered IRQ (and my request is on
this part). As you can see in the wfx driver (in bus_sdio.c and bh.c),
I use a threaded IRQ for that. Unfortunately, I receive some IRQs twice.
I traced the problem, I get:
QSGRenderThread-981 [000] d.h. 247.485524: irq_handler_entry: irq=80 name=wfx
QSGRenderThread-981 [000] d.h. 247.485547: irq_handler_exit: irq=80 ret=handled
QSGRenderThread-981 [000] d.h. 247.485600: irq_handler_entry: irq=80 name=wfx
QSGRenderThread-981 [000] d.h. 247.485606: irq_handler_exit: irq=80 ret=handled
irq/80-wfx-260 [001] .... 247.485828: io_read32: CONTROL: 0000f046
irq/80-wfx-260 [001] .... 247.486072: io_read32: CONTROL: 0000f046
kworker/1:1H-116 [001] .... 247.486214: io_read: QUEUE: 8b 00 84 18 00 00 00 00 01 00 15 82 2b 48 01 1e 88 42 30 00 08 6b d7 c3 53 e0 28 80 88 67 32 af ... (192 bytes)
kworker/1:1H-116 [001] .... 247.493097: io_read: QUEUE: 00 00 00 00 00 00 00 00 06 06 00 6a 3f 95 00 60 00 00 00 00 08 62 00 00 01 00 5e 00 00 07 28 80 ... (192 bytes)
[...]
On this trace, we can see:
- the hard IRQ handler
- the IRQ acknowledge from the thread irq/80-wfx-260
- the access to the data from kworker/1:1H-116
As far as I understand, the first call to the IRQ handler (at
247.485524) should mask the IRQ 80. So, the second IRQ (at 247.485600)
should not happen and the thread irq/80 should be triggered only once.
Do you have any idea of what is going wrong with this IRQ?
Thank you,
[1] available in drivers/staging/wfx of the staging-next branch of the
Greg KH's repository. Be sure you get the up-to-date version.
[2] see commit 7c926492d38a3feef4b4b29c91b7c03eb1b8b546 for detail about
the interactions between clock and debouncing.
--
Jérôme Pouiller
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v6] ARM: boot: Obtain start of physical memory from DTB
From: Lukasz Stelmach @ 2020-05-19 8:53 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Arnd Bergmann, Nicolas Pitre, Masahiro Yamada,
Bartlomiej Zolnierkiewicz, Russell King, linux-kernel,
linux-renesas-soc, Chris Brandt, Uwe Kleine-König, Eric Miao,
Dmitry Osipenko, Ard Biesheuvel, linux-arm-kernel,
Marek Szyprowski
In-Reply-To: <20200429082120.16259-1-geert+renesas@glider.be>
[-- Attachment #1.1: Type: text/plain, Size: 9690 bytes --]
It was <2020-04-29 śro 10:21>, when Geert Uytterhoeven wrote:
> Currently, the start address of physical memory is obtained by masking
> the program counter with a fixed mask of 0xf8000000. This mask value
> was chosen as a balance between the requirements of different platforms.
> However, this does require that the start address of physical memory is
> a multiple of 128 MiB, precluding booting Linux on platforms where this
> requirement is not fulfilled.
>
> Fix this limitation by obtaining the start address from the DTB instead,
> if available (either explicitly passed, or appended to the kernel).
> Fall back to the traditional method when needed.
>
> This allows to boot Linux on r7s9210/rza2mevb using the 64 MiB of SDRAM
> on the RZA2MEVB sub board, which is located at 0x0C000000 (CS3 space),
> i.e. not at a multiple of 128 MiB.
>
> Suggested-by: Nicolas Pitre <nico@fluxnic.net>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> Reviewed-by: Nicolas Pitre <nico@fluxnic.net>
> Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
> Tested-by: Dmitry Osipenko <digetx@gmail.com>
> ---
[...]
Apparently reading physical memory layout from DTB breaks crashdump
kernels. A crashdump kernel is loaded into a region of memory, that is
reserved in the original (i.e. to be crashed) kernel. The reserved
region is large enough for the crashdump kernel to run completely inside
it and don't modify anything outside it, just read and dump the remains
of the crashed kernel. Using the information from DTB makes the
decompressor place the kernel outside of the dedicated region.
The log below shows that a zImage and DTB are loaded at 0x18eb8000 and
0x193f6000 (physical). The kernel is expected to run at 0x18008000, but
it is decompressed to 0x00008000 (see r4 reported before jumping from
within __enter_kernel). If I were to suggest something, there need to be
one more bit of information passed in the DTB telling the decompressor
to use the old masking technique to determain kernel address. It would
be set in the DTB loaded along with the crashdump kernel.
Despite the fact the kernel is able to start and get quite far it simply
panics (for a reason unknown to me at the moment).
Kind regards,
ŁS
--8<---------------cut here---------------start------------->8---
[ 42.358349] kexec_file:__do_sys_kexec_file_load:435: kexec_file: Loading segment 0: buf=0xf1871bcb bufsz=0x52c870 mem=0x18eb8000 memsz=0x52d000
[ 42.374615] kexec_file:__do_sys_kexec_file_load:435: kexec_file: Loading segment 1: buf=0x012365f6 bufsz=0x5abf mem=0x193f6000 memsz=0x6000
root@target:~# sync && echo c > /proc/sysrq-trigger
[ 62.206252] sysrq: Trigger a crash
[ 62.209711] Kernel panic - not syncing: sysrq triggered crash
[ 62.215548] CPU: 0 PID: 1236 Comm: bash Kdump: loaded Tainted: G W 5.7.0-rc6-00011-gad3fbe6a883e #174
[ 62.226225] Hardware name: BCM2711
[ 62.229676] Backtrace:
[ 62.232178] [<c010bfa4>] (dump_backtrace) from [<c010c334>] (show_stack+0x20/0x24)
[ 62.239863] r7:00000008 r6:c0b4a48d r5:00000000 r4:c0eb7b18
[ 62.245617] [<c010c314>] (show_stack) from [<c03e475c>] (dump_stack+0x20/0x28)
[ 62.252954] [<c03e473c>] (dump_stack) from [<c011e368>] (panic+0xf4/0x320)
[ 62.259941] [<c011e274>] (panic) from [<c044bb60>] (sysrq_handle_crash+0x1c/0x20)
[ 62.267536] r3:c044bb44 r2:c57e1c21 r1:60000093 r0:c0b4a48d
[ 62.273278] r7:00000008
[ 62.275853] [<c044bb44>] (sysrq_handle_crash) from [<c044c198>] (__handle_sysrq+0xa0/0x150)
[ 62.284334] [<c044c0f8>] (__handle_sysrq) from [<c044c620>] (write_sysrq_trigger+0x68/0x78)
[ 62.292814] r10:00000002 r9:e9123f50 r8:00000002 r7:012f2408 r6:e9112cc0 r5:c044c5b8
[ 62.300757] r4:00000002
[ 62.303335] [<c044c5b8>] (write_sysrq_trigger) from [<c02a7ad4>] (proc_reg_write+0x98/0xa8)
[ 62.311808] r5:c044c5b8 r4:eb655700
[ 62.315443] [<c02a7a3c>] (proc_reg_write) from [<c023b080>] (__vfs_write+0x48/0xf4)
[ 62.323216] r9:012f2408 r8:c02a7a3c r7:00000002 r6:e9112cc0 r5:e9123f50 r4:c0e04248
[ 62.331077] [<c023b038>] (__vfs_write) from [<c023c900>] (vfs_write+0xa8/0xcc)
[ 62.338407] r8:e9123f50 r7:012f2408 r6:00000002 r5:00000000 r4:e9112cc0
[ 62.345211] [<c023c858>] (vfs_write) from [<c023cae0>] (ksys_write+0x78/0xc4)
[ 62.352454] r9:012f2408 r8:e9123f5c r7:c0e04248 r6:e9123f50 r5:012f2408 r4:e9112cc0
[ 62.360316] [<c023ca68>] (ksys_write) from [<c023cb44>] (sys_write+0x18/0x1c)
[ 62.367559] r10:00000004 r9:e9122000 r8:c0100264 r7:00000004 r6:b6edcd90 r5:012f2408
[ 62.375504] r4:00000002
[ 62.378080] [<c023cb2c>] (sys_write) from [<c0100060>] (ret_fast_syscall+0x0/0x54)
[ 62.385759] Exception stack(0xe9123fa8 to 0xe9123ff0)
[ 62.390889] 3fa0: 00000002 012f2408 00000001 012f2408 00000002 00000000
[ 62.399190] 3fc0: 00000002 012f2408 b6edcd90 00000004 012f2408 00000002 00000000 00118fd8
[ 62.407488] 3fe0: 0000006c be82b7e8 b6df7010 b6e546e4
[ 62.412647] Loading crashdump kernel...
[ 62.416628] Bye!
Uncompressing Linux... done, booting the kernel.
r2:0x193F6000
r4:0x00008000
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 5.7.0-rc6-00011-gad3fbe6a883e (l.stelmach@AMDC1062) (gcc version 8.3.0 (Debian 8.3.0-2), GNU ld (GNU Binutils for Debian) 2.31.1) #174 Tue May 19
09:37:10 CEST 2020
[ 0.000000] CPU: ARMv7 Processor [410fd083] revision 3 (ARMv7), cr=10c5383d
[ 0.000000] CPU: div instructions available: patching division code
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
[ 0.000000] OF: fdt: Machine model: Raspberry Pi 4 Model B
[ 0.000000] earlycon: uart8250 at MMIO32 0xfe215040 (options '')
[ 0.000000] printk: bootconsole [uart8250] enabled
[ 0.000000] Memory policy: Data cache writeback
[ 0.000000] Reserved memory: created CMA memory pool at 0x04000000, size 64 MiB
[ 0.000000] OF: reserved mem: initialized node linux,cma, compatible id shared-dma-pool
[ 0.000000] 8<--- cut here ---
[ 0.000000] Unable to handle kernel paging request at virtual address d93f6000
[ 0.000000] pgd = (ptrval)
[ 0.000000] [d93f6000] *pgd=00000000
[ 0.000000] Internal error: Oops: 5 [#1] ARM
[ 0.000000] Modules linked in:
[ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 5.7.0-rc6-00011-gad3fbe6a883e #174
[ 0.000000] Hardware name: BCM2711
[ 0.000000] PC is at fdt32_ld+0xc/0x18
[ 0.000000] LR is at fdt_check_header+0x14/0x15c
[ 0.000000] pc : [<c03e4b10>] lr : [<c03e4c24>] psr: a00000d3
[ 0.000000] sp : c0e01ed8 ip : c0e01ee8 fp : c0e01ee4
[ 0.000000] r10: c3ffff40 r9 : c0e2e4f4 r8 : 00000000
[ 0.000000] r7 : c0f5b35c r6 : d93f6000 r5 : c0e085d0 r4 : c0d25510
[ 0.000000] r3 : d93f6000 r2 : c0f5b35c r1 : 00000000 r0 : d93f6000
[ 0.000000] Flags: NzCv IRQs off FIQs off Mode SVC_32 ISA ARM Segment none
[ 0.000000] Control: 10c5383d Table: 00004059 DAC: 00000051
[ 0.000000] Process swapper (pid: 0, stack limit = 0x(ptrval))
[ 0.000000] Stack: (0xc0e01ed8 to 0xc0e02000)
[ 0.000000] 1ec0: c0e01f04 c0e01ee8
[ 0.000000] 1ee0: c03e4c24 c03e4b10 c0d25510 c0e085d0 d93f6000 c0f5b35c c0e01f2c c0e01f08
[ 0.000000] 1f00: c05f7d94 c03e4c1c c0d25510 c0e085d0 07ffffff 00000000 c0f4c580 c0e2e4f4
[ 0.000000] 1f20: c0e01f4c c0e01f30 c0d26a54 c05f7ccc 00000000 c0e01f40 c0123458 c0d2ff08
[ 0.000000] 1f40: c0e01fa4 c0e01f50 c0d03c18 c0d26a28 ffffffff 10c5383d c0d0d244 c0e04248
[ 0.000000] 1f60: c0b11587 c09000e7 c0e01f94 c0e01f78 c01580e4 00000000 c0e01f9c c0d00330
[ 0.000000] 1f80: c0e04248 c0e04240 ffffffff 193f6000 c0eb77fc 10c53c7d c0e01ff4 c0e01fa8
[ 0.000000] 1fa0: c0d00b5c c0d035a4 00000000 00000000 00000000 00000000 00000000 c0d31a30
[ 0.000000] 1fc0: 00000000 00000000 00000000 c0d00330 00000051 10c03c7d ffffffff 193f6000
[ 0.000000] 1fe0: 410fd083 10c53c7d 00000000 c0e01ff8 00000000 c0d00b08 00000000 00000000
[ 0.000000] Backtrace:
[ 0.000000] [<c03e4b04>] (fdt32_ld) from [<c03e4c24>] (fdt_check_header+0x14/0x15c)
[ 0.000000] [<c03e4c10>] (fdt_check_header) from [<c05f7d94>] (__unflatten_device_tree+0xd4/0x284)
[ 0.000000] r7:c0f5b35c r6:d93f6000 r5:c0e085d0 r4:c0d25510
[ 0.000000] [<c05f7cc0>] (__unflatten_device_tree) from [<c0d26a54>] (unflatten_device_tree+0x38/0x54)
[ 0.000000] r9:c0e2e4f4 r8:c0f4c580 r7:00000000 r6:07ffffff r5:c0e085d0 r4:c0d25510
[ 0.000000] [<c0d26a1c>] (unflatten_device_tree) from [<c0d03c18>] (setup_arch+0x680/0xabc)
[ 0.000000] r4:c0d2ff08
[ 0.000000] [<c0d03598>] (setup_arch) from [<c0d00b5c>] (start_kernel+0x60/0x500)
[ 0.000000] r10:10c53c7d r9:c0eb77fc r8:193f6000 r7:ffffffff r6:c0e04240 r5:c0e04248
[ 0.000000] r4:c0d00330
[ 0.000000] [<c0d00afc>] (start_kernel) from [<00000000>] (0x0)
[ 0.000000] r10:10c53c7d r9:410fd083 r8:193f6000 r7:ffffffff r6:10c03c7d r5:00000051
[ 0.000000] r4:c0d00330
[ 0.000000] Code: c03e49d0 e1a0c00d e92dd800 e24cb004 (e5900000)
[ 0.000000] random: get_random_bytes called from init_oops_id+0x30/0x4c with crng_init=0
[ 0.000000] ---[ end trace 0000000000000000 ]---
[ 0.000000] Kernel panic - not syncing: Attempted to kill the idle task!
[ 0.000000] ---[ end Kernel panic - not syncing: Attempted to kill the idle task! ]---
--8<---------------cut here---------------end--------------->8---
--
Łukasz Stelmach
Samsung R&D Institute Poland
Samsung Electronics
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [GIT PULL] pinctrl: samsung: Stuff for v5.8
From: Linus Walleij @ 2020-05-19 8:46 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: linux-samsung-soc, Sylwester Nawrocki, Tomasz Figa,
linux-kernel@vger.kernel.org, open list:GPIO SUBSYSTEM, Linux ARM
In-Reply-To: <20200519070240.6510-1-krzk@kernel.org>
On Tue, May 19, 2020 at 9:02 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
> Minor updates for Samsung pinctrl drivers.
Pulled into my "devel" branch, thanks!
Yours,
Linus Walleij
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 3/3] ARM: dts: qcom: Add MikroTik RB3011
From: Jonathan McDowell @ 2020-05-18 18:10 UTC (permalink / raw)
To: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <cover.1589824955.git.noodles@earth.li>
This patch adds a DTS file for the MikroTik RouterBoard 3011, which is a
1U rackmount router based on the IPQ8064, supporting the serial UART,
dual QCA8337 Gigabit ethernet switches, boot loader NOR and user LED
device.
Signed-off-by: Jonathan McDowell <noodles@earth.li>
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/qcom-ipq8064-rb3011.dts | 308 ++++++++++++++++++++++
2 files changed, 309 insertions(+)
create mode 100644 arch/arm/boot/dts/qcom-ipq8064-rb3011.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index e8dd99201397..e697a4bd7426 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -884,6 +884,7 @@ dtb-$(CONFIG_ARCH_QCOM) += \
qcom-ipq4019-ap.dk07.1-c1.dtb \
qcom-ipq4019-ap.dk07.1-c2.dtb \
qcom-ipq8064-ap148.dtb \
+ qcom-ipq8064-rb3011.dtb \
qcom-msm8660-surf.dtb \
qcom-msm8960-cdp.dtb \
qcom-msm8974-fairphone-fp2.dtb \
diff --git a/arch/arm/boot/dts/qcom-ipq8064-rb3011.dts b/arch/arm/boot/dts/qcom-ipq8064-rb3011.dts
new file mode 100644
index 000000000000..282b89ce3d45
--- /dev/null
+++ b/arch/arm/boot/dts/qcom-ipq8064-rb3011.dts
@@ -0,0 +1,308 @@
+// SPDX-License-Identifier: GPL-2.0
+#include "qcom-ipq8064.dtsi"
+#include <dt-bindings/input/input.h>
+
+/ {
+ model = "MikroTik RB3011UiAS-RM";
+ compatible = "mikrotik,rb3011";
+
+ aliases {
+ serial0 = &gsbi7_serial;
+ ethernet0 = &gmac0;
+ ethernet1 = &gmac3;
+ mdio-gpio0 = &mdio0;
+ mdio-gpio1 = &mdio1;
+ };
+
+ chosen {
+ bootargs = "loglevel=8 console=ttyMSM0,115200";
+ stdout-path = "serial0:115200n8";
+ };
+
+ memory@0 {
+ reg = <0x42000000 0x3e000000>;
+ device_type = "memory";
+ };
+
+ mdio0: mdio@0 {
+ status = "okay";
+ compatible = "virtual,mdio-gpio";
+ gpios = <&qcom_pinmux 1 GPIO_ACTIVE_HIGH>,
+ <&qcom_pinmux 0 GPIO_ACTIVE_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pinctrl-0 = <&mdio0_pins>;
+ pinctrl-names = "default";
+
+ switch0: switch@10 {
+ compatible = "qca,qca8337";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ dsa,member = <0 0>;
+
+ pinctrl-0 = <&sw0_reset_pin>;
+ pinctrl-names = "default";
+
+ reset-gpios = <&qcom_pinmux 16 GPIO_ACTIVE_LOW>;
+ reg = <0x10>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ switch0cpu: port@0 {
+ reg = <0>;
+ label = "cpu";
+ ethernet = <&gmac0>;
+ phy-mode = "rgmii-id";
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ label = "sw1";
+ };
+
+ port@2 {
+ reg = <2>;
+ label = "sw2";
+ };
+
+ port@3 {
+ reg = <3>;
+ label = "sw3";
+ };
+
+ port@4 {
+ reg = <4>;
+ label = "sw4";
+ };
+
+ port@5 {
+ reg = <5>;
+ label = "sw5";
+ };
+ };
+ };
+ };
+
+ mdio1: mdio@1 {
+ status = "okay";
+ compatible = "virtual,mdio-gpio";
+ gpios = <&qcom_pinmux 11 GPIO_ACTIVE_HIGH>,
+ <&qcom_pinmux 10 GPIO_ACTIVE_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pinctrl-0 = <&mdio1_pins>;
+ pinctrl-names = "default";
+
+ switch1: switch@14 {
+ compatible = "qca,qca8337";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ dsa,member = <1 0>;
+
+ pinctrl-0 = <&sw1_reset_pin>;
+ pinctrl-names = "default";
+
+ reset-gpios = <&qcom_pinmux 17 GPIO_ACTIVE_LOW>;
+ reg = <0x10>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ switch1cpu: port@0 {
+ reg = <0>;
+ label = "cpu";
+ ethernet = <&gmac3>;
+ phy-mode = "sgmii";
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ label = "sw6";
+ };
+
+ port@2 {
+ reg = <2>;
+ label = "sw7";
+ };
+
+ port@3 {
+ reg = <3>;
+ label = "sw8";
+ };
+
+ port@4 {
+ reg = <4>;
+ label = "sw9";
+ };
+
+ port@5 {
+ reg = <5>;
+ label = "sw10";
+ };
+ };
+ };
+ };
+
+ soc {
+ gsbi5: gsbi@1a200000 {
+ qcom,mode = <GSBI_PROT_SPI>;
+ status = "okay";
+
+ spi4: spi@1a280000 {
+ status = "okay";
+ spi-max-frequency = <50000000>;
+
+ pinctrl-0 = <&spi_pins>;
+ pinctrl-names = "default";
+
+ cs-gpios = <&qcom_pinmux 20 GPIO_ACTIVE_HIGH>;
+
+ norflash: s25fl016k@0 {
+ compatible = "jedec,spi-nor";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ spi-max-frequency = <50000000>;
+ reg = <0>;
+
+ partition@0 {
+ label = "RouterBoot";
+ reg = <0x0 0x40000>;
+ };
+ };
+ };
+ };
+
+ gpio_keys {
+ compatible = "gpio-keys";
+ pinctrl-0 = <&buttons_pins>;
+ pinctrl-names = "default";
+
+ button@1 {
+ label = "reset";
+ linux,code = <KEY_RESTART>;
+ gpios = <&qcom_pinmux 66 GPIO_ACTIVE_LOW>;
+ linux,input-type = <1>;
+ debounce-interval = <60>;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-0 = <&leds_pins>;
+ pinctrl-names = "default";
+
+ led@7 {
+ label = "rb3011:green:user";
+ gpios = <&qcom_pinmux 33 GPIO_ACTIVE_HIGH>;
+ default-state = "off";
+ };
+ };
+
+ };
+};
+
+&gmac0 {
+ status = "okay";
+
+ phy-mode = "rgmii";
+ qcom,id = <0>;
+ phy-handle = <&switch0cpu>;
+
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
+};
+
+&gmac3 {
+ status = "okay";
+
+ phy-mode = "sgmii";
+ qcom,id = <3>;
+ phy-handle = <&switch1cpu>;
+
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
+};
+
+&gsbi7 {
+ status = "okay";
+ qcom,mode = <GSBI_PROT_I2C_UART>;
+};
+
+&gsbi7_serial {
+ status = "okay";
+};
+
+&qcom_pinmux {
+ buttons_pins: buttons_pins {
+ mux {
+ pins = "gpio66";
+ drive-strength = <16>;
+ bias-disable;
+ };
+ };
+
+ leds_pins: leds_pins {
+ mux {
+ pins = "gpio33";
+ drive-strength = <16>;
+ bias-disable;
+ };
+ };
+
+ mdio0_pins: mdio0_pins {
+ mux {
+ pins = "gpio0", "gpio1";
+ function = "gpio";
+ drive-strength = <8>;
+ bias-disable;
+ };
+ };
+
+ mdio1_pins: mdio1_pins {
+ mux {
+ pins = "gpio10", "gpio11";
+ function = "gpio";
+ drive-strength = <8>;
+ bias-disable;
+ };
+ };
+
+ sw0_reset_pin: sw0_reset_pin {
+ mux {
+ pins = "gpio16";
+ drive-strength = <16>;
+ function = "gpio";
+ bias-disable;
+ input-disable;
+ };
+ };
+
+ sw1_reset_pin: sw1_reset_pin {
+ mux {
+ pins = "gpio17";
+ drive-strength = <16>;
+ function = "gpio";
+ bias-disable;
+ input-disable;
+ };
+ };
+};
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 2/3] ARM: dts: qcom: add ethernet definitions to ipq8064
From: Jonathan McDowell @ 2020-05-18 18:09 UTC (permalink / raw)
To: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <cover.1589824955.git.noodles@earth.li>
Plumb in the 4 IPQ8064 stmmac based ethernet interfaces.
Signed-off-by: Jonathan McDowell <noodles@earth.li>
---
arch/arm/boot/dts/qcom-ipq8064.dtsi | 108 ++++++++++++++++++++++++++++
1 file changed, 108 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-ipq8064.dtsi b/arch/arm/boot/dts/qcom-ipq8064.dtsi
index b912da9a3ff3..9c0d5510c805 100644
--- a/arch/arm/boot/dts/qcom-ipq8064.dtsi
+++ b/arch/arm/boot/dts/qcom-ipq8064.dtsi
@@ -597,6 +597,114 @@
perst-gpio = <&qcom_pinmux 63 GPIO_ACTIVE_LOW>;
};
+ nss_common: syscon@03000000 {
+ compatible = "syscon";
+ reg = <0x03000000 0x0000FFFF>;
+ };
+
+ qsgmii_csr: syscon@1bb00000 {
+ compatible = "syscon";
+ reg = <0x1bb00000 0x000001FF>;
+ };
+
+ stmmac_axi_setup: stmmac-axi-config {
+ snps,wr_osr_lmt = <7>;
+ snps,rd_osr_lmt = <7>;
+ snps,blen = <16 0 0 0 0 0 0>;
+ };
+
+ gmac0: ethernet@37000000 {
+ device_type = "network";
+ compatible = "qcom,ipq806x-gmac";
+ reg = <0x37000000 0x200000>;
+ interrupts = <GIC_SPI 220 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "macirq";
+
+ snps,axi-config = <&stmmac_axi_setup>;
+ snps,pbl = <32>;
+ snps,aal = <1>;
+
+ qcom,nss-common = <&nss_common>;
+ qcom,qsgmii-csr = <&qsgmii_csr>;
+
+ clocks = <&gcc GMAC_CORE1_CLK>;
+ clock-names = "stmmaceth";
+
+ resets = <&gcc GMAC_CORE1_RESET>;
+ reset-names = "stmmaceth";
+
+ status = "disabled";
+ };
+
+ gmac1: ethernet@37200000 {
+ device_type = "network";
+ compatible = "qcom,ipq806x-gmac";
+ reg = <0x37200000 0x200000>;
+ interrupts = <GIC_SPI 223 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "macirq";
+
+ snps,axi-config = <&stmmac_axi_setup>;
+ snps,pbl = <32>;
+ snps,aal = <1>;
+
+ qcom,nss-common = <&nss_common>;
+ qcom,qsgmii-csr = <&qsgmii_csr>;
+
+ clocks = <&gcc GMAC_CORE2_CLK>;
+ clock-names = "stmmaceth";
+
+ resets = <&gcc GMAC_CORE2_RESET>;
+ reset-names = "stmmaceth";
+
+ status = "disabled";
+ };
+
+ gmac2: ethernet@37400000 {
+ device_type = "network";
+ compatible = "qcom,ipq806x-gmac";
+ reg = <0x37400000 0x200000>;
+ interrupts = <GIC_SPI 226 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "macirq";
+
+ snps,axi-config = <&stmmac_axi_setup>;
+ snps,pbl = <32>;
+ snps,aal = <1>;
+
+ qcom,nss-common = <&nss_common>;
+ qcom,qsgmii-csr = <&qsgmii_csr>;
+
+ clocks = <&gcc GMAC_CORE3_CLK>;
+ clock-names = "stmmaceth";
+
+ resets = <&gcc GMAC_CORE3_RESET>;
+ reset-names = "stmmaceth";
+
+ status = "disabled";
+ };
+
+ gmac3: ethernet@37600000 {
+ device_type = "network";
+ compatible = "qcom,ipq806x-gmac";
+ reg = <0x37600000 0x200000>;
+ interrupts = <GIC_SPI 229 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "macirq";
+
+ snps,axi-config = <&stmmac_axi_setup>;
+ snps,pbl = <32>;
+ snps,aal = <1>;
+
+ qcom,nss-common = <&nss_common>;
+ qcom,qsgmii-csr = <&qsgmii_csr>;
+
+ clocks = <&gcc GMAC_CORE4_CLK>;
+ clock-names = "stmmaceth";
+
+ resets = <&gcc GMAC_CORE4_RESET>;
+ reset-names = "stmmaceth";
+
+ status = "disabled";
+ };
+
vsdcc_fixed: vsdcc-regulator {
compatible = "regulator-fixed";
regulator-name = "SDCC Power";
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 1/3] dt-bindings: vendor-prefixes: Add MikroTik
From: Jonathan McDowell @ 2020-05-18 18:09 UTC (permalink / raw)
To: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <cover.1589824955.git.noodles@earth.li>
MikroTik (SIA Mikrotīkls) is a Latvian company who develop routers and
wireless ISP systems.
Signed-off-by: Jonathan McDowell <noodles@earth.li>
---
Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index d3891386d671..d3277fe6640b 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -633,6 +633,8 @@ patternProperties:
description: Microsoft Corporation
"^mikroe,.*":
description: MikroElektronika d.o.o.
+ "^mikrotik,.*":
+ description: MikroTik
"^miniand,.*":
description: Miniand Tech
"^minix,.*":
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 0/3] Add initial support for MikroTik RB3011
From: Jonathan McDowell @ 2020-05-18 18:09 UTC (permalink / raw)
To: linux-arm-msm, devicetree, linux-kernel
This patches do some prep (device tree vendor addition, missing ethernet
definitions for IPQ8064 dts) and then add an initial device tree for the
MikroTik RB3011 1U router, which is an IPQ8064 device with 1G RAM. They
are sufficient to boot with an initrd, the serial console and the first
5 switch ports fully functional (the second bank of 5 require some extra
patches to the QCA8K driver which will follow later). The bootloader NOR
is also supported, but the 128MB NAND is not yet enabled.
Jonathan McDowell (3):
dt-bindings: vendor-prefixes: Add MikroTik
ARM: dts: qcom: add ethernet definitions to ipq8064
ARM: dts: qcom: Add MikroTik RB3011
.../devicetree/bindings/vendor-prefixes.yaml | 2 +
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/qcom-ipq8064-rb3011.dts | 308 ++++++++++++++++++
arch/arm/boot/dts/qcom-ipq8064.dtsi | 108 ++++++
4 files changed, 419 insertions(+)
create mode 100644 arch/arm/boot/dts/qcom-ipq8064-rb3011.dts
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: arm64: Register modification during syscall entry/exit stop
From: Keno Fischer @ 2020-05-19 8:37 UTC (permalink / raw)
To: Will Deacon
Cc: Catalin Marinas, Kyle Huey, Oleg Nesterov, linux-arm-kernel,
Linux Kernel Mailing List
In-Reply-To: <20200519081551.GA9980@willie-the-truck>
Hi Will,
> Yes, we inherited this from ARM and I think strace relies on it. In
> hindsight, it is a little odd, although x7 is a parameter register in the
> PCS and so it won't be live on entry to a system call.
I'm not familiar with the PCS acronym, but I assume you mean the
calling convention? You have more faith in userspace than I do ;). For
example, cursory googling brought up this arm64 syscall definition in musl:
https://github.com/bminor/musl/blob/593caa456309714402ca4cb77c3770f4c24da9da/arch/aarch64/syscall_arch.h
The constraints on those asm blocks allow the compiler to assume that
x7 is preserved across the syscall. If a ptracer accidentally modified it
(which is easy to do in the situations that I mentioned), it could
absolutely cause incorrect execution of the userspace program.
> Although the examples you've
> listed above are interesting, I don't see why x7 is important in any of
> them (and we only support up to 6 system call arguments).
It's not so much that x7 is important, it's that lying to the ptracer is
problematic, because it might remember that lie and act on it later.
I did run into exactly this problem, where my ptracer accidentally
changed the value of x7 and caused incorrect execution in the tracee
(now that incorrect execution happened to be an assertion, because
my application is paranoid about these kinds of issues, but it was
incorrect nevertheless)
If it would be helpful, I can code up the syscall entry -> signal trap example
ptracer to have a concrete example.
Keno
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v5 1/5] ARM: at91: add atmel tcb capabilities
From: Kamel Bouhara @ 2020-05-19 8:37 UTC (permalink / raw)
To: William Breathitt Gray, Rob Herring, Mark Rutland, Nicolas Ferre,
Alexandre Belloni, Ludovic Desroches, linux-arm-kernel
Cc: linux-iio, devicetree, Kamel Bouhara, Thomas Petazzoni,
linux-input
In-Reply-To: <20200519083716.938384-1-kamel.bouhara@bootlin.com>
Some atmel socs have extra tcb capabilities that allow using a generic
clock source or enabling a quadrature decoder.
Signed-off-by: Kamel Bouhara <kamel.bouhara@bootlin.com>
---
include/soc/at91/atmel_tcb.h | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/include/soc/at91/atmel_tcb.h b/include/soc/at91/atmel_tcb.h
index c3c7200ce151..1d7071dc0bca 100644
--- a/include/soc/at91/atmel_tcb.h
+++ b/include/soc/at91/atmel_tcb.h
@@ -36,9 +36,14 @@ struct clk;
/**
* struct atmel_tcb_config - SoC data for a Timer/Counter Block
* @counter_width: size in bits of a timer counter register
+ * @has_gclk: boolean indicating if a timer counter has a generic clock
+ * @has_qdec: boolean indicating if a timer counter has a quadrature
+ * decoder.
*/
struct atmel_tcb_config {
size_t counter_width;
+ bool has_gclk;
+ bool has_qdec;
};
/**
--
2.25.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v5 3/5] dt-bindings: microchip: atmel, at91rm9200-tcb: add sama5d2 compatible
From: Kamel Bouhara @ 2020-05-19 8:37 UTC (permalink / raw)
To: William Breathitt Gray, Rob Herring, Mark Rutland, Nicolas Ferre,
Alexandre Belloni, Ludovic Desroches, linux-arm-kernel
Cc: linux-iio, devicetree, Thomas Petazzoni, linux-input
In-Reply-To: <20200519083716.938384-1-kamel.bouhara@bootlin.com>
From: Alexandre Belloni <alexandre.belloni@bootlin.com>
The sama5d2 TC block TIMER_CLOCK1 is different from the at91sam9x5 one.
Instead of being MCK / 2, it is the TCB GCLK.
Cc: Rob Herring <robh+dt@kernel.org>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
---
.../soc/microchip/atmel,at91rm9200-tcb.yaml | 36 +++++++++++++++----
1 file changed, 30 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/soc/microchip/atmel,at91rm9200-tcb.yaml b/Documentation/devicetree/bindings/soc/microchip/atmel,at91rm9200-tcb.yaml
index 4b683151265e..38403760f64d 100644
--- a/Documentation/devicetree/bindings/soc/microchip/atmel,at91rm9200-tcb.yaml
+++ b/Documentation/devicetree/bindings/soc/microchip/atmel,at91rm9200-tcb.yaml
@@ -19,6 +19,7 @@ properties:
- enum:
- atmel,at91rm9200-tcb
- atmel,at91sam9x5-tcb
+ - atmel,sama5d2-tcb
- const: simple-mfd
- const: syscon
@@ -38,12 +39,6 @@ properties:
t1_clk and t2_clk if a clock per channel is available.
minItems: 2
maxItems: 4
- items:
- enum:
- - t0_clk
- - t1_clk
- - t2_clk
- - slow_clk
clocks:
minItems: 2
@@ -72,6 +67,35 @@ patternProperties:
- compatible
- reg
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: atmel,sama5d2-tcb
+ then:
+ properties:
+ clocks:
+ minItems: 3
+ maxItems: 3
+ clock-names:
+ items:
+ - const: t0_clk
+ - const: gclk
+ - const: slow_clk
+ else:
+ properties:
+ clocks:
+ minItems: 2
+ maxItems: 4
+ clock-names:
+ items:
+ enum:
+ - t0_clk
+ - t1_clk
+ - t2_clk
+ - slow_clk
+
required:
- compatible
- reg
--
2.25.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v5 0/5] Microchip TCB Capture driver
From: Kamel Bouhara @ 2020-05-19 8:37 UTC (permalink / raw)
To: William Breathitt Gray, Rob Herring, Mark Rutland, Nicolas Ferre,
Alexandre Belloni, Ludovic Desroches, linux-arm-kernel
Cc: linux-iio, devicetree, Kamel Bouhara, Thomas Petazzoni,
linux-input
Hello,
Here is a new counter driver to support Microchip TCB capture devices.
Each SoC has two TCB blocks, each one including three independent
channels.The following series adds support for two counter modes:
increase and quadrature decoder.
As for the atmel clocksource and pwm, the counter driver needs to fill
some tcb capabilities in order to operate with the right configuration.
This is achieved in first patch of this series.
Please feel free to comment.
Cheers,
Changes in v5:
- Fix duplicate keys errors in yaml dt-schema
Changes in v4:
- Use existing binding to document capture mode of the Microchip TCBs.
Changes in v3:
- Updated the brand name: s/atmel/microchip/.
- Added missing kernel doc for new elements introduced in structure
atmel_tcb_config.
- Removed useless blank line
- Added an explicit clock removing path using devm_add_action_or_reset
Changes in v2:
- Fixed first patch not applying on mainline
- Updated return code to -EINVAL when user is requesting qdec mode on
a counter device not supporting it.
- Added an error case returning -EINVAL when action edge is performed
in
qdec mode.
- Removed no need to explicity setting ops to NULL from static struct
as
it is the default value.
- Changed confusing code by using snprintf for the sake of clarity.
- Changed code to use ARRAY_SIZE so that future reviewers will know
that num_counts matches what's in the atmel_tc_count array without
having to check so themselves.
- Fixed errors reported by dt_binding_check
Alexandre Belloni (2):
dt-bindings: atmel-tcb: convert bindings to json-schema
dt-bindings: microchip: atmel,at91rm9200-tcb: add sama5d2 compatible
Kamel Bouhara (3):
ARM: at91: add atmel tcb capabilities
dt-bindings: counter: microchip-tcb-capture counter
counter: Add microchip TCB capture counter
.../devicetree/bindings/mfd/atmel-tcb.txt | 56 ---
.../soc/microchip/atmel,at91rm9200-tcb.yaml | 176 ++++++++
drivers/counter/Kconfig | 11 +
drivers/counter/Makefile | 1 +
drivers/counter/microchip-tcb-capture.c | 397 ++++++++++++++++++
include/soc/at91/atmel_tcb.h | 5 +
6 files changed, 590 insertions(+), 56 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/mfd/atmel-tcb.txt
create mode 100644 Documentation/devicetree/bindings/soc/microchip/atmel,at91rm9200-tcb.yaml
create mode 100644 drivers/counter/microchip-tcb-capture.c
--
2.25.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox