* [PATCH v4 4/5] ARM: shmobile: Enable NXP pcf85363 rtc in shmobile_defconfig
From: Biju Das @ 2018-12-07 11:27 UTC (permalink / raw)
To: Simon Horman
Cc: linux-rtc, Fabrizio Castro, Alexandre Belloni, Geert Uytterhoeven,
Magnus Damm, Russell King, Biju Das, linux-renesas-soc,
Chris Paterson, Srinivas Kandagatla, linux-arm-kernel
In-Reply-To: <1544182066-31528-1-git-send-email-biju.das@bp.renesas.com>
The iWave RZ/G1C SBC supports RTC (NXP pcf85263). To increase hardware
support enable the driver in the shmobile_defconfig multiplatform
configuration.
Signed-off-by: Biju Das <biju.das@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
V1-->V2
* No change.
V2-->V3
* No change.
V3-->V4
* No Change.
---
arch/arm/configs/shmobile_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/shmobile_defconfig b/arch/arm/configs/shmobile_defconfig
index 9e5a5ad..fdac4e4 100644
--- a/arch/arm/configs/shmobile_defconfig
+++ b/arch/arm/configs/shmobile_defconfig
@@ -177,6 +177,7 @@ CONFIG_LEDS_CLASS=y
CONFIG_LEDS_GPIO=y
CONFIG_RTC_CLASS=y
CONFIG_RTC_DRV_RS5C372=y
+CONFIG_RTC_DRV_PCF85363=y
CONFIG_RTC_DRV_BQ32K=y
CONFIG_RTC_DRV_S35390A=y
CONFIG_RTC_DRV_RX8581=y
--
2.7.4
_______________________________________________
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: [RFC PATCH 4/6] dt-bindings: update mvneta binding document
From: Russell King - ARM Linux @ 2018-12-07 11:33 UTC (permalink / raw)
To: Kishon Vijay Abraham I
Cc: Mark Rutland, Rob Herring, Jason Cooper, Andrew Lunn, netdev,
Gregory CLEMENT, Maxime Chevallier, devicetree, Thomas Petazzoni,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Sebastian Hesselbarth
In-Reply-To: <2ac6488c-a060-6875-bc92-c14fe2dbf8af@ti.com>
On Fri, Dec 07, 2018 at 04:43:27PM +0530, Kishon Vijay Abraham I wrote:
> Russell,
>
> No, I haven't merged patches from this series. That would have failed
> compilation since Grygorii modified enum phy_mode which is used in this series.
> You have also noted this in your cover letter.
Ok, but in any case, given the complexities of modifying the patch
and properly testing it, I think I'll wait until those changes have
hit mainline before re-spinning this series. Alternatively, if
you're happy to take just build-tested version, I could re-spin
with that so at least we can get the phy bits queued for the merge
window.
In any case, I'm busy trying to get to the bottom of several OMAP4
bugs while ill, so this isn't something I want to do at the moment.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [RESEND PATCH] i2c: at91: switched to resume/suspend callbacks.
From: Andrei.Stefanescu @ 2018-12-07 11:33 UTC (permalink / raw)
To: wsa, Nicolas.Ferre, alexandre.belloni, Cristian.Birsan
Cc: Andrei.Stefanescu, linux-i2c, linux-arm-kernel, linux-kernel
In the previous version of the driver resume/suspend_noirq callbacks
were used. Because of this, when resuming from suspend-to-ram,
an I2C (belonging to a FLEXCOM) would resume before FLEXCOM.
The first read on the I2C bus would then result in a timeout.
This patch switches to resume/suspend callbacks which are
called after FLEXCOM resumes. FLEXCOM, SPI and USART drivers use
resume/suspend callbacks.
Signed-off-by: Andrei Stefanescu <andrei.stefanescu@microchip.com>
---
drivers/i2c/busses/i2c-at91.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/i2c/busses/i2c-at91.c b/drivers/i2c/busses/i2c-at91.c
index bfd1fdf..81f7b94 100644
--- a/drivers/i2c/busses/i2c-at91.c
+++ b/drivers/i2c/busses/i2c-at91.c
@@ -1174,7 +1174,7 @@ static int at91_twi_runtime_resume(struct device *dev)
return clk_prepare_enable(twi_dev->clk);
}
-static int at91_twi_suspend_noirq(struct device *dev)
+static int at91_twi_suspend(struct device *dev)
{
if (!pm_runtime_status_suspended(dev))
at91_twi_runtime_suspend(dev);
@@ -1182,7 +1182,7 @@ static int at91_twi_suspend_noirq(struct device *dev)
return 0;
}
-static int at91_twi_resume_noirq(struct device *dev)
+static int at91_twi_resume(struct device *dev)
{
struct at91_twi_dev *twi_dev = dev_get_drvdata(dev);
int ret;
@@ -1202,8 +1202,8 @@ static int at91_twi_resume_noirq(struct device *dev)
}
static const struct dev_pm_ops at91_twi_pm = {
- .suspend_noirq = at91_twi_suspend_noirq,
- .resume_noirq = at91_twi_resume_noirq,
+ .suspend = at91_twi_suspend,
+ .resume = at91_twi_resume,
.runtime_suspend = at91_twi_runtime_suspend,
.runtime_resume = at91_twi_runtime_resume,
};
--
2.7.4
_______________________________________________
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 01/10] mailbox: Support blocking transfers in atomic context
From: Thierry Reding @ 2018-12-07 11:32 UTC (permalink / raw)
To: Jassi Brar, Greg KH
Cc: Devicetree List, mliljeberg, Mikko Perttunen, talho, linux-serial,
jslaby, linux-tegra, ppessi, Jon Hunter, linux-arm-kernel
In-Reply-To: <CABb+yY1G+6MQmrSeZvOXnuREB87+DYHGxNu1tBb9W6apizLtGw@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 10848 bytes --]
On Thu, Dec 06, 2018 at 11:56:25PM -0600, Jassi Brar wrote:
> On Thu, Nov 29, 2018 at 9:23 AM Thierry Reding <thierry.reding@gmail.com> wrote:
> >
> > On Wed, Nov 28, 2018 at 11:23:36PM -0600, Jassi Brar wrote:
> > > On Wed, Nov 28, 2018 at 3:43 AM Jon Hunter <jonathanh@nvidia.com> wrote:
> > > >
> > > >
> > > > On 12/11/2018 15:18, Thierry Reding wrote:
> > > > > From: Thierry Reding <treding@nvidia.com>
> > > > >
> > > > > The mailbox framework supports blocking transfers via completions for
> > > > > clients that can sleep. In order to support blocking transfers in cases
> > > > > where the transmission is not permitted to sleep, add a new ->flush()
> > > > > callback that controller drivers can implement to busy loop until the
> > > > > transmission has been completed. This will automatically be called when
> > > > > available and interrupts are disabled for clients that request blocking
> > > > > transfers.
> > > > >
> > > > > Signed-off-by: Thierry Reding <treding@nvidia.com>
> > > > > ---
> > > > > drivers/mailbox/mailbox.c | 8 ++++++++
> > > > > include/linux/mailbox_controller.h | 4 ++++
> > > > > 2 files changed, 12 insertions(+)
> > > > >
> > > > > diff --git a/drivers/mailbox/mailbox.c b/drivers/mailbox/mailbox.c
> > > > > index 674b35f402f5..0eaf21259874 100644
> > > > > --- a/drivers/mailbox/mailbox.c
> > > > > +++ b/drivers/mailbox/mailbox.c
> > > > > @@ -267,6 +267,14 @@ int mbox_send_message(struct mbox_chan *chan, void *mssg)
> > > > > unsigned long wait;
> > > > > int ret;
> > > > >
> > > > > + if (irqs_disabled() && chan->mbox->ops->flush) {
> > > > > + ret = chan->mbox->ops->flush(chan, chan->cl->tx_tout);
> > > > > + if (ret < 0)
> > > > > + tx_tick(chan, ret);
> > > > > +
> > > > > + return ret;
> > > > > + }
> > > >
> > > > It seems to me that if mbox_send_message() is called from an atomic
> > > > context AND tx_block is true, then if 'flush' is not populated this
> > > > should be an error condition as we do not wish to call
> > > > wait_for_completion from an atomic context.
> > > >
> > > > I understand that there is some debate about adding such flush support,
> > > > but irrespective of the above change, it seems to me that if the
> > > > mbox_send_message() can be called from an atomic context (which it
> > > > appears to), then it should be detecting if someone is trying to do so
> > > > with 'tx_block' set as this should be an error.
> > > >
> > > Layers within kernel space have to trust each other. A badly written
> > > client can break the consumer in so many ways, we can not catch every
> > > possibility.
> > >
> > > > Furthermore, if the underlying mailbox driver can support sending a
> > > > message from an atomic context and busy wait until it is done, surely
> > > > the mailbox framework should provide a means to support this?
> > > >
> > > Being able to put the message on bus in atomic context is a feature -
> > > which we do support. But busy-waiting in a loop is not a feature, and
> > > we don't want to encourage that.
> >
> > I agree that in generally busy-waiting is a bad idea and shouldn't be
> > encouraged. However, I also think that an exception proves the rule. If
> > you look at the console drivers in drivers/tty/serial, all of them will
> > busy loop prior to or after sending a character. This is pretty much
> > part of the API and as such busy-looping is very much a feature.
> >
> > The reason why this is done is because on one hand we have an atomic
> > context and on the other hand we want to make sure that all characters
> > actually make it to the console when we print them.
> >
> > As an example how this can break, I've taken your suggestion to
> > implement a producer/consumer mode in the TCU driver where the console
> > write function will just stash characters into a circular buffer and a
> > work queue will then use mbox_send_message() to drain the circular
> > buffer. While this does work on the surface, I was able to concern both
> > of the issues that I was concerned about: 1) it is easy to overflow the
> > circular buffer by just dumping enough data at once to the console and
> > 2) when a crash happens, everything in the kernel stops, including the
> > consumer workqueue that is supposed to drain the circular buffer and
> > flush messages to the TCU. The result is that, in my particular case,
> > the boot log will just stop at a random place in the middle of messages
> > from much earlier in the boot because the TCU hasn't caught up yet and
> > there's a lot of characters still in the circular buffer.
> >
> > Now, 1) can be mitigated by increasing the circular buffer size. A value
> > that seems to give reliably good results in 2 << CONFIG_LOG_BUF_SHIFT.
> >
> Yes please.
As I explained elsewhere, I actually went and implemented this. But
given the nature of buffering, this ends up making the TCU completely
useless as a console because in case of a crash, the system will stop
working with a large number of characters still stuck in the buffer.
And that's especially bad in case of a crash because those last
characters that get stuck in the buffer are the most relevant ones
because they contain the stack dump.
> > I thought that I could also mitigate 2) by busy looping in the TCU driver,
> > but it turns out that that doesn't work. The reason is that since we are
> > in atomic context with all interrupts disabled, the mailbox won't ever
> > consume any new characters, so the read pointer in the circular buffer
> > won't increment, leaving me with no condition upon which to loop that
> > would work.
> >
> So you want to be able to rely on an emulated console (running on a
> totally different subsystem) to dump development-phase early-boot
> logs? At the cost of legitimizing busy looping in atomic context - one
> random driver messing up the api for ever. Maybe you could have the
> ring buffer in some shmem and only pass the number of valid characters
> in it, to the remote?
First of all, this is not about development-phase early-boot messages.
We're talking about the system console here. This is what everyone will
want to be using when developing on this device. Sure at some point you
may end up with a system that works and you can have the console on the
network or an attached display or whatever, but even then you may still
want to attach to the console if you ever run into issues where the
system doesn't come up.
Secondly, I don't understand why you think this is an emulated console.
The way that this works is that there's a microprocessor in the system
that interacts with other microprocessors via shared mailboxes to
receive log messages. That microprocessor collects these log messages
and outputs them on a physical UART via multiplexed streams. The host
system can connect to that physical UART and demultiplex these streams
to get the individual log messages from each of the components in the
system.
Lastly, I don't understand why you think we're messing up the API here.
The proposal in this series doesn't even change any of the API, but it
makes it aware of the state of interrupts internally so that it can do
the right thing depending on the call stack. The other proposal, in v3,
is more explicit in that it adds new API to flush the mailbox. The new
API is completely optional and I even offered to document it as being
discouraged because it involves busy looping. At the same time it does
solve a real problem and it doesn't impact any existing mailbox drivers
nor any of their users (because it is completely opt-in).
While I can somewhat relate to your reluctance to extend the API, I do
not see a way around it. Sure, you could decide that this is something
that Linux just won't support, but that would be a first. I'm not aware
of any cases where a concious decision was ever made not to support a
feature because it didn't fit into any existing frameworks. Typically
we deal with this by improving things so that we can support the
additional use-cases. It's really one of the strong points of Linux.
I'm open to any suggestions on how this could be done better. You had
already suggested the ring buffer and I did go and implement it, but it
only confirmed the concerns that I've had with it all along. I realize
that at this point I may be blind to other obvious solutions, but I've
done my best to come up with alternatives and none of them work. If you
have any other ideas, please do share them and I will investigate.
> > http://patchwork.ozlabs.org/project/linux-tegra/list/?series=78477
> >
> > The difference to the earlier versions is that the flushing is now
> > explicit. I think this combines the best of both worlds. On one hand it
> > makes the mechanism completely opt-in, so nothing gets hidden in the
> > regular functions. On the other hand, it allows clients to make use of
> > this functionality very explicitly. A client that doesn't call the
> > mbox_flush() function will just not busy-loop. But clients that need to
> > make sure messages are flushed in atomic contexts can now do that. Does
> > that sound like a more acceptable solution to you? We could even go and
> > add documentation to mbox_flush() that it should only be used under
> > special circumstances.
> >
> > If you still think that's a bad idea, do you have any other suggestions
> > on how to move forward?
> >
> It would help if other maintainers chime in if a subsystem should
> support busy-wait in atomic context for a one-off driver.
Just as an additional note: it's not the driver that actually requires
the busy looping, it's the use-case (i.e. the consumer). The driver is
working perfectly fine with interrupts enabled, it's just that in the
particular use-case of the console that we have no way of detecting if
or when an interrupt occurred.
Greg,
any ideas on how we can move forward here? For reasons given elsewhere
in this thread I understand that there is no way to make the console
code run in non-atomic context. Have you ever run into a case where the
console driver couldn't busy-loop? Were there any solutions to this?
I've looked through quite a few drivers and they all end up with a busy
loop, waiting for the transmission FIFO to become empty. There are also
a few implementations for hypervisors that call back into some firmware
in order to send the characters, but I expect those to do the busy
looping in the firmware.
Perhaps the most prominent case that I came across and that is quite
similar to this discussion is netconsole. There's a lot of code in the
network layer that exists only to allow using a network device for
outputting a console. I don't think the changes to the mailbox
framework are anywhere near as complicated.
Thierry
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 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
* [2nd RESEND PATCH 2/2] i2c: at91: Save the bus clock frequency in adapter
From: Tudor.Ambarus @ 2018-12-07 11:29 UTC (permalink / raw)
To: wsa
Cc: alexandre.belloni, Tudor.Ambarus, linux-kernel, Ludovic.Desroches,
linux-i2c, linux-arm-kernel
In-Reply-To: <20181207112939.15791-1-tudor.ambarus@microchip.com>
From: "Tudor.Ambarus@microchip.com" <Tudor.Ambarus@microchip.com>
The clock-frequency property is not mandatory for the i2c buses. If it's
not present in the device tree, the buses __usually__ assume it's 100kHZ
(see altera, at91, axxia, etc.). Broadcom uses a 375kHZ default
clock-frequency, so the default clock frequency varies from bus to bus.
There are i2c clients that need to know the bus clock frequency in order to
compute their wake token (see atecc508a i2c client).
The clock-frequency value has to be propagated to the i2c clients, otherwise,
if they will not find the i2c bus clock frequency in the device tree, they
will have to make their own assumption of the clock frequency.
Spare the i2c clients of making wrong assumptions of the i2c bus clock
frequency and provide the bus clock frequency in adapter.
Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
Acked-by: Ludovic Desroches <ludovic.desroches@microchip.com>
---
drivers/i2c/busses/i2c-at91.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/i2c/busses/i2c-at91.c b/drivers/i2c/busses/i2c-at91.c
index 3f3e8b3bf5ff..9aa0937817ac 100644
--- a/drivers/i2c/busses/i2c-at91.c
+++ b/drivers/i2c/busses/i2c-at91.c
@@ -1124,6 +1124,7 @@ static int at91_twi_probe(struct platform_device *pdev)
dev->adapter.quirks = &at91_twi_quirks;
dev->adapter.dev.parent = dev->dev;
dev->adapter.nr = pdev->id;
+ dev->adapter.bus_freq_hz = bus_clk_rate;
dev->adapter.timeout = AT91_I2C_TIMEOUT;
dev->adapter.dev.of_node = pdev->dev.of_node;
--
2.9.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [2nd RESEND PATCH 1/2] i2c: enable buses to save their clock frequency in adapter
From: Tudor.Ambarus @ 2018-12-07 11:29 UTC (permalink / raw)
To: wsa
Cc: alexandre.belloni, Tudor.Ambarus, linux-kernel, Ludovic.Desroches,
linux-i2c, linux-arm-kernel
In-Reply-To: <20181207112939.15791-1-tudor.ambarus@microchip.com>
From: "Tudor.Ambarus@microchip.com" <Tudor.Ambarus@microchip.com>
The clock-frequency property is not mandatory for the i2c buses. If it's
not present in the device tree, the buses __usually__ assume it's 100kHZ
(see altera, at91, axxia, etc.). Broadcom uses a 375kHZ default
clock-frequency, so the default clock frequency varies from bus to bus.
There are i2c clients that need to know the bus clock frequency in order to
compute their wake token (see atecc508a i2c client).
The clock-frequency value has to be propagated to the i2c clients, otherwise,
if they will not find the i2c bus clock frequency in the device tree, they
will have to make their own assumption of the clock frequency.
Spare the i2c clients of making wrong assumptions of the i2c bus clock
frequency and enable the buses to save their clock frequency in adapter.
Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
Reviwed-by: Ludovic Desroches <ludovic.desroches@microchip.com>
---
include/linux/i2c.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/linux/i2c.h b/include/linux/i2c.h
index 65b4eaed1d96..f238da204c49 100644
--- a/include/linux/i2c.h
+++ b/include/linux/i2c.h
@@ -677,6 +677,7 @@ struct i2c_adapter {
struct rt_mutex bus_lock;
struct rt_mutex mux_lock;
+ u32 bus_freq_hz;
int timeout; /* in jiffies */
int retries;
struct device dev; /* the adapter device */
--
2.9.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [2nd RESEND PATCH 0/2] i2c: enable buses to save their clock frequency in adapter
From: Tudor.Ambarus @ 2018-12-07 11:29 UTC (permalink / raw)
To: wsa
Cc: alexandre.belloni, Tudor.Ambarus, linux-kernel, Ludovic.Desroches,
linux-i2c, linux-arm-kernel
From: Tudor Ambarus <tudor.ambarus@microchip.com>
The clock-frequency property is not mandatory for the i2c buses. If it's
not present in the device tree, the buses __usually__ assume it's 100kHZ
(see altera, at91, axxia, etc.). Broadcom uses a 375kHZ default
clock-frequency, so the default clock frequency varies from bus to bus.
There are i2c clients that need to know the bus clock frequency in order to
compute their wake token (see atecc508a i2c client).
The clock-frequency value has to be propagated to the i2c clients, otherwise,
if they will not find the i2c bus clock frequency in the device tree, they
will have to make their own assumption of the clock frequency.
Spare the i2c clients of making wrong assumptions of the i2c bus clock
frequency and enable the buses to save their clock frequency in adapter.
since rfc:
- reword commit messages
Tudor.Ambarus@microchip.com (2):
i2c: enable buses to save their clock frequency in adapter
i2c: at91: Save the bus clock frequency in adapter
drivers/i2c/busses/i2c-at91.c | 1 +
include/linux/i2c.h | 1 +
2 files changed, 2 insertions(+)
--
2.9.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v7 2/3] clk: clk-max77686: Clean clkdev lookup leak and use devm
From: Matti Vaittinen @ 2018-12-07 11:10 UTC (permalink / raw)
To: matti.vaittinen, mazziesaccount, corbet, cw00.choi, krzk,
b.zolnierkie, mturquette, sboyd, linux, pombredanne, sre, vkoul,
linux, pavel, sjhuang, andrew.smirnov, djkurtz, akshu.agrawal,
rafael.j.wysocki, linux-doc, linux-kernel, linux-clk,
linux-arm-kernel
In-Reply-To: <cover.1544177090.git.matti.vaittinen@fi.rohmeurope.com>
clk-max77686 never clean clkdev lookup at remove. This can cause
oops if clk-max77686 is removed and inserted again. Fix leak by
using new devm clkdev lookup registration. Simplify also error
path by using new devm_of_clk_add_hw_provider.
Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
---
Please note that the patch #2 requires this change to work correctly:
https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git/commit/?h=clk-next&id=05502bf9eb7a7297f5fa6f1d17b169b3d5b53570
drivers/clk/clk-max77686.c | 28 ++++++----------------------
1 file changed, 6 insertions(+), 22 deletions(-)
diff --git a/drivers/clk/clk-max77686.c b/drivers/clk/clk-max77686.c
index 22c937644c93..3727d5472450 100644
--- a/drivers/clk/clk-max77686.c
+++ b/drivers/clk/clk-max77686.c
@@ -235,8 +235,9 @@ static int max77686_clk_probe(struct platform_device *pdev)
return ret;
}
- ret = clk_hw_register_clkdev(&max_clk_data->hw,
- max_clk_data->clk_idata.name, NULL);
+ ret = devm_clk_hw_register_clkdev(dev, &max_clk_data->hw,
+ max_clk_data->clk_idata.name,
+ NULL);
if (ret < 0) {
dev_err(dev, "Failed to clkdev register: %d\n", ret);
return ret;
@@ -244,8 +245,8 @@ static int max77686_clk_probe(struct platform_device *pdev)
}
if (parent->of_node) {
- ret = of_clk_add_hw_provider(parent->of_node, of_clk_max77686_get,
- drv_data);
+ ret = devm_of_clk_add_hw_provider(dev, of_clk_max77686_get,
+ drv_data);
if (ret < 0) {
dev_err(dev, "Failed to register OF clock provider: %d\n",
@@ -261,27 +262,11 @@ static int max77686_clk_probe(struct platform_device *pdev)
1 << MAX77802_CLOCK_LOW_JITTER_SHIFT);
if (ret < 0) {
dev_err(dev, "Failed to config low-jitter: %d\n", ret);
- goto remove_of_clk_provider;
+ return ret;
}
}
return 0;
-
-remove_of_clk_provider:
- if (parent->of_node)
- of_clk_del_provider(parent->of_node);
-
- return ret;
-}
-
-static int max77686_clk_remove(struct platform_device *pdev)
-{
- struct device *parent = pdev->dev.parent;
-
- if (parent->of_node)
- of_clk_del_provider(parent->of_node);
-
- return 0;
}
static const struct platform_device_id max77686_clk_id[] = {
@@ -297,7 +282,6 @@ static struct platform_driver max77686_clk_driver = {
.name = "max77686-clk",
},
.probe = max77686_clk_probe,
- .remove = max77686_clk_remove,
.id_table = max77686_clk_id,
};
--
2.14.3
_______________________________________________
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 V5 4/7] arm64: mm: Offset TTBR1 to allow 52-bit PTRS_PER_PGD
From: Catalin Marinas @ 2018-12-07 11:21 UTC (permalink / raw)
To: Steve Capper
Cc: suzuki.poulose, jcm, ard.biesheuvel, will.deacon, linux-mm,
linux-arm-kernel
In-Reply-To: <20181206225042.11548-5-steve.capper@arm.com>
On Thu, Dec 06, 2018 at 10:50:39PM +0000, Steve Capper wrote:
> Enabling 52-bit VAs on arm64 requires that the PGD table expands from 64
> entries (for the 48-bit case) to 1024 entries. This quantity,
> PTRS_PER_PGD is used as follows to compute which PGD entry corresponds
> to a given virtual address, addr:
>
> pgd_index(addr) -> (addr >> PGDIR_SHIFT) & (PTRS_PER_PGD - 1)
>
> Userspace addresses are prefixed by 0's, so for a 48-bit userspace
> address, uva, the following is true:
> (uva >> PGDIR_SHIFT) & (1024 - 1) == (uva >> PGDIR_SHIFT) & (64 - 1)
>
> In other words, a 48-bit userspace address will have the same pgd_index
> when using PTRS_PER_PGD = 64 and 1024.
>
> Kernel addresses are prefixed by 1's so, given a 48-bit kernel address,
> kva, we have the following inequality:
> (kva >> PGDIR_SHIFT) & (1024 - 1) != (kva >> PGDIR_SHIFT) & (64 - 1)
>
> In other words a 48-bit kernel virtual address will have a different
> pgd_index when using PTRS_PER_PGD = 64 and 1024.
>
> If, however, we note that:
> kva = 0xFFFF << 48 + lower (where lower[63:48] == 0b)
> and, PGDIR_SHIFT = 42 (as we are dealing with 64KB PAGE_SIZE)
>
> We can consider:
> (kva >> PGDIR_SHIFT) & (1024 - 1) - (kva >> PGDIR_SHIFT) & (64 - 1)
> = (0xFFFF << 6) & 0x3FF - (0xFFFF << 6) & 0x3F // "lower" cancels out
> = 0x3C0
>
> In other words, one can switch PTRS_PER_PGD to the 52-bit value globally
> provided that they increment ttbr1_el1 by 0x3C0 * 8 = 0x1E00 bytes when
> running with 48-bit kernel VAs (TCR_EL1.T1SZ = 16).
>
> For kernel configuration where 52-bit userspace VAs are possible, this
> patch offsets ttbr1_el1 and sets PTRS_PER_PGD corresponding to the
> 52-bit value.
>
> Suggested-by: Catalin Marinas <catalin.marinas@arm.com>
> Signed-off-by: Steve Capper <steve.capper@arm.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 2/2] kgdb/treewide: constify struct kgdb_arch arch_kgdb_ops
From: Michael Ellerman @ 2018-12-07 11:15 UTC (permalink / raw)
To: Christophe Leroy, Vineet Gupta, Russell King, Catalin Marinas,
Will Deacon, Yoshinori Sato, Richard Kuo, Michal Simek,
Ralf Baechle, Paul Burton, James Hogan, Ley Foon Tan,
Benjamin Herrenschmidt, Paul Mackerras, Rich Felker,
David S. Miller, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
x86, Jason Wessel, Daniel Thompson, GitAuthor: Christophe Leroy,
Douglas Anderson, Randy Dunlap, Gustavo A. R. Silva
Cc: uclinux-h8-devel, linux-sh, linux-hexagon, linux-kernel,
linux-mips, kgdb-bugreport, sparclinux, nios2-dev, linux-snps-arc,
linuxppc-dev, linux-arm-kernel
In-Reply-To: <5e130b11680be09537913aae9649c84ede763ec8.1544083483.git.christophe.leroy@c-s.fr>
Christophe Leroy <christophe.leroy@c-s.fr> writes:
> checkpatch.pl reports the following:
>
> WARNING: struct kgdb_arch should normally be const
> #28: FILE: arch/mips/kernel/kgdb.c:397:
> +struct kgdb_arch arch_kgdb_ops = {
>
> This report makes sense, as all other ops struct, this
> one should also be const. This patch does the change.
...
> diff --git a/arch/powerpc/kernel/kgdb.c b/arch/powerpc/kernel/kgdb.c
> index 59c578f865aa..bdb588b1d8fb 100644
> --- a/arch/powerpc/kernel/kgdb.c
> +++ b/arch/powerpc/kernel/kgdb.c
> @@ -477,7 +477,7 @@ int kgdb_arch_remove_breakpoint(struct kgdb_bkpt *bpt)
> /*
> * Global data
> */
> -struct kgdb_arch arch_kgdb_ops;
> +const struct kgdb_arch arch_kgdb_ops;
>
> static int kgdb_not_implemented(struct pt_regs *regs)
> {
Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc)
cheers
_______________________________________________
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] media: cedrus: don't initialize pointers with zero
From: Hans Verkuil @ 2018-12-07 11:14 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: devel, Maxime Ripard, Greg Kroah-Hartman, Mauro Carvalho Chehab,
Paul Kocialkowski, Chen-Yu Tsai, linux-arm-kernel,
Linux Media Mailing List
In-Reply-To: <dd25052db89ccf292f2a5e45b7e94e8e6d000c40.1544180158.git.mchehab+samsung@kernel.org>
On 12/07/2018 11:56 AM, Mauro Carvalho Chehab wrote:
> A common mistake is to assume that initializing a var with:
> struct foo f = { 0 };
>
> Would initialize a zeroed struct. Actually, what this does is
> to initialize the first element of the struct to zero.
>
> According to C99 Standard 6.7.8.21:
>
> "If there are fewer initializers in a brace-enclosed
> list than there are elements or members of an aggregate,
> or fewer characters in a string literal used to initialize
> an array of known size than there are elements in the array,
> the remainder of the aggregate shall be initialized implicitly
> the same as objects that have static storage duration."
>
> So, in practice, it could zero the entire struct, but, if the
> first element is not an integer, it will produce warnings:
>
> drivers/staging/media/sunxi/cedrus/cedrus.c:drivers/staging/media/sunxi/cedrus/cedrus.c:78:49: warning: Using plain integer as NULL pointer
> drivers/staging/media/sunxi/cedrus/cedrus_dec.c:drivers/staging/media/sunxi/cedrus/cedrus_dec.c:29:35: warning: Using plain integer as NULL pointer
>
> A proper way to initialize it with gcc is to use:
>
> struct foo f = { };
>
> But that seems to be a gcc extension. So, I decided to check upstream
No, this is not a gcc extension. It's part of the latest C standard.
It's used all over in the kernel, so please use {} instead of { NULL }.
Personally I think {} is a fantastic invention and I wish C++ had it as
well.
Regards,
Hans
> what's the most commonly pattern. The gcc pattern has about 2000 entries:
>
> $ git grep -E "=\s*\{\s*\}"|wc -l
> 1951
>
> The standard-C compliant pattern has about 2500 entries:
>
> $ git grep -E "=\s*\{\s*NULL\s*\}"|wc -l
> 137
> $ git grep -E "=\s*\{\s*0\s*\}"|wc -l
> 2323
>
> So, let's initialize those structs with:
> = { NULL }
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> ---
> drivers/staging/media/sunxi/cedrus/cedrus.c | 2 +-
> drivers/staging/media/sunxi/cedrus/cedrus_dec.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.c b/drivers/staging/media/sunxi/cedrus/cedrus.c
> index b538eb0321d8..44c45c687503 100644
> --- a/drivers/staging/media/sunxi/cedrus/cedrus.c
> +++ b/drivers/staging/media/sunxi/cedrus/cedrus.c
> @@ -75,7 +75,7 @@ static int cedrus_init_ctrls(struct cedrus_dev *dev, struct cedrus_ctx *ctx)
> memset(ctx->ctrls, 0, ctrl_size);
>
> for (i = 0; i < CEDRUS_CONTROLS_COUNT; i++) {
> - struct v4l2_ctrl_config cfg = { 0 };
> + struct v4l2_ctrl_config cfg = { NULL };
>
> cfg.elem_size = cedrus_controls[i].elem_size;
> cfg.id = cedrus_controls[i].id;
> diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
> index e40180a33951..4099a42dba2d 100644
> --- a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
> +++ b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
> @@ -26,7 +26,7 @@ void cedrus_device_run(void *priv)
> {
> struct cedrus_ctx *ctx = priv;
> struct cedrus_dev *dev = ctx->dev;
> - struct cedrus_run run = { 0 };
> + struct cedrus_run run = { NULL };
> struct media_request *src_req;
> unsigned long flags;
>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC PATCH 4/6] dt-bindings: update mvneta binding document
From: Kishon Vijay Abraham I @ 2018-12-07 11:13 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Mark Rutland, Rob Herring, Jason Cooper, Andrew Lunn, netdev,
Gregory CLEMENT, Maxime Chevallier, devicetree, Thomas Petazzoni,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Sebastian Hesselbarth
In-Reply-To: <20181207104142.GY30658@n2100.armlinux.org.uk>
Russell,
On 07/12/18 4:11 PM, Russell King - ARM Linux wrote:
> On Fri, Dec 07, 2018 at 09:37:54AM +0530, Kishon Vijay Abraham I wrote:
>> Hi Russell,
>>
>> On 05/12/18 9:00 PM, Rob Herring wrote:
>>> On Wed, Dec 5, 2018 at 5:00 AM Russell King - ARM Linux
>>> <linux@armlinux.org.uk> wrote:
>>>>
>>>> On Mon, Dec 03, 2018 at 05:54:55PM -0600, Rob Herring wrote:
>>>>> On Mon, Nov 12, 2018 at 12:31:02PM +0000, Russell King wrote:
>>>>>> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
>>>>>
>>>>> Needs a better subject and a commit msg.
>>>>
>>>> Hmm, not sure why it didn't contain:
>>>>
>>>> "dt-bindings: net: mvneta: add phys property
>>>>
>>>> Add an optional phys property to the mvneta binding documentation for
>>>> the common phy.
>>>>
>>>> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>"
>>>>
>>>> as the commit message. With the correct commit message, are you happy
>>>> with it?
>>>
>>> Yes.
>>>
>>> Reviewed-by: Rob Herring <robh@kernel.org>
>>
>> Are you planning to resend this series?
>
> I'm not - you said previously that you had merged the first three
> patches into the phy tree, which are fine. The next two could be
No, I haven't merged patches from this series. That would have failed
compilation since Grygorii modified enum phy_mode which is used in this series.
You have also noted this in your cover letter.
Thanks
Kishon
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] media: cetrus: return an error if alloc fails
From: Mauro Carvalho Chehab @ 2018-12-07 11:13 UTC (permalink / raw)
Cc: devel, Maxime Ripard, Greg Kroah-Hartman, Mauro Carvalho Chehab,
Paul Kocialkowski, Chen-Yu Tsai, Mauro Carvalho Chehab,
linux-arm-kernel, Linux Media Mailing List
As warned by smatch:
drivers/staging/media/sunxi/cedrus/cedrus.c: drivers/staging/media/sunxi/cedrus/cedrus.c:93 cedrus_init_ctrls() error: potential null dereference 'ctx->ctrls'. (kzalloc returns null)
While here, remove the memset(), as kzalloc() already zeroes the
struct.
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
---
drivers/staging/media/sunxi/cedrus/cedrus.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.c b/drivers/staging/media/sunxi/cedrus/cedrus.c
index 44c45c687503..24b89cd2b692 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus.c
+++ b/drivers/staging/media/sunxi/cedrus/cedrus.c
@@ -72,7 +72,8 @@ static int cedrus_init_ctrls(struct cedrus_dev *dev, struct cedrus_ctx *ctx)
ctrl_size = sizeof(ctrl) * CEDRUS_CONTROLS_COUNT + 1;
ctx->ctrls = kzalloc(ctrl_size, GFP_KERNEL);
- memset(ctx->ctrls, 0, ctrl_size);
+ if (!ctx->ctrls)
+ return -ENOMEM;
for (i = 0; i < CEDRUS_CONTROLS_COUNT; i++) {
struct v4l2_ctrl_config cfg = { NULL };
--
2.19.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 v7 3/3] clk: clk-st: avoid clkdev lookup leak at remove
From: Matti Vaittinen @ 2018-12-07 11:10 UTC (permalink / raw)
To: matti.vaittinen, mazziesaccount, corbet, cw00.choi, krzk,
b.zolnierkie, mturquette, sboyd, linux, pombredanne, sre, vkoul,
linux, pavel, sjhuang, andrew.smirnov, djkurtz, akshu.agrawal,
rafael.j.wysocki, linux-doc, linux-kernel, linux-clk,
linux-arm-kernel
In-Reply-To: <cover.1544177090.git.matti.vaittinen@fi.rohmeurope.com>
Use devm based clkdev lookup registration to avoid leaking lookup
structures.
Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
---
drivers/clk/x86/clk-st.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/x86/clk-st.c b/drivers/clk/x86/clk-st.c
index 3a0996f2d556..25d4b97aff9b 100644
--- a/drivers/clk/x86/clk-st.c
+++ b/drivers/clk/x86/clk-st.c
@@ -52,7 +52,8 @@ static int st_clk_probe(struct platform_device *pdev)
0, st_data->base + MISCCLKCNTL1, OSCCLKENB,
CLK_GATE_SET_TO_DISABLE, NULL);
- clk_hw_register_clkdev(hws[ST_CLK_GATE], "oscout1", NULL);
+ devm_clk_hw_register_clkdev(&pdev->dev, hws[ST_CLK_GATE], "oscout1",
+ NULL);
return 0;
}
--
2.14.3
_______________________________________________
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 v7 1/3] clkdev: add managed clkdev lookup registration
From: Matti Vaittinen @ 2018-12-07 11:09 UTC (permalink / raw)
To: matti.vaittinen, mazziesaccount, corbet, cw00.choi, krzk,
b.zolnierkie, mturquette, sboyd, linux, pombredanne, sre, vkoul,
linux, pavel, sjhuang, andrew.smirnov, djkurtz, akshu.agrawal,
rafael.j.wysocki, linux-doc, linux-kernel, linux-clk,
linux-arm-kernel
In-Reply-To: <cover.1544177090.git.matti.vaittinen@fi.rohmeurope.com>
Clkdev registration lacks of managed registration functions and it
seems few drivers do not drop clkdev lookups at exit. Add
devm_clk_hw_register_clkdev and devm_clk_release_clkdev to ease lookup
releasing at exit.
Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
---
Documentation/driver-model/devres.txt | 1 +
drivers/clk/clkdev.c | 111 +++++++++++++++++++++++++++-------
include/linux/clkdev.h | 4 ++
3 files changed, 93 insertions(+), 23 deletions(-)
diff --git a/Documentation/driver-model/devres.txt b/Documentation/driver-model/devres.txt
index 43681ca0837f..dbf14326243b 100644
--- a/Documentation/driver-model/devres.txt
+++ b/Documentation/driver-model/devres.txt
@@ -238,6 +238,7 @@ CLOCK
devm_clk_put()
devm_clk_hw_register()
devm_of_clk_add_hw_provider()
+ devm_clk_hw_register_clkdev()
DMA
dmaenginem_async_device_register()
diff --git a/drivers/clk/clkdev.c b/drivers/clk/clkdev.c
index 9ab3db8b3988..4621f8a91fc0 100644
--- a/drivers/clk/clkdev.c
+++ b/drivers/clk/clkdev.c
@@ -401,6 +401,23 @@ static struct clk_lookup *__clk_register_clkdev(struct clk_hw *hw,
return cl;
}
+static int do_clk_register_clkdev(struct clk_hw *hw,
+ struct clk_lookup **cl, const char *con_id, const char *dev_id)
+{
+ if (IS_ERR(hw))
+ return PTR_ERR(hw);
+ /*
+ * Since dev_id can be NULL, and NULL is handled specially, we must
+ * pass it as either a NULL format string, or with "%s".
+ */
+ if (dev_id)
+ *cl = __clk_register_clkdev(hw, con_id, "%s", dev_id);
+ else
+ *cl = __clk_register_clkdev(hw, con_id, NULL);
+
+ return *cl ? 0 : -ENOMEM;
+}
+
/**
* clk_register_clkdev - register one clock lookup for a struct clk
* @clk: struct clk to associate with all clk_lookups
@@ -423,17 +440,8 @@ int clk_register_clkdev(struct clk *clk, const char *con_id,
if (IS_ERR(clk))
return PTR_ERR(clk);
- /*
- * Since dev_id can be NULL, and NULL is handled specially, we must
- * pass it as either a NULL format string, or with "%s".
- */
- if (dev_id)
- cl = __clk_register_clkdev(__clk_get_hw(clk), con_id, "%s",
- dev_id);
- else
- cl = __clk_register_clkdev(__clk_get_hw(clk), con_id, NULL);
-
- return cl ? 0 : -ENOMEM;
+ return do_clk_register_clkdev(__clk_get_hw(clk), &cl, con_id,
+ dev_id);
}
EXPORT_SYMBOL(clk_register_clkdev);
@@ -456,18 +464,75 @@ int clk_hw_register_clkdev(struct clk_hw *hw, const char *con_id,
{
struct clk_lookup *cl;
- if (IS_ERR(hw))
- return PTR_ERR(hw);
+ return do_clk_register_clkdev(hw, &cl, con_id, dev_id);
+}
+EXPORT_SYMBOL(clk_hw_register_clkdev);
- /*
- * Since dev_id can be NULL, and NULL is handled specially, we must
- * pass it as either a NULL format string, or with "%s".
- */
- if (dev_id)
- cl = __clk_register_clkdev(hw, con_id, "%s", dev_id);
- else
- cl = __clk_register_clkdev(hw, con_id, NULL);
+static void devm_clkdev_release(struct device *dev, void *res)
+{
+ clkdev_drop(*(struct clk_lookup **)res);
+}
- return cl ? 0 : -ENOMEM;
+static int devm_clk_match_clkdev(struct device *dev, void *res, void *data)
+{
+ struct clk_lookup **l = res;
+
+ return *l == data;
}
-EXPORT_SYMBOL(clk_hw_register_clkdev);
+
+/**
+ * devm_clk_release_clkdev - Resource managed clkdev lookup release
+ * @dev: device this lookup is bound
+ * @con_id: connection ID string on device
+ * @dev_id: format string describing device name
+ *
+ * Drop the clkdev lookup created with devm_clk_hw_register_clkdev.
+ * Normally this function will not need to be called and the resource
+ * management code will ensure that the resource is freed.
+ */
+void devm_clk_release_clkdev(struct device *dev, const char *con_id,
+ const char *dev_id)
+{
+ struct clk_lookup *cl;
+ int rval;
+
+ cl = clk_find(dev_id, con_id);
+ WARN_ON(!cl);
+ rval = devres_release(dev, devm_clkdev_release,
+ devm_clk_match_clkdev, cl);
+ WARN_ON(rval);
+}
+EXPORT_SYMBOL(devm_clk_release_clkdev);
+
+/**
+ * devm_clk_hw_register_clkdev - managed clk lookup registration for clk_hw
+ * @dev: device this lookup is bound
+ * @hw: struct clk_hw to associate with all clk_lookups
+ * @con_id: connection ID string on device
+ * @dev_id: format string describing device name
+ *
+ * con_id or dev_id may be NULL as a wildcard, just as in the rest of
+ * clkdev.
+ *
+ * To make things easier for mass registration, we detect error clk_hws
+ * from a previous clk_hw_register_*() call, and return the error code for
+ * those. This is to permit this function to be called immediately
+ * after clk_hw_register_*().
+ */
+int devm_clk_hw_register_clkdev(struct device *dev, struct clk_hw *hw,
+ const char *con_id, const char *dev_id)
+{
+ int rval = -ENOMEM;
+ struct clk_lookup **cl;
+
+ cl = devres_alloc(devm_clkdev_release, sizeof(*cl), GFP_KERNEL);
+ if (cl) {
+ rval = do_clk_register_clkdev(hw, cl, con_id, dev_id);
+ if (!rval)
+ devres_add(dev, cl);
+ else
+ devres_free(cl);
+ }
+ return rval;
+}
+EXPORT_SYMBOL(devm_clk_hw_register_clkdev);
diff --git a/include/linux/clkdev.h b/include/linux/clkdev.h
index 4890ff033220..ccb32af5848b 100644
--- a/include/linux/clkdev.h
+++ b/include/linux/clkdev.h
@@ -52,4 +52,8 @@ int clk_add_alias(const char *, const char *, const char *, struct device *);
int clk_register_clkdev(struct clk *, const char *, const char *);
int clk_hw_register_clkdev(struct clk_hw *, const char *, const char *);
+int devm_clk_hw_register_clkdev(struct device *dev, struct clk_hw *hw,
+ const char *con_id, const char *dev_id);
+void devm_clk_release_clkdev(struct device *dev, const char *con_id,
+ const char *dev_id);
#endif
--
2.14.3
_______________________________________________
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 v3 0/8] Workaround for Cortex-A76 erratum 1165522
From: James Morse @ 2018-12-07 11:09 UTC (permalink / raw)
To: Marc Zyngier
Cc: Mark Rutland, kvm, Suzuki K Poulose, Catalin Marinas, Will Deacon,
Christoffer Dall, kvmarm, linux-arm-kernel
In-Reply-To: <20181206173126.139877-1-marc.zyngier@arm.com>
Hi Marc,
On 06/12/2018 17:31, Marc Zyngier wrote:
> Early Cortex-A76 suffer from an erratum that can result in invalid
> TLBs when the CPU speculatively executes an AT instruction in the
> middle of a guest world switch, while the guest virtual memory
> configuration is in an inconsistent state.
>
> We handle this issue by mandating the use of VHE and making sure that
> the guest context is fully installed before switching HCR_EL2.TGE to
> zero. This ensures that a speculated AT instruction is either executed
> on the host context (TGE set) or the guest context (TGE clear), and
> that there is no intermediate state.
>
> There is some additional complexity in the TLB invalidation code,
> where we most make sure that a speculated AT instruction cannot mess
> the stage-1 TLBs.
For the series:
Reviewed-by: James Morse <james.morse@arm.com>
Thanks,
James
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v7 0/3] clk: clkdev add managed lookup registrations
From: Matti Vaittinen @ 2018-12-07 11:09 UTC (permalink / raw)
To: matti.vaittinen, mazziesaccount, corbet, cw00.choi, krzk,
b.zolnierkie, mturquette, sboyd, linux, pombredanne, sre, vkoul,
linux, pavel, sjhuang, andrew.smirnov, djkurtz, akshu.agrawal,
rafael.j.wysocki, linux-doc, linux-kernel, linux-clk,
linux-arm-kernel
Series adds managed clkdev lookup interfaces and cleans few drivers
Few clk drivers appear to be leaking clkdev lookup registrations at
driver remove. The patch series adds devm versions of lookup
registrations and cleans up few drivers. Driver clean-up patches have
not been tested as I lack the HW. All testing and comments if
driver/device removal is even possible for changed drivers is highly
appreciated. If removal is not possible I will gladly drop the patches
from series - although leaking lookups may serve as bad example for new
developers =)
Changed drivers are:
clk-max77686 and clk-st
Please note that the patch #2 requires this change to work correctly:
https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git/commit/?h=clk-next&id=05502bf9eb7a7297f5fa6f1d17b169b3d5b53570
Changelog v7:
- rewmoved already applied of_provider patches and
now independent bd718x7 patch from the series.
- No functional changes.
Changelog v6
- Drop 'devm_of_clk_add_parent_hw_provider'. Change
'devm_of_clk_add_hw_provider' to look the parent device node for
provider information if device's own node does not contain
#clock-cells - property.
- Add kerneldoc in own patch.
- Remove NULL checks from devres match function for clkdev releasing
- Clean styling issues from clkdev.c
Changelog v5
- Split v4 patch 1. Place clkdev stuff to patch 1 and clk provider to patch 2
- Remove devm_clk_release_clkdev from devres.txt
- Added kerneldoc for managed provider registrations.
- Cleaned styling issues.
Changelog v4
- Add support for ROHM bd718x7 PMIC clock gate. Included in this patch
series because it depends on managed interfaces added in patch 1.
Changelog v3
Address issues spotted by Krzysztof Kozlowski
- Drop patch 3 for clk-s3c2410-dclk as this device can never be removed
- Fix indentiation for clk-max77686
- Rest of the patches are unchanged.
Changelog v2
Issue spotted by 0-Day test suite
- Add a stub function 'devm_of_clk_add_parent_hw_provider' for no OF config.
- patches 2-8 are unchanged.
This patch series is based on clk-next
---
Matti Vaittinen (3):
clkdev: add managed clkdev lookup registration
clk: clk-max77686: Clean clkdev lookup leak and use devm
clk: clk-st: avoid clkdev lookup leak at remove
Documentation/driver-model/devres.txt | 1 +
drivers/clk/clk-max77686.c | 28 ++-------
drivers/clk/clkdev.c | 111 +++++++++++++++++++++++++++-------
drivers/clk/x86/clk-st.c | 3 +-
include/linux/clkdev.h | 4 ++
5 files changed, 101 insertions(+), 46 deletions(-)
--
2.14.3
_______________________________________________
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 0/2] meson: Fix IRQ trigger type
From: Carlo Caione @ 2018-12-07 11:03 UTC (permalink / raw)
To: Jerome Brunet, Emiliano Ingrassia, Martin Blumenstingl
Cc: mark.rutland, devicetree, khilman, robh+dt, linux-amlogic,
linux-arm-kernel
In-Reply-To: <44c9eedf4dc2616645c2a49b080f42a493fe03fd.camel@baylibre.com>
On Fri, 2018-12-07 at 11:49 +0100, Jerome Brunet wrote:
> On Thu, 2018-12-06 at 19:51 +0100, Emiliano Ingrassia wrote:
> > Hi Carlo,
> >
> > I keep running tests with packet generator,
> > using nload to show bandwidth usage.
> >
> > Here is my test results with packet generators
> > both running on laptop and board with rate 1 Gbps.
>
> Testing in UDP is unlikely to give us clear picture of anything for
> this sort
> of fixes.
>
> All your test seems in show it the fact the Amlogic SoC usually
> prioritize the
> TX traffic over RX, which is something we've known about for a while.
>
> It would be helpful if you could provide TCP figures with a traffic
> generator
> we can all share an inspect, such as iperf3
For reference you can use something like:
iperf3 -c ${IP} -i ${IPERF_LOGPERIOD} -w 400k -p ${PORT} -t ${DURATION}
Cheers,
--
Carlo Caione
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] media: cedrus: don't initialize pointers with zero
From: Mauro Carvalho Chehab @ 2018-12-07 10:56 UTC (permalink / raw)
Cc: devel, Maxime Ripard, Greg Kroah-Hartman, Mauro Carvalho Chehab,
Paul Kocialkowski, Chen-Yu Tsai, Mauro Carvalho Chehab,
linux-arm-kernel, Linux Media Mailing List
A common mistake is to assume that initializing a var with:
struct foo f = { 0 };
Would initialize a zeroed struct. Actually, what this does is
to initialize the first element of the struct to zero.
According to C99 Standard 6.7.8.21:
"If there are fewer initializers in a brace-enclosed
list than there are elements or members of an aggregate,
or fewer characters in a string literal used to initialize
an array of known size than there are elements in the array,
the remainder of the aggregate shall be initialized implicitly
the same as objects that have static storage duration."
So, in practice, it could zero the entire struct, but, if the
first element is not an integer, it will produce warnings:
drivers/staging/media/sunxi/cedrus/cedrus.c:drivers/staging/media/sunxi/cedrus/cedrus.c:78:49: warning: Using plain integer as NULL pointer
drivers/staging/media/sunxi/cedrus/cedrus_dec.c:drivers/staging/media/sunxi/cedrus/cedrus_dec.c:29:35: warning: Using plain integer as NULL pointer
A proper way to initialize it with gcc is to use:
struct foo f = { };
But that seems to be a gcc extension. So, I decided to check upstream
what's the most commonly pattern. The gcc pattern has about 2000 entries:
$ git grep -E "=\s*\{\s*\}"|wc -l
1951
The standard-C compliant pattern has about 2500 entries:
$ git grep -E "=\s*\{\s*NULL\s*\}"|wc -l
137
$ git grep -E "=\s*\{\s*0\s*\}"|wc -l
2323
So, let's initialize those structs with:
= { NULL }
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
---
drivers/staging/media/sunxi/cedrus/cedrus.c | 2 +-
drivers/staging/media/sunxi/cedrus/cedrus_dec.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.c b/drivers/staging/media/sunxi/cedrus/cedrus.c
index b538eb0321d8..44c45c687503 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus.c
+++ b/drivers/staging/media/sunxi/cedrus/cedrus.c
@@ -75,7 +75,7 @@ static int cedrus_init_ctrls(struct cedrus_dev *dev, struct cedrus_ctx *ctx)
memset(ctx->ctrls, 0, ctrl_size);
for (i = 0; i < CEDRUS_CONTROLS_COUNT; i++) {
- struct v4l2_ctrl_config cfg = { 0 };
+ struct v4l2_ctrl_config cfg = { NULL };
cfg.elem_size = cedrus_controls[i].elem_size;
cfg.id = cedrus_controls[i].id;
diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
index e40180a33951..4099a42dba2d 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
+++ b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
@@ -26,7 +26,7 @@ void cedrus_device_run(void *priv)
{
struct cedrus_ctx *ctx = priv;
struct cedrus_dev *dev = ctx->dev;
- struct cedrus_run run = { 0 };
+ struct cedrus_run run = { NULL };
struct media_request *src_req;
unsigned long flags;
--
2.19.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 v2 1/2] arm64: dts: meson: Fix IRQ trigger type for macirq
From: Carlo Caione @ 2018-12-07 10:52 UTC (permalink / raw)
To: robh+dt, mark.rutland, khilman, devicetree, linux-arm-kernel,
linux-amlogic, martin.blumenstingl, ingrassia
Cc: Carlo Caione
In-Reply-To: <20181207105231.25593-1-ccaione@baylibre.com>
A long running stress test on a custom board shipping an AXG SoCs and a
Realtek RTL8211F PHY revealed that after a few hours the connection
speed would drop drastically, from ~1000Mbps to ~3Mbps. At the same time
the 'macirq' (eth0) IRQ would stop being triggered at all and as
consequence the GMAC IRQs never ACKed.
After a painful investigation the problem seemed to be due to a wrong
defined IRQ type for the GMAC IRQ that should be LEVEL_HIGH instead of
EDGE_RISING.
The change in the macirq IRQ type also solved another long standing
issue affecting this SoC/PHY where EEE was causing the network
connection to die after stressing it with iperf3 (even though much
sooner). It's now possible to remove the 'eee-broken-1000t' quirk as
well.
Fixes: feb3cbea0946 ("ARM64: dts: meson-gxbb-odroidc2: fix GbE tx link breakage")
Fixes: 6d28d577510f ("ARM64: dts: meson-axg: fix ethernet stability issue")
Reviewed-by: Jerome Brunet <jbrunet@baylibre.com>
Tested-by: Jerome Brunet <jbrunet@baylibre.com>
Acked-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Carlo Caione <ccaione@baylibre.com>
---
arch/arm64/boot/dts/amlogic/meson-axg-s400.dts | 1 -
arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 2 +-
arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 2 +-
arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 1 -
arch/arm64/boot/dts/amlogic/meson-gxbb-wetek.dtsi | 1 -
5 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
index 18778ada7bd3..4d57363ac536 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
@@ -357,7 +357,6 @@
eth_phy0: ethernet-phy@0 {
/* Realtek RTL8211F (0x001cc916) */
reg = <0>;
- eee-broken-1000t;
};
};
};
diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
index df017dbd2e57..b1a42e99cb67 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
@@ -143,7 +143,7 @@
compatible = "amlogic,meson-axg-dwmac", "snps,dwmac";
reg = <0x0 0xff3f0000 0x0 0x10000
0x0 0xff634540 0x0 0x8>;
- interrupts = <GIC_SPI 8 IRQ_TYPE_EDGE_RISING>;
+ interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
interrupt-names = "macirq";
clocks = <&clkc CLKID_ETH>,
<&clkc CLKID_FCLK_DIV2>,
diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
index f1e5cdbade5e..58e6bcaac1d8 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
@@ -462,7 +462,7 @@
compatible = "amlogic,meson-gx-dwmac", "amlogic,meson-gxbb-dwmac", "snps,dwmac";
reg = <0x0 0xc9410000 0x0 0x10000
0x0 0xc8834540 0x0 0x4>;
- interrupts = <GIC_SPI 8 IRQ_TYPE_EDGE_RISING>;
+ interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
interrupt-names = "macirq";
status = "disabled";
};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
index 54954b314a45..f8d1cedbe600 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
@@ -143,7 +143,6 @@
interrupt-parent = <&gpio_intc>;
/* MAC_INTR on GPIOZ_15 */
interrupts = <29 IRQ_TYPE_LEVEL_LOW>;
- eee-broken-1000t;
};
};
};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-wetek.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxbb-wetek.dtsi
index 70325b273bd2..ec09bb5792b7 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-wetek.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-wetek.dtsi
@@ -142,7 +142,6 @@
eth_phy0: ethernet-phy@0 {
/* Realtek RTL8211F (0x001cc916) */
reg = <0>;
- eee-broken-1000t;
};
};
};
--
2.19.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 v2 2/2] arm: dts: meson: Fix IRQ trigger type for macirq
From: Carlo Caione @ 2018-12-07 10:52 UTC (permalink / raw)
To: robh+dt, mark.rutland, khilman, devicetree, linux-arm-kernel,
linux-amlogic, martin.blumenstingl, ingrassia
Cc: Carlo Caione
In-Reply-To: <20181207105231.25593-1-ccaione@baylibre.com>
A long running stress test on a custom board shipping an AXG SoCs and a
Realtek RTL8211F PHY revealed that after a few hours the connection
speed would drop drastically, from ~1000Mbps to ~3Mbps. At the same time
the 'macirq' (eth0) IRQ would stop being triggered at all and as
consequence the GMAC IRQs never ACKed.
After a painful investigation the problem seemed to be due to a wrong
defined IRQ type for the GMAC IRQ that should be LEVEL_HIGH instead of
EDGE_RISING.
The change in the macirq IRQ type also solved another long standing
issue affecting this SoC/PHY where EEE was causing the network
connection to die after stressing it with iperf3 (even though much
sooner). It's now possible to remove the 'eee-broken-1000t' quirk as
well.
Fixes: 9c15795a4f96 ("ARM: dts: meson8b-odroidc1: ethernet support")
Signed-off-by: Carlo Caione <ccaione@baylibre.com>
---
arch/arm/boot/dts/meson.dtsi | 2 +-
arch/arm/boot/dts/meson8b-odroidc1.dts | 1 -
2 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/meson.dtsi b/arch/arm/boot/dts/meson.dtsi
index 0d9faf1a51ea..a86b89086334 100644
--- a/arch/arm/boot/dts/meson.dtsi
+++ b/arch/arm/boot/dts/meson.dtsi
@@ -263,7 +263,7 @@
compatible = "amlogic,meson6-dwmac", "snps,dwmac";
reg = <0xc9410000 0x10000
0xc1108108 0x4>;
- interrupts = <GIC_SPI 8 IRQ_TYPE_EDGE_RISING>;
+ interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>;
interrupt-names = "macirq";
status = "disabled";
};
diff --git a/arch/arm/boot/dts/meson8b-odroidc1.dts b/arch/arm/boot/dts/meson8b-odroidc1.dts
index 58669abda259..a951a6632d0c 100644
--- a/arch/arm/boot/dts/meson8b-odroidc1.dts
+++ b/arch/arm/boot/dts/meson8b-odroidc1.dts
@@ -221,7 +221,6 @@
/* Realtek RTL8211F (0x001cc916) */
eth_phy: ethernet-phy@0 {
reg = <0>;
- eee-broken-1000t;
interrupt-parent = <&gpio_intc>;
/* GPIOH_3 */
interrupts = <17 IRQ_TYPE_LEVEL_LOW>;
--
2.19.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 v2 0/2] meson: Fix IRQ trigger type
From: Carlo Caione @ 2018-12-07 10:52 UTC (permalink / raw)
To: robh+dt, mark.rutland, khilman, devicetree, linux-arm-kernel,
linux-amlogic, martin.blumenstingl, ingrassia
Cc: Carlo Caione
The wrong IRQ trigger type for the macirq was causing the connection
speed to drop after a few hours when stress testing the DUT. The fix
seems also to fix another long standing issue with EEE.
The fixes are tested on a AXG board but we think that the same fix is
valid also for all the others Amlogic SoC families.
Changelog:
V2:
- Merge arm64 patches in one single patch
- Merge arm patches in a different patch
- Added T/R/A to the arm64 patch
Carlo Caione (2):
arm64: dts: meson: Fix IRQ trigger type for macirq
arm: dts: meson: Fix IRQ trigger type for macirq
arch/arm/boot/dts/meson.dtsi | 2 +-
arch/arm/boot/dts/meson8b-odroidc1.dts | 1 -
arch/arm64/boot/dts/amlogic/meson-axg-s400.dts | 1 -
arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 2 +-
arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 2 +-
arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 1 -
arch/arm64/boot/dts/amlogic/meson-gxbb-wetek.dtsi | 1 -
7 files changed, 3 insertions(+), 7 deletions(-)
--
2.19.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 0/2] meson: Fix IRQ trigger type
From: Jerome Brunet @ 2018-12-07 10:49 UTC (permalink / raw)
To: Emiliano Ingrassia, Carlo Caione, Martin Blumenstingl
Cc: mark.rutland, devicetree, khilman, robh+dt, linux-amlogic,
linux-arm-kernel
In-Reply-To: <20181206185158.GA19901@ingrassia.epigenesys.com>
On Thu, 2018-12-06 at 19:51 +0100, Emiliano Ingrassia wrote:
> Hi Carlo,
>
> I keep running tests with packet generator,
> using nload to show bandwidth usage.
>
> Here is my test results with packet generators
> both running on laptop and board with rate 1 Gbps.
Testing in UDP is unlikely to give us clear picture of anything for this sort
of fixes.
All your test seems in show it the fact the Amlogic SoC usually prioritize the
TX traffic over RX, which is something we've known about for a while.
It would be helpful if you could provide TCP figures with a traffic generator
we can all share an inspect, such as iperf3
Finally, Your test do not show the original issue regarding EEE. So the work
around we put (yes, it was never considered a solution) for it should not be
kept IHMO. Your numbers for EEE may be due to the way the traffic is generated
and the PHY entering LPI and taking a bit of time to exit it. Again UDP is not
very helpful to characterize this.
>
> TEST 0: no patch applied.
>
> 1) Start packet generator on laptop:
>
> | incoming traffic | outgoing traffic
> =====================================================
> nload (board) | ~940 Mbps | 0 Mbps
> -----------------------------------------------------
> nload (laptop)| 0 Mbps | ~940 Mbps
> =====================================================
>
> 2) Start packet generator on board:
>
> | incoming traffic | outgoing traffic
> ==============+===================+==================
> nload (board) | ~460 Mbps | ~256 Mbps
> --------------+-------------------+------------------
> nload (laptop)| ~256 Mbps | ~940 Mbps
> =====================================================
>
> 3) Stop packet generator on laptop:
>
> | incoming traffic | outgoing traffic
> =====================================================
> nload (board) | 0 Mbps | ~940 Mbps
> -----------------------------------------------------
> nload (laptop)| ~940 Mbps | 0 Mbps
> =====================================================
>
> 4) Restart packet generator on laptop:
>
> | incoming traffic | outgoing traffic
> =====================================================
> nload (board) | ~0 Mbps | ~940 Mbps
> -----------------------------------------------------
> nload (laptop)| ~940 Mbps | ~940 Mbps
> =====================================================
>
> In the last case the "ifconfig" statistics about RX packets
> remain fixed which probably indicates that the incoming traffic
> to the board is effectively being dropped.
>
> The eth0 interrupt counter keeps incrementing.
> Simple ping test works correctly.
>
>
> TEST 1: IRQ type patch applied
>
> Same results as TEST 0.
>
>
> TEST 2: eee-broken-1000t flag removed
>
> 1) Start packet generator on laptop:
>
> | incoming traffic | outgoing traffic
> =====================================================
> nload (board) | ~3Mbps | 0 Mbps
> -----------------------------------------------------
> nload (laptop)| 0 Mbps | ~940 Mbps
> =====================================================
>
> 2) Start packet generator on board:
>
> | incoming traffic | outgoing traffic
> ==============+===================+==================
> nload (board) | ~0 Mbps | ~940 Mbps
> --------------+-------------------+------------------
> nload (laptop)| ~940 Mbps | ~940 Mbps
> =====================================================
>
> 3) Stop packet generator on laptop:
>
> | incoming traffic | outgoing traffic
> =====================================================
> nload (board) | 0 Mbps | ~940 Mbps
> -----------------------------------------------------
> nload (laptop)| ~940 Mbps | 0 Mbps
> =====================================================
>
> 4) Restart packet generator on laptop:
>
> | incoming traffic | outgoing traffic
> =====================================================
> nload (board) | ~0 Mbps | ~940 Mbps
> -----------------------------------------------------
> nload (laptop)| ~940 Mbps | ~940 Mbps
> =====================================================
>
> In the first case the "ifconfig" statistics about RX packets
> are incremented consistently with the incoming traffic value
> showed by the nload (board side).
>
> In the last case the "ifconfig" statistics about RX packets
> remain fixed which probably indicates that the incoming traffic
> to the board is effectively being dropped.
>
> The eth0 interrupt counter keeps incrementing.
> Simple ping test from laptop to board shows a packet loss
> of 90% and more while no packet loss achieved pinging
> the laptop from the board.
>
>
> TEST 3: both patches applied.
>
> Same results as TEST 2.
>
>
> From the results obtained from these tests,
> which are more accurate than the previous one,
> I can say that the second patch (remove eee-broken-1000t flag)
> should NOT be applied.
>
> About the first one (change MAC IRQ type), I would like
> to do other tests with other tools like iperf3.
> With these results only, I would say to not apply it
> because nothing changed but if your stress test failed on
> long running and this patch fix it I would like to test it more deeply.
>
> As final thought, the conducted tests clearly show that if the board
> transmits at full rate, all the incoming traffic is dropped.
> I think that this behaviour should be fixed but don't know if
> it depends on the driver or device tree description.
> I'll keep investigating.
>
> Regards,
>
> Emiliano
>
> On Thu, Dec 06, 2018 at 04:52:28PM +0100, Emiliano Ingrassia wrote:
> > Hi Carlo,
> >
> > thanks for the answer.
> >
> > On Thu, Dec 06, 2018 at 01:17:58PM +0000, Carlo Caione wrote:
> > > On Thu, 2018-12-06 at 13:43 +0100, Emiliano Ingrassia wrote:
> > > > Hi all,
> > >
> > > Hi Emiliano,
> > >
> > > > thank you for involving me.
> > > >
> > > > I applied Carlo's patches[0] on a kernel vanilla 4.19.6
> > > > and tested it with kernel packet generator, monitoring
> > > > bandwidth usage with "nload".
> > > >
> > > > All tests were conducted on an Odroid-C1+ Rev. 0.4-20150930 board
> > > > with a short ethernet cable directly attached to a laptop with
> > > > 1G ethernet interface, with "nload" running on the board.
> > > >
> > > > The tests I performed are composed by the following steps:
> > > >
> > > > 1) Start packet generator with "rate 1000M" on laptop;
> > > >
> > > > 2) Keep packet generator active on the laptop and
> > > > start the packet generator on the board with "rate 1000M";
> > > >
> > > > 3) Stop both packet generators;
> > > >
> > > > 4) Start packet generator on the board;
> > > >
> > > > 5) Keep packet generator active on the board and
> > > > start the packet generator on the laptop.
> > >
> > > out of curiosity: why do you expect to see something different from
> > > point (2)?
> > >
> >
> > I did not expect it indeed, I tried and got different results.
> >
> > > > Test results without Carlo's patches applied:
> > > >
> > > > 1) "nload" shows an incoming traffic of ~950Mbps;
> > > >
> > > > 2) "nload" shows an incoming traffic of ~400Mbps
> > > > and an outgoing traffic of ~250Mbps;
> > > >
> > > > 3) "nload" shows 0Mbps both for incoming and outgoing traffic;
> > > >
> > > > 4) "nload" shows an outgoing traffic of ~950Mbps from the board;
> > > >
> > > > 5) "nload" shows incoming traffic of 0Mbps
> > > > and an outgoing traffic of ~950Mbps.
> > > >
> > > > Applying only the first patch (change mac IRQ type) I got the same
> > > > results.
> > >
> > > This is expected. The change in the IRQ type is solving an issue that
> > > you can see if the run a stress test involving multiple components for
> > > several hours.
> > >
> >
> > OK, did you use "stress-ng" tool for tests?
> >
> > > > Applying only the second patch (drop eee-broken-1000t) I got the same
> > > > results!
> > >
> > > I am a bit confused here. Wasn't the eee-broken-1000t added to fix a
> > > problem with the ethernet? Are you suggesting that for some reason you
> > > cannot reproduce anymore the problem for which the quirk was
> > > introduced?
> > >
> >
> > Problems without the "eee-broken-1000t" flags were experimented
> > one and a half years ago on a Amlogic development kernel from [0],
> > probably a 4.14 version.
> > Many patches about Meson8b SoC, dwmac-meson8b and dwmac driver
> > were introduced so yes, the "eee-broken-1000t" was added
> > to fix a problem with the ethernet (one and a half years ago),
> > but new tests are needed to say if it still necessary.
> >
> > > > With both patches applied I got the same results but with an incoming
> > > > traffic
> > > > of ~3Mbps on the board.
> > >
> > > On all the tests and immediately from the start of the tests?
> > >
> >
> > Yes, in all the 5 steps immediately from the start.
> >
> > I also tried to execute "nload" on both sides to see the bandwidth
> > usage.
> >
> > With bot patches applied, after starting kernel packet generator
> > on my laptop with 1Gbps rate, "nload" on the laptop side shows me
> > an outgoing traffic of ~940Mbps while "nload" on the board side shows
> > me an incoming traffic of ~3Mbps.
> >
> > Also consider that a pinging test from my laptop to the board shows
> > a packet loss of about 90%.
> >
> > > When you hit the problem con you check in /proc/interrupts if you see
> > > the IRQ counter for the eth0 incrementing or not?
> > >
> >
> > The eth0 IRQ counter is incremented during the test.
> >
> > > Cheers,
> > >
> > > --
> > > Carlo Caione
> > >
> > >
> >
> > I would like to conduct other tests with iperf3 to be sure about
> > the obtained results. What do you think?
> > Should I apply your patches on the latest Amlogic development kernel?
> >
> > Regards,
> >
> > Emiliano
> >
> > [0]
> > https://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-amlogic.git/
>
> Cheers,
>
> Emiliano
>
> _______________________________________________
> linux-amlogic mailing list
> linux-amlogic@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-amlogic
_______________________________________________
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 v7 2/2] mtd: rawnand: meson: add support for Amlogic NAND flash controller
From: Miquel Raynal @ 2018-12-07 10:48 UTC (permalink / raw)
To: Liang Yang
Cc: Rob Herring, Hanjie Lin, Victor Wan, Jianxin Pan, Marek Vasut,
Martin Blumenstingl, Richard Weinberger, Neil Armstrong,
Yixun Lan, linux-kernel, Boris Brezillon, Jian Hu, linux-mtd,
Kevin Hilman, Carlo Caione, linux-amlogic, Brian Norris,
David Woodhouse, linux-arm-kernel, Jerome Brunet
In-Reply-To: <ac486ae7-7997-6f35-f29c-267c9c6f0f8c@amlogic.com>
Hi Liang,
Liang Yang <liang.yang@amlogic.com> wrote on Fri, 7 Dec 2018 18:41:39
+0800:
> Hi Miquel,
>
> Appreciate your time.
Sorry for being late to do this review.
> I will follow the nand/next and rework some next week as soon as possible.
There is no hurry, I don't think the driver will enter 4.21 (or
whatever it is called) as we are already late in the release cycle. It
should enter in the next release though.
Thanks,
Miquèl
_______________________________________________
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: WARN_ON_ONCE issue when resuming from hibernation
From: Will Deacon @ 2018-12-07 10:47 UTC (permalink / raw)
To: Kunihiko Hayashi; +Cc: arm, james.morse, linux-arm-kernel
In-Reply-To: <20181207104049.5F64.4A936039@socionext.com>
[+ James]
On Fri, Dec 07, 2018 at 10:40:50AM +0900, Kunihiko Hayashi wrote:
> I found that a WARN_ON_ONCE dump occured in the resuming sequence from
> hibernation on arm64 SoC (I use UniPhier LD20 environment).
>
> ...
> Disabling non-boot CPUs ...
> CPU1: shutdown
> psci: CPU1 killed.
> CPU2: shutdown
> psci: CPU2 killed.
> CPU3: shutdown
> psci: CPU3 killed.
> WARNING: CPU: 0 PID: 1 at ../kernel/smp.c:416 smp_call_function_many+0xd4/0x350
> Modules linked in:
> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.20.0-rc4 #1
> ...
>
> I show the result of reading the code, however,
> I'm not sure that this issue occurs in other arm64 SoC.
>
> In the resuming sequence, once all CPUs are stopped and local IRQs
> are disabled [1].
>
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/kernel/power/hibernate.c?h=v4.20-rc4#n450
>
> In case of arm64, flush_icache_range() will be called after that.
> This calls kick_all_cpus_sync() to sync all CPUs with IPI, and
> since local IRQs are disabled, WARN_ON_ONCE() will be called in
> smp_call_function_many() [2].
>
> [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/kernel/smp.c?h=v4.20-rc4#n415
>
> The following tree shows a part of the callgraph.
>
> resume_target_kernel()
> +- local_irq_disable()
> +- swsusp_arch_resume() /* for arm64 */
> +- create_safe_exec_page() /* for arm64 */
> +- flush_icache_range() /* for arm64 */
> +- kick_all_cpus_sync()
> +- smp_call_function()
> +- smp_call_function_many()
> +- WARN_ON_ONCE(irq_disabled())
>
> What is the possible way to solve this issue?
Given that all secondary CPUs are hotplugged out at this point, we can
just use the non-IPI version of flush_icache_range(). Completely untested
diff below.
Will
--->8
diff --git a/arch/arm64/kernel/hibernate.c b/arch/arm64/kernel/hibernate.c
index 6b2686d54411..29cdc99688f3 100644
--- a/arch/arm64/kernel/hibernate.c
+++ b/arch/arm64/kernel/hibernate.c
@@ -214,7 +214,7 @@ static int create_safe_exec_page(void *src_start, size_t length,
}
memcpy((void *)dst, src_start, length);
- flush_icache_range(dst, dst + length);
+ __flush_icache_range(dst, dst + length);
pgdp = pgd_offset_raw(allocator(mask), dst_addr);
if (pgd_none(READ_ONCE(*pgdp))) {
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox