* Re: Re: [PATCH 3/3] ARM: dts: sunxi: add support for Orange Pi Zero board
From: Maxime Ripard @ 2016-11-14 13:10 UTC (permalink / raw)
To: Hans de Goede
Cc: Chen-Yu Tsai, Icenowy Zheng, Jonathan Corbet, Rob Herring,
Mark Rutland, Russell King,
linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel, linux-kernel, devicetree, linux-sunxi
In-Reply-To: <cbbf8ae1-ff29-2a83-265b-a9ff5bacf97b-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 953 bytes --]
On Mon, Nov 14, 2016 at 11:00:32AM +0100, Hans de Goede wrote:
> > > > +&usbphy {
> > > > + /* USB VBUS is always on */
> > >
> > > You can put the always on regulators (I'm guessing reg_vcc5v0 ?) here.
> >
> > AFAIK the regulator properties are optional the the USB PHY.
> > So we probably don't need to add it. Hans (CC-ed) could explain
> > his original intent?
>
> I've made the regulators optional exactly for boards like these,
> where there is no regulator. Likely the Vbus is simply wired
> directly to the 5V DC-in jack. So IMHO adding something like
> the fixed reg_vcc5v0 a supply here just makes the dt
> harder to read.
It also makes the regulator tree more complete and accurate because
you'd list all the devices that are needing those regulators. That
would also make it easier to deal with in the future.
But fair enough.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [linux-sunxi] Re: [PATCH 3/3] ARM: dts: sunxi: add support for Orange Pi Zero board
From: Maxime Ripard @ 2016-11-14 13:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cbbf8ae1-ff29-2a83-265b-a9ff5bacf97b@redhat.com>
On Mon, Nov 14, 2016 at 11:00:32AM +0100, Hans de Goede wrote:
> > > > +&usbphy {
> > > > + /* USB VBUS is always on */
> > >
> > > You can put the always on regulators (I'm guessing reg_vcc5v0 ?) here.
> >
> > AFAIK the regulator properties are optional the the USB PHY.
> > So we probably don't need to add it. Hans (CC-ed) could explain
> > his original intent?
>
> I've made the regulators optional exactly for boards like these,
> where there is no regulator. Likely the Vbus is simply wired
> directly to the 5V DC-in jack. So IMHO adding something like
> the fixed reg_vcc5v0 a supply here just makes the dt
> harder to read.
It also makes the regulator tree more complete and accurate because
you'd list all the devices that are needing those regulators. That
would also make it easier to deal with in the future.
But fair enough.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161114/4cfb2c48/attachment.sig>
^ permalink raw reply
* Re: [Qemu-devel] [PATCH v2 0/5] [RFC] Add HAX support
From: Vincent Palatin @ 2016-11-14 13:09 UTC (permalink / raw)
To: Stefan Weil; +Cc: qemu-devel
In-Reply-To: <174f2d59-636d-9a25-eb46-47c30b7125e3@weilnetz.de>
On Mon, Nov 14, 2016 at 1:36 PM, Stefan Weil <sw@weilnetz.de> wrote:
> Am 11.11.2016 um 12:28 schrieb Vincent Palatin:
> [...]
>> I have tested the end result on a Windows 10 Pro machine (with UG support)
>> with the Intel HAXM module 6.0.4 and a large ChromiumOS x86_64 image to
>> exercise various code paths. It looks stable.
>> I also did a quick regression testing of the integration by running a Linux
>> build with KVM enabled.
>
> My test on Windows 7 with HAXM 6.0.4 fails:
>
> $ test/qemu-system-x86_64.exe --enable-hax
> HAX is working and emulator runs in fast virt mode.
> Unknown hax vcpu return 1
Sorry about this.
I did notice that just running the default Seabios/iPXE was triggering
an issue and forgot to debug it (as I'm mostly running Chromium OS
images).
I will have a look and try to sort this out..
>
> This application has requested the Runtime to terminate it in an unusual
> way.
> Please contact the application's support team for more information.
>
> $ test/qemu-system-i386.exe --enable-hax
> HAX is working and emulator runs in fast virt mode.
> Unknown hax vcpu return 1
>
> This application has requested the Runtime to terminate it in an unusual
> way.
> Please contact the application's support team for more information.
>
> I tested debug code (configure --enable-debug && make) based on
> latest QEMU from git, this patch series and my include fixes.
>
> Stefan
>
^ permalink raw reply
* Re: [PATCH RFC] ARM: dts: add support for Turris Omnia
From: Andrew Lunn @ 2016-11-14 13:10 UTC (permalink / raw)
To: tomas.hlavacek-x+rMaJPWets
Cc: Uwe Kleine-König, Mark Rutland, Jason Cooper,
Martin Strba??ka, devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring,
Gregory Clement,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Sebastian Hesselbarth
In-Reply-To: <1479126185.15557.5-TAvD023jEQEN+BqQ9rBEUg@public.gmane.org>
> Actually SFP is connected to SGMII interface of eth1, which is
> routed through SERDES 5.
You say eth1 here. Yet lower down you say got eth0 and eth1 are
connected to the switch?
> We have our proprietary support hacked onto mvneta driver for
> disconnecting PHY on the fly. It is a bit nasty, so I suggest to
> ignore SFP in this DTS altogether and let's wait till "phylink based
> SFP module support" or something alike hits upstream, so we can base
> the SFP support on solid code;
It would be great if you could work on getting the phylink patches
into mainline. It is something i have wanted to do for a long time,
but it is too low down on my priority list to get to. The code is high
quality, so i don't think there will be too many issues. It probably
just needs splitting up into smaller batches, submitting, and working
on any comments.
> Actually eth0 and eth1 (both are RGMII) are connected to the 88E6176
> switch. The problem is that from what I have read so far the switch
> can not operate in DSA mode with two CPU ports.
Again, this is something i wanted to do, and i did have a prototype at
one point. But again, not enough time. If you have resources to work
on this, i can find my code, explain my ideas, and let you complete
it.
Andrew
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH RFC] ARM: dts: add support for Turris Omnia
From: Andrew Lunn @ 2016-11-14 13:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479126185.15557.5@smtp.gmail.com>
> Actually SFP is connected to SGMII interface of eth1, which is
> routed through SERDES 5.
You say eth1 here. Yet lower down you say got eth0 and eth1 are
connected to the switch?
> We have our proprietary support hacked onto mvneta driver for
> disconnecting PHY on the fly. It is a bit nasty, so I suggest to
> ignore SFP in this DTS altogether and let's wait till "phylink based
> SFP module support" or something alike hits upstream, so we can base
> the SFP support on solid code;
It would be great if you could work on getting the phylink patches
into mainline. It is something i have wanted to do for a long time,
but it is too low down on my priority list to get to. The code is high
quality, so i don't think there will be too many issues. It probably
just needs splitting up into smaller batches, submitting, and working
on any comments.
> Actually eth0 and eth1 (both are RGMII) are connected to the 88E6176
> switch. The problem is that from what I have read so far the switch
> can not operate in DSA mode with two CPU ports.
Again, this is something i wanted to do, and i did have a prototype at
one point. But again, not enough time. If you have resources to work
on this, i can find my code, explain my ideas, and let you complete
it.
Andrew
^ permalink raw reply
* [PATCH] spi: atmel: Fix scheduling while atomic
From: Alexandre Belloni @ 2016-11-14 13:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478792090-6376-1-git-send-email-ben.whitten@gmail.com>
Hi,
On 10/11/2016 at 15:34:50 +0000, ben.whitten at gmail.com wrote :
> From: Ben Whitten <ben.whitten@lairdtech.com>
>
> A call to clk_get_rate appears to be called in the context of an interrupt,
> cache the bus clock for the frequency calculations in transmission.
>
> This fixes a 'BUG: scheduling while atomic' and
> 'WARNING: CPU: 0 PID: 777 at kernel/sched/core.c:2960 atmel_spi_unlock'
>
> Signed-off-by: Ben Whitten <ben.whitten@lairdtech.com>
> Signed-off-by: Steve deRosier <steve.derosier@lairdtech.com>
The spi subsystem maintainer is not copied so this fix will not be
applied.
Else, it seems ok to me.
> ---
> drivers/spi/spi-atmel.c | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c
> index 8feac59..c281d1a 100644
> --- a/drivers/spi/spi-atmel.c
> +++ b/drivers/spi/spi-atmel.c
> @@ -295,6 +295,7 @@ struct atmel_spi {
> int irq;
> struct clk *clk;
> struct platform_device *pdev;
> + unsigned long spi_clk;
>
> struct spi_transfer *current_transfer;
> int current_remaining_bytes;
> @@ -864,7 +865,7 @@ static int atmel_spi_set_xfer_speed(struct atmel_spi *as,
> unsigned long bus_hz;
>
> /* v1 chips start out at half the peripheral bus speed. */
> - bus_hz = clk_get_rate(as->clk);
> + bus_hz = as->spi_clk;
> if (!atmel_spi_is_v2(as))
> bus_hz /= 2;
>
> @@ -1606,6 +1607,9 @@ static int atmel_spi_probe(struct platform_device *pdev)
> ret = clk_prepare_enable(clk);
> if (ret)
> goto out_free_irq;
> +
> + as->spi_clk = clk_get_rate(clk);
> +
> spi_writel(as, CR, SPI_BIT(SWRST));
> spi_writel(as, CR, SPI_BIT(SWRST)); /* AT91SAM9263 Rev B workaround */
> if (as->caps.has_wdrbt) {
> --
> 2.7.4
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH 2/2] arm64: dts: r8a7796: salvator-x: Add GPIO keys support
From: Laurent Pinchart @ 2016-11-14 13:07 UTC (permalink / raw)
To: linux-renesas-soc; +Cc: kieran.bingham
In-Reply-To: <1479128837-30985-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
The Salvator-X board as a 4 lines DIP switch and 3 push buttons
connected to SoC GPIOs, meant to be used as general-purpose test keys.
Add a corresponding node in DT, mapping (semi-randomly) the DIP switch
to keys 1-4 and the push buttons to keys A-C.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
---
arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts | 63 ++++++++++++++++++++++
1 file changed, 63 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts b/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts
index f35e96ca7d60..8e511fab880c 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts
@@ -11,6 +11,7 @@
/dts-v1/;
#include "r8a7796.dtsi"
#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
/ {
model = "Renesas Salvator-X board based on r8a7796";
@@ -31,6 +32,63 @@
reg = <0x0 0x48000000 0x0 0x78000000>;
};
+ keys {
+ compatible = "gpio-keys";
+
+ pinctrl-0 = <&keys_pins>;
+ pinctrl-names = "default";
+
+ key-1 {
+ gpios = <&gpio5 17 GPIO_ACTIVE_LOW>;
+ linux,code = <KEY_1>;
+ label = "SW4-1";
+ wakeup-source;
+ debounce-interval = <20>;
+ };
+ key-2 {
+ gpios = <&gpio5 20 GPIO_ACTIVE_LOW>;
+ linux,code = <KEY_2>;
+ label = "SW4-2";
+ wakeup-source;
+ debounce-interval = <20>;
+ };
+ key-3 {
+ gpios = <&gpio5 22 GPIO_ACTIVE_LOW>;
+ linux,code = <KEY_3>;
+ label = "SW4-3";
+ wakeup-source;
+ debounce-interval = <20>;
+ };
+ key-4 {
+ gpios = <&gpio5 23 GPIO_ACTIVE_LOW>;
+ linux,code = <KEY_4>;
+ label = "SW4-4";
+ wakeup-source;
+ debounce-interval = <20>;
+ };
+ key-a {
+ gpios = <&gpio6 11 GPIO_ACTIVE_LOW>;
+ linux,code = <KEY_A>;
+ label = "TSW0";
+ wakeup-source;
+ debounce-interval = <20>;
+ };
+ key-b {
+ gpios = <&gpio6 12 GPIO_ACTIVE_LOW>;
+ linux,code = <KEY_B>;
+ label = "TSW1";
+ wakeup-source;
+ debounce-interval = <20>;
+ };
+ key-c {
+ gpios = <&gpio6 13 GPIO_ACTIVE_LOW>;
+ linux,code = <KEY_C>;
+ label = "TSW2";
+ wakeup-source;
+ debounce-interval = <20>;
+ };
+ };
+
reg_1p8v: regulator0 {
compatible = "regulator-fixed";
regulator-name = "fixed-1.8V";
@@ -116,6 +174,11 @@
function = "i2c2";
};
+ keys_pins: keys {
+ pins = "GP_5_17", "GP_5_20", "GP_5_22";
+ bias-pull-up;
+ };
+
sdhi0_pins: sd0 {
groups = "sdhi0_data4", "sdhi0_ctrl";
function = "sdhi0";
--
Regards,
Laurent Pinchart
^ permalink raw reply related
* [PATCH 1/2] arm64: dts: r8a7795: salvator-x: Add GPIO keys support
From: Laurent Pinchart @ 2016-11-14 13:07 UTC (permalink / raw)
To: linux-renesas-soc; +Cc: kieran.bingham
In-Reply-To: <1479128837-30985-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
The Salvator-X board as a 4 lines DIP switch and 3 push buttons
connected to SoC GPIOs, meant to be used as general-purpose test keys.
Add a corresponding node in DT, mapping (semi-randomly) the DIP switch
to keys 1-4 and the push buttons to keys A-C.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
---
arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts | 63 ++++++++++++++++++++++
1 file changed, 63 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
index bcaf4008d32d..ef3511cab367 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
@@ -34,6 +34,7 @@
/dts-v1/;
#include "r8a7795.dtsi"
#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
/ {
model = "Renesas Salvator-X board based on r8a7795";
@@ -56,6 +57,63 @@
reg = <0x0 0x48000000 0x0 0x38000000>;
};
+ keys {
+ compatible = "gpio-keys";
+
+ pinctrl-0 = <&keys_pins>;
+ pinctrl-names = "default";
+
+ key-1 {
+ gpios = <&gpio5 17 GPIO_ACTIVE_LOW>;
+ linux,code = <KEY_1>;
+ label = "SW4-1";
+ wakeup-source;
+ debounce-interval = <20>;
+ };
+ key-2 {
+ gpios = <&gpio5 20 GPIO_ACTIVE_LOW>;
+ linux,code = <KEY_2>;
+ label = "SW4-2";
+ wakeup-source;
+ debounce-interval = <20>;
+ };
+ key-3 {
+ gpios = <&gpio5 22 GPIO_ACTIVE_LOW>;
+ linux,code = <KEY_3>;
+ label = "SW4-3";
+ wakeup-source;
+ debounce-interval = <20>;
+ };
+ key-4 {
+ gpios = <&gpio5 23 GPIO_ACTIVE_LOW>;
+ linux,code = <KEY_4>;
+ label = "SW4-4";
+ wakeup-source;
+ debounce-interval = <20>;
+ };
+ key-a {
+ gpios = <&gpio6 11 GPIO_ACTIVE_LOW>;
+ linux,code = <KEY_A>;
+ label = "TSW0";
+ wakeup-source;
+ debounce-interval = <20>;
+ };
+ key-b {
+ gpios = <&gpio6 12 GPIO_ACTIVE_LOW>;
+ linux,code = <KEY_B>;
+ label = "TSW1";
+ wakeup-source;
+ debounce-interval = <20>;
+ };
+ key-c {
+ gpios = <&gpio6 13 GPIO_ACTIVE_LOW>;
+ linux,code = <KEY_C>;
+ label = "TSW2";
+ wakeup-source;
+ debounce-interval = <20>;
+ };
+ };
+
x12_clk: x12_clk {
compatible = "fixed-clock";
#clock-cells = <0>;
@@ -256,6 +314,11 @@
function = "du";
};
+ keys_pins: keys {
+ pins = "GP_5_17", "GP_5_20", "GP_5_22";
+ bias-pull-up;
+ };
+
sdhi0_pins: sd0 {
groups = "sdhi0_data4", "sdhi0_ctrl";
function = "sdhi0";
--
Regards,
Laurent Pinchart
^ permalink raw reply related
* [PATCH 0/2] Salvator-X: Add GPIO keys support
From: Laurent Pinchart @ 2016-11-14 13:07 UTC (permalink / raw)
To: linux-renesas-soc; +Cc: kieran.bingham
Hello,
This simple series adds GPIO keys support to both the H3- and M3-W-based
Salvator-X boards. Please see individual patches for details.
Laurent Pinchart (2):
arm64: dts: r8a7795: salvator-x: Add GPIO keys support
arm64: dts: r8a7796: salvator-x: Add GPIO keys support
arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts | 63 ++++++++++++++++++++++
arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts | 63 ++++++++++++++++++++++
2 files changed, 126 insertions(+)
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH] input: bma150: Only claim to support the bma180 if the separate iio bma180 driver is not build
From: Hans de Goede @ 2016-11-14 13:06 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input, linux-arm-kernel, Dr . H . Nikolaus Schaller
In-Reply-To: <20161114053523.GA21471@dtor-ws>
Hi,
On 14-11-16 06:35, Dmitry Torokhov wrote:
> Hi Hans,
>
> On Sun, Nov 13, 2016 at 07:34:07PM +0100, Hans de Goede wrote:
>> commit ef3714fdbc8d ("Input: bma150 - extend chip detection for bma180"),
>> adds bma180 chip-ids to the input bma150 driver, assuming that they are
>> 100% compatible, but the bma180 is not compatible with the bma150 at all,
>> it has 14 bits resolution instead of 10, and it has quite different
>> control registers too.
>>
>> Treating the bma180 as a bma150 wrt its data registers will just result
>> in throwing away the lowest 4 bits, which is not too bad. But the ctrl
>> registers are a different story. Things happen to just work but supporting
>> that certainly does not make treating the bma180 the same as the bma150
>> right.
>>
>> Since some setups depend on the evdev interface the bma150 driver offers
>> on top of the bma180, we cannot simply remove the bma180 ids.
>>
>> So this commit only removes the bma180 id when the bma180 iio driver,
>> which does treat the bma180 properly, is enabled.
>>
>> Cc: Dr. H. Nikolaus Schaller <hns@goldelico.com>
>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>> ---
>> drivers/input/misc/bma150.c | 8 +++++++-
>> 1 file changed, 7 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/input/misc/bma150.c b/drivers/input/misc/bma150.c
>> index b0d4453..9fa1c9a 100644
>> --- a/drivers/input/misc/bma150.c
>> +++ b/drivers/input/misc/bma150.c
>> @@ -539,7 +539,11 @@ static int bma150_probe(struct i2c_client *client,
>> }
>>
>> chip_id = i2c_smbus_read_byte_data(client, BMA150_CHIP_ID_REG);
>> - if (chip_id != BMA150_CHIP_ID && chip_id != BMA180_CHIP_ID) {
>> + if (chip_id != BMA150_CHIP_ID
>> +#ifndef CONFIG_BMA180
>> + && chip_id != BMA180_CHIP_ID
>> +#endif
>
> Does not this break if bma180 is compiled as module? I'd rather we did
>
> if (chip_id != BMA150_CHIP_ID &&
> (IS_ENABLED(CONFIG_BMA180) || chip_id != BMA180_CHIP_ID)) {
> ...
Yes using IS_ENABLED() is a good idea, both for readability and for
the building as module reason. I'll send a v2.
Regards,
Hans
>
>
>> + ) {
>> dev_err(&client->dev, "BMA150 chip id error: %d\n", chip_id);
>> return -EINVAL;
>> }
>> @@ -643,7 +647,9 @@ static UNIVERSAL_DEV_PM_OPS(bma150_pm, bma150_suspend, bma150_resume, NULL);
>>
>> static const struct i2c_device_id bma150_id[] = {
>> { "bma150", 0 },
>> +#ifndef CONFIG_BMA180
> #if !IS_ENABLED(CONFIG_BMA180)
>
>> { "bma180", 0 },
>> +#endif
>> { "smb380", 0 },
>> { "bma023", 0 },
>> { }
>> --
>> 2.9.3
>>
>
> Thanks.
>
^ permalink raw reply
* [PATCH] input: bma150: Only claim to support the bma180 if the separate iio bma180 driver is not build
From: Hans de Goede @ 2016-11-14 13:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161114053523.GA21471@dtor-ws>
Hi,
On 14-11-16 06:35, Dmitry Torokhov wrote:
> Hi Hans,
>
> On Sun, Nov 13, 2016 at 07:34:07PM +0100, Hans de Goede wrote:
>> commit ef3714fdbc8d ("Input: bma150 - extend chip detection for bma180"),
>> adds bma180 chip-ids to the input bma150 driver, assuming that they are
>> 100% compatible, but the bma180 is not compatible with the bma150 at all,
>> it has 14 bits resolution instead of 10, and it has quite different
>> control registers too.
>>
>> Treating the bma180 as a bma150 wrt its data registers will just result
>> in throwing away the lowest 4 bits, which is not too bad. But the ctrl
>> registers are a different story. Things happen to just work but supporting
>> that certainly does not make treating the bma180 the same as the bma150
>> right.
>>
>> Since some setups depend on the evdev interface the bma150 driver offers
>> on top of the bma180, we cannot simply remove the bma180 ids.
>>
>> So this commit only removes the bma180 id when the bma180 iio driver,
>> which does treat the bma180 properly, is enabled.
>>
>> Cc: Dr. H. Nikolaus Schaller <hns@goldelico.com>
>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>> ---
>> drivers/input/misc/bma150.c | 8 +++++++-
>> 1 file changed, 7 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/input/misc/bma150.c b/drivers/input/misc/bma150.c
>> index b0d4453..9fa1c9a 100644
>> --- a/drivers/input/misc/bma150.c
>> +++ b/drivers/input/misc/bma150.c
>> @@ -539,7 +539,11 @@ static int bma150_probe(struct i2c_client *client,
>> }
>>
>> chip_id = i2c_smbus_read_byte_data(client, BMA150_CHIP_ID_REG);
>> - if (chip_id != BMA150_CHIP_ID && chip_id != BMA180_CHIP_ID) {
>> + if (chip_id != BMA150_CHIP_ID
>> +#ifndef CONFIG_BMA180
>> + && chip_id != BMA180_CHIP_ID
>> +#endif
>
> Does not this break if bma180 is compiled as module? I'd rather we did
>
> if (chip_id != BMA150_CHIP_ID &&
> (IS_ENABLED(CONFIG_BMA180) || chip_id != BMA180_CHIP_ID)) {
> ...
Yes using IS_ENABLED() is a good idea, both for readability and for
the building as module reason. I'll send a v2.
Regards,
Hans
>
>
>> + ) {
>> dev_err(&client->dev, "BMA150 chip id error: %d\n", chip_id);
>> return -EINVAL;
>> }
>> @@ -643,7 +647,9 @@ static UNIVERSAL_DEV_PM_OPS(bma150_pm, bma150_suspend, bma150_resume, NULL);
>>
>> static const struct i2c_device_id bma150_id[] = {
>> { "bma150", 0 },
>> +#ifndef CONFIG_BMA180
> #if !IS_ENABLED(CONFIG_BMA180)
>
>> { "bma180", 0 },
>> +#endif
>> { "smb380", 0 },
>> { "bma023", 0 },
>> { }
>> --
>> 2.9.3
>>
>
> Thanks.
>
^ permalink raw reply
* Re: [PATCH v3] Idleness DRRS test
From: Chris Wilson @ 2016-11-14 13:06 UTC (permalink / raw)
To: Petri Latvala
Cc: daniel.vetter, intel-gfx, Nautiyal Ankit, paulo.r.zanoni,
rodrigo.vivi
In-Reply-To: <20161114124435.dgfyzuzng4t75knb@platvala-desk.ger.corp.intel.com>
On Mon, Nov 14, 2016 at 02:44:35PM +0200, Petri Latvala wrote:
> Chris, happy with this revision?
Me? No. It still uses a thread instead of events, so I don't think it
qualifies as a good example for anyone else wanting to do the same thing.
Lots of hardcoded expectations (specific sleep patterns, rather than
waiting for the kernel to change with a timeout for failure). It doesn't
check all the possible ways that the output maybe changed (and if they
are irrelevent, that too also needs to be tested to establish expected
behaviour and catch future regressions). Important question, how is
userspace expected to know that the vrefresh changed? How do get around
that userspace is expecting a fixed vblank frequency?
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* RE: [PATCH 2/2] tpm/tpm2-chip: fix kdoc errors
From: Winkler, Tomas @ 2016-11-14 13:05 UTC (permalink / raw)
To: Jarkko Sakkinen
Cc: tpmdd-devel@lists.sourceforge.net, Jason Gunthorpe,
linux-kernel@vger.kernel.org
In-Reply-To: <20161104042559.b2pp3sn4xdy7yvuc@intel.com>
.org
> Subject: Re: [PATCH 2/2] tpm/tpm2-chip: fix kdoc errors
>
> On Tue, Nov 01, 2016 at 03:05:14AM +0200, Tomas Winkler wrote:
> > Use correct kdoc format, describe correct parameters and return values.
> >
> > Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
> > ---
> > drivers/char/tpm/tpm2-cmd.c | 107
> > +++++++++++++++++++++++++++-----------------
> > 1 file changed, 66 insertions(+), 41 deletions(-)
> >
> > diff --git a/drivers/char/tpm/tpm2-cmd.c b/drivers/char/tpm/tpm2-cmd.c
> > index 7df55d58c939..a7a519c87bee 100644
> > --- a/drivers/char/tpm/tpm2-cmd.c
> > +++ b/drivers/char/tpm/tpm2-cmd.c
> > @@ -258,11 +258,13 @@ static const struct tpm_input_header
> tpm2_pcrread_header = {
> > * tpm2_pcr_read() - read a PCR value
> > * @chip: TPM chip to use.
> > * @pcr_idx: index of the PCR to read.
> > - * @ref_buf: buffer to store the resulting hash,
> > + * @res_buf: buffer to store the resulting hash,
> > *
> > - * 0 is returned when the operation is successful. If a negative
> > number is
> > - * returned it remarks a POSIX error code. If a positive number is
> > returned
> > - * it remarks a TPM error.
> > + *
> > + * Return:
> > + * 0 when the operation is successful
> > + * A negative number for system errors (errno)
> > + * A positive number for a TPM error.
> > */
> > int tpm2_pcr_read(struct tpm_chip *chip, int pcr_idx, u8 *res_buf) {
> > @@ -304,13 +306,15 @@ static const struct tpm_input_header
> > tpm2_pcrextend_header = {
> >
> > /**
> > * tpm2_pcr_extend() - extend a PCR value
> > + *
> > * @chip: TPM chip to use.
> > * @pcr_idx: index of the PCR.
> > * @hash: hash value to use for the extend operation.
> > *
> > - * 0 is returned when the operation is successful. If a negative
> > number is
> > - * returned it remarks a POSIX error code. If a positive number is
> > returned
> > - * it remarks a TPM error.
> > + * Return:
> > + * 0 when the operation is successful
> > + * A negative number for system errors (errno)
> > + * A positive number for a TPM error.
>
> Put this to tpm_transmit_cmd only and refer to that from other functions with
> "same as with tpm_transmit_cmd()" with parenthesis because that marks in rst
> a link to that function.
And then tpm_transmit_cmd() will point to tpm_transmit() ?
I'm not sure I'm happy about those links, rst is okay but after all mostly we're just looking directly to the sources with a simple editor.
Anyhow this patch is to resolve the kdoc syntax bug, the overhaul of the documentation can be built on top of it.
Thanks
Tomas
^ permalink raw reply
* Re: [PATCH] drm/amdgpu:impl vgt_flush for VI(V3)
From: Christian König @ 2016-11-14 13:04 UTC (permalink / raw)
To: Monk Liu, amd-gfx-CC+yJ3UmIYqDUpFQwHEjaQ
In-Reply-To: <1479127939-17570-1-git-send-email-Monk.Liu-5C7GfCeVMHo@public.gmane.org>
Am 14.11.2016 um 13:52 schrieb Monk Liu:
> when shadowing enabled, tesselation app will trigger
> vm fault because below three tesselation registers:
>
> VGT_TF_RING_SIZE__CI__VI,
> VGT_HS_OFFCHIP_PARAM__CI__VI,
> VGT_TF_MEMORY_BASE__CI__VI,
>
> need to be programed after vgt-flush.
>
> Tesselation picture vm fault disappeared after vgt-flush
> introduced.
>
> v2:implement vgt-flush for CI & SI.
> v3:move vgt flush inside of cntx_cntrl
>
> Change-Id: I77d87d93ce6580e559e734fb41d97ee8c59d245b
> Signed-off-by: Monk Liu <Monk.Liu@amd.com>
We also need to increase the DW estimation for the three gfx engines.
With that fixed the patch is Reviewed-by: Christian König
<christian.koenig@amd.com>.
> ---
> drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c | 9 +++++++++
> drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c | 13 +++++++++++++
> drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 13 +++++++++++++
> 3 files changed, 35 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c b/drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c
> index 9423501..0aacd36 100644
> --- a/drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c
> @@ -1463,6 +1463,13 @@ static void gfx_v6_0_ring_emit_hdp_flush(struct amdgpu_ring *ring)
> amdgpu_ring_write(ring, 0x1);
> }
>
> +static void gfx_v6_0_ring_emit_vgt_flush(struct amdgpu_ring *ring)
> +{
> + amdgpu_ring_write(ring, PACKET3(PACKET3_EVENT_WRITE, 0));
> + amdgpu_ring_write(ring, EVENT_TYPE(VGT_FLUSH) |
> + EVENT_INDEX(0));
> +}
> +
> /**
> * gfx_v6_0_ring_emit_hdp_invalidate - emit an hdp invalidate on the cp
> *
> @@ -2802,6 +2809,8 @@ static uint64_t gfx_v6_0_get_gpu_clock_counter(struct amdgpu_device *adev)
>
> static void gfx_v6_ring_emit_cntxcntl(struct amdgpu_ring *ring, uint32_t flags)
> {
> + if (flags & AMDGPU_HAVE_CTX_SWITCH) {
> + gfx_v6_0_ring_emit_vgt_flush(ring);
> amdgpu_ring_write(ring, PACKET3(PACKET3_CONTEXT_CONTROL, 1));
> amdgpu_ring_write(ring, 0x80000000);
> amdgpu_ring_write(ring, 0);
> diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c b/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c
> index bd9a6c8..493d889 100644
> --- a/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c
> @@ -2105,6 +2105,18 @@ static void gfx_v7_0_ring_emit_hdp_flush(struct amdgpu_ring *ring)
> amdgpu_ring_write(ring, 0x20); /* poll interval */
> }
>
> +static void gfx_v7_0_ring_emit_vgt_flush(struct amdgpu_ring *ring)
> +{
> + amdgpu_ring_write(ring, PACKET3(PACKET3_EVENT_WRITE, 0));
> + amdgpu_ring_write(ring, EVENT_TYPE(VS_PARTIAL_FLUSH) |
> + EVENT_INDEX(4));
> +
> + amdgpu_ring_write(ring, PACKET3(PACKET3_EVENT_WRITE, 0));
> + amdgpu_ring_write(ring, EVENT_TYPE(VGT_FLUSH) |
> + EVENT_INDEX(0));
> +}
> +
> +
> /**
> * gfx_v7_0_ring_emit_hdp_invalidate - emit an hdp invalidate on the cp
> *
> @@ -2260,6 +2272,7 @@ static void gfx_v7_ring_emit_cntxcntl(struct amdgpu_ring *ring, uint32_t flags)
>
> dw2 |= 0x80000000; /* set load_enable otherwise this package is just NOPs */
> if (flags & AMDGPU_HAVE_CTX_SWITCH) {
> + gfx_v7_0_ring_emit_vgt_flush(ring);
> /* set load_global_config & load_global_uconfig */
> dw2 |= 0x8001;
> /* set load_cs_sh_regs */
> diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> index 9017803..d52f458 100644
> --- a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> @@ -6187,6 +6187,18 @@ static void gfx_v8_0_ring_emit_hdp_flush(struct amdgpu_ring *ring)
> amdgpu_ring_write(ring, 0x20); /* poll interval */
> }
>
> +static void gfx_v8_0_ring_emit_vgt_flush(struct amdgpu_ring *ring)
> +{
> + amdgpu_ring_write(ring, PACKET3(PACKET3_EVENT_WRITE, 0));
> + amdgpu_ring_write(ring, EVENT_TYPE(VS_PARTIAL_FLUSH) |
> + EVENT_INDEX(4));
> +
> + amdgpu_ring_write(ring, PACKET3(PACKET3_EVENT_WRITE, 0));
> + amdgpu_ring_write(ring, EVENT_TYPE(VGT_FLUSH) |
> + EVENT_INDEX(0));
> +}
> +
> +
> static void gfx_v8_0_ring_emit_hdp_invalidate(struct amdgpu_ring *ring)
> {
> amdgpu_ring_write(ring, PACKET3(PACKET3_WRITE_DATA, 3));
> @@ -6372,6 +6384,7 @@ static void gfx_v8_ring_emit_cntxcntl(struct amdgpu_ring *ring, uint32_t flags)
>
> dw2 |= 0x80000000; /* set load_enable otherwise this package is just NOPs */
> if (flags & AMDGPU_HAVE_CTX_SWITCH) {
> + gfx_v8_0_ring_emit_vgt_flush(ring);
> /* set load_global_config & load_global_uconfig */
> dw2 |= 0x8001;
> /* set load_cs_sh_regs */
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
^ permalink raw reply
* RE: [ath9k-devel] [NOT FOR MERGE] ath9k: work around key cache corruption
From: Stam, Michel [FINT] @ 2016-11-14 12:50 UTC (permalink / raw)
To: Johannes Berg, Sebastian Gottschall, Kalle Valo,
Antonio Quartulli
Cc: ath9k-devel@lists.ath9k.org, linux-wireless@vger.kernel.org,
Antonio Quartulli
In-Reply-To: <1477580802.4534.20.camel@sipsolutions.net>
Dear List,
After 2 weeks of Ferry Huberts and me trying to resolve this issue, this is the result:
The problem can be mitigated by resetting the chip and immediately replumbing the encryption keys. I wrote a patch for this, which unfortunately this seems to suffer from some locking issues, rtnl_lock and sc->mutex being the chief culprits.
Code snippet:
static void ath9k_plumb_key(struct ieee80211_hw *hw,
struct ieee80211_vif *vif,
struct ieee80211_sta *sta,
struct ieee80211_key_conf *keyconf, void *data)
{
struct ath_common *common = (struct ath_common *)data;
int ret;
/* delete and re-install keys which were programmed into the hardware */
if (vif && test_bit(keyconf->hw_key_idx, common->keymap)) {
ath_key_delete(common, keyconf);
keyconf->hw_key_idx = 0;
ret = ath_key_config(common, vif, sta, keyconf);
if (ret >= 0)
keyconf->hw_key_idx = ret;
}
}
To reset and replumb, taken from ath_reset_internal():
ath9k_hw_kill_interrupts(sc->sc_ah);
set_bit(ATH_OP_HW_RESET, &common->op_flags);
ath9k_ps_wakeup(sc);
ath_reset_internal(sc, NULL);
rtnl_lock();
ieee80211_iter_keys(sc->hw, NULL, ath9k_plumb_key, common);
rtnl_unlock();
ath9k_ps_restore(sc);
In any case, the problem is only mitigated. It is not solved, as I see the error appearing still (less frequently though).
Looking at the OpenHAL has not yielded anything working either (there is a reference to KEY_PLUMB_WAR, but it is not a full implementation).
What I understand from previous attempts to tackle this issue is that Qualcomm is aware of the problem, and a workaround exists in at least the proprietary driver. I have tried to contact Qualcomm support about this, since it is not radio card specific, but I have not received any response so far.
I hope a Qualcomm employee reads this and is able to help obtain the information that is necessary to resolve this issue. Until then, I recommend using software encryption (nohwcrypt), or setting a very long rekeying time.
Kind regards,
Michel Stam
-----Original Message-----
From: ath9k-devel-bounces@lists.ath9k.org [mailto:ath9k-devel-bounces@lists.ath9k.org] On Behalf Of Johannes Berg
Sent: Thursday, October 27, 2016 17:07 PM
To: Sebastian Gottschall; Kalle Valo; Antonio Quartulli
Cc: ath9k-devel@lists.ath9k.org; linux-wireless@vger.kernel.org; Antonio Quartulli
Subject: Re: [ath9k-devel] [NOT FOR MERGE] ath9k: work around key cache corruption
On Thu, 2016-10-27 at 09:54 +0200, Sebastian Gottschall wrote:
> all patches have a unclear license since most patches are not comming
> with any licence declaration ;-)
You should read the DCO some time. Maybe you shouldn't be sending
patches if you think so.
johannes
_______________________________________________
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
^ permalink raw reply
* Re: Debugging Ethernet issues
From: Sebastian Frias @ 2016-11-14 13:03 UTC (permalink / raw)
To: Florian Fainelli, Mason, Andrew Lunn
Cc: netdev, Mans Rullgard, Sergei Shtylyov, Tom Lendacky, Zach Brown,
Shaohui Xie, Tim Beale, Brian Hill, Vince Bridgers,
Balakumaran Kannan, David S. Miller, Kirill Kapranov
In-Reply-To: <9d1f28a7-959b-fdde-3403-f6da5f521125@gmail.com>
On 11/13/2016 08:55 PM, Florian Fainelli wrote:
> Le 13/11/2016 à 11:51, Mason a écrit :
>> On 13/11/2016 04:09, Andrew Lunn wrote:
>>
>>> Mason wrote:
>>>
>>>> When connected to a Gigabit switch
>>>> 3.4 negotiates a LAN DHCP setup instantly
>>>> 4.7 requires over 5 seconds to do so
>>>
>>> When you run tcpdump on the DHCP server, are you noticing the first
>>> request is missing?
>>>
>>> What can happen is the dhclient gets started immediately and sends out
>>> its first request before auto-negotiation has finished. So this first packet
>>> gets lost. The retransmit after a few seconds is then successful.
>>
>> I will run tcpdump on the server as I run udhcpc on the client
>> for Linux 3.4 vs 4.7
>>
>> Do you know what would make auto-negotiation fail at 100 Mbps
>> on 4.7? (whereas it succeeds on 3.4)
>>
>> (Thinking out loud) If the problem were in auto-negotiation,
>> then if should work if I hard-code speed and duplex using
>> ethtool, right? (IIRC, hard-coding doesn't help.)
>
> I would start with checking basic things:
>
> - does your Ethernet driver get a link UP being reported correctly
> (netif_carrier_ok returns 1)?
> - if you let the bootloader configure the PHY and utilize the Generic
> PHY driver instead of the Atheros PHY driver, does the problem appear as
> well?
Would using a "fixed-link" serve the same?
It appears that using a fixed-link
ð0 {
#address-cells = <1>;
#size-cells = <0>;
#ifdef WITH_FIXED_LINK
phy-connection-type = "rgmii";
fixed-link {
speed = <100>;
full-duplex;
};
#else
phy-connection-type = "rgmii";
phy-handle = <ð0_phy>;
/* Atheros AR8035 */
eth0_phy: ethernet-phy@4 {
interrupt-parent = <&irq0>;
compatible = "ethernet-phy-id004d.d072",
"ethernet-phy-ieee802.3-c22";
interrupts = <37 IRQ_TYPE_EDGE_RISING>;
reg = <4>;
};
#endif
};
works.
----
For what is worth, the patch that Mason was talking about earlier
in the thread:
"...After much hair-pulling, it turned out that *some* of the breakage
was caused by a local patch..."
was setting changing the following delay in 'drivers/net/phy/phy.c:phy_state_machine()'
/* Only re-schedule a PHY state machine change if we are polling the
* PHY, if PHY_IGNORE_INTERRUPT is set, then we will be moving
* between states from phy_mac_interrupt()
*/
if (phydev->irq == PHY_POLL)
queue_delayed_work(system_power_efficient_wq, &phydev->state_queue,
PHY_STATE_TIME * HZ);
from "PHY_STATE_TIME * HZ" to "0".
That caused 2 of 3 types of boards to fail, while one of them always worked
regardless of the delay.
In a nutshell:
- Board A, chip X: works with delay "PHY_STATE_TIME * HZ" or "0".
- Board B, chip X: does not work with delay "0"
- Board C, chip Y: does not work with delay "0"
Does board A works by "luck" when this delay is "0"?
(this delay has always been there, but it is not clear why)
> - what do transmit/receive counters on the Ethernet driver/MAC return?
>
^ permalink raw reply
* [PATCH] ARM: ftrace: fix syscall name matching
From: Rabin Vincent @ 2016-11-14 13:03 UTC (permalink / raw)
To: linux; +Cc: rostedt, linux-arm-kernel, linux-kernel, Rabin Vincent
From: Rabin Vincent <rabinv@axis.com>
ARM has a few system calls (most notably mmap) for which the names of
the functions which are referenced in the syscall table do not match the
names of the syscall tracepoints. As a consequence of this, these
tracepoints are not made available. Implement
arch_syscall_match_sym_name to fix this and allow tracing even these
system calls.
Signed-off-by: Rabin Vincent <rabinv@axis.com>
---
arch/arm/include/asm/ftrace.h | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/arch/arm/include/asm/ftrace.h b/arch/arm/include/asm/ftrace.h
index bfe2a2f..8467909 100644
--- a/arch/arm/include/asm/ftrace.h
+++ b/arch/arm/include/asm/ftrace.h
@@ -54,6 +54,27 @@ static inline void *return_address(unsigned int level)
#define ftrace_return_address(n) return_address(n)
+#define ARCH_HAS_SYSCALL_MATCH_SYM_NAME
+
+static inline bool arch_syscall_match_sym_name(const char *sym,
+ const char *name)
+{
+ /* Skip sys_ */
+ sym += 4;
+ name += 4;
+
+ if (!strcmp(sym, "mmap2"))
+ sym = "mmap_pgoff";
+ else if (!strcmp(sym, "statfs64_wrapper"))
+ sym = "statfs64";
+ else if (!strcmp(sym, "fstatfs64_wrapper"))
+ sym = "fstatfs64";
+ else if (!strcmp(sym, "arm_fadvise64_64"))
+ sym = "fadvise64_64";
+
+ return !strcmp(sym, name);
+}
+
#endif /* ifndef __ASSEMBLY__ */
#endif /* _ASM_ARM_FTRACE */
--
2.1.4
^ permalink raw reply related
* [PATCH] ARM: ftrace: fix syscall name matching
From: Rabin Vincent @ 2016-11-14 13:03 UTC (permalink / raw)
To: linux-arm-kernel
From: Rabin Vincent <rabinv@axis.com>
ARM has a few system calls (most notably mmap) for which the names of
the functions which are referenced in the syscall table do not match the
names of the syscall tracepoints. As a consequence of this, these
tracepoints are not made available. Implement
arch_syscall_match_sym_name to fix this and allow tracing even these
system calls.
Signed-off-by: Rabin Vincent <rabinv@axis.com>
---
arch/arm/include/asm/ftrace.h | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/arch/arm/include/asm/ftrace.h b/arch/arm/include/asm/ftrace.h
index bfe2a2f..8467909 100644
--- a/arch/arm/include/asm/ftrace.h
+++ b/arch/arm/include/asm/ftrace.h
@@ -54,6 +54,27 @@ static inline void *return_address(unsigned int level)
#define ftrace_return_address(n) return_address(n)
+#define ARCH_HAS_SYSCALL_MATCH_SYM_NAME
+
+static inline bool arch_syscall_match_sym_name(const char *sym,
+ const char *name)
+{
+ /* Skip sys_ */
+ sym += 4;
+ name += 4;
+
+ if (!strcmp(sym, "mmap2"))
+ sym = "mmap_pgoff";
+ else if (!strcmp(sym, "statfs64_wrapper"))
+ sym = "statfs64";
+ else if (!strcmp(sym, "fstatfs64_wrapper"))
+ sym = "fstatfs64";
+ else if (!strcmp(sym, "arm_fadvise64_64"))
+ sym = "fadvise64_64";
+
+ return !strcmp(sym, name);
+}
+
#endif /* ifndef __ASSEMBLY__ */
#endif /* _ASM_ARM_FTRACE */
--
2.1.4
^ permalink raw reply related
* RE: [PATCH net-next v5] cadence: Add LSO support.
From: Rafal Ozieblo @ 2016-11-14 9:32 UTC (permalink / raw)
To: David Miller
Cc: nicolas.ferre@atmel.com, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
From: David Miller [mailto:davem@davemloft.net]
Sent: 10 listopada 2016 18:01
To: Rafal Ozieblo
Cc: nicolas.ferre@atmel.com; netdev@vger.kernel.org; linux-kernel@vger.kernel.org
Subject: Re: [PATCH net-next v5]] cadence: Add LSO support.
From: Rafal Ozieblo <rafalo@cadence.com>
Date: Wed, 9 Nov 2016 13:41:02 +0000
> First, please remove the spurious closing bracket in your Subject line in future submittions.
>
>> + if (is_udp) /* is_udp is only set when (is_lso) is checked */
>> + /* zero UDP checksum, not calculated by h/w for UFO */
>> + udp_hdr(skb)->check = 0;
>
> This is really not ok.
>
> If UFO is in use it should not silently disable UDP checksums.
>
> If you cannot support UFO with proper checksumming, then you cannot enable support for that feature.
According Cadence Gigabit Ethernet MAC documentation:
"Hardware will not calculate the UDP checksum or modify the UDP checksum field. Therefore software
must set a value of zero in the checksum field in the UDP header (in the first payload buffer)
to indicate to the receiver that the UDP datagram does not include a checksum."
It is hardware requirement.
^ permalink raw reply
* [bug report] qedr: Add support for QP verbs
From: Dan Carpenter @ 2016-11-14 13:03 UTC (permalink / raw)
To: Ram.Amrani-YGCgFSpz5w/QT0dZR+AlfA; +Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA
Hello Ram Amrani,
The patch cecbcddf6461: "qedr: Add support for QP verbs" from Oct 10,
2016, leads to the following static checker warning:
drivers/infiniband/hw/qedr/verbs.c:2067 qedr_destroy_qp()
'0x5 | 0x1' has '0x1' set on both sides
drivers/infiniband/hw/qedr/verbs.c
2056 int qedr_destroy_qp(struct ib_qp *ibqp)
2057 {
2058 struct qedr_qp *qp = get_qedr_qp(ibqp);
2059 struct qedr_dev *dev = qp->dev;
2060 struct ib_qp_attr attr;
2061 int attr_mask = 0;
2062 int rc = 0;
2063
2064 DP_DEBUG(dev, QEDR_MSG_QP, "destroy qp: destroying %p, qp type=%d\n",
2065 qp, qp->qp_type);
2066
2067 if (qp->state != (QED_ROCE_QP_STATE_RESET | QED_ROCE_QP_STATE_ERR |
2068 QED_ROCE_QP_STATE_INIT)) {
These aren't bitfields, they're just numbers. This code is pretty
suspect. Not sure what was intended.
2069 attr.qp_state = IB_QPS_ERR;
2070 attr_mask |= IB_QP_STATE;
2071
2072 /* Change the QP state to ERROR */
2073 qedr_modify_qp(ibqp, &attr, attr_mask, NULL);
2074 }
regards,
dan carpenter
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/2] go: Add recipes for golang compilers and tools
From: Alexander Kanavin @ 2016-11-14 13:00 UTC (permalink / raw)
To: openembedded-core
In-Reply-To: <1478887474.23123.233.camel@linuxfoundation.org>
On 11/11/2016 08:04 PM, Richard Purdie wrote:
> This was something that came up at OEDEM. There are several layers with
> several attempts at getting this right, most have some issues.
>
> Whilst we've been pulling things out of core, we also need to consider
> things that perhaps should get added. Having this in core would
> certainly address a number of issues (but is also potentially a
> maintenance burden).
>
> We did agree there that we'd consider this. Obviously input from people
> not there is welcome though and this does need discussion. I'm leaning
> moderately in favour of adding it as things stand.
I guess I would be more open to this if Khem at the same time sent a
patch that explicitly assigns maintainership of all those new recipes.
So please don't merge until that is agreed and done.
Alex
^ permalink raw reply
* [PATCH] i2c: mux: fix up dependencies
From: Linus Walleij @ 2016-11-14 13:03 UTC (permalink / raw)
To: Wolfram Sang, linux-i2c
Cc: Linus Walleij, stable, Jonathan Cameron, Peter Rosin
We get the following build error from UM Linux after adding
an entry to drivers/iio/gyro/Kconfig that issues "select I2C_MUX":
ERROR: "devm_ioremap_resource"
[drivers/i2c/muxes/i2c-mux-reg.ko] undefined!
ERROR: "of_address_to_resource"
[drivers/i2c/muxes/i2c-mux-reg.ko] undefined!
It appears that the I2C mux core code actually only requires
CONFIG_OF, but depends on HAS_IOMEM for historical reasons,
while CONFIG_I2C_MUX_REG does *not* have a direct dependency
on HAS_IOMEM.
This creates a situation where a allyesconfig or allmodconfig
for UM Linux will select I2C_MUX, and will implicitly enable
I2C_MUX_REG as well, and the compilation will fail for the
register driver.
Fix this up by making I2C_MUX_REG depend on HAS_IOMEM and
the I2C_MUX depend on OF.
Cc: stable@vger.kernel.org
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Reported-by: Jonathan Cameron <jic23@jic23.retrosnub.co.uk>
Cc: Jonathan Cameron <jic23@jic23.retrosnub.co.uk>
Cc: Peter Rosin <peda@axentia.se>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
drivers/i2c/Kconfig | 2 +-
drivers/i2c/muxes/Kconfig | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/i2c/Kconfig b/drivers/i2c/Kconfig
index d223650a97e4..b9e378cfe1d1 100644
--- a/drivers/i2c/Kconfig
+++ b/drivers/i2c/Kconfig
@@ -59,7 +59,7 @@ config I2C_CHARDEV
config I2C_MUX
tristate "I2C bus multiplexing support"
- depends on HAS_IOMEM
+ depends on OF
help
Say Y here if you want the I2C core to support the ability to
handle multiplexed I2C bus topologies, by presenting each
diff --git a/drivers/i2c/muxes/Kconfig b/drivers/i2c/muxes/Kconfig
index e280c8ecc0b5..96de9ce5669b 100644
--- a/drivers/i2c/muxes/Kconfig
+++ b/drivers/i2c/muxes/Kconfig
@@ -63,6 +63,7 @@ config I2C_MUX_PINCTRL
config I2C_MUX_REG
tristate "Register-based I2C multiplexer"
+ depends on HAS_IOMEM
help
If you say yes to this option, support will be included for a
register based I2C multiplexer. This driver provides access to
--
2.7.4
^ permalink raw reply related
* [net-next PATCH v2] net: dummy: Introduce dummy virtual functions
From: Phil Sutter @ 2016-11-14 13:02 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Sabrina Dubroca
The idea for this was born when testing VF support in iproute2 which was
impeded by hardware requirements. In fact, not every VF-capable hardware
driver implements all netdev ops, so testing the interface is still hard
to do even with a well-sorted hardware shelf.
To overcome this and allow for testing the user-kernel interface, this
patch allows to turn dummy into a PF with a configurable amount of VFs.
Due to the assumption that all PFs are PCI devices, this implementation
is not completely straightforward: In order to allow for
rtnl_fill_ifinfo() to see the dummy VFs, a fake PCI parent device is
attached to the dummy netdev. This has to happen at the right spot so
register_netdevice() does not get confused. This patch abuses
ndo_fix_features callback for that. In ndo_uninit callback, the fake
parent is removed again for the same purpose.
Joint work with Sabrina Dubroca.
Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
Signed-off-by: Phil Sutter <phil@nwl.cc>
---
Changes since v1:
- Fixed issues reported by kbuild test robot:
- pci_dev->sriov is only present if CONFIG_PCI_ATS is active.
- pci_bus_type does not exist if CONFIG_PCI is not defined.
---
drivers/net/dummy.c | 199 +++++++++++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 197 insertions(+), 2 deletions(-)
diff --git a/drivers/net/dummy.c b/drivers/net/dummy.c
index 69fc8409a9733..a831537145bd9 100644
--- a/drivers/net/dummy.c
+++ b/drivers/net/dummy.c
@@ -34,6 +34,8 @@
#include <linux/etherdevice.h>
#include <linux/init.h>
#include <linux/moduleparam.h>
+#include <linux/pci.h>
+#include "../pci/pci.h" /* for struct pci_sriov */
#include <linux/rtnetlink.h>
#include <net/rtnetlink.h>
#include <linux/u64_stats_sync.h>
@@ -42,6 +44,37 @@
#define DRV_VERSION "1.0"
static int numdummies = 1;
+static int num_vfs;
+
+static struct pci_sriov pdev_sriov;
+
+static struct pci_dev pci_pdev = {
+ .is_physfn = 1,
+#ifdef CONFIG_PCI_ATS
+ .sriov = &pdev_sriov,
+#endif
+#ifdef CONFIG_PCI
+ .dev.bus = &pci_bus_type,
+#endif
+};
+
+struct vf_data_storage {
+ unsigned char vf_mac[ETH_ALEN];
+ u16 pf_vlan; /* When set, guest VLAN config not allowed. */
+ u16 pf_qos;
+ __be16 vlan_proto;
+ u16 min_tx_rate;
+ u16 max_tx_rate;
+ u8 spoofchk_enabled;
+ bool rss_query_enabled;
+ u8 trusted;
+ int link_state;
+};
+
+struct dummy_priv {
+ int num_vfs;
+ struct vf_data_storage *vfinfo;
+};
/* fake multicast ability */
static void set_multicast_list(struct net_device *dev)
@@ -91,15 +124,29 @@ static netdev_tx_t dummy_xmit(struct sk_buff *skb, struct net_device *dev)
static int dummy_dev_init(struct net_device *dev)
{
+ struct dummy_priv *priv = netdev_priv(dev);
+
dev->dstats = netdev_alloc_pcpu_stats(struct pcpu_dstats);
if (!dev->dstats)
return -ENOMEM;
+ priv->num_vfs = num_vfs;
+ priv->vfinfo = NULL;
+
+ if (!num_vfs)
+ return 0;
+
+ priv->vfinfo = kcalloc(num_vfs, sizeof(struct vf_data_storage),
+ GFP_KERNEL);
+ if (!priv->vfinfo)
+ return -ENOMEM;
+
return 0;
}
static void dummy_dev_uninit(struct net_device *dev)
{
+ dev->dev.parent = NULL;
free_percpu(dev->dstats);
}
@@ -112,6 +159,129 @@ static int dummy_change_carrier(struct net_device *dev, bool new_carrier)
return 0;
}
+/* fake, just to set fake PCI parent after netdev_register_kobject() */
+static netdev_features_t dummy_fix_features(struct net_device *dev,
+ netdev_features_t features)
+{
+ struct dummy_priv *priv = netdev_priv(dev);
+
+ if (priv->num_vfs)
+ dev->dev.parent = &pci_pdev.dev;
+
+ return features;
+}
+
+static int dummy_set_vf_mac(struct net_device *dev, int vf, u8 *mac)
+{
+ struct dummy_priv *priv = netdev_priv(dev);
+
+ if (!is_valid_ether_addr(mac) || (vf >= priv->num_vfs))
+ return -EINVAL;
+
+ memcpy(priv->vfinfo[vf].vf_mac, mac, ETH_ALEN);
+
+ return 0;
+}
+
+static int dummy_set_vf_vlan(struct net_device *dev, int vf,
+ u16 vlan, u8 qos, __be16 vlan_proto)
+{
+ struct dummy_priv *priv = netdev_priv(dev);
+
+ if ((vf >= priv->num_vfs) || (vlan > 4095) || (qos > 7))
+ return -EINVAL;
+
+ priv->vfinfo[vf].pf_vlan = vlan;
+ priv->vfinfo[vf].pf_qos = qos;
+ priv->vfinfo[vf].vlan_proto = vlan_proto;
+
+ return 0;
+}
+
+static int dummy_set_vf_rate(struct net_device *dev, int vf, int min, int max)
+{
+ struct dummy_priv *priv = netdev_priv(dev);
+
+ if (vf >= priv->num_vfs)
+ return -EINVAL;
+
+ priv->vfinfo[vf].min_tx_rate = min;
+ priv->vfinfo[vf].max_tx_rate = max;
+
+ return 0;
+}
+
+static int dummy_set_vf_spoofchk(struct net_device *dev, int vf, bool val)
+{
+ struct dummy_priv *priv = netdev_priv(dev);
+
+ if (vf >= priv->num_vfs)
+ return -EINVAL;
+
+ priv->vfinfo[vf].spoofchk_enabled = val;
+
+ return 0;
+}
+
+static int dummy_set_vf_rss_query_en(struct net_device *dev, int vf, bool val)
+{
+ struct dummy_priv *priv = netdev_priv(dev);
+
+ if (vf >= priv->num_vfs)
+ return -EINVAL;
+
+ priv->vfinfo[vf].rss_query_enabled = val;
+
+ return 0;
+}
+
+static int dummy_set_vf_trust(struct net_device *dev, int vf, bool val)
+{
+ struct dummy_priv *priv = netdev_priv(dev);
+
+ if (vf >= priv->num_vfs)
+ return -EINVAL;
+
+ priv->vfinfo[vf].trusted = val;
+
+ return 0;
+}
+
+static int dummy_get_vf_config(struct net_device *dev,
+ int vf, struct ifla_vf_info *ivi)
+{
+ struct dummy_priv *priv = netdev_priv(dev);
+
+ if (vf >= priv->num_vfs)
+ return -EINVAL;
+
+ ivi->vf = vf;
+ memcpy(&ivi->mac, priv->vfinfo[vf].vf_mac, ETH_ALEN);
+ ivi->vlan = priv->vfinfo[vf].pf_vlan;
+ ivi->qos = priv->vfinfo[vf].pf_qos;
+ ivi->spoofchk = priv->vfinfo[vf].spoofchk_enabled;
+ ivi->linkstate = priv->vfinfo[vf].link_state;
+ ivi->min_tx_rate = priv->vfinfo[vf].min_tx_rate;
+ ivi->max_tx_rate = priv->vfinfo[vf].max_tx_rate;
+ ivi->rss_query_en = priv->vfinfo[vf].rss_query_enabled;
+ ivi->trusted = priv->vfinfo[vf].trusted;
+ ivi->vlan_proto = priv->vfinfo[vf].vlan_proto;
+
+ return 0;
+}
+
+static int dummy_set_vf_link_state(struct net_device *dev, int vf, int state)
+{
+ struct dummy_priv *priv = netdev_priv(dev);
+
+ if (vf >= priv->num_vfs)
+ return -EINVAL;
+
+ priv->vfinfo[vf].link_state = state;
+
+ return 0;
+}
+
static const struct net_device_ops dummy_netdev_ops = {
.ndo_init = dummy_dev_init,
.ndo_uninit = dummy_dev_uninit,
@@ -121,6 +291,15 @@ static const struct net_device_ops dummy_netdev_ops = {
.ndo_set_mac_address = eth_mac_addr,
.ndo_get_stats64 = dummy_get_stats64,
.ndo_change_carrier = dummy_change_carrier,
+ .ndo_fix_features = dummy_fix_features,
+ .ndo_set_vf_mac = dummy_set_vf_mac,
+ .ndo_set_vf_vlan = dummy_set_vf_vlan,
+ .ndo_set_vf_rate = dummy_set_vf_rate,
+ .ndo_set_vf_spoofchk = dummy_set_vf_spoofchk,
+ .ndo_set_vf_trust = dummy_set_vf_trust,
+ .ndo_get_vf_config = dummy_get_vf_config,
+ .ndo_set_vf_link_state = dummy_set_vf_link_state,
+ .ndo_set_vf_rss_query_en = dummy_set_vf_rss_query_en,
};
static void dummy_get_drvinfo(struct net_device *dev,
@@ -134,6 +313,14 @@ static const struct ethtool_ops dummy_ethtool_ops = {
.get_drvinfo = dummy_get_drvinfo,
};
+static void dummy_free_netdev(struct net_device *dev)
+{
+ struct dummy_priv *priv = netdev_priv(dev);
+
+ kfree(priv->vfinfo);
+ free_netdev(dev);
+}
+
static void dummy_setup(struct net_device *dev)
{
ether_setup(dev);
@@ -141,7 +328,7 @@ static void dummy_setup(struct net_device *dev)
/* Initialize the device structure. */
dev->netdev_ops = &dummy_netdev_ops;
dev->ethtool_ops = &dummy_ethtool_ops;
- dev->destructor = free_netdev;
+ dev->destructor = dummy_free_netdev;
/* Fill in device structure with ethernet-generic values. */
dev->flags |= IFF_NOARP;
@@ -169,6 +356,7 @@ static int dummy_validate(struct nlattr *tb[], struct nlattr *data[])
static struct rtnl_link_ops dummy_link_ops __read_mostly = {
.kind = DRV_NAME,
+ .priv_size = sizeof(struct dummy_priv),
.setup = dummy_setup,
.validate = dummy_validate,
};
@@ -177,12 +365,16 @@ static struct rtnl_link_ops dummy_link_ops __read_mostly = {
module_param(numdummies, int, 0);
MODULE_PARM_DESC(numdummies, "Number of dummy pseudo devices");
+module_param(num_vfs, int, 0);
+MODULE_PARM_DESC(num_vfs, "Number of dummy VFs per dummy device");
+
static int __init dummy_init_one(void)
{
struct net_device *dev_dummy;
int err;
- dev_dummy = alloc_netdev(0, "dummy%d", NET_NAME_UNKNOWN, dummy_setup);
+ dev_dummy = alloc_netdev(sizeof(struct dummy_priv),
+ "dummy%d", NET_NAME_UNKNOWN, dummy_setup);
if (!dev_dummy)
return -ENOMEM;
@@ -190,6 +382,7 @@ static int __init dummy_init_one(void)
err = register_netdevice(dev_dummy);
if (err < 0)
goto err;
+
return 0;
err:
@@ -201,6 +394,8 @@ static int __init dummy_init_module(void)
{
int i, err = 0;
+ pdev_sriov.num_VFs = num_vfs;
+
rtnl_lock();
err = __rtnl_link_register(&dummy_link_ops);
if (err < 0)
--
2.10.0
^ permalink raw reply related
* [LTP] [RFC] [PATCH] doc: Remove doc/testcases/*
From: Cyril Hrubis @ 2016-11-14 13:01 UTC (permalink / raw)
To: ltp
In-Reply-To: <2065515236.2077378.1479125866081.JavaMail.zimbra@redhat.com>
Hi!
> No objections to removal. I suspect many of these descriptions
> are repeated in testcases (which are more up to date).
Pushed with your ack.
--
Cyril Hrubis
chrubis@suse.cz
^ permalink raw reply
* Recent changes (master)
From: Jens Axboe @ 2016-11-14 13:00 UTC (permalink / raw)
To: fio
The following changes since commit 206c546d6015fe3809b8e52ea95f56114b8e9f25:
rbd: fix crash with zero sized image (2016-11-12 08:36:23 -0700)
are available in the git repository at:
git://git.kernel.dk/fio.git master
for you to fetch changes up to 471bb52b2e75413d18e8def5bb7d301aab7541e9:
Fix memory leak on tmp_buf (2016-11-14 00:05:37 +0000)
----------------------------------------------------------------
Colin Ian King (1):
Fix memory leak on tmp_buf
oslib/libmtd.c | 1 +
1 file changed, 1 insertion(+)
---
Diff of recent changes:
diff --git a/oslib/libmtd.c b/oslib/libmtd.c
index 5b22d6a..24e9db9 100644
--- a/oslib/libmtd.c
+++ b/oslib/libmtd.c
@@ -1116,6 +1116,7 @@ static int legacy_auto_oob_layout(const struct mtd_dev_info *mtd, int fd,
len = mtd->oob_size - start;
memcpy(oob + start, tmp_buf + start, len);
}
+ free(tmp_buf);
return 0;
}
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.