* [PATCH 2/2] ARM: dts: apq8064: add support to pm8821
From: Srinivas Kandagatla @ 2016-11-14 17:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161108191343.GP25787@tuxbot>
Thanks Bjorn for review comments.
On 08/11/16 19:13, Bjorn Andersson wrote:
> On Tue 08 Nov 08:29 PST 2016, Srinivas Kandagatla wrote:
>
>> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
>> ---
>> arch/arm/boot/dts/qcom-apq8064.dtsi | 28 ++++++++++++++++++++++++++++
>> 1 file changed, 28 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/qcom-apq8064.dtsi b/arch/arm/boot/dts/qcom-apq8064.dtsi
>> index 1dbe697..fde006c 100644
>> --- a/arch/arm/boot/dts/qcom-apq8064.dtsi
>> +++ b/arch/arm/boot/dts/qcom-apq8064.dtsi
>> @@ -627,6 +627,34 @@
>> clock-names = "core";
>> };
>>
>> + qcom,ssbi at c00000 {
>
> No "qcom," in the node name.
Will fix it in next version, I agree with rest of the comments too.
All of them will be fixed in next version.
>
>> + compatible = "qcom,ssbi";
>> + reg = <0x00c00000 0x1000>;
>> + qcom,controller-type = "pmic-arbiter";
>> +
>> + pmicintc2: pmic at 1 {
>
> I think we should follow Linus' lead and label this "pm8821".
>
>> + compatible = "qcom,pm8821";
>> + interrupt-parent = <&tlmm_pinmux>;
>> + interrupts = <76 8>;
>
> Please spell out IRQ_TYPE_LEVEL_LOW.
>
> And interrupts-extended = <&tlmm_pinmux 76 IRQ_TYPE_LEVEL_LOW> combines
> the two lines nicely.
>
>> + #interrupt-cells = <2>;
>> + interrupt-controller;
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + pm8821_mpps: mpps at 50 {
>> +
>
> Extra newline.
>
>> + compatible = "qcom,pm8821-mpp", "qcom,ssbi-mpp";
>> + reg = <0x50>;
>> +
>> + interrupts = <24 1>, <25 1>, <26 1>,
>> + <27 1>;
>
> I think these should be IRQ_TYPE_NONE per the discussion on how to share
> interrupts between the gpio/mpp driver and other clients.
>
> On the other hand, per the pm8821 driver we only support LEVEL_LOW
> (high?).
>
>> +
>> + gpio-controller;
>> + #gpio-cells = <2>;
>> + };
>> + };
>> + };
>> +
>
> Regards,
> Bjorn
>
^ permalink raw reply
* Re: [PATCH 2/2] ARM: dts: apq8064: add support to pm8821
From: Srinivas Kandagatla @ 2016-11-14 17:32 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Lee Jones, Rob Herring, Andy Gross, devicetree, linux-kernel,
linux-arm-msm, linux-soc, linux-arm-kernel
In-Reply-To: <20161108191343.GP25787@tuxbot>
Thanks Bjorn for review comments.
On 08/11/16 19:13, Bjorn Andersson wrote:
> On Tue 08 Nov 08:29 PST 2016, Srinivas Kandagatla wrote:
>
>> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
>> ---
>> arch/arm/boot/dts/qcom-apq8064.dtsi | 28 ++++++++++++++++++++++++++++
>> 1 file changed, 28 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/qcom-apq8064.dtsi b/arch/arm/boot/dts/qcom-apq8064.dtsi
>> index 1dbe697..fde006c 100644
>> --- a/arch/arm/boot/dts/qcom-apq8064.dtsi
>> +++ b/arch/arm/boot/dts/qcom-apq8064.dtsi
>> @@ -627,6 +627,34 @@
>> clock-names = "core";
>> };
>>
>> + qcom,ssbi@c00000 {
>
> No "qcom," in the node name.
Will fix it in next version, I agree with rest of the comments too.
All of them will be fixed in next version.
>
>> + compatible = "qcom,ssbi";
>> + reg = <0x00c00000 0x1000>;
>> + qcom,controller-type = "pmic-arbiter";
>> +
>> + pmicintc2: pmic@1 {
>
> I think we should follow Linus' lead and label this "pm8821".
>
>> + compatible = "qcom,pm8821";
>> + interrupt-parent = <&tlmm_pinmux>;
>> + interrupts = <76 8>;
>
> Please spell out IRQ_TYPE_LEVEL_LOW.
>
> And interrupts-extended = <&tlmm_pinmux 76 IRQ_TYPE_LEVEL_LOW> combines
> the two lines nicely.
>
>> + #interrupt-cells = <2>;
>> + interrupt-controller;
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + pm8821_mpps: mpps@50 {
>> +
>
> Extra newline.
>
>> + compatible = "qcom,pm8821-mpp", "qcom,ssbi-mpp";
>> + reg = <0x50>;
>> +
>> + interrupts = <24 1>, <25 1>, <26 1>,
>> + <27 1>;
>
> I think these should be IRQ_TYPE_NONE per the discussion on how to share
> interrupts between the gpio/mpp driver and other clients.
>
> On the other hand, per the pm8821 driver we only support LEVEL_LOW
> (high?).
>
>> +
>> + gpio-controller;
>> + #gpio-cells = <2>;
>> + };
>> + };
>> + };
>> +
>
> Regards,
> Bjorn
>
^ permalink raw reply
* [PATCH 2/2] ARM: davinci_all_defconfig: enable the mstpri and ddrctl drivers
From: Bartosz Golaszewski @ 2016-11-14 17:32 UTC (permalink / raw)
To: Kevin Hilman, Michael Turquette, Sekhar Nori, Rob Herring,
Frank Rowand, Mark Rutland, Peter Ujfalusi, Russell King
Cc: LKML, arm-soc, linux-drm, linux-devicetree, Jyri Sarha,
Tomi Valkeinen, David Airlie, Laurent Pinchart,
Bartosz Golaszewski
In-Reply-To: <1479144724-14231-1-git-send-email-bgolaszewski@baylibre.com>
With the da8xx memory controller and master peripheral priority
drivers merged and corresponding device tree changes in place we can
now enable appropriate options by default.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
arch/arm/configs/davinci_all_defconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/configs/davinci_all_defconfig b/arch/arm/configs/davinci_all_defconfig
index b5e978f..f814f01 100644
--- a/arch/arm/configs/davinci_all_defconfig
+++ b/arch/arm/configs/davinci_all_defconfig
@@ -56,6 +56,7 @@ CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y
# CONFIG_FW_LOADER is not set
+CONFIG_DA8XX_MSTPRI=y
CONFIG_MTD=m
CONFIG_MTD_BLOCK=m
CONFIG_MTD_CFI=m
@@ -187,6 +188,7 @@ CONFIG_DMADEVICES=y
CONFIG_TI_EDMA=y
CONFIG_MEMORY=y
CONFIG_TI_AEMIF=m
+CONFIG_DA8XX_DDRCTL=y
CONFIG_EXT2_FS=y
CONFIG_EXT3_FS=y
CONFIG_XFS_FS=m
--
2.9.3
^ permalink raw reply related
* Re: [Qemu-devel] [PATCH 1/3] 9pfs: add cleanup operation in FileOperations
From: Greg Kurz @ 2016-11-14 17:32 UTC (permalink / raw)
To: Li Qiang; +Cc: qemu-devel, liqiang6-s
In-Reply-To: <5829af0b.84f4420a.a436f.4a6d@mx.google.com>
On Mon, 14 Nov 2016 07:32:56 -0500
Li Qiang <liq3ea@gmail.com> wrote:
> From: Li Qiang <liq3ea@gmail.com>
>
> Currently, the backend of VirtFS doesn't have a cleanup
> function. This will lead resource leak issues if the backed
> driver allocates resources. This patch addresses this issue.
>
> Signed-off-by: Li Qiang <liq3ea@gmail.com>
> ---
> fsdev/file-op-9p.h | 1 +
> hw/9pfs/9p.c | 3 +++
> 2 files changed, 4 insertions(+)
>
> diff --git a/fsdev/file-op-9p.h b/fsdev/file-op-9p.h
> index 6db9fea..a56dc84 100644
> --- a/fsdev/file-op-9p.h
> +++ b/fsdev/file-op-9p.h
> @@ -100,6 +100,7 @@ struct FileOperations
> {
> int (*parse_opts)(QemuOpts *, struct FsDriverEntry *);
> int (*init)(struct FsContext *);
> + void (*cleanup)(struct FsContext *);
> int (*lstat)(FsContext *, V9fsPath *, struct stat *);
> ssize_t (*readlink)(FsContext *, V9fsPath *, char *, size_t);
> int (*chmod)(FsContext *, V9fsPath *, FsCred *);
> diff --git a/hw/9pfs/9p.c b/hw/9pfs/9p.c
> index aea7e9d..166b5a7 100644
> --- a/hw/9pfs/9p.c
> +++ b/hw/9pfs/9p.c
> @@ -3532,6 +3532,9 @@ void v9fs_device_unrealize_common(V9fsState *s, Error **errp)
> {
> g_free(s->ctx.fs_root);
> g_free(s->tag);
> + if (s->ops->cleanup) {
> + s->ops->cleanup(&s->ctx);
> + }
Unrealize should undo things that were set during realize in reverse order:
please move the cleanup stuff above calls to g_free() (which are actually
misordered since tag is allocated after fs_root... maybe you can fix that
too in a preparatory patch).
You also have to call cleanup in the error path of realize if init was
called.
> }
>
> typedef struct VirtfsCoResetData {
^ permalink raw reply
* [PATCH 1/2] ARM: dts: da850: add the mstpri and ddrctl nodes
From: Bartosz Golaszewski @ 2016-11-14 17:32 UTC (permalink / raw)
To: Kevin Hilman, Michael Turquette, Sekhar Nori, Rob Herring,
Frank Rowand, Mark Rutland, Peter Ujfalusi, Russell King
Cc: LKML, arm-soc, linux-drm, linux-devicetree, Jyri Sarha,
Tomi Valkeinen, David Airlie, Laurent Pinchart,
Bartosz Golaszewski
In-Reply-To: <1479144724-14231-1-git-send-email-bgolaszewski@baylibre.com>
Add the nodes for the MSTPRI configuration and DDR2/mDDR memory
controller drivers to da850.dtsi.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
arch/arm/boot/dts/da850.dtsi | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index 1bb1f6d..1635218 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -440,6 +440,11 @@
interrupts = <52>;
status = "disabled";
};
+
+ mstpri: mstpri@14110 {
+ compatible = "ti,da850-mstpri";
+ reg = <0x14110 0x0c>;
+ };
};
aemif: aemif@68000000 {
compatible = "ti,da850-aemif";
@@ -451,4 +456,8 @@
1 0 0x68000000 0x00008000>;
status = "disabled";
};
+ ddrctl: ddrctl@b0000000 {
+ compatible = "ti,da850-ddr-controller";
+ reg = <0xb0000000 0xe8>;
+ };
};
--
2.9.3
^ permalink raw reply related
* [PATCH 0/2] ARM: da850: enable the MSTPRI and DDR2/mDDR drivers
From: Bartosz Golaszewski @ 2016-11-14 17:32 UTC (permalink / raw)
To: Kevin Hilman, Michael Turquette, Sekhar Nori, Rob Herring,
Frank Rowand, Mark Rutland, Peter Ujfalusi, Russell King
Cc: LKML, arm-soc, linux-drm, linux-devicetree, Jyri Sarha,
Tomi Valkeinen, David Airlie, Laurent Pinchart,
Bartosz Golaszewski
This is a follow-up for my previous series:
ARM: da850: new drivers for better LCDC support
from which the new drivers were merged, while the patch adding the
panel node was nacked and has been dropped.
The first patch in this series enables the new drivers in da850.dtsi.
It has been changed since the last iteration to not disable the added
nodes. Also: the patch enabling the nodes in da850-lcdk.dts has been
dropped too.
The second patch updates the davinci defconfig.
Bartosz Golaszewski (2):
ARM: dts: da850: add the mstpri and ddrctl nodes
ARM: davinci_all_defconfig: enable the mstpri and ddrctl drivers
arch/arm/boot/dts/da850.dtsi | 9 +++++++++
arch/arm/configs/davinci_all_defconfig | 2 ++
2 files changed, 11 insertions(+)
--
2.9.3
^ permalink raw reply
* [U-Boot] [PATCH] armv8/ls1043a: Add the OCRAM initialization
From: york sun @ 2016-11-14 17:32 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1ff50edd-3948-c861-6ac9-9a0618ea3584@nxp.com>
On 11/07/2016 10:36 AM, york.sun at nxp.com wrote:
> On 10/27/2016 02:47 AM, Calvin Johnson wrote:
>> Hi York,
>>
>>> -----Original Message-----
>>> From: york sun
>>> Sent: Wednesday, October 26, 2016 10:09 PM
>>> To: Calvin Johnson <calvin.johnson@nxp.com>; Prabhakar Kushwaha
>>> <prabhakar.kushwaha@nxp.com>; Pratiyush
>>> Srivastava <pratiyush.srivastava@nxp.com>; u-boot at lists.denx.de;
>>> Mingkai Hu <mingkai.hu@nxp.com>
>>> Cc: Hou Zhiqiang <Zhiqiang.Hou@freescale.com>
>>> Subject: Re: [PATCH] armv8/ls1043a: Add the OCRAM initialization
>>>
>>> On 10/24/2016 09:30 PM, Calvin Johnson wrote:
>>>
>>>>>>> I wonder why we don't see ECC errors before this patch. We have
>>>>>>> LS1043A boots on NAND, SD.
>>>>>>>
>>>>>>
>>>>>> OCRAM has a requirement of initializing before first time "read".
>>>>>> If user reads OCRAM before **initializing**; ECC error will come.
>>>>>> (u-boot is not handling this error for now).
>>>>>>
>>>>>> I can only guess the reason of not seeing this error as OCRAM
>>>>>> never read before any write.
>>>>>> Even in case of Stack, data is first written and then read.
>>>>>>
>>>>>
>>>>> Is there a case you want to read from OCRAM before writing anything
>>>>> to it? Why don't we need to do so for SPL or
>>> LSCH3?
>>>>
>>>> This issue will be seen ONLY in secure boot. It was reproduced on
>>>> LS1043A also.
>>>>
>>>
>>> How about LSCH3? We have LS2080A secure boot.
>>
>> I don't know about LS2080A. Prabhakar or Ruchika(copied) may be able
>> to comment on this.
>>
>
> Please follow up on this thread. We need to understand when and where
> OCRAM needs to be cleared.
>
Can Prabhakar or Ruchika verify this OCRAM init on LSCH3? If it is
required and effective, we can take this patch.
York
^ permalink raw reply
* Re: Debugging Ethernet issues
From: Florian Fainelli @ 2016-11-14 17:32 UTC (permalink / raw)
To: 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, Sebastian Frias,
Kirill Kapranov
In-Reply-To: <5829D95C.6060509@free.fr>
On 11/14/2016 07:33 AM, Mason wrote:
> On 14/11/2016 15:58, Mason wrote:
>
>> nb8800 26000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
>> vs
>> nb8800 26000.ethernet eth0: Link is Up - 100Mbps/Full - flow control off
>>
>> I'm not sure whether "flow control" is relevant...
>
> Based on phy_print_status()
> phydev->pause ? "rx/tx" : "off"
> I added the following patch.
>
> diff --git a/drivers/net/ethernet/aurora/nb8800.c b/drivers/net/ethernet/aurora/nb8800.c
> index defc22a15f67..4e758c1cfa4e 100644
> --- a/drivers/net/ethernet/aurora/nb8800.c
> +++ b/drivers/net/ethernet/aurora/nb8800.c
> @@ -667,6 +667,8 @@ static void nb8800_link_reconfigure(struct net_device *dev)
> struct phy_device *phydev = priv->phydev;
> int change = 0;
>
> + printk("%s from %pf\n", __func__, __builtin_return_address(0));
> +
> if (phydev->link) {
> if (phydev->speed != priv->speed) {
> priv->speed = phydev->speed;
> @@ -1274,9 +1276,9 @@ static int nb8800_hw_init(struct net_device *dev)
> nb8800_writeb(priv, NB8800_PQ2, val & 0xff);
>
> /* Auto-negotiate by default */
> - priv->pause_aneg = true;
> - priv->pause_rx = true;
> - priv->pause_tx = true;
> + priv->pause_aneg = false;
> + priv->pause_rx = false;
> + priv->pause_tx = false;
>
> nb8800_mc_init(dev, 0);
>
>
> Connected to 1000 Mbps switch:
>
> # time udhcpc | while read LINE; do date; echo $LINE; done
> Thu Jan 1 00:00:22 UTC 1970
> udhcpc (v1.22.1) started
> Thu Jan 1 00:00:22 UTC 1970
> Sending discover...
> [ 24.565346] nb8800_link_reconfigure from phy_state_machine
> Thu Jan 1 00:00:25 UTC 1970
> Sending discover...
> [ 26.575402] nb8800_link_reconfigure from phy_state_machine
> [ 26.580972] nb8800 26000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx
> Thu Jan 1 00:00:28 UTC 1970
> Sending discover...
> Thu Jan 1 00:00:29 UTC 1970
> Sending select for 172.27.64.58...
> Thu Jan 1 00:00:29 UTC 1970
> Lease of 172.27.64.58 obtained, lease time 604800
> Thu Jan 1 00:00:29 UTC 1970
> deleting routers
> Thu Jan 1 00:00:29 UTC 1970
> adding dns 172.27.0.17
>
> real 0m7.388s
> user 0m0.040s
> sys 0m0.090s
>
>
>
> Connected to 100 Mbps switch:
>
> # time udhcpc | while read LINE; do date; echo $LINE; done
> Thu Jan 1 00:00:14 UTC 1970
> udhcpc (v1.22.1) started
> Thu Jan 1 00:00:15 UTC 1970
> Sending discover...
> [ 16.968621] nb8800_link_reconfigure from phy_state_machine
> [ 17.975359] nb8800_link_reconfigure from phy_state_machine
> [ 17.980923] nb8800 26000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
> Thu Jan 1 00:00:18 UTC 1970
> Sending discover...
> Thu Jan 1 00:00:19 UTC 1970
> Sending select for 172.27.64.58...
> Thu Jan 1 00:00:19 UTC 1970
> Lease of 172.27.64.58 obtained, lease time 604800
> Thu Jan 1 00:00:19 UTC 1970
> deleting routers
> Thu Jan 1 00:00:19 UTC 1970
> adding dns 172.27.0.17
>
> real 0m4.355s
> user 0m0.043s
> sys 0m0.083s
>
And the time difference is clearly accounted for auto-negotiation time
here, as you can see it takes about 3 seconds for Gigabit Ethernet to
auto-negotiate and that seems completely acceptable and normal to me
since it is a more involved process than lower speeds.
>
>
> OK, so now it works (by accident?) even on 100 Mbps switch, but it still
> prints "flow control rx/tx"...
Because your link partner advertises flow control, and that's what
phydev->pause and phydev->asym_pause report (I know it's confusing, but
that's what it is at the moment).
>
> # ethtool -a eth0
> Pause parameters for eth0:
> Autonegotiate: off
> RX: off
> TX: off
>
> These values make sense considering my changes in the driver.
>
> Are 100 Mbps switches supposed to support these pause features,
> and are they supposed to be able to auto-negotiate them?
Yes, switches can support flow control aka pause frames, and unless they
are configurable, they typically advertise what their EEPROM has defined
for them, so most likely the full auto-negotiated spectrum:
10/100/1000Mbps and support for flow control, but your mileage may vary
of course.
--
Florian
^ permalink raw reply
* [PATCH 2/2] ARM: davinci_all_defconfig: enable the mstpri and ddrctl drivers
From: Bartosz Golaszewski @ 2016-11-14 17:32 UTC (permalink / raw)
To: Kevin Hilman, Michael Turquette, Sekhar Nori, Rob Herring,
Frank Rowand, Mark Rutland, Peter Ujfalusi, Russell King
Cc: linux-devicetree, LKML, linux-drm, Bartosz Golaszewski,
Tomi Valkeinen, Jyri Sarha, arm-soc, Laurent Pinchart
In-Reply-To: <1479144724-14231-1-git-send-email-bgolaszewski@baylibre.com>
With the da8xx memory controller and master peripheral priority
drivers merged and corresponding device tree changes in place we can
now enable appropriate options by default.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
arch/arm/configs/davinci_all_defconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/configs/davinci_all_defconfig b/arch/arm/configs/davinci_all_defconfig
index b5e978f..f814f01 100644
--- a/arch/arm/configs/davinci_all_defconfig
+++ b/arch/arm/configs/davinci_all_defconfig
@@ -56,6 +56,7 @@ CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y
# CONFIG_FW_LOADER is not set
+CONFIG_DA8XX_MSTPRI=y
CONFIG_MTD=m
CONFIG_MTD_BLOCK=m
CONFIG_MTD_CFI=m
@@ -187,6 +188,7 @@ CONFIG_DMADEVICES=y
CONFIG_TI_EDMA=y
CONFIG_MEMORY=y
CONFIG_TI_AEMIF=m
+CONFIG_DA8XX_DDRCTL=y
CONFIG_EXT2_FS=y
CONFIG_EXT3_FS=y
CONFIG_XFS_FS=m
--
2.9.3
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related
* [PATCH 2/2] ARM: davinci_all_defconfig: enable the mstpri and ddrctl drivers
From: Bartosz Golaszewski @ 2016-11-14 17:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479144724-14231-1-git-send-email-bgolaszewski@baylibre.com>
With the da8xx memory controller and master peripheral priority
drivers merged and corresponding device tree changes in place we can
now enable appropriate options by default.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
arch/arm/configs/davinci_all_defconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/configs/davinci_all_defconfig b/arch/arm/configs/davinci_all_defconfig
index b5e978f..f814f01 100644
--- a/arch/arm/configs/davinci_all_defconfig
+++ b/arch/arm/configs/davinci_all_defconfig
@@ -56,6 +56,7 @@ CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y
# CONFIG_FW_LOADER is not set
+CONFIG_DA8XX_MSTPRI=y
CONFIG_MTD=m
CONFIG_MTD_BLOCK=m
CONFIG_MTD_CFI=m
@@ -187,6 +188,7 @@ CONFIG_DMADEVICES=y
CONFIG_TI_EDMA=y
CONFIG_MEMORY=y
CONFIG_TI_AEMIF=m
+CONFIG_DA8XX_DDRCTL=y
CONFIG_EXT2_FS=y
CONFIG_EXT3_FS=y
CONFIG_XFS_FS=m
--
2.9.3
^ permalink raw reply related
* [PATCH 1/2] ARM: dts: da850: add the mstpri and ddrctl nodes
From: Bartosz Golaszewski @ 2016-11-14 17:32 UTC (permalink / raw)
To: Kevin Hilman, Michael Turquette, Sekhar Nori, Rob Herring,
Frank Rowand, Mark Rutland, Peter Ujfalusi, Russell King
Cc: linux-devicetree, LKML, linux-drm, Bartosz Golaszewski,
Tomi Valkeinen, Jyri Sarha, arm-soc, Laurent Pinchart
In-Reply-To: <1479144724-14231-1-git-send-email-bgolaszewski@baylibre.com>
Add the nodes for the MSTPRI configuration and DDR2/mDDR memory
controller drivers to da850.dtsi.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
arch/arm/boot/dts/da850.dtsi | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index 1bb1f6d..1635218 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -440,6 +440,11 @@
interrupts = <52>;
status = "disabled";
};
+
+ mstpri: mstpri@14110 {
+ compatible = "ti,da850-mstpri";
+ reg = <0x14110 0x0c>;
+ };
};
aemif: aemif@68000000 {
compatible = "ti,da850-aemif";
@@ -451,4 +456,8 @@
1 0 0x68000000 0x00008000>;
status = "disabled";
};
+ ddrctl: ddrctl@b0000000 {
+ compatible = "ti,da850-ddr-controller";
+ reg = <0xb0000000 0xe8>;
+ };
};
--
2.9.3
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related
* [PATCH 1/2] ARM: dts: da850: add the mstpri and ddrctl nodes
From: Bartosz Golaszewski @ 2016-11-14 17:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479144724-14231-1-git-send-email-bgolaszewski@baylibre.com>
Add the nodes for the MSTPRI configuration and DDR2/mDDR memory
controller drivers to da850.dtsi.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
arch/arm/boot/dts/da850.dtsi | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index 1bb1f6d..1635218 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -440,6 +440,11 @@
interrupts = <52>;
status = "disabled";
};
+
+ mstpri: mstpri at 14110 {
+ compatible = "ti,da850-mstpri";
+ reg = <0x14110 0x0c>;
+ };
};
aemif: aemif at 68000000 {
compatible = "ti,da850-aemif";
@@ -451,4 +456,8 @@
1 0 0x68000000 0x00008000>;
status = "disabled";
};
+ ddrctl: ddrctl at b0000000 {
+ compatible = "ti,da850-ddr-controller";
+ reg = <0xb0000000 0xe8>;
+ };
};
--
2.9.3
^ permalink raw reply related
* [PATCH 0/2] ARM: da850: enable the MSTPRI and DDR2/mDDR drivers
From: Bartosz Golaszewski @ 2016-11-14 17:32 UTC (permalink / raw)
To: Kevin Hilman, Michael Turquette, Sekhar Nori, Rob Herring,
Frank Rowand, Mark Rutland, Peter Ujfalusi, Russell King
Cc: linux-devicetree, LKML, linux-drm, Bartosz Golaszewski,
Tomi Valkeinen, Jyri Sarha, arm-soc, Laurent Pinchart
This is a follow-up for my previous series:
ARM: da850: new drivers for better LCDC support
from which the new drivers were merged, while the patch adding the
panel node was nacked and has been dropped.
The first patch in this series enables the new drivers in da850.dtsi.
It has been changed since the last iteration to not disable the added
nodes. Also: the patch enabling the nodes in da850-lcdk.dts has been
dropped too.
The second patch updates the davinci defconfig.
Bartosz Golaszewski (2):
ARM: dts: da850: add the mstpri and ddrctl nodes
ARM: davinci_all_defconfig: enable the mstpri and ddrctl drivers
arch/arm/boot/dts/da850.dtsi | 9 +++++++++
arch/arm/configs/davinci_all_defconfig | 2 ++
2 files changed, 11 insertions(+)
--
2.9.3
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* [PATCH 0/2] ARM: da850: enable the MSTPRI and DDR2/mDDR drivers
From: Bartosz Golaszewski @ 2016-11-14 17:32 UTC (permalink / raw)
To: linux-arm-kernel
This is a follow-up for my previous series:
ARM: da850: new drivers for better LCDC support
from which the new drivers were merged, while the patch adding the
panel node was nacked and has been dropped.
The first patch in this series enables the new drivers in da850.dtsi.
It has been changed since the last iteration to not disable the added
nodes. Also: the patch enabling the nodes in da850-lcdk.dts has been
dropped too.
The second patch updates the davinci defconfig.
Bartosz Golaszewski (2):
ARM: dts: da850: add the mstpri and ddrctl nodes
ARM: davinci_all_defconfig: enable the mstpri and ddrctl drivers
arch/arm/boot/dts/da850.dtsi | 9 +++++++++
arch/arm/configs/davinci_all_defconfig | 2 ++
2 files changed, 11 insertions(+)
--
2.9.3
^ permalink raw reply
* [PATCH V2] python3-git: upgrade to 2.1.0
From: Edwin Plauchu @ 2016-11-14 17:33 UTC (permalink / raw)
To: openembedded-core; +Cc: Edwin Plauchu
From: Edwin Plauchu <edwin.plauchu.camacho@intel.com>
Signed-off-by: Edwin Plauchu <edwin.plauchu.camacho@linux.intel.com>
---
meta/recipes-devtools/python/python-git.inc | 4 ++--
.../python/{python3-git_2.0.7.bb => python3-git_2.1.0.bb} | 0
2 files changed, 2 insertions(+), 2 deletions(-)
rename meta/recipes-devtools/python/{python3-git_2.0.7.bb => python3-git_2.1.0.bb} (100%)
diff --git a/meta/recipes-devtools/python/python-git.inc b/meta/recipes-devtools/python/python-git.inc
index 13c097a..ad41561 100644
--- a/meta/recipes-devtools/python/python-git.inc
+++ b/meta/recipes-devtools/python/python-git.inc
@@ -10,8 +10,8 @@ LIC_FILES_CHKSUM = "file://LICENSE;md5=8b8d26c37c1d5a04f9b0186edbebc183"
SRC_URI = "https://files.pythonhosted.org/packages/source/G/GitPython/GitPython-${PV}.tar.gz"
-SRC_URI[md5sum] = "aa0ba9df0abe4c8f35dd7bb9be85d56e"
-SRC_URI[sha256sum] = "d8e7adaacceedd3d043e6cd2544f57dbe00c53fc26374880b7cea67f3188aa68"
+SRC_URI[md5sum] = "29b1fcf504d080dc7a5e630957e829d7"
+SRC_URI[sha256sum] = "3ebda1e6ff1ef68597e41dcd1b99c2a5ae902f4dc2b22ad3533cc89c32b42aad"
UPSTREAM_CHECK_URI = "https://pypi.python.org/pypi/GitPython/"
UPSTREAM_CHECK_REGEX = "/GitPython/(?P<pver>(\d+[\.\-_]*)+)"
diff --git a/meta/recipes-devtools/python/python3-git_2.0.7.bb b/meta/recipes-devtools/python/python3-git_2.1.0.bb
similarity index 100%
rename from meta/recipes-devtools/python/python3-git_2.0.7.bb
rename to meta/recipes-devtools/python/python3-git_2.1.0.bb
--
2.1.4
^ permalink raw reply related
* Re: [PATCH net-next v7 03/10] dpaa_eth: add option to use one buffer pool set
From: David Miller @ 2016-11-14 17:31 UTC (permalink / raw)
To: madalin.bucur
Cc: netdev, linuxppc-dev, linux-kernel, oss, ppc, joe, pebolle,
joakim.tjernlund
In-Reply-To: <AM4PR04MB16040D32960405FD16007950ECBC0@AM4PR04MB1604.eurprd04.prod.outlook.com>
From: Madalin-Cristian Bucur <madalin.bucur@nxp.com>
Date: Mon, 14 Nov 2016 10:25:13 +0000
> I've introduced this Kconfig option as a backwards compatible option, to
> be able to run comparative tests between the independent buffer pool setup
> and the previous common buffer pool setup. There are not so many reasons
> to use the same buffer pool besides "having the old setup", the memory
> saving is marginal, in all other aspects the separate buffer pools setup
> fares better.
>
> I'll remove this patch from the next submission. Should anyone care for
> this I can add an entry to the feature backlog to add runtime support but
> it will be quite low in priority.
If it's a debugging feature then that's certainly how this should be
handled.
^ permalink raw reply
* Re: [PATCH 1/2] iio: bmi160: Support hardware fifo
From: Marcin Niestroj @ 2016-11-14 17:30 UTC (permalink / raw)
To: Jonathan Cameron, Peter Meerwald-Stadler
Cc: Hartmut Knaack, Lars-Peter Clausen, Daniel Baluta, Gregor Boirie,
Sanchayan Maity, Rob Herring, linux-iio
In-Reply-To: <92772d4a-0bfb-26d4-b98a-2f0a36304afe@kernel.org>
On 12.11.2016 16:55, Jonathan Cameron wrote:
> On 09/11/16 17:16, Marcin Niestroj wrote:
>> On 09.11.2016 15:16, Marcin Niestroj wrote:
>>> Hi,
>>> Thanks for review, below are my comments.
>>>
>>> On 03.11.2016 13:09, Peter Meerwald-Stadler wrote:
>>>>
>>>>> This patch was developed primarily based on bmc150_accel hardware fifo
>>>>> implementation.
>>>>
>>>> parts of the patch are cleanup and bugfixing; should be separate?
>>>>
>>>> more comments below
>>>>
>>>>> IRQ handler was added, which for now is responsible only for handling
>>>>> watermark interrupts. The BMI160 chip has two interrupt outputs. By
>>>>> default INT is considered to be connected. If INT2 is used instead, the
>>>>> interrupt-names device-tree property can be used to specify that.
>>>>>
>>>>> Signed-off-by: Marcin Niestroj <m.niestroj@grinn-global.com>
>>
>> <snip>
>>
>>>>> @@ -574,8 +1114,11 @@ int bmi160_core_probe(struct device *dev,
>>>>> struct regmap *regmap,
>>>>>
>>>>> data = iio_priv(indio_dev);
>>>>> dev_set_drvdata(dev, indio_dev);
>>>>> + data->irq = irq;
>>>>> data->regmap = regmap;
>>>>>
>>>>> + mutex_init(&data->mutex);
>>>>> +
>>>>> ret = bmi160_chip_init(data, use_spi);
>>>>> if (ret < 0)
>>>>> return ret;
>>>>> @@ -591,10 +1134,50 @@ int bmi160_core_probe(struct device *dev,
>>>>> struct regmap *regmap,
>>>>> indio_dev->info = &bmi160_info;
>>>>>
>>>>> ret = iio_triggered_buffer_setup(indio_dev, NULL,
>>>>> - bmi160_trigger_handler, NULL);
>>>>> + bmi160_trigger_handler,
>>>>> + &bmi160_buffer_ops);
>>>>> if (ret < 0)
>>>>> goto uninit;
>>>>>
>>>>> + if (data->irq > 0) {
>>>>> + /* Check which interrupt pin is connected to our board */
>>>>> + irq2 = of_irq_get_byname(dev->of_node, "INT2");
>>>>> + if (irq2 == data->irq) {
>>>>> + dev_dbg(dev, "Using interrupt line INT2\n");
>>>>> + data->irq_data = &bmi160_irq2_data;
>>>>> + } else {
>>>>> + dev_dbg(dev, "Using interrupt line INT1\n");
>>>>> + data->irq_data = &bmi160_irq1_data;
>>>>> + }
>>>>> +
>>>>> + ret = devm_request_threaded_irq(dev,
>>>>> + data->irq,
>>>>> + bmi160_irq_handler,
>>>>> + bmi160_irq_thread_handler,
>>>>> + IRQF_ONESHOT,
>>>>> + BMI160_IRQ_NAME,
>>>>> + indio_dev);
>>>>> + if (ret)
>>>>> + return ret;
>>
>> I just noticed, that there should be a "goto buffer_cleanup" instead.
>>
>>>>> +
>>>>> + ret = bmi160_enable_irq(data);
>>>>> + if (ret < 0)
>>>>> + goto buffer_cleanup;
>>>>> +
>>>>> + if (block_supported) {
>>>>> + indio_dev->modes |= INDIO_BUFFER_SOFTWARE;
>>>>> + indio_dev->info = &bmi160_info_fifo;
>>>>> + indio_dev->buffer->attrs = bmi160_fifo_attributes;
>>>>> + data->fifo_buffer = devm_kmalloc(dev,
>>>>> + BMI160_FIFO_LENGTH,
>>>>> + GFP_KERNEL);
>>>>> + if (!data->fifo_buffer) {
>>>>> + ret = -ENOMEM;
>>>>
>>>> need to disable irq on failure?
>>>
>>> Yes, I missed that.
>>
>> I am just wondering now if it is really neccessary. bmi160_enable_irq()
>> is just enabling IRQ output on INT1 or INT2 depending on device-tree.
>> This alone will not trigger interrupts, as all should be masked at this
>> stage.
> You should always unwind everything in error paths as it makes them
> 'obviously' correct rather than subject to subtle bugs.
Ok. And what about issuing a softreset of the device? This should
revert all registers to defaults.
>>
>>>
>>>>
>>>>> + goto buffer_cleanup;
>>>>> + }
>>>>> + }
>>>>> + }
>>>>> +
>>>>> ret = iio_device_register(indio_dev);
>>>>> if (ret < 0)
>>>>> goto buffer_cleanup;
>>>>> diff --git a/drivers/iio/imu/bmi160/bmi160_i2c.c
>>>>> b/drivers/iio/imu/bmi160/bmi160_i2c.c
>>>>> index 07a179d..aa63f89 100644
>>>>> --- a/drivers/iio/imu/bmi160/bmi160_i2c.c
>>>>> +++ b/drivers/iio/imu/bmi160/bmi160_i2c.c
>>>>> @@ -23,6 +23,10 @@ static int bmi160_i2c_probe(struct i2c_client
>>>>> *client,
>>>>> {
>>>>> struct regmap *regmap;
>>>>> const char *name = NULL;
>>>>> + bool block_supported =
>>>>> + i2c_check_functionality(client->adapter, I2C_FUNC_I2C) ||
>>>>> + i2c_check_functionality(client->adapter,
>>>>> + I2C_FUNC_SMBUS_READ_I2C_BLOCK);
>>>>>
>>>>> regmap = devm_regmap_init_i2c(client, &bmi160_regmap_config);
>>>>> if (IS_ERR(regmap)) {
>>>>> @@ -34,7 +38,8 @@ static int bmi160_i2c_probe(struct i2c_client *client,
>>>>> if (id)
>>>>> name = id->name;
>>>>>
>>>>> - return bmi160_core_probe(&client->dev, regmap, name, false);
>>>>> + return bmi160_core_probe(&client->dev, regmap, name, client->irq,
>>>>> + false, block_supported);
>>>>> }
>>>>>
>>>>> static int bmi160_i2c_remove(struct i2c_client *client)
>>>>> diff --git a/drivers/iio/imu/bmi160/bmi160_spi.c
>>>>> b/drivers/iio/imu/bmi160/bmi160_spi.c
>>>>> index 1ec8b12..9b57fbe 100644
>>>>> --- a/drivers/iio/imu/bmi160/bmi160_spi.c
>>>>> +++ b/drivers/iio/imu/bmi160/bmi160_spi.c
>>>>> @@ -25,7 +25,8 @@ static int bmi160_spi_probe(struct spi_device *spi)
>>>>> (int)PTR_ERR(regmap));
>>>>> return PTR_ERR(regmap);
>>>>> }
>>>>> - return bmi160_core_probe(&spi->dev, regmap, id->name, true);
>>>>> + return bmi160_core_probe(&spi->dev, regmap, id->name, spi->irq,
>>>>> + true, true);
>>>>> }
>>>>>
>>>>> static int bmi160_spi_remove(struct spi_device *spi)
>>>>>
>>>>
>>>
>>
>
--
Marcin Niestroj
^ permalink raw reply
* Re: [WireGuard] [PATCH v3] ip6_output: ensure flow saddr actually belongs to device
From: Hannes Frederic Sowa @ 2016-11-14 17:33 UTC (permalink / raw)
To: David Ahern, Jason A. Donenfeld, Netdev, WireGuard mailing list,
LKML, YOSHIFUJI Hideaki
In-Reply-To: <c75290bd-7ea2-0bf8-7ac0-fc5a3c81e312@cumulusnetworks.com>
On 14.11.2016 18:17, David Ahern wrote:
> On 11/14/16 10:04 AM, Hannes Frederic Sowa wrote:
>> On 14.11.2016 17:55, David Ahern wrote:
>>> On 11/14/16 9:44 AM, Hannes Frederic Sowa wrote:
>>>> On Mon, Nov 14, 2016, at 00:28, Jason A. Donenfeld wrote:
>>>>> This puts the IPv6 routing functions in parity with the IPv4 routing
>>>>> functions. Namely, we now check in v6 that if a flowi6 requests an
>>>>> saddr, the returned dst actually corresponds to a net device that has
>>>>> that saddr. This mirrors the v4 logic with __ip_dev_find in
>>>>> __ip_route_output_key_hash. In the event that the returned dst is not
>>>>> for a dst with a dev that has the saddr, we return -EINVAL, just like
>>>>> v4; this makes it easy to use the same error handlers for both cases.
>>>>>
>>>>> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
>>>>> Cc: David Ahern <dsa@cumulusnetworks.com>
>>>>> ---
>>>>> Changes from v2:
>>>>> It turns out ipv6_chk_addr already has the device enumeration
>>>>> logic that we need by simply passing NULL.
>>>>>
>>>>> net/ipv6/ip6_output.c | 4 ++++
>>>>> 1 file changed, 4 insertions(+)
>>>>>
>>>>> diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
>>>>> index 6001e78..b3b5cb6 100644
>>>>> --- a/net/ipv6/ip6_output.c
>>>>> +++ b/net/ipv6/ip6_output.c
>>>>> @@ -926,6 +926,10 @@ static int ip6_dst_lookup_tail(struct net *net,
>>>>> const struct sock *sk,
>>>>> int err;
>>>>> int flags = 0;
>>>>>
>>>>> + if (!ipv6_addr_any(&fl6->saddr) &&
>>>>> + !ipv6_chk_addr(net, &fl6->saddr, NULL, 1))
>>>>> + return -EINVAL;
>>>>
>>>> Hmm, this check is too permissive, no?
>>>>
>>>> E.g. what happens if you move a link local address from one interface to
>>>> another? In this case this code would still allow the saddr to be used.
>>>
>>> This check -- like the ipv4 variant -- only verifies the saddr is locally assigned. If the address moves interfaces it should be fine.
>>
>> But in this case we should actually bail out, no?
>>
>> Let's say, user assumes we are on ifindex eth0 with LL address from
>> eth0. Suddenly the LL address from eth0 is moved to eth1, we can't
>> accept this source address anymore and need to return -EINVAL, too.
>
> so you mean if rt6_need_strict(&fl6->saddr) then the dev needs to be considered.
Exactly, like we do in the user space facing APIs.
>>>> I just also quickly read up on the history (sorry was travelling last
>>>> week) and wonder if you ever saw a user space facing bug or if this is
>>>> basically some difference you saw while writing out of tree code?
>>>
>>> I checked the userspace API this morning. bind and cmsg for example check that the address is valid with calls to ipv6_chk_addr.
>>
>> Hmm, so it fixes no real bug.
>>
>> Because of translations of flowi6_oif we actually can't do a correct
>> check of source address for cases like the one I outlined above? Hmm,
>> maybe we should simply depend on user space checks.
>
> I believe Jason's case is forwarding path and the ipv6_stub->ipv6_dst_lookup API.
It is not a kernel API, because we don't support something like that for
external kernel modules. We basically exported ipv6_dst_lookup to allow
some IPv4 code to do ipv6 stunts when the IPv6 module is loaded. ;)
Bye,
Hannes
^ permalink raw reply
* [Buildroot] [PATCH] config: bump U-Boot to 2016.11-rc3 in synopsys defconfigs
From: Fabio Estevam @ 2016-11-14 17:30 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1479138470-47444-1-git-send-email-vzakhar@synopsys.com>
On Mon, Nov 14, 2016 at 1:47 PM, Vlad Zakharov
<Vladislav.Zakharov@synopsys.com> wrote:
> With this commit we upgrade U-Boot version to 2016.11-rc3
> in "snps_axs101_defconfig" and "snps_axs103_defconfig".
>
> Important fixes: new version fixes U-Boot build for arc700.
> Since gcc-6.x "-marc700" option is no longer supported,
> "-mcpu=arc700" should be used instead.
>
> We haven't sent it before as we were waiting for U-Boot
> 2016.11 release. But as it unfortunately hasn't come up yet we
> bump U-Boot version to the latest release candidate.
> We are going to upgrade it to 2016.11 as soon as the release
> comes.
U-Boot 2016.11 is released now and I sent Buildroot patches bumping to
this version.
^ permalink raw reply
* Re: [PATCH net-next v5] cadence: Add LSO support.
From: David Miller @ 2016-11-14 17:30 UTC (permalink / raw)
To: rafalo; +Cc: nicolas.ferre, netdev, linux-kernel
In-Reply-To: <BN3PR07MB2516C30913D2FB8D4788071AC9BC0@BN3PR07MB2516.namprd07.prod.outlook.com>
From: Rafal Ozieblo <rafalo@cadence.com>
Date: Mon, 14 Nov 2016 09:32:34 +0000
>> 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.
I do not doubt that it is a hardware restriction.
But I am saying that you cannot enable this feature under Linux if
this is how it operates on your hardware.
^ permalink raw reply
* Re: Long delays creating a netns after deleting one (possibly RCU related)
From: Hannes Frederic Sowa @ 2016-11-14 17:29 UTC (permalink / raw)
To: Cong Wang, Paul E. McKenney
Cc: Rolf Neugebauer, LKML, Linux Kernel Network Developers,
Justin Cormack, Ian Campbell
In-Reply-To: <CAM_iQpUDnPfVayQv7Q+ZtC_2_ZbX9MRX=514gFpF3E6XY+GtSA@mail.gmail.com>
Hi Cong,
On Sat, Nov 12, 2016, at 01:55, Cong Wang wrote:
> On Fri, Nov 11, 2016 at 4:23 PM, Paul E. McKenney
> <paulmck@linux.vnet.ibm.com> wrote:
> >
> > Ah! This net_mutex is different than RTNL. Should synchronize_net() be
> > modified to check for net_mutex being held in addition to the current
> > checks for RTNL being held?
> >
>
> Good point!
>
> Like commit be3fc413da9eb17cce0991f214ab0, checking
> for net_mutex for this case seems to be an optimization, I assume
> synchronize_rcu_expedited() and synchronize_rcu() have the same
> behavior...
>
> diff --git a/net/core/dev.c b/net/core/dev.c
> index eaad4c2..3415b6b 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -7762,7 +7762,7 @@ EXPORT_SYMBOL(free_netdev);
> void synchronize_net(void)
> {
> might_sleep();
> - if (rtnl_is_locked())
> + if (rtnl_is_locked() || lockdep_is_held(&net_mutex))
> synchronize_rcu_expedited();
I don't think we should depend on lockdep for this check but rather use
mutex_is_locked here (I think it would fail to build like this without
CONFIG_LOCKDEP).
Bye,
Hannes
^ permalink raw reply
* Re: [RFC PATCH v3 06/20] x86: Add support to enable SME during early boot processing
From: Borislav Petkov @ 2016-11-14 17:29 UTC (permalink / raw)
To: Tom Lendacky
Cc: linux-arch, linux-efi, kvm, linux-doc, x86, linux-kernel,
kasan-dev, linux-mm, iommu, Rik van Riel,
Radim Krčmář, Arnd Bergmann, Jonathan Corbet,
Matt Fleming, Joerg Roedel, Konrad Rzeszutek Wilk, Paolo Bonzini,
Larry Woodman, Ingo Molnar, Andy Lutomirski, H. Peter Anvin,
Andrey Ryabinin, Alexander Potapenko, Thomas Gleixner,
Dmitry Vyukov
In-Reply-To: <20161110003543.3280.99623.stgit@tlendack-t1.amdoffice.net>
On Wed, Nov 09, 2016 at 06:35:43PM -0600, Tom Lendacky wrote:
> This patch adds support to the early boot code to use Secure Memory
> Encryption (SME). Support is added to update the early pagetables with
> the memory encryption mask and to encrypt the kernel in place.
>
> The routines to set the encryption mask and perform the encryption are
> stub routines for now with full function to be added in a later patch.
>
> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
> ---
> arch/x86/kernel/Makefile | 2 ++
> arch/x86/kernel/head_64.S | 35 ++++++++++++++++++++++++++++++++++-
> arch/x86/kernel/mem_encrypt_init.c | 29 +++++++++++++++++++++++++++++
> 3 files changed, 65 insertions(+), 1 deletion(-)
> create mode 100644 arch/x86/kernel/mem_encrypt_init.c
>
> diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
> index 45257cf..27e22f4 100644
> --- a/arch/x86/kernel/Makefile
> +++ b/arch/x86/kernel/Makefile
> @@ -141,4 +141,6 @@ ifeq ($(CONFIG_X86_64),y)
>
> obj-$(CONFIG_PCI_MMCONFIG) += mmconf-fam10h_64.o
> obj-y += vsmp_64.o
> +
> + obj-y += mem_encrypt_init.o
> endif
> diff --git a/arch/x86/kernel/head_64.S b/arch/x86/kernel/head_64.S
> index c98a559..9a28aad 100644
> --- a/arch/x86/kernel/head_64.S
> +++ b/arch/x86/kernel/head_64.S
> @@ -95,6 +95,17 @@ startup_64:
> jnz bad_address
>
> /*
> + * Enable Secure Memory Encryption (if available). Save the mask
> + * in %r12 for later use and add the memory encryption mask to %rbp
> + * to include it in the page table fixups.
> + */
> + push %rsi
> + call sme_enable
> + pop %rsi
Why %rsi?
sme_enable() is void so no args in registers and returns in %rax.
/me is confused.
> + movq %rax, %r12
> + addq %r12, %rbp
> +
> + /*
> * Fixup the physical addresses in the page table
> */
> addq %rbp, early_level4_pgt + (L4_START_KERNEL*8)(%rip)
> @@ -117,6 +128,7 @@ startup_64:
> shrq $PGDIR_SHIFT, %rax
>
> leaq (4096 + _KERNPG_TABLE)(%rbx), %rdx
> + addq %r12, %rdx
> movq %rdx, 0(%rbx,%rax,8)
> movq %rdx, 8(%rbx,%rax,8)
>
> @@ -133,6 +145,7 @@ startup_64:
> movq %rdi, %rax
> shrq $PMD_SHIFT, %rdi
> addq $(__PAGE_KERNEL_LARGE_EXEC & ~_PAGE_GLOBAL), %rax
> + addq %r12, %rax
> leaq (_end - 1)(%rip), %rcx
> shrq $PMD_SHIFT, %rcx
> subq %rdi, %rcx
> @@ -163,9 +176,21 @@ startup_64:
> cmp %r8, %rdi
> jne 1b
>
> - /* Fixup phys_base */
> + /*
> + * Fixup phys_base, remove the memory encryption mask from %rbp
> + * to obtain the true physical address.
> + */
> + subq %r12, %rbp
> addq %rbp, phys_base(%rip)
>
> + /*
> + * The page tables have been updated with the memory encryption mask,
> + * so encrypt the kernel if memory encryption is active
> + */
> + push %rsi
> + call sme_encrypt_kernel
> + pop %rsi
Ditto.
> +
> movq $(early_level4_pgt - __START_KERNEL_map), %rax
> jmp 1f
> ENTRY(secondary_startup_64)
> @@ -186,9 +211,17 @@ ENTRY(secondary_startup_64)
> /* Sanitize CPU configuration */
> call verify_cpu
>
> + push %rsi
> + call sme_get_me_mask
> + pop %rsi
Ditto.
> + movq %rax, %r12
> +
> movq $(init_level4_pgt - __START_KERNEL_map), %rax
> 1:
>
> + /* Add the memory encryption mask to RAX */
I think that should say something like:
/*
* Add the memory encryption mask to init_level4_pgt's physical address
*/
or so...
> + addq %r12, %rax
> +
> /* Enable PAE mode and PGE */
> movl $(X86_CR4_PAE | X86_CR4_PGE), %ecx
> movq %rcx, %cr4
> diff --git a/arch/x86/kernel/mem_encrypt_init.c b/arch/x86/kernel/mem_encrypt_init.c
> new file mode 100644
> index 0000000..388d6fb
> --- /dev/null
> +++ b/arch/x86/kernel/mem_encrypt_init.c
So nothing in the commit message explains why we need a separate
mem_encrypt_init.c file when we already have arch/x86/mm/mem_encrypt.c
for all memory encryption code...
> @@ -0,0 +1,29 @@
> +/*
> + * AMD Memory Encryption Support
> + *
> + * Copyright (C) 2016 Advanced Micro Devices, Inc.
> + *
> + * Author: Tom Lendacky <thomas.lendacky@amd.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include <linux/linkage.h>
> +#include <linux/init.h>
> +#include <linux/mem_encrypt.h>
> +
> +void __init sme_encrypt_kernel(void)
> +{
> +}
> +
> +unsigned long __init sme_get_me_mask(void)
> +{
> + return sme_me_mask;
> +}
> +
> +unsigned long __init sme_enable(void)
> +{
> + return sme_me_mask;
> +}
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
^ permalink raw reply
* Re: [RFC PATCH v3 06/20] x86: Add support to enable SME during early boot processing
From: Borislav Petkov @ 2016-11-14 17:29 UTC (permalink / raw)
To: Tom Lendacky
Cc: linux-efi-u79uwXL29TY76Z2rM5mHXA, kvm-u79uwXL29TY76Z2rM5mHXA,
Radim Krčmář, Matt Fleming,
x86-DgEjT+Ai2ygdnm+yROfE0A, linux-mm-Bw31MaZKKs3YtjvyW6yDsg,
Alexander Potapenko, H. Peter Anvin, Larry Woodman,
linux-arch-u79uwXL29TY76Z2rM5mHXA, Jonathan Corbet,
linux-doc-u79uwXL29TY76Z2rM5mHXA,
kasan-dev-/JYPxA39Uh5TLH3MbocFFw, Ingo Molnar, Andrey Ryabinin,
Rik van Riel, Arnd Bergmann, Andy Lutomirski, Thomas Gleixner,
Dmitry Vyukov, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA, Paolo Bonzini
In-Reply-To: <20161110003543.3280.99623.stgit-qCXWGYdRb2BnqfbPTmsdiZQ+2ll4COg0XqFh9Ls21Oc@public.gmane.org>
On Wed, Nov 09, 2016 at 06:35:43PM -0600, Tom Lendacky wrote:
> This patch adds support to the early boot code to use Secure Memory
> Encryption (SME). Support is added to update the early pagetables with
> the memory encryption mask and to encrypt the kernel in place.
>
> The routines to set the encryption mask and perform the encryption are
> stub routines for now with full function to be added in a later patch.
>
> Signed-off-by: Tom Lendacky <thomas.lendacky-5C7GfCeVMHo@public.gmane.org>
> ---
> arch/x86/kernel/Makefile | 2 ++
> arch/x86/kernel/head_64.S | 35 ++++++++++++++++++++++++++++++++++-
> arch/x86/kernel/mem_encrypt_init.c | 29 +++++++++++++++++++++++++++++
> 3 files changed, 65 insertions(+), 1 deletion(-)
> create mode 100644 arch/x86/kernel/mem_encrypt_init.c
>
> diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
> index 45257cf..27e22f4 100644
> --- a/arch/x86/kernel/Makefile
> +++ b/arch/x86/kernel/Makefile
> @@ -141,4 +141,6 @@ ifeq ($(CONFIG_X86_64),y)
>
> obj-$(CONFIG_PCI_MMCONFIG) += mmconf-fam10h_64.o
> obj-y += vsmp_64.o
> +
> + obj-y += mem_encrypt_init.o
> endif
> diff --git a/arch/x86/kernel/head_64.S b/arch/x86/kernel/head_64.S
> index c98a559..9a28aad 100644
> --- a/arch/x86/kernel/head_64.S
> +++ b/arch/x86/kernel/head_64.S
> @@ -95,6 +95,17 @@ startup_64:
> jnz bad_address
>
> /*
> + * Enable Secure Memory Encryption (if available). Save the mask
> + * in %r12 for later use and add the memory encryption mask to %rbp
> + * to include it in the page table fixups.
> + */
> + push %rsi
> + call sme_enable
> + pop %rsi
Why %rsi?
sme_enable() is void so no args in registers and returns in %rax.
/me is confused.
> + movq %rax, %r12
> + addq %r12, %rbp
> +
> + /*
> * Fixup the physical addresses in the page table
> */
> addq %rbp, early_level4_pgt + (L4_START_KERNEL*8)(%rip)
> @@ -117,6 +128,7 @@ startup_64:
> shrq $PGDIR_SHIFT, %rax
>
> leaq (4096 + _KERNPG_TABLE)(%rbx), %rdx
> + addq %r12, %rdx
> movq %rdx, 0(%rbx,%rax,8)
> movq %rdx, 8(%rbx,%rax,8)
>
> @@ -133,6 +145,7 @@ startup_64:
> movq %rdi, %rax
> shrq $PMD_SHIFT, %rdi
> addq $(__PAGE_KERNEL_LARGE_EXEC & ~_PAGE_GLOBAL), %rax
> + addq %r12, %rax
> leaq (_end - 1)(%rip), %rcx
> shrq $PMD_SHIFT, %rcx
> subq %rdi, %rcx
> @@ -163,9 +176,21 @@ startup_64:
> cmp %r8, %rdi
> jne 1b
>
> - /* Fixup phys_base */
> + /*
> + * Fixup phys_base, remove the memory encryption mask from %rbp
> + * to obtain the true physical address.
> + */
> + subq %r12, %rbp
> addq %rbp, phys_base(%rip)
>
> + /*
> + * The page tables have been updated with the memory encryption mask,
> + * so encrypt the kernel if memory encryption is active
> + */
> + push %rsi
> + call sme_encrypt_kernel
> + pop %rsi
Ditto.
> +
> movq $(early_level4_pgt - __START_KERNEL_map), %rax
> jmp 1f
> ENTRY(secondary_startup_64)
> @@ -186,9 +211,17 @@ ENTRY(secondary_startup_64)
> /* Sanitize CPU configuration */
> call verify_cpu
>
> + push %rsi
> + call sme_get_me_mask
> + pop %rsi
Ditto.
> + movq %rax, %r12
> +
> movq $(init_level4_pgt - __START_KERNEL_map), %rax
> 1:
>
> + /* Add the memory encryption mask to RAX */
I think that should say something like:
/*
* Add the memory encryption mask to init_level4_pgt's physical address
*/
or so...
> + addq %r12, %rax
> +
> /* Enable PAE mode and PGE */
> movl $(X86_CR4_PAE | X86_CR4_PGE), %ecx
> movq %rcx, %cr4
> diff --git a/arch/x86/kernel/mem_encrypt_init.c b/arch/x86/kernel/mem_encrypt_init.c
> new file mode 100644
> index 0000000..388d6fb
> --- /dev/null
> +++ b/arch/x86/kernel/mem_encrypt_init.c
So nothing in the commit message explains why we need a separate
mem_encrypt_init.c file when we already have arch/x86/mm/mem_encrypt.c
for all memory encryption code...
> @@ -0,0 +1,29 @@
> +/*
> + * AMD Memory Encryption Support
> + *
> + * Copyright (C) 2016 Advanced Micro Devices, Inc.
> + *
> + * Author: Tom Lendacky <thomas.lendacky-5C7GfCeVMHo@public.gmane.org>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include <linux/linkage.h>
> +#include <linux/init.h>
> +#include <linux/mem_encrypt.h>
> +
> +void __init sme_encrypt_kernel(void)
> +{
> +}
> +
> +unsigned long __init sme_get_me_mask(void)
> +{
> + return sme_me_mask;
> +}
> +
> +unsigned long __init sme_enable(void)
> +{
> + return sme_me_mask;
> +}
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
^ permalink raw reply
* Re: [PATCH v2 0/2] bnx2: Wait for in-flight DMA to complete at probe stage
From: David Miller @ 2016-11-14 17:28 UTC (permalink / raw)
To: pmenzel
Cc: bhe, netdev, michael.chan, linux-kernel, Dept-GELinuxNICDev,
rasesh.mody, harish.patil, frank, jsr, jroedel, dyoung
In-Reply-To: <8010f40d-e7ca-8fd1-7317-f576289c112f@molgen.mpg.de>
From: Paul Menzel <pmenzel@molgen.mpg.de>
Date: Mon, 14 Nov 2016 09:25:47 +0100
> Dear Baoquan,
>
> On 11/13/16 06:01, Baoquan He wrote:
>> This is v2 post.
>>
>> In commit 3e1be7a ("bnx2: Reset device during driver initialization"),
>> firmware requesting code was moved from open stage to probe stage.
>> The reason is in kdump kernel hardware iommu need device be reset in
>> driver probe stage, otherwise those in-flight DMA from 1st kernel
>> will continue going and look up into the newly created io-page tables.
>> However bnx2 chip resetting involves firmware requesting issue, that
>> need be done in open stage.
>>
>> Michale Chan suggested we can just wait for the old in-flight DMA to
>> complete at probe stage, then though without device resetting, we
>> don't need to worry the old in-flight DMA could continue looking up
>> the newly created io-page tables.
>>
>> v1->v2:
>> Michael suggested to wait for the in-flight DMA to complete at probe
>> stage. So give up the old method of trying to reset chip at probe
>> stage, take the new way accordingly.
>
> thank you for posting the updated series. Could you please resend a v3
> with stable@vger.kernel.org added [1]?
This is not the proper procedure for networking patches.
^ permalink raw reply
* [PATCH 2/2] block: add support for async simple direct-io for bdevs
From: Jens Axboe @ 2016-11-14 17:28 UTC (permalink / raw)
To: axboe, linux-block; +Cc: hch, Jens Axboe
In-Reply-To: <1479144519-15738-1-git-send-email-axboe@fb.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
---
fs/block_dev.c | 76 ++++++++++++++++++++++++++++++++++++++++++++++++++--------
1 file changed, 66 insertions(+), 10 deletions(-)
diff --git a/fs/block_dev.c b/fs/block_dev.c
index 2010997fd326..62ca4ce21222 100644
--- a/fs/block_dev.c
+++ b/fs/block_dev.c
@@ -176,9 +176,68 @@ static struct inode *bdev_file_inode(struct file *file)
return file->f_mapping->host;
}
+static void blkdev_bio_end_io_async(struct bio *bio)
+{
+ struct kiocb *iocb = bio->bi_private;
+
+ iocb->ki_complete(iocb, bio->bi_error, 0);
+
+ if (bio_op(bio) == REQ_OP_READ)
+ bio_check_pages_dirty(bio);
+ else
+ bio_put(bio);
+}
+
+static ssize_t
+__blkdev_direct_IO_async(struct kiocb *iocb, struct iov_iter *iter,
+ int nr_pages)
+{
+ struct file *file = iocb->ki_filp;
+ struct block_device *bdev = I_BDEV(bdev_file_inode(file));
+ unsigned blkbits = blksize_bits(bdev_logical_block_size(bdev));
+ loff_t pos = iocb->ki_pos;
+ struct bio *bio;
+ ssize_t ret;
+
+ if ((pos | iov_iter_alignment(iter)) & ((1 << blkbits) - 1))
+ return -EINVAL;
+
+ bio = bio_alloc(GFP_KERNEL, nr_pages);
+ if (!bio)
+ return -ENOMEM;
+
+ bio->bi_bdev = bdev;
+ bio->bi_iter.bi_sector = pos >> blkbits;
+ bio->bi_private = iocb;
+ bio->bi_end_io = blkdev_bio_end_io_async;
+
+ ret = bio_iov_iter_get_pages(bio, iter);
+ if (unlikely(ret))
+ return ret;
+
+ /*
+ * Overload bio size in error. If it gets set, we lose the
+ * size, but we don't need the size for that case. IO is limited
+ * to BIO_MAX_PAGES, so we can't overflow.
+ */
+ ret = bio->bi_error = bio->bi_iter.bi_size;
+
+ if (iov_iter_rw(iter) == READ) {
+ bio_set_op_attrs(bio, REQ_OP_READ, 0);
+ bio_set_pages_dirty(bio);
+ } else {
+ bio_set_op_attrs(bio, REQ_OP_WRITE, REQ_SYNC | REQ_IDLE);
+ task_io_account_write(ret);
+ }
+
+ submit_bio(bio);
+ iocb->ki_pos += ret;
+ return -EIOCBQUEUED;
+}
+
#define DIO_INLINE_BIO_VECS 4
-static void blkdev_bio_end_io_simple(struct bio *bio)
+static void blkdev_bio_end_io_sync(struct bio *bio)
{
struct task_struct *waiter = bio->bi_private;
@@ -187,8 +246,7 @@ static void blkdev_bio_end_io_simple(struct bio *bio)
}
static ssize_t
-__blkdev_direct_IO_simple(struct kiocb *iocb, struct iov_iter *iter,
- int nr_pages)
+__blkdev_direct_IO_sync(struct kiocb *iocb, struct iov_iter *iter, int nr_pages)
{
struct file *file = iocb->ki_filp;
struct block_device *bdev = I_BDEV(bdev_file_inode(file));
@@ -218,7 +276,7 @@ __blkdev_direct_IO_simple(struct kiocb *iocb, struct iov_iter *iter,
bio.bi_bdev = bdev;
bio.bi_iter.bi_sector = pos >> blkbits;
bio.bi_private = current;
- bio.bi_end_io = blkdev_bio_end_io_simple;
+ bio.bi_end_io = blkdev_bio_end_io_sync;
ret = bio_iov_iter_get_pages(&bio, iter);
if (unlikely(ret))
@@ -263,18 +321,16 @@ __blkdev_direct_IO_simple(struct kiocb *iocb, struct iov_iter *iter,
static ssize_t
blkdev_direct_IO(struct kiocb *iocb, struct iov_iter *iter)
{
- struct file *file = iocb->ki_filp;
- struct inode *inode = bdev_file_inode(file);
int nr_pages;
nr_pages = iov_iter_npages(iter, BIO_MAX_PAGES);
if (!nr_pages)
return 0;
+
if (is_sync_kiocb(iocb))
- return __blkdev_direct_IO_simple(iocb, iter, nr_pages);
- return __blockdev_direct_IO(iocb, inode, I_BDEV(inode), iter,
- blkdev_get_block, NULL, NULL,
- DIO_SKIP_DIO_COUNT);
+ return __blkdev_direct_IO_sync(iocb, iter, nr_pages);
+
+ return __blkdev_direct_IO_async(iocb, iter, nr_pages);
}
int __sync_blockdev(struct block_device *bdev, int wait)
--
2.7.4
^ 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.