Re: [PATCH V7 3/3] dma: add Qualcomm Technologies HIDMA channel driver
On Wed, Dec 02, 2015 at 02:04:05PM -0500, Sinan Kaya wrote: > >> > You are missing the point. Channel can be paused, yes but the descriptor > >> > is in queue and is not paused. The descriptor running is paused, yes. > >> > There is subtle difference between these > > I'll follow your recommendation. PAUSE for the currently active > > descriptor and DMA_IN_PROGRESS for the rest. > > > > I'm now confused. > > I looked at several DMA driver implementations. > > 1. They call dma_cookie_status function to see if the job is done. > 2. If done, they return right ahead. > 3. Otherwise, dma_cookie_status returns DMA_IN_PROGRESS. > 4. Next the code checks if the channel is paused and return value is > DMA_IN_PROGRESS. The code changes return code to DMA_PAUSED. > > Whereas, I was returning paused first before even checking if the > descriptor is done. Are you OK with the sequence 1..4 above? Yes am okay with this with slight change in 4. You should set to PAUSED only for current descriptor and not for the ones in queue -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V7 2/3] dma: add Qualcomm Technologies HIDMA management driver
On Tue, Dec 01, 2015 at 11:57:34PM -0500, Sinan Kaya wrote:
> On 11/30/2015 10:17 PM, Vinod Koul wrote:
> > On Mon, Nov 30, 2015 at 09:42:01AM -0500, Sinan Kaya wrote:
> >
> +static int hidma_mgmt_probe(struct platform_device *pdev)
> +{
> +struct hidma_mgmt_dev *mgmtdev;
> +struct resource *res;
> +void __iomem *virtaddr;
> +int irq;
> +int rc;
> +u32 val;
> +
> +pm_runtime_set_autosuspend_delay(>dev,
> AUTOSUSPEND_TIMEOUT);
> +pm_runtime_use_autosuspend(>dev);
> +pm_runtime_set_active(>dev);
> +pm_runtime_enable(>dev);
> >>>
> >>> at this time pm core will treat device as fully enabled and pm methods can
> >>> be invoked, but you are not ready yet right. Typically these are done at
> >>> the
> >>> end of the probe unless you have a reason...
> >>
> >> I need it here because the clocks are declared as ACPI power resources.
> >> The kernel is turning off all power resources during initialization. In
> >> order for this code to touch the hardware, I need to call enable so that
> >> clocks are enabled once again.
> >
> > The question is are you ready in your driver routines to be invoked by pm
> > core?
> >
>
> I don't have any support for suspend and resume PM APIs. The only PM
> interface I support is PM runtime. PM can turn on/off the clocks based
> on the reference counts it maintains after get/set APIs. Since PM is
> turning off the clocks during power up before my driver load, I do need
> to grab this lock to re-enable it during HW initialization. Then, let PM
> turn off the clocks again after the AUTOSUSPEND_TIMEOUT when I'm done.
>
> Is there any other interaction with the PM that I'm not aware of?
No this is fine. The the runtime_resume will be onvoked and it will request
resources are those set before you enable the device?
--
~Vinod
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH net-next 1/2] net: hns: enet specisies a reference to dsaf
enet is associating with dasf. before this patch, the association is
the same strings between ae-name and dsa-name. in a general way, enet
specifies a reference to dsaf should be a good idea. so this patch
deletes the ae-name in enet, and adds parsing the ae-handle
from DT to set the associating with dsaf.
Signed-off-by: yankejian
---
drivers/net/ethernet/hisilicon/hns/hnae.c | 17 +++--
drivers/net/ethernet/hisilicon/hns/hnae.h | 7 +--
drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c | 4
drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c | 10 +-
drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.h | 1 +
drivers/net/ethernet/hisilicon/hns/hns_enet.c | 13 +
drivers/net/ethernet/hisilicon/hns/hns_enet.h | 2 +-
7 files changed, 28 insertions(+), 26 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns/hnae.c
b/drivers/net/ethernet/hisilicon/hns/hnae.c
index b364529..3bfe36f 100644
--- a/drivers/net/ethernet/hisilicon/hns/hnae.c
+++ b/drivers/net/ethernet/hisilicon/hns/hnae.c
@@ -95,21 +95,17 @@ static struct hnae_buf_ops hnae_bops = {
static int __ae_match(struct device *dev, const void *data)
{
struct hnae_ae_dev *hdev = cls_to_ae_dev(dev);
- const char *ae_id = data;
- if (!strncmp(ae_id, hdev->name, AE_NAME_SIZE))
- return 1;
-
- return 0;
+ return hdev->dev->of_node == data;
}
-static struct hnae_ae_dev *find_ae(const char *ae_id)
+static struct hnae_ae_dev *find_ae(const struct device_node *ae_node)
{
struct device *dev;
- WARN_ON(!ae_id);
+ WARN_ON(!ae_node);
- dev = class_find_device(hnae_class, NULL, ae_id, __ae_match);
+ dev = class_find_device(hnae_class, NULL, ae_node, __ae_match);
return dev ? cls_to_ae_dev(dev) : NULL;
}
@@ -316,7 +312,8 @@ EXPORT_SYMBOL(hnae_reinit_handle);
* return handle ptr or ERR_PTR
*/
struct hnae_handle *hnae_get_handle(struct device *owner_dev,
- const char *ae_id, u32 port_id,
+ const struct device_node *ae_node,
+ u32 port_id,
struct hnae_buf_ops *bops)
{
struct hnae_ae_dev *dev;
@@ -324,7 +321,7 @@ struct hnae_handle *hnae_get_handle(struct device
*owner_dev,
int i, j;
int ret;
- dev = find_ae(ae_id);
+ dev = find_ae(ae_node);
if (!dev)
return ERR_PTR(-ENODEV);
diff --git a/drivers/net/ethernet/hisilicon/hns/hnae.h
b/drivers/net/ethernet/hisilicon/hns/hnae.h
index d1f3316..0012664 100644
--- a/drivers/net/ethernet/hisilicon/hns/hnae.h
+++ b/drivers/net/ethernet/hisilicon/hns/hnae.h
@@ -523,8 +523,11 @@ struct hnae_handle {
#define ring_to_dev(ring) ((ring)->q->dev->dev)
-struct hnae_handle *hnae_get_handle(struct device *owner_dev, const char
*ae_id,
- u32 port_id, struct hnae_buf_ops *bops);
+struct hnae_handle *hnae_get_handle(struct device *owner_dev,
+ const struct device_node *ae_node,
+ u32 port_id,
+ struct hnae_buf_ops *bops);
+
void hnae_put_handle(struct hnae_handle *handle);
int hnae_ae_register(struct hnae_ae_dev *dev, struct module *owner);
void hnae_ae_unregister(struct hnae_ae_dev *dev);
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c
b/drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c
index 77c6edb..ed9a72c 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c
@@ -848,6 +848,7 @@ static struct hnae_ae_ops hns_dsaf_ops = {
int hns_dsaf_ae_init(struct dsaf_device *dsaf_dev)
{
struct hnae_ae_dev *ae_dev = _dev->ae_dev;
+ static atomic_t id = ATOMIC_INIT(-1);
switch (dsaf_dev->dsaf_ver) {
case AE_VERSION_1:
@@ -859,6 +860,9 @@ int hns_dsaf_ae_init(struct dsaf_device *dsaf_dev)
default:
break;
}
+
+ snprintf(ae_dev->name, AE_NAME_SIZE, "%s%d", DSAF_DEVICE_NAME,
+(int)atomic_inc_return());
ae_dev->ops = _dsaf_ops;
ae_dev->dev = dsaf_dev->dev;
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c
b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c
index 636b205..f3de749 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c
@@ -35,7 +35,7 @@ int hns_dsaf_get_cfg(struct dsaf_device *dsaf_dev)
int ret, i;
u32 desc_num;
u32 buf_size;
- const char *name, *mode_str;
+ const char *mode_str;
struct device_node *np = dsaf_dev->dev->of_node;
if (of_device_is_compatible(np, "hisilicon,hns-dsaf-v1"))
@@ -43,14 +43,6 @@ int hns_dsaf_get_cfg(struct dsaf_device *dsaf_dev)
else
dsaf_dev->dsaf_ver =
[PATCH RESEND net-next 3/3] arm64: hip05-d02: Document devicetree bindings for Hisilicon D02 Board
This patch adds documentation for the devicetree bindings used by the
DT files of Hisilicon Hip05-D02 development board.
Signed-off-by: yankejian
---
.../devicetree/bindings/arm/hisilicon/hisilicon.txt | 16
1 file changed, 16 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt
b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt
index 6ac7c00..5318d78 100644
--- a/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt
+++ b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt
@@ -187,6 +187,22 @@ Example:
reg = <0xb000 0x1>;
};
+Hisilicon HiP05 PERISUB system controller
+
+Required properties:
+- compatible : "hisilicon,peri-c-subctrl", "syscon";
+- reg : Register address and size
+
+The HiP05 PERISUB system controller is shared by peripheral controllers in
+HiP05 Soc to implement some basic configurations. the peripheral
+ controllers include mdio, ddr, iic, uart, timer and so on.
+
+Example:
+ /* for HiP05 PCIe-SAS system */
+ pcie_sas: system_controller@0xb000 {
+ compatible = "hisilicon,pcie-sas-subctrl", "syscon";
+ reg = <0xb000 0x1>;
+ };
---
Hisilicon CPU controller
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RESEND net-next 0/3] dts: hisi: fixes can't find eth for hip05-D02
sorry, pls ignore this patchset. On 2015/12/5 15:54, yankejian wrote: > this patchset fixes the bug that eth can't initial successful on hip05-D02 > because the dts files doesn't match the source code. > > yankejian (3): > dts: hisi: enables the ethX for D02 board > dts: hisi: fixes no syscon error when init mdio > arm64: hip05-d02: Document devicetree bindings for Hisilicon D02 Board > > .../devicetree/bindings/arm/hisilicon/hisilicon.txt | 16 > > arch/arm64/boot/dts/hisilicon/hip05-d02.dts | 16 > > arch/arm64/boot/dts/hisilicon/hip05.dtsi | 4 > arch/arm64/boot/dts/hisilicon/hip05_hns.dtsi | 4 ++-- > 4 files changed, 38 insertions(+), 2 deletions(-) > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/10] cpufreq: add generic cpufreq driver support for Exynos542x/5800 platforms
Hi, On Saturday, December 05, 2015 09:24:44 AM Viresh Kumar wrote: > On 04-12-15, 18:30, Bartlomiej Zolnierkiewicz wrote: > > Hi, > > > > This patch series adds generic arm_big_little_dt cpufreq driver > > support for Exynos542x/5800 (using the new CPU clock type which > > allows it). It also: > > - enhances arm_big_little[_dt] driver with CPU cluster regulator > > support > > - adds CPU clock configuration data and CPU operating points > > setup for Exynos542x/5800 > > - adds CPU cluster regulator supplies for Exynos542x/5800 boards > > > > This patch series has been tested on Exynos5422 based ODROID-XU3 > > Lite board. > > > > Please note that this is not a final version of the patchset. > > I just wanted to push out current work-in-progress patches that > > integrate changes from Anand, Ben and me. > > What's going on guys, Ben tried exactly same thing few days back: > > http://marc.info/?l=linux-kernel=144909193925508=2 Why I appreciate Ben's work this not exactly the same thing as the above patchset lacks critical CLK_RECALC_NEW_RATES bugfix and few other minor fixes. > And the comments given there applies to you as well. Yes, sure. That's why I wrote that this is work-in-progress and put the TODO in the cover letter. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R Institute Poland Samsung Electronics -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH net-next 0/2] net: hns: enet specisies a reference to dsaf
in this patchset, enet specifies a reference to dsaf. and delete the ae-name in enet, and adds parsing the ae-handle from DT to set the associating with dsaf. the patchset updates the dtsi and bindings documents as well. yankejian (2): net: hns: enet specisies a reference to dsaf net: hns: enet specisies a reference to dsaf (config and documents) .../devicetree/bindings/net/hisilicon-hns-dsaf.txt| 5 + .../devicetree/bindings/net/hisilicon-hns-nic.txt | 7 --- arch/arm64/boot/dts/hisilicon/hip05_hns.dtsi | 19 +-- drivers/net/ethernet/hisilicon/hns/hnae.c | 17 +++-- drivers/net/ethernet/hisilicon/hns/hnae.h | 7 +-- drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c | 4 drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c| 10 +- drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.h| 1 + drivers/net/ethernet/hisilicon/hns/hns_enet.c | 13 + drivers/net/ethernet/hisilicon/hns/hns_enet.h | 2 +- 10 files changed, 42 insertions(+), 43 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH net-next 2/2] net: hns: enet specisies a reference to dsaf (config and documents)
when enet specisies a reference to dsaf, the correlative config and
documents needs to update. this patch updates the correlative dtsi file
and bindings documents .
Signed-off-by: yankejian
---
.../devicetree/bindings/net/hisilicon-hns-dsaf.txt| 5 +
.../devicetree/bindings/net/hisilicon-hns-nic.txt | 7 ---
arch/arm64/boot/dts/hisilicon/hip05_hns.dtsi | 19 +--
3 files changed, 14 insertions(+), 17 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/hisilicon-hns-dsaf.txt
b/Documentation/devicetree/bindings/net/hisilicon-hns-dsaf.txt
index 80411b2..ecacfa4 100644
--- a/Documentation/devicetree/bindings/net/hisilicon-hns-dsaf.txt
+++ b/Documentation/devicetree/bindings/net/hisilicon-hns-dsaf.txt
@@ -4,8 +4,6 @@ Required properties:
- compatible: should be "hisilicon,hns-dsaf-v1" or "hisilicon,hns-dsaf-v2".
"hisilicon,hns-dsaf-v1" is for hip05.
"hisilicon,hns-dsaf-v2" is for Hi1610 and Hi1612.
-- dsa-name: dsa fabric name who provide this interface.
- should be "dsafX", X is the dsaf id.
- mode: dsa fabric mode string. only support one of dsaf modes like these:
"2port-64vf",
"6port-16rss",
@@ -26,9 +24,8 @@ Required properties:
Example:
-dsa: dsa@c700 {
+dsaf0: dsa@c700 {
compatible = "hisilicon,hns-dsaf-v1";
- dsa_name = "dsaf0";
mode = "6port-16rss";
interrupt-parent = <_dsa>;
reg = <0x0 0xC000 0x0 0x42
diff --git a/Documentation/devicetree/bindings/net/hisilicon-hns-nic.txt
b/Documentation/devicetree/bindings/net/hisilicon-hns-nic.txt
index 41d19be..e6a9d1c 100644
--- a/Documentation/devicetree/bindings/net/hisilicon-hns-nic.txt
+++ b/Documentation/devicetree/bindings/net/hisilicon-hns-nic.txt
@@ -4,8 +4,9 @@ Required properties:
- compatible: "hisilicon,hns-nic-v1" or "hisilicon,hns-nic-v2".
"hisilicon,hns-nic-v1" is for hip05.
"hisilicon,hns-nic-v2" is for Hi1610 and Hi1612.
-- ae-name: accelerator name who provides this interface,
- is simply a name referring to the name of name in the accelerator node.
+- ae-handle: accelerator engine handle for hns,
+ specifies a reference to the associating hardware driver node.
+ see Documentation/devicetree/bindings/net/hisilicon-hns-dsaf.txt
- port-id: is the index of port provided by DSAF (the accelerator). DSAF can
connect to 8 PHYs. Port 0 to 1 are both used for adminstration purpose. They
are called debug ports.
@@ -41,7 +42,7 @@ Example:
ethernet@0{
compatible = "hisilicon,hns-nic-v1";
- ae-name = "dsaf0";
+ ae-handle = <>;
port-id = <0>;
local-mac-address = [a2 14 e4 4b 56 76];
};
diff --git a/arch/arm64/boot/dts/hisilicon/hip05_hns.dtsi
b/arch/arm64/boot/dts/hisilicon/hip05_hns.dtsi
index 606dd5a..89c883e 100644
--- a/arch/arm64/boot/dts/hisilicon/hip05_hns.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hip05_hns.dtsi
@@ -23,9 +23,8 @@ soc0: soc@0 {
};
};
- dsa: dsa@c700 {
+ dsaf0: dsa@c700 {
compatible = "hisilicon,hns-dsaf-v1";
- dsa_name = "dsaf0";
mode = "6port-16rss";
interrupt-parent = <_dsa>;
@@ -127,7 +126,7 @@ soc0: soc@0 {
eth0: ethernet@0{
compatible = "hisilicon,hns-nic-v1";
- ae-name = "dsaf0";
+ ae-handle = <>;
port-id = <0>;
local-mac-address = [00 00 00 01 00 58];
status = "disabled";
@@ -135,14 +134,14 @@ soc0: soc@0 {
};
eth1: ethernet@1{
compatible = "hisilicon,hns-nic-v1";
- ae-name = "dsaf0";
+ ae-handle = <>;
port-id = <1>;
status = "disabled";
dma-coherent;
};
eth2: ethernet@2{
compatible = "hisilicon,hns-nic-v1";
- ae-name = "dsaf0";
+ ae-handle = <>;
port-id = <2>;
local-mac-address = [00 00 00 01 00 5a];
status = "disabled";
@@ -150,7 +149,7 @@ soc0: soc@0 {
};
eth3: ethernet@3{
compatible = "hisilicon,hns-nic-v1";
- ae-name = "dsaf0";
+ ae-handle = <>;
port-id = <3>;
local-mac-address = [00 00 00 01 00 5b];
status = "disabled";
@@ -158,7 +157,7 @@ soc0: soc@0 {
};
eth4: ethernet@4{
compatible = "hisilicon,hns-nic-v1";
- ae-name = "dsaf0";
+ ae-handle = <>;
port-id = <4>;
local-mac-address = [00 00 00 01 00 5c];
status = "disabled";
@@ -166,7 +165,7 @@ soc0: soc@0 {
};
eth5: ethernet@5{
compatible = "hisilicon,hns-nic-v1";
- ae-name = "dsaf0";
[PATCH RESEND net-next 1/3] dts: hisi: enables the ethX for D02 board
this patch enables the ethX for D02 board on hip05-d02.dts. otherwise it
cannot find hns ethX by ifconfig -a.
Signed-off-by: yankejian
---
arch/arm64/boot/dts/hisilicon/hip05-d02.dts | 16
1 file changed, 16 insertions(+)
diff --git a/arch/arm64/boot/dts/hisilicon/hip05-d02.dts
b/arch/arm64/boot/dts/hisilicon/hip05-d02.dts
index ae34e25..6aa5cb2 100644
--- a/arch/arm64/boot/dts/hisilicon/hip05-d02.dts
+++ b/arch/arm64/boot/dts/hisilicon/hip05-d02.dts
@@ -34,3 +34,19 @@
{
status = "ok";
};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH RESEND net-next 2/3] dts: hisi: fixes no syscon error when init mdio
when linux start up, we get the log below:
"Hi-HNS_MDIO 803c.mdio: no syscon hisilicon,peri-c-subctrl
mdio_bus mdio@803c: mdio sys ctl reg has not maped "
the source code about the subctrl is dealled with syscon, but dts doesn't.
it cause such fault. so this patch adds the syscon info on dts files to
fixes it.
Signed-off-by: yankejian
---
arch/arm64/boot/dts/hisilicon/hip05.dtsi | 4
arch/arm64/boot/dts/hisilicon/hip05_hns.dtsi | 4 ++--
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/hisilicon/hip05.dtsi
b/arch/arm64/boot/dts/hisilicon/hip05.dtsi
index 4ff16d0..daaca63 100644
--- a/arch/arm64/boot/dts/hisilicon/hip05.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hip05.dtsi
@@ -246,6 +246,10 @@
clock-frequency = <2>;
};
+ peri_c_subctrl: sub_ctrl_c@8000 {
+ compatible = "hisilicon,peri-c-subctrl", "syscon";
+ reg = < 0x0 0x8000 0x0 0x1>;
+ };
uart0: uart@8030 {
compatible = "snps,dw-apb-uart";
reg = <0x0 0x8030 0x0 0x1>;
diff --git a/arch/arm64/boot/dts/hisilicon/hip05_hns.dtsi
b/arch/arm64/boot/dts/hisilicon/hip05_hns.dtsi
index 606dd5a..4d4815e 100644
--- a/arch/arm64/boot/dts/hisilicon/hip05_hns.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hip05_hns.dtsi
@@ -10,8 +10,8 @@ soc0: soc@0 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "hisilicon,hns-mdio";
- reg = <0x0 0x803c 0x0 0x1
- 0x0 0x8000 0x0 0x1>;
+ reg = <0x0 0x803c 0x0 0x1>;
+ subctrl_vbase = <_c_subctrl>;
soc0_phy0: ethernet-phy@0 {
reg = <0x0>;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH RESEND net-next 0/3] dts: hisi: fixes can't find eth for hip05-D02
this patchset fixes the bug that eth can't initial successful on hip05-D02 because the dts files doesn't match the source code. yankejian (3): dts: hisi: enables the ethX for D02 board dts: hisi: fixes no syscon error when init mdio arm64: hip05-d02: Document devicetree bindings for Hisilicon D02 Board .../devicetree/bindings/arm/hisilicon/hisilicon.txt | 16 arch/arm64/boot/dts/hisilicon/hip05-d02.dts | 16 arch/arm64/boot/dts/hisilicon/hip05.dtsi | 4 arch/arm64/boot/dts/hisilicon/hip05_hns.dtsi | 4 ++-- 4 files changed, 38 insertions(+), 2 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH RESEND net-next 0/3] dts: hisi: fixes can't find eth for hip05-D02
this patchset fixes the bug that eth can't initial successful on hip05-D02 because the dts files doesn't match the source code. yankejian (3): dts: hisi: enables the ethX for D02 board dts: hisi: fixes no syscon error when init mdio arm64: hip05-d02: Document devicetree bindings for Hisilicon D02 Board .../devicetree/bindings/arm/hisilicon/hisilicon.txt | 16 arch/arm64/boot/dts/hisilicon/hip05-d02.dts | 16 arch/arm64/boot/dts/hisilicon/hip05.dtsi | 4 arch/arm64/boot/dts/hisilicon/hip05_hns.dtsi | 4 ++-- 4 files changed, 38 insertions(+), 2 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH RESEND net-next 2/3] dts: hisi: fixes no syscon error when init mdio
when linux start up, we get the log below:
"Hi-HNS_MDIO 803c.mdio: no syscon hisilicon,peri-c-subctrl
mdio_bus mdio@803c: mdio sys ctl reg has not maped "
the source code about the subctrl is dealled with syscon, but dts doesn't.
it cause such fault. so this patch adds the syscon info on dts files to
fixes it.
Signed-off-by: yankejian
---
arch/arm64/boot/dts/hisilicon/hip05.dtsi | 4
arch/arm64/boot/dts/hisilicon/hip05_hns.dtsi | 4 ++--
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/hisilicon/hip05.dtsi
b/arch/arm64/boot/dts/hisilicon/hip05.dtsi
index 4ff16d0..daaca63 100644
--- a/arch/arm64/boot/dts/hisilicon/hip05.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hip05.dtsi
@@ -246,6 +246,10 @@
clock-frequency = <2>;
};
+ peri_c_subctrl: sub_ctrl_c@8000 {
+ compatible = "hisilicon,peri-c-subctrl", "syscon";
+ reg = < 0x0 0x8000 0x0 0x1>;
+ };
uart0: uart@8030 {
compatible = "snps,dw-apb-uart";
reg = <0x0 0x8030 0x0 0x1>;
diff --git a/arch/arm64/boot/dts/hisilicon/hip05_hns.dtsi
b/arch/arm64/boot/dts/hisilicon/hip05_hns.dtsi
index 606dd5a..4d4815e 100644
--- a/arch/arm64/boot/dts/hisilicon/hip05_hns.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hip05_hns.dtsi
@@ -10,8 +10,8 @@ soc0: soc@0 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "hisilicon,hns-mdio";
- reg = <0x0 0x803c 0x0 0x1
- 0x0 0x8000 0x0 0x1>;
+ reg = <0x0 0x803c 0x0 0x1>;
+ subctrl_vbase = <_c_subctrl>;
soc0_phy0: ethernet-phy@0 {
reg = <0x0>;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH RESEND net-next 1/3] dts: hisi: enables the ethX for D02 board
this patch enables the ethX for D02 board on hip05-d02.dts. otherwise it
cannot find hns ethX by ifconfig -a.
Signed-off-by: yankejian
---
arch/arm64/boot/dts/hisilicon/hip05-d02.dts | 16
1 file changed, 16 insertions(+)
diff --git a/arch/arm64/boot/dts/hisilicon/hip05-d02.dts
b/arch/arm64/boot/dts/hisilicon/hip05-d02.dts
index ae34e25..6aa5cb2 100644
--- a/arch/arm64/boot/dts/hisilicon/hip05-d02.dts
+++ b/arch/arm64/boot/dts/hisilicon/hip05-d02.dts
@@ -34,3 +34,19 @@
{
status = "ok";
};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH RESEND net-next 3/3] arm64: hip05-d02: Document devicetree bindings for Hisilicon D02 Board
This patch adds documentation for the devicetree bindings used by the
DT files of Hisilicon Hip05-D02 development board.
Signed-off-by: yankejian
---
.../devicetree/bindings/arm/hisilicon/hisilicon.txt | 16
1 file changed, 16 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt
b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt
index 6ac7c00..5318d78 100644
--- a/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt
+++ b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt
@@ -187,6 +187,22 @@ Example:
reg = <0xb000 0x1>;
};
+Hisilicon HiP05 PERISUB system controller
+
+Required properties:
+- compatible : "hisilicon,peri-c-subctrl", "syscon";
+- reg : Register address and size
+
+The HiP05 PERISUB system controller is shared by peripheral controllers in
+HiP05 Soc to implement some basic configurations. the peripheral
+ controllers include mdio, ddr, iic, uart, timer and so on.
+
+Example:
+ /* for HiP05 PCIe-SAS system */
+ pcie_sas: system_controller@0xb000 {
+ compatible = "hisilicon,pcie-sas-subctrl", "syscon";
+ reg = <0xb000 0x1>;
+ };
---
Hisilicon CPU controller
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] mm/memblock: use memblock_insert_region() for the empty array
We have the special case for an empty array in the memblock_add_range()
function. In the same time we have almost the same functional in the
memblock_insert_region() function. Let's use the memblock_insert_region()
instead of direct initialization.
Signed-off-by: Alexander Kuleshov
---
mm/memblock.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/mm/memblock.c b/mm/memblock.c
index d300f13..e8a897d 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -496,12 +496,16 @@ static void __init_memblock memblock_insert_region(struct
memblock_type *type,
struct memblock_region *rgn = >regions[idx];
BUG_ON(type->cnt >= type->max);
- memmove(rgn + 1, rgn, (type->cnt - idx) * sizeof(*rgn));
+ /* special case for empty array */
+ if (idx)
+ {
+ memmove(rgn + 1, rgn, (type->cnt - idx) * sizeof(*rgn));
+ type->cnt++;
+ }
rgn->base = base;
rgn->size = size;
rgn->flags = flags;
memblock_set_region_node(rgn, nid);
- type->cnt++;
type->total_size += size;
}
@@ -536,11 +540,7 @@ int __init_memblock memblock_add_range(struct
memblock_type *type,
/* special case for empty array */
if (type->regions[0].size == 0) {
WARN_ON(type->cnt != 1 || type->total_size);
- type->regions[0].base = base;
- type->regions[0].size = size;
- type->regions[0].flags = flags;
- memblock_set_region_node(>regions[0], nid);
- type->total_size = size;
+ memblock_insert_region(type, 0, base, size, nid, flags);
return 0;
}
repeat:
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] RTC: RK808: Work around hardware bug on November 31st
> If you set the alarm > for Dec 25th and it's currently Oct 31st then you'll have to adjust in > the alarm code and you'll really set it for Dec 24th. As per above, > we're in S3 (presumably) or have some persistent kernel state so we > know to adjust everything when we wake up (even if we wake up for a > non-alarm reason). How do you deal with the case where you set an alarm in late December, but you then power the system on earlier in December by other means? I think then you couldn't tell if the fix had already been applied? > You'll still get a failure if you set the alarm and then forcibly go > into S5 without software knowledge, then stay in S5 long enough to > cross over Nov 31st without seeing it (but somehow keep the RTC > state). ...but come on, that seems so incredibly rare! :-P I think you could just set it to "November 31st, disabled" at probe time (if it isn't already) and keep it like that indefinitely? I think as long as you don't need to actually use the alarm, that would work fine. Still, with the vast majority of practically existing devices with an RK808 almost constantly connected to some network, I'm not sure if a huge hack-around is really worth it here. (I guess we could still just do the S3 thing which is much less complicated, assuming we can guarantee correct identification.) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH net-next] net: hns: optimize XGE capability by reducing cpu usage
here is the patch raising the performance of XGE by:
1)changes the way page management method for enet momery, and
2)reduces the count of rmb, and
3)adds Memory prefetching
Signed-off-by: yankejian
---
drivers/net/ethernet/hisilicon/hns/hnae.h | 5 +-
drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c | 1 -
drivers/net/ethernet/hisilicon/hns/hns_enet.c | 79 +++
3 files changed, 55 insertions(+), 30 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns/hnae.h
b/drivers/net/ethernet/hisilicon/hns/hnae.h
index d1f3316..6ca94dc 100644
--- a/drivers/net/ethernet/hisilicon/hns/hnae.h
+++ b/drivers/net/ethernet/hisilicon/hns/hnae.h
@@ -341,7 +341,8 @@ struct hnae_queue {
void __iomem *io_base;
phys_addr_t phy_base;
struct hnae_ae_dev *dev;/* the device who use this queue */
- struct hnae_ring rx_ring, tx_ring;
+ struct hnae_ring rx_ring cacheline_internodealigned_in_smp;
+ struct hnae_ring tx_ring cacheline_internodealigned_in_smp;
struct hnae_handle *handle;
};
@@ -597,11 +598,9 @@ static inline void hnae_replace_buffer(struct hnae_ring
*ring, int i,
struct hnae_desc_cb *res_cb)
{
struct hnae_buf_ops *bops = ring->q->handle->bops;
- struct hnae_desc_cb tmp_cb = ring->desc_cb[i];
bops->unmap_buffer(ring, >desc_cb[i]);
ring->desc_cb[i] = *res_cb;
- *res_cb = tmp_cb;
ring->desc[i].addr = (__le64)ring->desc_cb[i].dma;
ring->desc[i].rx.ipoff_bnum_pid_flag = 0;
}
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c
b/drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c
index 77c6edb..522b264 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c
@@ -341,7 +341,6 @@ void hns_ae_toggle_ring_irq(struct hnae_ring *ring, u32
mask)
else
flag = RCB_INT_FLAG_RX;
- hns_rcb_int_clr_hw(ring->q, flag);
hns_rcb_int_ctrl_hw(ring->q, flag, mask);
}
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_enet.c
b/drivers/net/ethernet/hisilicon/hns/hns_enet.c
index cad2663..e2be510 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_enet.c
@@ -33,6 +33,7 @@
#define RCB_IRQ_NOT_INITED 0
#define RCB_IRQ_INITED 1
+#define HNS_BUFFER_SIZE_2048 2048
#define BD_MAX_SEND_SIZE 8191
#define SKB_TMP_LEN(SKB) \
@@ -491,13 +492,51 @@ static unsigned int hns_nic_get_headlen(unsigned char
*data, u32 flag,
return max_size;
}
-static void
-hns_nic_reuse_page(struct hnae_desc_cb *desc_cb, int tsize, int last_offset)
+static void hns_nic_reuse_page(struct sk_buff *skb, int i,
+ struct hnae_ring *ring, int pull_len,
+ struct hnae_desc_cb *desc_cb)
{
+ struct hnae_desc *desc;
+ int truesize, size;
+ int last_offset = 0;
+
+ desc = >desc[ring->next_to_clean];
+ size = le16_to_cpu(desc->rx.size);
+
+#if (PAGE_SIZE < 8192)
+ if (hnae_buf_size(ring) == HNS_BUFFER_SIZE_2048) {
+ truesize = hnae_buf_size(ring);
+ } else {
+ truesize = ALIGN(size, L1_CACHE_BYTES);
+ last_offset = hnae_page_size(ring) - hnae_buf_size(ring);
+ }
+
+#else
+ truesize = ALIGN(size, L1_CACHE_BYTES);
+ last_offset = hnae_page_size(ring) - hnae_buf_size(ring);
+#endif
+
+ skb_add_rx_frag(skb, i, desc_cb->priv, desc_cb->page_offset + pull_len,
+ size - pull_len, truesize - pull_len);
+
/* avoid re-using remote pages,flag default unreuse */
if (likely(page_to_nid(desc_cb->priv) == numa_node_id())) {
+#if (PAGE_SIZE < 8192)
+ if (hnae_buf_size(ring) == HNS_BUFFER_SIZE_2048) {
+ /* if we are only owner of page we can reuse it */
+ if (likely(page_count(desc_cb->priv) == 1)) {
+ /* flip page offset to other buffer */
+ desc_cb->page_offset ^= truesize;
+
+ desc_cb->reuse_flag = 1;
+ /* bump ref count on page before it is given*/
+ get_page(desc_cb->priv);
+ }
+ return;
+ }
+#endif
/* move offset up to the next cache line */
- desc_cb->page_offset += tsize;
+ desc_cb->page_offset += truesize;
if (desc_cb->page_offset <= last_offset) {
desc_cb->reuse_flag = 1;
@@ -529,11 +568,10 @@ static int hns_nic_poll_rx_skb(struct hns_nic_ring_data
*ring_data,
struct hnae_desc *desc;
struct hnae_desc_cb *desc_cb;
unsigned char *va;
- int bnum, length, size, i, truesize, last_offset;
+ int bnum, length, i;
Re: rhashtable: Use __vmalloc with GFP_ATOMIC for table allocation
On Fri, Dec 04, 2015 at 07:15:55PM +0100, Phil Sutter wrote: > > > Only one should really do this, while others are waiting. > > Sure, that was my previous understanding of how this thing works. Yes that's clearly how it should be. Unfortunately while adding the locking to do this, I found out that you can't actually call __vmalloc with BH disabled so this is a no-go. Unless we can make __vmalloc work with BH disabled, I guess we'll have to go back to multi-level lookups unless someone has a better suggestion. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: rhashtable: Use __vmalloc with GFP_ATOMIC for table allocation
On Fri, Dec 04, 2015 at 04:53:34PM -0500, David Miller wrote: > From: Herbert Xu > Date: Fri, 4 Dec 2015 22:39:56 +0800 > > > When an rhashtable user pounds rhashtable hard with back-to-back > > insertions we may end up growing the table in GFP_ATOMIC context. > > Unfortunately when the table reaches a certain size this often > > fails because we don't have enough physically contiguous pages > > to hold the new table. > > > > Eric Dumazet suggested (and in fact wrote this patch) using > > __vmalloc instead which can be used in GFP_ATOMIC context. > > > > Reported-by: Phil Sutter > > Suggested-by: Eric Dumazet > > Signed-off-by: Herbert Xu > > Applied, thanks Herbert. Sorry Dave but you'll have to revert this because I've been able to trigger the following crash with the patch: Testing concurrent rhashtable access from 50 threads [ cut here ] kernel BUG at ../mm/vmalloc.c:1337! invalid opcode: [#1] PREEMPT SMP The reason is that because I was testing insertions with BH disabled, and __vmalloc doesn't like that, even with GFP_ATOMIC. As we obviously want to continue to support rhashtable users inserting entries with BH disabled, we'll have to look for an alternate solution. Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 26/34] mm: implement new mprotect_key() system call
Dave,
On 12/04/2015 02:15 AM, Dave Hansen wrote:
> From: Dave Hansen
>
> mprotect_key() is just like mprotect, except it also takes a
> protection key as an argument. On systems that do not support
> protection keys, it still works, but requires that key=0.
> Otherwise it does exactly what mprotect does.
Is there a man page for this API?
Thanks,
Michael
> I expect it to get used like this, if you want to guarantee that
> any mapping you create can *never* be accessed without the right
> protection keys set up.
>
> pkey_deny_access(11); // random pkey
> int real_prot = PROT_READ|PROT_WRITE;
> ptr = mmap(NULL, PAGE_SIZE, PROT_NONE, MAP_ANONYMOUS|MAP_PRIVATE, -1,
> 0);
> ret = mprotect_key(ptr, PAGE_SIZE, real_prot, 11);
>
> This way, there is *no* window where the mapping is accessible
> since it was always either PROT_NONE or had a protection key set.
>
> We settled on 'unsigned long' for the type of the key here. We
> only need 4 bits on x86 today, but I figured that other
> architectures might need some more space.
>
> Signed-off-by: Dave Hansen
> Cc: linux-...@vger.kernel.org
> ---
>
> b/arch/x86/include/asm/mmu_context.h | 10 +++--
> b/include/linux/pkeys.h |7 +-
> b/mm/Kconfig |7 ++
> b/mm/mprotect.c | 36
> +--
> 4 files changed, 51 insertions(+), 9 deletions(-)
>
> diff -puN arch/x86/include/asm/mmu_context.h~pkeys-85-mprotect_pkey
> arch/x86/include/asm/mmu_context.h
> --- a/arch/x86/include/asm/mmu_context.h~pkeys-85-mprotect_pkey
> 2015-12-03 16:21:30.181877894 -0800
> +++ b/arch/x86/include/asm/mmu_context.h 2015-12-03 16:21:30.190878302
> -0800
> @@ -4,6 +4,7 @@
> #include
> #include
> #include
> +#include
>
> #include
>
> @@ -243,10 +244,14 @@ static inline void arch_unmap(struct mm_
> mpx_notify_unmap(mm, vma, start, end);
> }
>
> +#ifdef CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS
> +/*
> + * If the config option is off, we get the generic version from
> + * include/linux/pkeys.h.
> + */
> static inline int vma_pkey(struct vm_area_struct *vma)
> {
> u16 pkey = 0;
> -#ifdef CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS
> unsigned long vma_pkey_mask = VM_PKEY_BIT0 | VM_PKEY_BIT1 |
> VM_PKEY_BIT2 | VM_PKEY_BIT3;
> /*
> @@ -259,9 +264,10 @@ static inline int vma_pkey(struct vm_are
>*/
> pkey = (vma->vm_flags >> vm_pkey_shift) &
> (vma_pkey_mask >> vm_pkey_shift);
> -#endif
> +
> return pkey;
> }
> +#endif
>
> static inline bool __pkru_allows_pkey(u16 pkey, bool write)
> {
> diff -puN include/linux/pkeys.h~pkeys-85-mprotect_pkey include/linux/pkeys.h
> --- a/include/linux/pkeys.h~pkeys-85-mprotect_pkey2015-12-03
> 16:21:30.183877985 -0800
> +++ b/include/linux/pkeys.h 2015-12-03 16:21:30.190878302 -0800
> @@ -2,10 +2,10 @@
> #define _LINUX_PKEYS_H
>
> #include
> -#include
>
> #ifdef CONFIG_ARCH_HAS_PKEYS
> #include
> +#include
> #else /* ! CONFIG_ARCH_HAS_PKEYS */
>
> /*
> @@ -17,6 +17,11 @@ static inline bool arch_validate_pkey(in
> {
> return true;
> }
> +
> +static inline int vma_pkey(struct vm_area_struct *vma)
> +{
> + return 0;
> +}
> #endif /* ! CONFIG_ARCH_HAS_PKEYS */
>
> #endif /* _LINUX_PKEYS_H */
> diff -puN mm/Kconfig~pkeys-85-mprotect_pkey mm/Kconfig
> --- a/mm/Kconfig~pkeys-85-mprotect_pkey 2015-12-03 16:21:30.185878075
> -0800
> +++ b/mm/Kconfig 2015-12-03 16:21:30.190878302 -0800
> @@ -673,3 +673,10 @@ config ARCH_USES_HIGH_VMA_FLAGS
> bool
> config ARCH_HAS_PKEYS
> bool
> +
> +config NR_PROTECTION_KEYS
> + int
> + # Everything supports a _single_ key, so allow folks to
> + # at least call APIs that take keys, but require that the
> + # key be 0.
> + default 1
> diff -puN mm/mprotect.c~pkeys-85-mprotect_pkey mm/mprotect.c
> --- a/mm/mprotect.c~pkeys-85-mprotect_pkey2015-12-03 16:21:30.186878121
> -0800
> +++ b/mm/mprotect.c 2015-12-03 16:21:30.191878347 -0800
> @@ -24,6 +24,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -344,10 +345,13 @@ fail:
> return error;
> }
>
> -SYSCALL_DEFINE3(mprotect, unsigned long, start, size_t, len,
> - unsigned long, prot)
> +/*
> + * pkey=-1 when doing a legacy mprotect()
> + */
> +static int do_mprotect_pkey(unsigned long start, size_t len,
> + unsigned long prot, int pkey)
> {
> - unsigned long vm_flags, nstart, end, tmp, reqprot;
> + unsigned long nstart, end, tmp, reqprot;
> struct vm_area_struct *vma, *prev;
> int error = -EINVAL;
> const int grows = prot & (PROT_GROWSDOWN|PROT_GROWSUP);
> @@ -373,8 +377,6 @@ SYSCALL_DEFINE3(mprotect, unsigned long,
> if ((prot & PROT_READ) && (current->personality & READ_IMPLIES_EXEC))
> prot |=
[PATCH] clk: let clk_disable() return immediately if clk is NULL or error
The clk_disable() in the common clock framework (drivers/clk/clk.c)
returns immediately if the given clk is NULL or an error pointer.
It allows drivers to call clk_disable() (and clk_disable_unprepare())
with a clock that might be NULL or an error pointer as long as the
drivers are only used along with the common clock framework.
Unfortunately, NULL/error checking is missing from some of non-common
clk_disable() implementations. This prevents us from completely
dropping NULL/error from callers. Let's add IS_ERR_OR_NULL(clk)
checks to all callees.
Signed-off-by: Masahiro Yamada
---
arch/arm/mach-ep93xx/clock.c | 2 +-
arch/arm/mach-lpc32xx/clock.c| 3 +++
arch/arm/mach-mmp/clock.c| 3 +++
arch/arm/mach-sa1100/clock.c | 15 ---
arch/arm/mach-w90x900/clock.c| 3 +++
arch/blackfin/mach-bf609/clock.c | 3 +++
arch/m68k/coldfire/clk.c | 4
arch/mips/bcm63xx/clk.c | 3 +++
arch/mips/lantiq/clk.c | 3 +++
drivers/sh/clk/core.c| 2 +-
10 files changed, 32 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-ep93xx/clock.c b/arch/arm/mach-ep93xx/clock.c
index 39ef3b6..4e11f7d 100644
--- a/arch/arm/mach-ep93xx/clock.c
+++ b/arch/arm/mach-ep93xx/clock.c
@@ -293,7 +293,7 @@ void clk_disable(struct clk *clk)
{
unsigned long flags;
- if (!clk)
+ if (IS_ERR_OR_NULL(clk))
return;
spin_lock_irqsave(_lock, flags);
diff --git a/arch/arm/mach-lpc32xx/clock.c b/arch/arm/mach-lpc32xx/clock.c
index 661c8f4..07faac2 100644
--- a/arch/arm/mach-lpc32xx/clock.c
+++ b/arch/arm/mach-lpc32xx/clock.c
@@ -1125,6 +1125,9 @@ void clk_disable(struct clk *clk)
{
unsigned long flags;
+ if (IS_ERR_OR_NULL(clk))
+ return;
+
spin_lock_irqsave(_clkregs_lock, flags);
local_clk_disable(clk);
spin_unlock_irqrestore(_clkregs_lock, flags);
diff --git a/arch/arm/mach-mmp/clock.c b/arch/arm/mach-mmp/clock.c
index 7c6f95f..7b33122 100644
--- a/arch/arm/mach-mmp/clock.c
+++ b/arch/arm/mach-mmp/clock.c
@@ -67,6 +67,9 @@ void clk_disable(struct clk *clk)
{
unsigned long flags;
+ if (IS_ERR_OR_NULL(clk))
+ return;
+
WARN_ON(clk->enabled == 0);
spin_lock_irqsave(_lock, flags);
diff --git a/arch/arm/mach-sa1100/clock.c b/arch/arm/mach-sa1100/clock.c
index cbf53bb..ea103fd 100644
--- a/arch/arm/mach-sa1100/clock.c
+++ b/arch/arm/mach-sa1100/clock.c
@@ -85,13 +85,14 @@ void clk_disable(struct clk *clk)
{
unsigned long flags;
- if (clk) {
- WARN_ON(clk->enabled == 0);
- spin_lock_irqsave(_lock, flags);
- if (--clk->enabled == 0)
- clk->ops->disable(clk);
- spin_unlock_irqrestore(_lock, flags);
- }
+ if (IS_ERR_OR_NULL(clk))
+ return;
+
+ WARN_ON(clk->enabled == 0);
+ spin_lock_irqsave(_lock, flags);
+ if (--clk->enabled == 0)
+ clk->ops->disable(clk);
+ spin_unlock_irqrestore(_lock, flags);
}
EXPORT_SYMBOL(clk_disable);
diff --git a/arch/arm/mach-w90x900/clock.c b/arch/arm/mach-w90x900/clock.c
index 2c371ff..90ec250 100644
--- a/arch/arm/mach-w90x900/clock.c
+++ b/arch/arm/mach-w90x900/clock.c
@@ -46,6 +46,9 @@ void clk_disable(struct clk *clk)
{
unsigned long flags;
+ if (IS_ERR_OR_NULL(clk))
+ return;
+
WARN_ON(clk->enabled == 0);
spin_lock_irqsave(_lock, flags);
diff --git a/arch/blackfin/mach-bf609/clock.c b/arch/blackfin/mach-bf609/clock.c
index 3783058..fed8015 100644
--- a/arch/blackfin/mach-bf609/clock.c
+++ b/arch/blackfin/mach-bf609/clock.c
@@ -97,6 +97,9 @@ EXPORT_SYMBOL(clk_enable);
void clk_disable(struct clk *clk)
{
+ if (IS_ERR_OR_NULL(clk))
+ return;
+
if (clk->ops && clk->ops->disable)
clk->ops->disable(clk);
}
diff --git a/arch/m68k/coldfire/clk.c b/arch/m68k/coldfire/clk.c
index fddfdcc..eb0e8c1 100644
--- a/arch/m68k/coldfire/clk.c
+++ b/arch/m68k/coldfire/clk.c
@@ -101,6 +101,10 @@ EXPORT_SYMBOL(clk_enable);
void clk_disable(struct clk *clk)
{
unsigned long flags;
+
+ if (IS_ERR_OR_NULL(clk))
+ return;
+
spin_lock_irqsave(_lock, flags);
if ((--clk->enabled == 0) && clk->clk_ops)
clk->clk_ops->disable(clk);
diff --git a/arch/mips/bcm63xx/clk.c b/arch/mips/bcm63xx/clk.c
index 6375652..d6a39bf 100644
--- a/arch/mips/bcm63xx/clk.c
+++ b/arch/mips/bcm63xx/clk.c
@@ -326,6 +326,9 @@ EXPORT_SYMBOL(clk_enable);
void clk_disable(struct clk *clk)
{
+ if (IS_ERR_OR_NULL(clk))
+ return;
+
mutex_lock(_mutex);
clk_disable_unlocked(clk);
mutex_unlock(_mutex);
diff --git a/arch/mips/lantiq/clk.c b/arch/mips/lantiq/clk.c
index a0706fd..c8d87b1 100644
--- a/arch/mips/lantiq/clk.c
+++ b/arch/mips/lantiq/clk.c
@@ -130,6 +130,9 @@
Re: [PATCH 14/19] fs: Permit FIBMAP for users with CAP_SYS_RAWIO in s_user_ns
On Fri, Dec 04, 2015 at 05:43:49PM -0600, Serge E. Hallyn wrote: > On Fri, Dec 04, 2015 at 06:11:52PM -0500, Theodore Ts'o wrote: > > On Fri, Dec 04, 2015 at 02:45:32PM -0600, Seth Forshee wrote: > > > On Fri, Dec 04, 2015 at 02:07:36PM -0600, Serge E. Hallyn wrote: > > > > Heh, I was looking over > > > > http://www.gossamer-threads.com/lists/linux/kernel/103611 > > > > a little while ago :) The same question was asked 16 years ago. > > > > Apparently > > > > the answer then was that it was easier than fixing the code. > > > > > > So it seems then that either it still isn't safe and so unprivileged > > > users shouldn't be allowed to do it at all, or else it's safe and we > > > should drop the requirement completely. I can't say which is right, > > > unfortunately. > > > > It may not have been safe 16 years agoo, but giving invalid arguments > > to FIBMAP is safe for ext4 and ext2. This is the sort of thing that > > tools like trinity should and does test for, so I think it should be > > fine to remove the root check for FIBMAP. > > Seth, can I tempt you into sending a standalone patch to remove that? :) Patch sent. I'll drop this patch in v2. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] fs: Drop CAP_SYS_RAWIO requirement for FIBMAP
The information exposed by FIBMAP is not privileged and is similar to the information provided by FIEMAP, which does not require privileges. According to [1] the reason the capability check was originally added was to prevent crashing the kernel by passing invalid arguments, but this should no longer be a problem, so this requirement can be removed. [1] http://www.gossamer-threads.com/lists/linux/kernel/103611 Cc: "Serge E. Hallyn" Cc: Theodore Ts'o Signed-off-by: Seth Forshee --- fs/ioctl.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/fs/ioctl.c b/fs/ioctl.c index 5d01d2638ca5..c963d82b0de8 100644 --- a/fs/ioctl.c +++ b/fs/ioctl.c @@ -55,8 +55,6 @@ static int ioctl_fibmap(struct file *filp, int __user *p) /* do we support this mess? */ if (!mapping->a_ops->bmap) return -EINVAL; - if (!capable(CAP_SYS_RAWIO)) - return -EPERM; res = get_user(block, p); if (res) return res; -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH net-next 1/2] net: hns: enet specisies a reference to dsaf
enet is associating with dasf. before this patch, the association is
the same strings between ae-name and dsa-name. in a general way, enet
specifies a reference to dsaf should be a good idea. so this patch
deletes the ae-name in enet, and adds parsing the ae-handle
from DT to set the associating with dsaf.
Signed-off-by: yankejian
---
drivers/net/ethernet/hisilicon/hns/hnae.c | 17 +++--
drivers/net/ethernet/hisilicon/hns/hnae.h | 7 +--
drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c | 4
drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c | 10 +-
drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.h | 1 +
drivers/net/ethernet/hisilicon/hns/hns_enet.c | 13 +
drivers/net/ethernet/hisilicon/hns/hns_enet.h | 2 +-
7 files changed, 28 insertions(+), 26 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns/hnae.c
b/drivers/net/ethernet/hisilicon/hns/hnae.c
index b364529..3bfe36f 100644
--- a/drivers/net/ethernet/hisilicon/hns/hnae.c
+++ b/drivers/net/ethernet/hisilicon/hns/hnae.c
@@ -95,21 +95,17 @@ static struct hnae_buf_ops hnae_bops = {
static int __ae_match(struct device *dev, const void *data)
{
struct hnae_ae_dev *hdev = cls_to_ae_dev(dev);
- const char *ae_id = data;
- if (!strncmp(ae_id, hdev->name, AE_NAME_SIZE))
- return 1;
-
- return 0;
+ return hdev->dev->of_node == data;
}
-static struct hnae_ae_dev *find_ae(const char *ae_id)
+static struct hnae_ae_dev *find_ae(const struct device_node *ae_node)
{
struct device *dev;
- WARN_ON(!ae_id);
+ WARN_ON(!ae_node);
- dev = class_find_device(hnae_class, NULL, ae_id, __ae_match);
+ dev = class_find_device(hnae_class, NULL, ae_node, __ae_match);
return dev ? cls_to_ae_dev(dev) : NULL;
}
@@ -316,7 +312,8 @@ EXPORT_SYMBOL(hnae_reinit_handle);
* return handle ptr or ERR_PTR
*/
struct hnae_handle *hnae_get_handle(struct device *owner_dev,
- const char *ae_id, u32 port_id,
+ const struct device_node *ae_node,
+ u32 port_id,
struct hnae_buf_ops *bops)
{
struct hnae_ae_dev *dev;
@@ -324,7 +321,7 @@ struct hnae_handle *hnae_get_handle(struct device
*owner_dev,
int i, j;
int ret;
- dev = find_ae(ae_id);
+ dev = find_ae(ae_node);
if (!dev)
return ERR_PTR(-ENODEV);
diff --git a/drivers/net/ethernet/hisilicon/hns/hnae.h
b/drivers/net/ethernet/hisilicon/hns/hnae.h
index d1f3316..0012664 100644
--- a/drivers/net/ethernet/hisilicon/hns/hnae.h
+++ b/drivers/net/ethernet/hisilicon/hns/hnae.h
@@ -523,8 +523,11 @@ struct hnae_handle {
#define ring_to_dev(ring) ((ring)->q->dev->dev)
-struct hnae_handle *hnae_get_handle(struct device *owner_dev, const char
*ae_id,
- u32 port_id, struct hnae_buf_ops *bops);
+struct hnae_handle *hnae_get_handle(struct device *owner_dev,
+ const struct device_node *ae_node,
+ u32 port_id,
+ struct hnae_buf_ops *bops);
+
void hnae_put_handle(struct hnae_handle *handle);
int hnae_ae_register(struct hnae_ae_dev *dev, struct module *owner);
void hnae_ae_unregister(struct hnae_ae_dev *dev);
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c
b/drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c
index 77c6edb..ed9a72c 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c
@@ -848,6 +848,7 @@ static struct hnae_ae_ops hns_dsaf_ops = {
int hns_dsaf_ae_init(struct dsaf_device *dsaf_dev)
{
struct hnae_ae_dev *ae_dev = _dev->ae_dev;
+ static atomic_t id = ATOMIC_INIT(-1);
switch (dsaf_dev->dsaf_ver) {
case AE_VERSION_1:
@@ -859,6 +860,9 @@ int hns_dsaf_ae_init(struct dsaf_device *dsaf_dev)
default:
break;
}
+
+ snprintf(ae_dev->name, AE_NAME_SIZE, "%s%d", DSAF_DEVICE_NAME,
+(int)atomic_inc_return());
ae_dev->ops = _dsaf_ops;
ae_dev->dev = dsaf_dev->dev;
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c
b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c
index 636b205..f3de749 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c
@@ -35,7 +35,7 @@ int hns_dsaf_get_cfg(struct dsaf_device *dsaf_dev)
int ret, i;
u32 desc_num;
u32 buf_size;
- const char *name, *mode_str;
+ const char *mode_str;
struct device_node *np = dsaf_dev->dev->of_node;
if (of_device_is_compatible(np, "hisilicon,hns-dsaf-v1"))
@@ -43,14 +43,6 @@ int hns_dsaf_get_cfg(struct dsaf_device *dsaf_dev)
else
dsaf_dev->dsaf_ver =
[PATCH net-next 0/2] net: hns: enet specisies a reference to dsaf
in this patchset, enet specifies a reference to dsaf. and delete the ae-name in enet, and adds parsing the ae-handle from DT to set the associating with dsaf. the patchset updates the dtsi and bindings documents as well. yankejian (2): net: hns: enet specisies a reference to dsaf net: hns: enet specisies a reference to dsaf (config and documents) .../devicetree/bindings/net/hisilicon-hns-dsaf.txt| 5 + .../devicetree/bindings/net/hisilicon-hns-nic.txt | 7 --- arch/arm64/boot/dts/hisilicon/hip05_hns.dtsi | 19 +-- drivers/net/ethernet/hisilicon/hns/hnae.c | 17 +++-- drivers/net/ethernet/hisilicon/hns/hnae.h | 7 +-- drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c | 4 drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c| 10 +- drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.h| 1 + drivers/net/ethernet/hisilicon/hns/hns_enet.c | 13 + drivers/net/ethernet/hisilicon/hns/hns_enet.h | 2 +- 10 files changed, 42 insertions(+), 43 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH net-next 2/2] net: hns: enet specisies a reference to dsaf (config and documents)
when enet specisies a reference to dsaf, the correlative config and
documents needs to update. this patch updates the correlative dtsi file
and bindings documents .
Signed-off-by: yankejian
---
.../devicetree/bindings/net/hisilicon-hns-dsaf.txt| 5 +
.../devicetree/bindings/net/hisilicon-hns-nic.txt | 7 ---
arch/arm64/boot/dts/hisilicon/hip05_hns.dtsi | 19 +--
3 files changed, 14 insertions(+), 17 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/hisilicon-hns-dsaf.txt
b/Documentation/devicetree/bindings/net/hisilicon-hns-dsaf.txt
index 80411b2..ecacfa4 100644
--- a/Documentation/devicetree/bindings/net/hisilicon-hns-dsaf.txt
+++ b/Documentation/devicetree/bindings/net/hisilicon-hns-dsaf.txt
@@ -4,8 +4,6 @@ Required properties:
- compatible: should be "hisilicon,hns-dsaf-v1" or "hisilicon,hns-dsaf-v2".
"hisilicon,hns-dsaf-v1" is for hip05.
"hisilicon,hns-dsaf-v2" is for Hi1610 and Hi1612.
-- dsa-name: dsa fabric name who provide this interface.
- should be "dsafX", X is the dsaf id.
- mode: dsa fabric mode string. only support one of dsaf modes like these:
"2port-64vf",
"6port-16rss",
@@ -26,9 +24,8 @@ Required properties:
Example:
-dsa: dsa@c700 {
+dsaf0: dsa@c700 {
compatible = "hisilicon,hns-dsaf-v1";
- dsa_name = "dsaf0";
mode = "6port-16rss";
interrupt-parent = <_dsa>;
reg = <0x0 0xC000 0x0 0x42
diff --git a/Documentation/devicetree/bindings/net/hisilicon-hns-nic.txt
b/Documentation/devicetree/bindings/net/hisilicon-hns-nic.txt
index 41d19be..e6a9d1c 100644
--- a/Documentation/devicetree/bindings/net/hisilicon-hns-nic.txt
+++ b/Documentation/devicetree/bindings/net/hisilicon-hns-nic.txt
@@ -4,8 +4,9 @@ Required properties:
- compatible: "hisilicon,hns-nic-v1" or "hisilicon,hns-nic-v2".
"hisilicon,hns-nic-v1" is for hip05.
"hisilicon,hns-nic-v2" is for Hi1610 and Hi1612.
-- ae-name: accelerator name who provides this interface,
- is simply a name referring to the name of name in the accelerator node.
+- ae-handle: accelerator engine handle for hns,
+ specifies a reference to the associating hardware driver node.
+ see Documentation/devicetree/bindings/net/hisilicon-hns-dsaf.txt
- port-id: is the index of port provided by DSAF (the accelerator). DSAF can
connect to 8 PHYs. Port 0 to 1 are both used for adminstration purpose. They
are called debug ports.
@@ -41,7 +42,7 @@ Example:
ethernet@0{
compatible = "hisilicon,hns-nic-v1";
- ae-name = "dsaf0";
+ ae-handle = <>;
port-id = <0>;
local-mac-address = [a2 14 e4 4b 56 76];
};
diff --git a/arch/arm64/boot/dts/hisilicon/hip05_hns.dtsi
b/arch/arm64/boot/dts/hisilicon/hip05_hns.dtsi
index 606dd5a..89c883e 100644
--- a/arch/arm64/boot/dts/hisilicon/hip05_hns.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hip05_hns.dtsi
@@ -23,9 +23,8 @@ soc0: soc@0 {
};
};
- dsa: dsa@c700 {
+ dsaf0: dsa@c700 {
compatible = "hisilicon,hns-dsaf-v1";
- dsa_name = "dsaf0";
mode = "6port-16rss";
interrupt-parent = <_dsa>;
@@ -127,7 +126,7 @@ soc0: soc@0 {
eth0: ethernet@0{
compatible = "hisilicon,hns-nic-v1";
- ae-name = "dsaf0";
+ ae-handle = <>;
port-id = <0>;
local-mac-address = [00 00 00 01 00 58];
status = "disabled";
@@ -135,14 +134,14 @@ soc0: soc@0 {
};
eth1: ethernet@1{
compatible = "hisilicon,hns-nic-v1";
- ae-name = "dsaf0";
+ ae-handle = <>;
port-id = <1>;
status = "disabled";
dma-coherent;
};
eth2: ethernet@2{
compatible = "hisilicon,hns-nic-v1";
- ae-name = "dsaf0";
+ ae-handle = <>;
port-id = <2>;
local-mac-address = [00 00 00 01 00 5a];
status = "disabled";
@@ -150,7 +149,7 @@ soc0: soc@0 {
};
eth3: ethernet@3{
compatible = "hisilicon,hns-nic-v1";
- ae-name = "dsaf0";
+ ae-handle = <>;
port-id = <3>;
local-mac-address = [00 00 00 01 00 5b];
status = "disabled";
@@ -158,7 +157,7 @@ soc0: soc@0 {
};
eth4: ethernet@4{
compatible = "hisilicon,hns-nic-v1";
- ae-name = "dsaf0";
+ ae-handle = <>;
port-id = <4>;
local-mac-address = [00 00 00 01 00 5c];
status = "disabled";
@@ -166,7 +165,7 @@ soc0: soc@0 {
};
eth5: ethernet@5{
compatible = "hisilicon,hns-nic-v1";
- ae-name = "dsaf0";
[RFC PATCH 4/7] mtd: add of_match_mtd_parser() and of_mtd_match_mtd_parser() helpers
Like the corresponding OF-based device/driver matching infrascture,
let's begin to support a mtd/partition-parser matching infrastructure.
Signed-off-by: Brian Norris
---
drivers/of/of_mtd.c| 33 +
include/linux/mtd/partitions.h | 2 ++
include/linux/of_mtd.h | 13 +
3 files changed, 48 insertions(+)
diff --git a/drivers/of/of_mtd.c b/drivers/of/of_mtd.c
index b7361ed70537..169d7500af5d 100644
--- a/drivers/of/of_mtd.c
+++ b/drivers/of/of_mtd.c
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
#include
/**
@@ -117,3 +118,35 @@ bool of_get_nand_on_flash_bbt(struct device_node *np)
return of_property_read_bool(np, "nand-on-flash-bbt");
}
EXPORT_SYMBOL_GPL(of_get_nand_on_flash_bbt);
+
+static const struct of_device_id *of_match_mtd_parser(
+ struct mtd_part_parser *parser, struct device_node *np)
+{
+ if (!parser || !np)
+ return NULL;
+
+ return of_match_node(parser->of_match_table, np);
+}
+
+static struct device_node *mtd_get_partitions_of_node(struct mtd_info *master)
+{
+ struct device_node *np = mtd_get_of_node(master);
+
+ if (!np)
+ return NULL;
+
+ return of_get_child_by_name(np, "partitions");
+}
+
+bool of_mtd_match_mtd_parser(struct mtd_info *mtd,
+struct mtd_part_parser *parser)
+{
+ struct device_node *np = mtd_get_partitions_of_node(mtd);
+ bool ret;
+
+ ret = of_match_mtd_parser(parser, np) != NULL;
+ of_node_put(np);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(of_mtd_match_mtd_parser);
diff --git a/include/linux/mtd/partitions.h b/include/linux/mtd/partitions.h
index 70736e1e6c8f..2e68ef561a40 100644
--- a/include/linux/mtd/partitions.h
+++ b/include/linux/mtd/partitions.h
@@ -51,6 +51,7 @@ struct mtd_partition {
struct mtd_info;
struct device_node;
+struct of_device_id;
/**
* struct mtd_part_parser_data - used to pass data to MTD partition parsers.
@@ -69,6 +70,7 @@ struct mtd_part_parser {
struct list_head list;
struct module *owner;
const char *name;
+ const struct of_device_id *of_match_table;
int (*parse_fn)(struct mtd_info *, const struct mtd_partition **,
struct mtd_part_parser_data *);
void (*cleanup)(const struct mtd_partition *pparts, int nr_parts);
diff --git a/include/linux/of_mtd.h b/include/linux/of_mtd.h
index e266caa36402..781362d0be0c 100644
--- a/include/linux/of_mtd.h
+++ b/include/linux/of_mtd.h
@@ -9,6 +9,10 @@
#ifndef __LINUX_OF_MTD_H
#define __LINUX_OF_MTD_H
+#include
+
+struct mtd_part_parser;
+
#ifdef CONFIG_OF_MTD
#include
@@ -18,6 +22,9 @@ int of_get_nand_ecc_strength(struct device_node *np);
int of_get_nand_bus_width(struct device_node *np);
bool of_get_nand_on_flash_bbt(struct device_node *np);
+bool of_mtd_match_mtd_parser(struct mtd_info *mtd,
+struct mtd_part_parser *parser);
+
#else /* CONFIG_OF_MTD */
static inline int of_get_nand_ecc_mode(struct device_node *np)
@@ -45,6 +52,12 @@ static inline bool of_get_nand_on_flash_bbt(struct
device_node *np)
return false;
}
+static inline bool of_mtd_match_mtd_parser(struct mtd_info *mtd,
+ struct mtd_part_parser *parser)
+{
+ return false;
+}
+
#endif /* CONFIG_OF_MTD */
#endif /* __LINUX_OF_MTD_H */
--
2.6.0.rc2.230.g3dd15c0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 2/7] mtd: move partition parsers' Kconfig under a sub-menu
For better organization. Signed-off-by: Brian Norris --- drivers/mtd/Kconfig| 134 + drivers/mtd/partitions/Kconfig | 131 2 files changed, 134 insertions(+), 131 deletions(-) create mode 100644 drivers/mtd/partitions/Kconfig diff --git a/drivers/mtd/Kconfig b/drivers/mtd/Kconfig index 42cc953309f1..a06e80d24499 100644 --- a/drivers/mtd/Kconfig +++ b/drivers/mtd/Kconfig @@ -23,137 +23,9 @@ config MTD_TESTS WARNING: some of the tests will ERASE entire MTD device which they test. Do not use these tests unless you really know what you do. -config MTD_REDBOOT_PARTS - tristate "RedBoot partition table parsing" - ---help--- - RedBoot is a ROM monitor and bootloader which deals with multiple - 'images' in flash devices by putting a table one of the erase - blocks on the device, similar to a partition table, which gives - the offsets, lengths and names of all the images stored in the - flash. - - If you need code which can detect and parse this table, and register - MTD 'partitions' corresponding to each image in the table, enable - this option. - - You will still need the parsing functions to be called by the driver - for your particular device. It won't happen automatically. The - SA1100 map driver (CONFIG_MTD_SA1100) has an option for this, for - example. - -if MTD_REDBOOT_PARTS - -config MTD_REDBOOT_DIRECTORY_BLOCK - int "Location of RedBoot partition table" - default "-1" - ---help--- - This option is the Linux counterpart to the - CYGNUM_REDBOOT_FIS_DIRECTORY_BLOCK RedBoot compile time - option. - - The option specifies which Flash sectors holds the RedBoot - partition table. A zero or positive value gives an absolute - erase block number. A negative value specifies a number of - sectors before the end of the device. - - For example "2" means block number 2, "-1" means the last - block and "-2" means the penultimate block. - -config MTD_REDBOOT_PARTS_UNALLOCATED - bool "Include unallocated flash regions" - help - If you need to register each unallocated flash region as a MTD - 'partition', enable this option. - -config MTD_REDBOOT_PARTS_READONLY - bool "Force read-only for RedBoot system images" - help - If you need to force read-only for 'RedBoot', 'RedBoot Config' and - 'FIS directory' images, enable this option. - -endif # MTD_REDBOOT_PARTS - -config MTD_CMDLINE_PARTS - tristate "Command line partition table parsing" - depends on MTD - ---help--- - Allow generic configuration of the MTD partition tables via the kernel - command line. Multiple flash resources are supported for hardware where - different kinds of flash memory are available. - - You will still need the parsing functions to be called by the driver - for your particular device. It won't happen automatically. The - SA1100 map driver (CONFIG_MTD_SA1100) has an option for this, for - example. - - The format for the command line is as follows: - - mtdparts=[; := :[,] - := [@offset][][ro] - := unique id used in mapping driver/device - := standard linux memsize OR "-" to denote all - remaining space - := (NAME) - - Due to the way Linux handles the command line, no spaces are - allowed in the partition definition, including mtd id's and partition - names. - - Examples: - - 1 flash resource (mtd-id "sa1100"), with 1 single writable partition: - mtdparts=sa1100:- - - Same flash, but 2 named partitions, the first one being read-only: - mtdparts=sa1100:256k(ARMboot)ro,-(root) - - If unsure, say 'N'. - -config MTD_AFS_PARTS - tristate "ARM Firmware Suite partition parsing" - depends on (ARM || ARM64) - ---help--- - The ARM Firmware Suite allows the user to divide flash devices into - multiple 'images'. Each such image has a header containing its name - and offset/size etc. - - If you need code which can detect and parse these tables, and - register MTD 'partitions' corresponding to each image detected, - enable this option. - - You will still need the parsing functions to be called by the driver - for your particular device. It won't happen automatically. The - 'physmap' map driver (CONFIG_MTD_PHYSMAP) does this, for example. - -config MTD_OF_PARTS - tristate "OpenFirmware partitioning information support" - default y - depends on OF - help - This provides a partition parsing function which derives - the partition map from the children of the flash
[RFC PATCH 0/7] mtd: partitions: add of_match_table support
Hi,
There have been several discussions [1] about adding a device tree binding for
associating flash devices with the partition parser(s) that are used on the
flash. There are a few reasons:
(1) drivers shouldn't have to be encoding platform knowledge by listing what
parsers might be used on a given system (this is the currently all that's
supported)
(2) we can't just scan for all supported parsers (like the block system does),
since
there is a wide diversity of "formats" (no standardization), and it is not
always safe or efficient to attempt to do so, particularly since many of
them allow their data structures to be placed anywhere on the flash, and
so require scanning the entire flash device to find them.
So instead, let's support a new binding so that a device tree can specify what
partition formats might be used. This seems like a reasonable choice (even
though it's not strictly a hardware description) because the flash layout /
partitioning is often very closely tied with the bootloader/firmware, at
production time.
Also, as an example first-use of this mechanism, I support Google's FMAP flash
structure, used on Chrome OS devices.
Note that this is an RFC, mainly for the reason noted in patch 6 ("RFC: mtd:
partitions: enable of_match_table matching"): the of_match_table support won't
yet autoload a partition parser that is built as a module. I'm not quite sure
if there's a lot of value in supporting MTD parsers as modules (block partition
support can't be), but that is supported for "by-name" parser lookups in MTD
already, so I don't feel like dropping that feature yet. Tips or thoughts are
particularly welcome on this aspect!
Also note that there's an existing undocumented binding for a
"linux,part-probe" property, but it is only usable on the physmap_of.c driver
at the moment, and it is IMO not a good binding. I posted my thoughts on that
previously here [2], and since no one else cared to make a better one...I did
it myself.
I'd love it if we could kill the unreviewed binding off in favor of something
more like this...
Currently based on v2 of "mtd: partitions: support cleanup callback for
parsers":
http://lkml.kernel.org/g/1449271518-118900-1-git-send-email-computersforpe...@gmail.com
and this series
("mtd: ofpart: don't complain about missing 'partitions' node too loudly" and
"doc: dt: mtd: partitions: add compatible property to "partitions" node"):
http://lkml.kernel.org/g/1449194529-145705-1-git-send-email-computersforpe...@gmail.com
Both of which should hopefully be merged soon.
The current total of this work is stashed here for now:
git fetch git://git.infradead.org/users/norris/linux-mtd.git
partition-of-match
I may rewrite this branch if I post future revisions of these patch sets, FYI.
I look forward to your reviews.
Regards,
Brian
[1] Trying to extend "linux,part-probe":
http://patchwork.ozlabs.org/patch/475988/
For bcm47xxpart:
http://patchwork.ozlabs.org/patch/475986/
For AFS:
http://patchwork.ozlabs.org/patch/537827/
[2] "mtd: document linux-specific partition parser DT binding"
http://lists.infradead.org/pipermail/linux-mtd/2015-October/062773.html
Brian Norris (7):
mtd: move partition parsers to drivers/mtd/partitions/
mtd: move partition parsers' Kconfig under a sub-menu
doc: dt: mtd: partition: add on-flash format binding
mtd: add of_match_mtd_parser() and of_mtd_match_mtd_parser() helpers
mtd: partitions: factor out "match by name" handling
RFC: mtd: partitions: enable of_match_table matching
mtd: partitions: add Google's FMAP partition parser
.../devicetree/bindings/mtd/partition.txt | 75 ++-
drivers/mtd/Kconfig| 134 +---
drivers/mtd/Makefile | 8 +-
drivers/mtd/mtdpart.c | 99 +++--
drivers/mtd/partitions/Kconfig | 138 +
drivers/mtd/partitions/Makefile| 8 +
drivers/mtd/{ => partitions}/afs.c | 0
drivers/mtd/{ => partitions}/ar7part.c | 0
drivers/mtd/{ => partitions}/bcm47xxpart.c | 0
drivers/mtd/{ => partitions}/bcm63xxpart.c | 0
drivers/mtd/{ => partitions}/cmdlinepart.c | 0
drivers/mtd/partitions/google_fmap.c | 226 +
drivers/mtd/{ => partitions}/ofpart.c | 0
drivers/mtd/{ => partitions}/redboot.c | 0
drivers/of/of_mtd.c| 33 +++
include/linux/mtd/partitions.h | 2 +
include/linux/of_mtd.h | 13 ++
17 files changed, 577 insertions(+), 159 deletions(-)
create mode 100644 drivers/mtd/partitions/Kconfig
create mode 100644 drivers/mtd/partitions/Makefile
rename drivers/mtd/{ => partitions}/afs.c (100%)
rename drivers/mtd/{ => partitions}/ar7part.c (100%)
rename drivers/mtd/{ =>
[RFC PATCH 1/7] mtd: move partition parsers to drivers/mtd/partitions/
For better organization.
Signed-off-by: Brian Norris
---
drivers/mtd/Makefile | 8 +---
drivers/mtd/partitions/Makefile| 7 +++
drivers/mtd/{ => partitions}/afs.c | 0
drivers/mtd/{ => partitions}/ar7part.c | 0
drivers/mtd/{ => partitions}/bcm47xxpart.c | 0
drivers/mtd/{ => partitions}/bcm63xxpart.c | 0
drivers/mtd/{ => partitions}/cmdlinepart.c | 0
drivers/mtd/{ => partitions}/ofpart.c | 0
drivers/mtd/{ => partitions}/redboot.c | 0
9 files changed, 8 insertions(+), 7 deletions(-)
create mode 100644 drivers/mtd/partitions/Makefile
rename drivers/mtd/{ => partitions}/afs.c (100%)
rename drivers/mtd/{ => partitions}/ar7part.c (100%)
rename drivers/mtd/{ => partitions}/bcm47xxpart.c (100%)
rename drivers/mtd/{ => partitions}/bcm63xxpart.c (100%)
rename drivers/mtd/{ => partitions}/cmdlinepart.c (100%)
rename drivers/mtd/{ => partitions}/ofpart.c (100%)
rename drivers/mtd/{ => partitions}/redboot.c (100%)
diff --git a/drivers/mtd/Makefile b/drivers/mtd/Makefile
index 99bb9a1f6e16..1c0cd3b1c7c3 100644
--- a/drivers/mtd/Makefile
+++ b/drivers/mtd/Makefile
@@ -6,13 +6,7 @@
obj-$(CONFIG_MTD) += mtd.o
mtd-y := mtdcore.o mtdsuper.o mtdconcat.o mtdpart.o
mtdchar.o
-obj-$(CONFIG_MTD_OF_PARTS) += ofpart.o
-obj-$(CONFIG_MTD_REDBOOT_PARTS) += redboot.o
-obj-$(CONFIG_MTD_CMDLINE_PARTS) += cmdlinepart.o
-obj-$(CONFIG_MTD_AFS_PARTS)+= afs.o
-obj-$(CONFIG_MTD_AR7_PARTS)+= ar7part.o
-obj-$(CONFIG_MTD_BCM63XX_PARTS)+= bcm63xxpart.o
-obj-$(CONFIG_MTD_BCM47XX_PARTS)+= bcm47xxpart.o
+obj-y += partitions/
# 'Users' - code which presents functionality to userspace.
obj-$(CONFIG_MTD_BLKDEVS) += mtd_blkdevs.o
diff --git a/drivers/mtd/partitions/Makefile b/drivers/mtd/partitions/Makefile
new file mode 100644
index ..89822f2bfa59
--- /dev/null
+++ b/drivers/mtd/partitions/Makefile
@@ -0,0 +1,7 @@
+obj-$(CONFIG_MTD_OF_PARTS) += ofpart.o
+obj-$(CONFIG_MTD_REDBOOT_PARTS) += redboot.o
+obj-$(CONFIG_MTD_CMDLINE_PARTS) += cmdlinepart.o
+obj-$(CONFIG_MTD_AFS_PARTS)+= afs.o
+obj-$(CONFIG_MTD_AR7_PARTS)+= ar7part.o
+obj-$(CONFIG_MTD_BCM63XX_PARTS)+= bcm63xxpart.o
+obj-$(CONFIG_MTD_BCM47XX_PARTS)+= bcm47xxpart.o
diff --git a/drivers/mtd/afs.c b/drivers/mtd/partitions/afs.c
similarity index 100%
rename from drivers/mtd/afs.c
rename to drivers/mtd/partitions/afs.c
diff --git a/drivers/mtd/ar7part.c b/drivers/mtd/partitions/ar7part.c
similarity index 100%
rename from drivers/mtd/ar7part.c
rename to drivers/mtd/partitions/ar7part.c
diff --git a/drivers/mtd/bcm47xxpart.c b/drivers/mtd/partitions/bcm47xxpart.c
similarity index 100%
rename from drivers/mtd/bcm47xxpart.c
rename to drivers/mtd/partitions/bcm47xxpart.c
diff --git a/drivers/mtd/bcm63xxpart.c b/drivers/mtd/partitions/bcm63xxpart.c
similarity index 100%
rename from drivers/mtd/bcm63xxpart.c
rename to drivers/mtd/partitions/bcm63xxpart.c
diff --git a/drivers/mtd/cmdlinepart.c b/drivers/mtd/partitions/cmdlinepart.c
similarity index 100%
rename from drivers/mtd/cmdlinepart.c
rename to drivers/mtd/partitions/cmdlinepart.c
diff --git a/drivers/mtd/ofpart.c b/drivers/mtd/partitions/ofpart.c
similarity index 100%
rename from drivers/mtd/ofpart.c
rename to drivers/mtd/partitions/ofpart.c
diff --git a/drivers/mtd/redboot.c b/drivers/mtd/partitions/redboot.c
similarity index 100%
rename from drivers/mtd/redboot.c
rename to drivers/mtd/partitions/redboot.c
--
2.6.0.rc2.230.g3dd15c0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 5/7] mtd: partitions: factor out "match by name" handling
This code structure is going to be imitated for a match-by-device-node
implementation, so let's factor out a few functions to make this easier.
Signed-off-by: Brian Norris
---
drivers/mtd/mtdpart.c | 67 +++
1 file changed, 52 insertions(+), 15 deletions(-)
diff --git a/drivers/mtd/mtdpart.c b/drivers/mtd/mtdpart.c
index 10bf304027dd..b3100742ddf6 100644
--- a/drivers/mtd/mtdpart.c
+++ b/drivers/mtd/mtdpart.c
@@ -687,23 +687,47 @@ int add_mtd_partitions(struct mtd_info *master,
static DEFINE_SPINLOCK(part_parser_lock);
static LIST_HEAD(part_parsers);
-static struct mtd_part_parser *mtd_part_parser_get(const char *name)
+static bool mtd_part_parser_match_name(struct mtd_part_parser *p,
+ const char *name)
+{
+ return !strcmp(p->name, name);
+}
+
+static struct mtd_part_parser *__mtd_part_parser_get_by_name(const char *name)
{
struct mtd_part_parser *p, *ret = NULL;
spin_lock(_parser_lock);
- list_for_each_entry(p, _parsers, list)
- if (!strcmp(p->name, name) && try_module_get(p->owner)) {
+ list_for_each_entry(p, _parsers, list) {
+ if (mtd_part_parser_match_name(p, name) &&
+ try_module_get(p->owner)) {
ret = p;
break;
}
+ }
spin_unlock(_parser_lock);
return ret;
}
+static struct mtd_part_parser *mtd_part_parser_get_by_name(const char *name)
+{
+ struct mtd_part_parser *p;
+
+ /* Get parser, if already loaded */
+ p = __mtd_part_parser_get_by_name(name);
+ if (p)
+ return p;
+
+ if (request_module("%s", name))
+ return NULL;
+
+ /* Try again */
+ return __mtd_part_parser_get_by_name(name);
+}
+
static inline void mtd_part_parser_put(const struct mtd_part_parser *p)
{
module_put(p->owner);
@@ -752,6 +776,27 @@ static const char * const default_mtd_part_types[] = {
NULL
};
+static int mtd_part_do_parse(struct mtd_part_parser *parser,
+struct mtd_info *master,
+struct mtd_partitions *pparts,
+struct mtd_part_parser_data *data)
+{
+ int ret;
+
+ ret = (*parser->parse_fn)(master, >parts, data);
+ pr_debug("%s: parser %s: %i\n", master->name, parser->name, ret);
+ if (ret <= 0)
+ return ret;
+
+ pr_notice("%d %s partitions found on MTD device %s\n",
+ ret, parser->name, master->name);
+
+ pparts->nr_parts = ret;
+ pparts->parser = parser;
+
+ return ret;
+}
+
/**
* parse_mtd_partitions - parse MTD partitions
* @master: the master partition (describes whole MTD device)
@@ -785,23 +830,15 @@ int parse_mtd_partitions(struct mtd_info *master, const
char *const *types,
for ( ; *types; types++) {
pr_debug("%s: parsing partitions %s\n", master->name, *types);
- parser = mtd_part_parser_get(*types);
- if (!parser && !request_module("%s", *types))
- parser = mtd_part_parser_get(*types);
+ parser = mtd_part_parser_get_by_name(*types);
pr_debug("%s: got parser %s\n", master->name,
parser ? parser->name : NULL);
if (!parser)
continue;
- ret = (*parser->parse_fn)(master, >parts, data);
- pr_debug("%s: parser %s: %i\n",
-master->name, parser->name, ret);
- if (ret > 0) {
- printk(KERN_NOTICE "%d %s partitions found on MTD
device %s\n",
- ret, parser->name, master->name);
- pparts->nr_parts = ret;
- pparts->parser = parser;
+ ret = mtd_part_do_parse(parser, master, pparts, data);
+ /* Found partitions! */
+ if (ret > 0)
return 0;
- }
mtd_part_parser_put(parser);
/*
* Stash the first error we see; only report it if no parser
--
2.6.0.rc2.230.g3dd15c0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 7/7] mtd: partitions: add Google's FMAP partition parser
Cc: David Hendricks
Signed-off-by: Brian Norris
---
drivers/mtd/partitions/Kconfig | 7 ++
drivers/mtd/partitions/Makefile | 1 +
drivers/mtd/partitions/google_fmap.c | 226 +++
3 files changed, 234 insertions(+)
create mode 100644 drivers/mtd/partitions/google_fmap.c
diff --git a/drivers/mtd/partitions/Kconfig b/drivers/mtd/partitions/Kconfig
index 0827d7a8be4e..98783f1d3a36 100644
--- a/drivers/mtd/partitions/Kconfig
+++ b/drivers/mtd/partitions/Kconfig
@@ -129,3 +129,10 @@ config MTD_BCM47XX_PARTS
help
This provides partitions parser for devices based on BCM47xx
boards.
+
+config MTD_GOOGLE_FMAP_PARTS
+ tristate "Google's Flash Map (FMAP) partition support"
+ help
+ This provides partition parsing for Google's flash map layout, used
+ primarily on the boot flash of Chrome OS hardware (e.g., Chromebooks
+ and Chromeboxes).
diff --git a/drivers/mtd/partitions/Makefile b/drivers/mtd/partitions/Makefile
index 89822f2bfa59..ab398c7f4d01 100644
--- a/drivers/mtd/partitions/Makefile
+++ b/drivers/mtd/partitions/Makefile
@@ -5,3 +5,4 @@ obj-$(CONFIG_MTD_AFS_PARTS) += afs.o
obj-$(CONFIG_MTD_AR7_PARTS)+= ar7part.o
obj-$(CONFIG_MTD_BCM63XX_PARTS)+= bcm63xxpart.o
obj-$(CONFIG_MTD_BCM47XX_PARTS)+= bcm47xxpart.o
+obj-$(CONFIG_MTD_GOOGLE_FMAP_PARTS) += google_fmap.o
diff --git a/drivers/mtd/partitions/google_fmap.c
b/drivers/mtd/partitions/google_fmap.c
new file mode 100644
index ..abd10eb65c84
--- /dev/null
+++ b/drivers/mtd/partitions/google_fmap.c
@@ -0,0 +1,226 @@
+/*
+ * Parse Google FMAP partitions
+ *
+ * Author: Brian Norris
+ *
+ * Copyright © 2015 Google, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * See:
+ * https://github.com/dhendrix/flashmap/blob/wiki/FmapSpec.md
+ *
+ * Notes:
+ * - scans only at block boundaries; this is not guaranteed for FMAP (the
+ * Chrome OS tools do a kind of stride search, of decreasing size), but
+ * seems like a decent start
+ * - at worst, scans (beginning of) every block on an unformatted flash
+ * - only validates the "__FMAP__" signature, just like the Chrome OS tools;
+ * however, this seems (theoretically) easy to produce false matches
+ * - major/minor version numbers are currently unused
+ */
+
+#define pr_fmt(fmt)KBUILD_MODNAME ": " fmt
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+static const char fmap_signature[] = "__FMAP__";
+
+struct fmap_layout {
+ uint8_t signature[8]; /* "__FMAP__" (0x5F5F50414D465F5F) */
+ uint8_t ver_major; /* major version number of this
structure */
+ uint8_t ver_minor; /* minor version of this structure */
+ __le64 base;/* physical memory-mapped address of
the flash chip */
+ __le32 size;/* size of the flash chip in bytes */
+ uint8_t name[32]; /* descriptive name of this flash
device, 0 terminated */
+ __le16 nareas; /* number of areas described by areas[]
below */
+ struct fmap_area {
+ __le32 offset; /* offset of this area in the flash
device */
+ __le32 size;/* size of this area in bytes */
+ uint8_t name[32]; /* descriptive name of this area, 0
terminated */
+ __le16 flags; /* flags for this area */
+ } __packed areas[0];
+} __packed;
+
+/* mtd_read() helper */
+static int fmap_mtd_read(struct mtd_info *mtd, loff_t offset, size_t len,
+void *buf)
+{
+ size_t retlen;
+ int ret;
+
+ ret = mtd_read(mtd, offset, len, , buf);
+ if (ret)
+ return ret;
+ if (retlen != len)
+ return -EIO;
+ return 0;
+}
+
+/* Return 0 on no match, non-zero on match */
+static inline int fmap_check_signature(struct fmap_layout *fmap)
+{
+ return !strncmp(fmap->signature, fmap_signature,
+ sizeof(fmap->signature));
+}
+
+static int fmap_parse_block(struct mtd_info *master,
+ const struct mtd_partition **pparts,
+ struct fmap_layout *fmap, size_t maxlen)
+{
+ struct mtd_partition *parts;
+ char *names;
+ int nparts;
+ int ret, i, namelen = 0;
+
+ if (!fmap_check_signature(fmap))
+
[RFC PATCH 3/7] doc: dt: mtd: partition: add on-flash format binding
The platform description (such as the type of partition formats used on
a given flash) should be done independently of the flash driver in use.
However, we can't reasonably have *all* partition parsers run on all
flash (until they find a match), so let's overload the 'partitions'
subnode to support specifying which format(s) to try in the device tree.
Start by supporting Google's (Chrome OS) FMAP structure.
There have been others interested in extending devicetree support to
other parsers, like the bcm47xxpart parser:
http://patchwork.ozlabs.org/patch/475986/
and the AFS (ARM Flash Structure?) parser:
http://patchwork.ozlabs.org/patch/537827/
Signed-off-by: Brian Norris
---
.../devicetree/bindings/mtd/partition.txt | 75 --
1 file changed, 69 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/mtd/partition.txt
b/Documentation/devicetree/bindings/mtd/partition.txt
index 28ae56f5c972..1bf9a7243993 100644
--- a/Documentation/devicetree/bindings/mtd/partition.txt
+++ b/Documentation/devicetree/bindings/mtd/partition.txt
@@ -1,29 +1,56 @@
-Representing flash partitions in devicetree
+Flash partitions in device tree
+===
-Partitions can be represented by sub-nodes of an mtd device. This can be used
+Flash devices can be partitioned into one or more functional ranges (e.g.,
+"boot code", "nvram", and "kernel") in at least two distinct ways:
+
+ (A) a fixed flash layout at production time or
+ (B) with an on-flash partition table, such as RedBoot, that describes the
+ geometry and naming/purpose of each functional region
+
+The former typically requires an operating system to learn about the
+partitioning from some kind of metadata provided by the bootloader/firmware.
+Such partitions can be described using the method in "Section A: Fixed
Partitions".
+
+The latter is somewhat analogous to partition tables used on block devices
+(e.g., MBR or GPT), except that there is less standardization for flash
+devices, and it is not always safe or efficient to attempt to search for all of
+them on every flash device in the system, particularly since many of them allow
+their data structures to be placed anywhere on the flash, and so require
+scanning the entire flash device to find them.
+
+To assist system software in locating these partition tables, we provide a
+binding to describe which partition format(s) may be used on a given flash,
+found below in "Section B: On-Flash Partition Tables".
+
+
+Section A: Fixed Partitions
+---
+
+Partitions can be represented by sub-nodes of a flash device. This can be used
on platforms which have strong conventions about which portions of a flash are
used for what purposes, but which don't use an on-flash partition table such
as RedBoot.
-The partition table should be a subnode of the mtd node and should be named
+The partition table should be a subnode of the flash node and should be named
'partitions'. This node should have the following property:
- compatible : (required) must be "partitions"
Partitions are then defined in subnodes of the partitions node.
-For backwards compatibility partitions as direct subnodes of the mtd device are
+For backwards compatibility partitions as direct subnodes of the flash device
are
supported. This use is discouraged.
NOTE: also for backwards compatibility, direct subnodes that have a compatible
string are not considered partitions, as they may be used for other bindings.
#address-cells & #size-cells must both be present in the partitions subnode of
the
-mtd device. There are two valid values for both:
+flash device. There are two valid values for both:
<1>: for partitions that require a single 32-bit cell to represent their
size/address (aka the value is below 4 GiB)
<2>: for partitions that require two 32-bit cells to represent their
size/address (aka the value is 4 GiB or greater).
Required properties:
-- reg : The partition's offset and size within the mtd bank.
+- reg : The partition's offset and size within the flash
Optional properties:
- label : The label / name for this partition. If omitted, the label is taken
@@ -89,3 +116,39 @@ flash@2 {
};
};
};
+
+
+Section B: On-Flash Partition Tables
+
+
+System designers use a variety of on-flash data structures to describe the
+layout of the flash. Because it's not always optimal for system software to
+scan for every sort of data structure that might be used, one can specify which
+structure(s) might be used on a given flash using the 'partitions' subnode of
+the flash node.
+
+Node name: partitions
+Properties:
+ - compatible: (required) used to define which partition format(s) may be in
+ use on this flash may contain one or more of the strings defined in the
+ following subsections
+
+
+Google's FMAP (Flash MAP)
+#
+
+Often used to describe
[RFC PATCH 6/7] RFC: mtd: partitions: enable of_match_table matching
Partition parsers can now provide an of_match_table to enable
flash<-->parser matching via device tree.
TODO: Doesn't yet work when parser is built as module. I can't just use
request_module() and friends, since OF matches don't tell me the name of
the driver/module. Maybe I can report uevents?
Signed-off-by: Brian Norris
---
drivers/mtd/mtdpart.c | 32
1 file changed, 32 insertions(+)
diff --git a/drivers/mtd/mtdpart.c b/drivers/mtd/mtdpart.c
index b3100742ddf6..91eb2df0bf1e 100644
--- a/drivers/mtd/mtdpart.c
+++ b/drivers/mtd/mtdpart.c
@@ -29,6 +29,7 @@
#include
#include
#include
+#include
#include
#include
@@ -728,6 +729,25 @@ static struct mtd_part_parser
*mtd_part_parser_get_by_name(const char *name)
return __mtd_part_parser_get_by_name(name);
}
+static struct mtd_part_parser *mtd_part_parser_get_by_of(struct mtd_info *mtd)
+{
+ struct mtd_part_parser *p, *ret = NULL;
+
+ spin_lock(_parser_lock);
+
+ list_for_each_entry(p, _parsers, list) {
+ if (of_mtd_match_mtd_parser(mtd, p) &&
+ try_module_get(p->owner)) {
+ ret = p;
+ break;
+ }
+ }
+
+ spin_unlock(_parser_lock);
+
+ return ret;
+}
+
static inline void mtd_part_parser_put(const struct mtd_part_parser *p)
{
module_put(p->owner);
@@ -847,6 +867,18 @@ int parse_mtd_partitions(struct mtd_info *master, const
char *const *types,
if (ret < 0 && !err)
err = ret;
}
+
+ parser = mtd_part_parser_get_by_of(master);
+ if (!parser)
+ return err;
+
+ ret = mtd_part_do_parse(parser, master, pparts, data);
+ if (ret > 0)
+ return 0;
+ mtd_part_parser_put(parser);
+ if (ret < 0 && !err)
+ err = ret;
+
return err;
}
--
2.6.0.rc2.230.g3dd15c0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH TRIVIAL] README: cosmetic fixes
Ping? On Thu, Nov 5, 2015 at 5:26 AM, Diego Viola wrote: > Signed-off-by: Diego Viola > --- > README | 14 +++--- > 1 file changed, 7 insertions(+), 7 deletions(-) > > diff --git a/README b/README > index a326a6a..e1df543 100644 > --- a/README > +++ b/README > @@ -59,7 +59,7 @@ DOCUMENTATION: > INSTALLING the kernel source: > > - If you install the full sources, put the kernel tarball in a > - directory where you have permissions (eg. your home directory) and > + directory where you have permissions (e.g. your home directory) and > unpack it: > > xz -cd linux-4.X.tar.xz | tar xvf - > @@ -125,7 +125,7 @@ BUILD directory for the kernel: > > When compiling the kernel, all output files will per default be > stored together with the kernel source code. > - Using the option "make O=output/dir" allow you to specify an alternate > + Using the option "make O=output/dir" allows you to specify an alternate > place for the output files (including .config). > Example: > > @@ -159,9 +159,9 @@ CONFIGURING the kernel: > > "make nconfig" Enhanced text based color menus. > > - "make xconfig" X windows (Qt) based configuration tool. > + "make xconfig" Qt based configuration tool. > > - "make gconfig" X windows (GTK+) based configuration tool. > + "make gconfig" GTK+ based configuration tool. > > "make oldconfig" Default all questions based on the contents of > your existing ./.config file and asking about > @@ -268,8 +268,8 @@ COMPILING the kernel: > Normally, the kernel build system runs in a fairly quiet mode (but not > totally silent). However, sometimes you or other kernel developers need > to see compile, link, or other commands exactly as they are executed. > - For this, use "verbose" build mode. This is done by inserting > - "V=1" in the "make" command. E.g.: > + For this, use "verbose" build mode. This is done by passing > + "V=1" to the "make" command, e.g. > > make V=1 all > > @@ -300,7 +300,7 @@ COMPILING the kernel: > kernel image file is usually /vmlinuz, /boot/vmlinuz, /bzImage or > /boot/bzImage. To use the new kernel, save a copy of the old image > and copy the new image over the old one. Then, you MUST RERUN LILO > - to update the loading map!! If you don't, you won't be able to boot > + to update the loading map! If you don't, you won't be able to boot > the new kernel image. > > Reinstalling LILO is usually a matter of running /sbin/lilo. > -- > 2.6.2 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] clk: fix codying style of if ... else blocks
Hi Stephen,
No value for this patch, or just you missed this?
2015-11-05 17:59 GMT+09:00 Masahiro Yamada :
> This code is unreadable due to the blank line between if and else
> blocks.
>
> Signed-off-by: Masahiro Yamada
> ---
>
> drivers/clk/clk-mux.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/clk/clk-mux.c b/drivers/clk/clk-mux.c
> index 7129c86..5ed03c8 100644
> --- a/drivers/clk/clk-mux.c
> +++ b/drivers/clk/clk-mux.c
> @@ -71,10 +71,9 @@ static int clk_mux_set_parent(struct clk_hw *hw, u8 index)
> u32 val;
> unsigned long flags = 0;
>
> - if (mux->table)
> + if (mux->table) {
> index = mux->table[index];
> -
> - else {
> + } else {
> if (mux->flags & CLK_MUX_INDEX_BIT)
> index = 1 << index;
>
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-clk" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Best Regards
Masahiro Yamada
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] RTC: RK808: Work around hardware bug on November 31st
Hi, On Fri, Dec 4, 2015 at 8:02 PM, Doug Anderson wrote: > Hi, > > On Fri, Dec 4, 2015 at 5:54 PM, Julius Werner wrote: >>> How would such a hook work? If userspace sees the system suspend on >>> Nov 30th and sees the system wake up on Dec 1st, how does it know >>> whether it should adjust? If it's truly Dec 1st then the kernel will >>> have adjusted the date from Nov 31st to Dec 1st. If it's truly Dec >>> 2nd then the kernel will not have adjusted the date and the RTC will >>> have ticked past Nov 31 and onto Dec 1st. Userspace can't tell. >>> Userspace could try to parse "dmesg" and look to see if the kernel >>> adjusted, but that's ugly. >> >> Good point, I didn't think that through far enough. I guess parsing >> dmesg would be an option, but a pretty ugly one and it wouldn't be >> guaranteed to work if you got an early boot kernel crash after the >> correction. So, really, it seems like there's no reliable way to fix >> this for S5 (unless we start doing crazy things like writing to disk >> from kernel code). > > Hmmm, this made me think. We _do_ have some storage we could use, > depending on how hacky^H^H^H^H^H^H clever we wanted to be. We've got > the alarm registers in the RTC. If we set the alarm to something but > then turn the alarm off then we can use that to store information that > will persist in S5 (as long as the RTC is ticking). What do you > think? I'd have to think of a scheme, but we could certainly use > alarms that are several years in the future (or the past) as a > sentinel, then use the day/month of the last time the kernel saw the > time Actually, it wouldn't even be that terribly hacky Whenever the alarm isn't in use then set it to the next Nov 31st. At boot time, if the alarm is set to Nov 31st and the current date is >= the alarm time then you adjust. At shutdown time always disable the alarm (and set to Nov 31st). To handle resume time you might as well just keep the state somewhere in RAM (see below for why). Whenever you set the alarm for real then presumably you'll need to adjust for Nov 31st and presumably you'll wake up and deal with the alarm, then turn it off. So if you set the alarm for July 4th then (presumably) you'll wake up way before Nov 31st. If you set the alarm for Dec 25th and it's currently Oct 31st then you'll have to adjust in the alarm code and you'll really set it for Dec 24th. As per above, we're in S3 (presumably) or have some persistent kernel state so we know to adjust everything when we wake up (even if we wake up for a non-alarm reason). You'll still get a failure if you set the alarm and then forcibly go into S5 without software knowledge, then stay in S5 long enough to cross over Nov 31st without seeing it (but somehow keep the RTC state). ...but come on, that seems so incredibly rare! :-P Of course, all this hinges on being able to tell whether we've got the bug or not so we know whether to adjust. Assuming that there is no ID register, we could get someone from Rockchip to agree to change _something_ in a way that it's visible to us if they ever fix the bug... -Doug -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
4.4-rc3, KVM, br0 and instant hang
Hi all, I've been trying to upgrade to something newer than 4.2.6 since I want to use LVM Cache on my home NFS fileserver, KVM server, test server, etc. So when it goes down, I lose all my other systems which mount stuff from it. Right now I'm trying to figure out how to use Netconsole to grab a dump of the oops, but it's not working well. But let me describe the situation as I've found it so far. When the system boots up, it first starts with eth0 on the network, then switches to br0 since I have a KVM bridge setup so my VMs can run on the same home network, 192.168.1.0/24 which is pretty standard. The system is an AMD Phenom(tm) II X4 945 Processor, running at a max of 3Ghz, with 16gb of RAM, mpt2 LSI PCI-E 8 port sata controller, on an ASUS motherboard. I can get details if you like. It's an older box, but still runs really well, so why change? Anyway, if I try to boot up anything past the 4.2.6 kernel, the system locks up pretty quickly with an oops message that scrolls off the screen too far. I've got some pictures which I'll attach in a bit, maybe they'll help. So at first I thought it was something to do with bad kworker threads, or SCSI or SATA interactions, but as I tried to configure Netconsole to log to my beaglebone black SBC, I found out that if I compiled and installed 4.4-rc3, started the bridge up (br0), even started KVM, but did NOT start my VMs, the system was stable. And if I didn't start br0, I could start a VM, but the system wouldn't crash. The VM wasn't on the network... but the system didn't crash. So I think I've found a wierd interaction here. My KVMs are both Debian images, with 1-2gb of RAM and 1 CPU each. Nothing strange. My network config is: > cat /etc/network/interfaces # This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5). # The loopback network interface auto lo iface lo inet loopback # Bridge for VMs auto br0 iface br0 inet static address 192.168.1.6 netmask 255.255.255.0 network 192.168.1.0 gateway 192.168.1.254 bridge_ports eth0 bridge_stp on bridge_maxwait 0 bridge_fd 0 # Old setup # auto eth0 # iface eth0 inet static #address 192.168.1.6 #netmask 255.255.255.0 #gateway 192.168.1.254 The currently running system version is: > cat /proc/version Linux version 4.4.0-rc3 (john@quad) (gcc version 4.9.2 (Debian 4.9.2-10) ) #1 SMP Thu Dec 3 12:13:30 EST 2015 And more detailed CPU info > cat /proc/cpuinfo . processor : 3 vendor_id : AuthenticAMD cpu family : 16 model : 4 model name : AMD Phenom(tm) II X4 945 Processor stepping: 3 microcode : 0x1b6 cpu MHz : 800.000 cache size : 512 KB physical id : 0 siblings: 4 core id : 3 cpu cores : 4 apicid : 3 initial apicid : 3 fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt hw_pstate npt lbrv svm_lock nrip_save vmmcall bugs: tlb_mmatch apic_c1e fxsave_leak sysret_ss_attrs bogomips: 6027.13 TLB size: 1024 4K pages clflush size: 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual power management: ts ttp tm stc 100mhzsteps hwpstate Here's my bootup messages, unfortunately I don't have any oops messages. For whatever reason, it kicks in so quickly, that I can't get anything out over the network. I'm going to see if I can stuff another network card in there and use that to send traffic, instead of over the brige. My next step is going to be to try and disable some of the bridge settings, like bridge_stp, bridge_maxwait and bridge_fd to just accept the defaults. I set this up under Debian Wheezy a long time ago and never touched it since. My network config is: quad:~> ifconfig -a br0 Link encap:Ethernet HWaddr 20:cf:30:95:5f:2f inet addr:192.168.1.6 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: 2002:42bd:1ac0:1:22cf:30ff:fe95:5f2f/64 Scope:Global inet6 addr: fe80::22cf:30ff:fe95:5f2f/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:24154 errors:0 dropped:0 overruns:0 frame:0 TX
Re: [net-next v5 0/8] dpaa_eth: Add the Freescale DPAA Ethernet driver
On Thu, Dec 3, 2015 at 6:08 AM, <> wrote: > From: Madalin Bucur > > This patch series adds the Ethernet driver for the Freescale > QorIQ Data Path Acceleration Architecture (DPAA). Please fix your git-send-email configuration, so that your emails are formatted properly. This is the From: header: From: <> -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC][PATCH] devicetree: Add DTS file to support the Nexus7 2013 (flo) device.
This patch adds a dts file to support the Nexus7 2013
device. Its based off of the qcom-apq8064-ifc6410.dts
which is similar hardware.
Also includes some comments and context folded in
from Vinay Simha BN
This is my first DTS submission, so thoughts or feedback
on would be appreciated.
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Ian Campbell
Cc: Kumar Gala
Cc: Russell King
Cc: Vinay Simha BN
Cc: Bjorn Andersson
Cc: devicet...@vger.kernel.org
Signed-off-by: John Stultz
---
arch/arm/boot/dts/Makefile| 1 +
arch/arm/boot/dts/qcom-apq8064-nexus7-flo.dts | 306 ++
arch/arm/boot/dts/qcom-apq8064.dtsi | 2 +
3 files changed, 309 insertions(+)
create mode 100644 arch/arm/boot/dts/qcom-apq8064-nexus7-flo.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 30bbc37..c0f9076a 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -502,6 +502,7 @@ dtb-$(CONFIG_ARCH_PRIMA2) += \
dtb-$(CONFIG_ARCH_QCOM) += \
qcom-apq8064-cm-qs600.dtb \
qcom-apq8064-ifc6410.dtb \
+ qcom-apq8064-nexus7-flo.dtb \
qcom-apq8074-dragonboard.dtb \
qcom-apq8084-ifc6540.dtb \
qcom-apq8084-mtp.dtb \
diff --git a/arch/arm/boot/dts/qcom-apq8064-nexus7-flo.dts
b/arch/arm/boot/dts/qcom-apq8064-nexus7-flo.dts
new file mode 100644
index 000..5183d18
--- /dev/null
+++ b/arch/arm/boot/dts/qcom-apq8064-nexus7-flo.dts
@@ -0,0 +1,306 @@
+#include "qcom-apq8064-v2.0.dtsi"
+#include
+#include
+#include
+/ {
+ model = "Qualcomm APQ8064/Nexus7(flo)";
+ compatible = "qcom,apq8064-nexus7-flo", "qcom,apq8064";
+
+ aliases {
+ serial0 = _serial;
+ serial1 = _serial;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ soc {
+ rpm@108000 {
+ regulators {
+ vdd_l1_l2_l12_l18-supply = <_s4>;
+ vin_lvs1_3_6-supply = <_s4>;
+ vin_lvs4_5_7-supply = <_s4>;
+
+
+ vdd_l24-supply = <_s1>;
+ vdd_l25-supply = <_s1>;
+ vin_lvs2-supply = <_s1>;
+
+ vdd_l26-supply = <_s7>;
+ vdd_l27-supply = <_s7>;
+ vdd_l28-supply = <_s7>;
+
+ vdd_ncp-supply = <_l6>;
+
+ /* Buck SMPS */
+ pm8921_s1: s1 {
+ regulator-always-on;
+ regulator-min-microvolt = <1225000>;
+ regulator-max-microvolt = <1225000>;
+ qcom,switch-mode-frequency = <320>;
+ bias-pull-down;
+ };
+
+ /* msm otg HSUSB_VDDCX */
+ pm8921_s3: s3 {
+ regulator-min-microvolt = <50>;
+ regulator-max-microvolt = <115>;
+ qcom,switch-mode-frequency = <480>;
+ };
+
+ /*
+* msm_sdcc.1-sdc-vdd_io
+* tabla2x-slim-CDC_VDDA_RX
+* tabla2x-slim-CDC_VDDA_TX
+* tabla2x-slim-CDC_VDD_CP
+* tabla2x-slim-VDDIO_CDC
+*/
+ pm8921_s4: s4 {
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ qcom,switch-mode-frequency = <320>;
+ regulator-always-on;
+ };
+
+ pm8921_s7: s7 {
+ regulator-min-microvolt = <130>;
+ regulator-max-microvolt = <130>;
+ qcom,switch-mode-frequency = <320>;
+ };
+
+ /* mipi_dsi.1-dsi1_pll_vdda */
+ pm8921_l2: l2 {
+ regulator-min-microvolt = <120>;
+ regulator-max-microvolt = <120>;
+ };
+
+ /* msm_otg-HSUSB_3p3 */
+ pm8921_l3: l3 {
+ regulator-min-microvolt = <3075000>;
+ regulator-max-microvolt
Re: [PATCH V2 5/6] cpufreq: governor: replace per-cpu delayed work with timers
On 05-12-15, 03:14, Rafael J. Wysocki wrote: > Well, almost, but not quite yet, because now the question is what prevents > gov_cancel_work() from racing with dbs_work_handler(). > > If you can guarantee that they'll never run in parallel with each other, They can run in parallel and that's how we fix it now: - raising skip_work to 2 makes sure that no new timer-handler can queue a new work. - After raising the value of skip_work to 2, we do cancel_work_sync(). Which will make sure that the work-handler has finished after cancel_work_sync() has returned. - At this point of time we are sure that the works and their handlers are completely killed. - All that is left is to kill all timer-handler (which might have gotten queued from the work handler, before it finished). - And we do that with gov_cancel_timers(). - And then we are in safe state, where we are guaranteed that there are no leftovers. > you probably don't need the whole counter dance. Otherwise, > dbs_work_handler() > should decrement the counter under the spinlock after all I suppose. Its not required because we don't have any race around that decrement operation. -- viresh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [TESTPATCH v2] xhci: fix usb2 resume timing and races.
On 1 December 2015 at 16:26, Mathias Nyman
wrote:
> usb2 ports need to signal resume for 20ms before moving to U0 state.
> Both device and host can initiate resume.
>
> On host initated resume port is set to resume state, sleep 20ms,
> and finally set port to U0 state.
>
> On device initated resume a port status interrupt with a port in resume
> state in issued. The interrupt handler tags a resume_done[port]
> timestamp with current time + 20ms, and kick roothub timer.
> Root hub timer requests for port status, finds the port in resume state,
> checks if resume_done[port] timestamp passed, and set port to U0 state.
>
> There are a few issues with this approach,
> 1. A host initated resume will also generate a resume event, the event
>handler will find the port in resume state, believe it's a device
>initated and act accordingly.
>
> 2. A port status request might cut the 20ms resume signalling short if a
>get_port_status request is handled during the 20ms host resume.
>The port will be found in resume state. The timestamp is not set leading
>to time_after_eq(jiffoes, timestamp) returning true, as timestamp = 0.
>get_port_status will proceed with moving the port to U0.
>
> 3. If an error, or anything else happends to the port during device
>initated 20ms resume signalling it will leave all device resume
>parameters hanging uncleared preventing further resume.
>
> Fix this by using the existing resuming_ports bitfield to indicate if
> resume signalling timing is taken care of.
> Also check if the resume_done[port] is set before using it in time
> comparison. Also clear out any resume signalling related variables if port
> is not in U0 or Resume state.
>
> v2. fix parentheses when checking for uncleared resume variables.
> we want: if ((unclear1 OR unclear2 ) AND !in_resume AND !in_U3) { .. }
>
> Signed-off-by: Mathias Nyman
Excellent; this correctly prevents the cyclic chain of suspend
attempts, resolving the issue.
Tested-by: Daniel J Blueman
Thanks Mathias!
Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] RTC: RK808: Work around hardware bug on November 31st
Hi, On Fri, Dec 4, 2015 at 5:54 PM, Julius Werner wrote: >> How would such a hook work? If userspace sees the system suspend on >> Nov 30th and sees the system wake up on Dec 1st, how does it know >> whether it should adjust? If it's truly Dec 1st then the kernel will >> have adjusted the date from Nov 31st to Dec 1st. If it's truly Dec >> 2nd then the kernel will not have adjusted the date and the RTC will >> have ticked past Nov 31 and onto Dec 1st. Userspace can't tell. >> Userspace could try to parse "dmesg" and look to see if the kernel >> adjusted, but that's ugly. > > Good point, I didn't think that through far enough. I guess parsing > dmesg would be an option, but a pretty ugly one and it wouldn't be > guaranteed to work if you got an early boot kernel crash after the > correction. So, really, it seems like there's no reliable way to fix > this for S5 (unless we start doing crazy things like writing to disk > from kernel code). Hmmm, this made me think. We _do_ have some storage we could use, depending on how hacky^H^H^H^H^H^H clever we wanted to be. We've got the alarm registers in the RTC. If we set the alarm to something but then turn the alarm off then we can use that to store information that will persist in S5 (as long as the RTC is ticking). What do you think? I'd have to think of a scheme, but we could certainly use alarms that are several years in the future (or the past) as a sentinel, then use the day/month of the last time the kernel saw the time ...and speaking of the alarm, we also need to handle the RTC bug for setting the alarm. If you set an alarm for 10 seconds after Nov 30, you need to set the alarm for Nov 31st or it will actually fire 10 seconds + 1 day later. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/10] cpufreq: add generic cpufreq driver support for Exynos542x/5800 platforms
On 04-12-15, 18:30, Bartlomiej Zolnierkiewicz wrote: > Hi, > > This patch series adds generic arm_big_little_dt cpufreq driver > support for Exynos542x/5800 (using the new CPU clock type which > allows it). It also: > - enhances arm_big_little[_dt] driver with CPU cluster regulator > support > - adds CPU clock configuration data and CPU operating points > setup for Exynos542x/5800 > - adds CPU cluster regulator supplies for Exynos542x/5800 boards > > This patch series has been tested on Exynos5422 based ODROID-XU3 > Lite board. > > Please note that this is not a final version of the patchset. > I just wanted to push out current work-in-progress patches that > integrate changes from Anand, Ben and me. What's going on guys, Ben tried exactly same thing few days back: http://marc.info/?l=linux-kernel=144909193925508=2 And the comments given there applies to you as well. -- viresh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] usb: xhci-mtk: fix AHB bus hang up caused by roothubs polling
when ip fails to enter sleep mode, register access protection will
be disabled, at the same time if all clocks are disabled, access
register will hang up AHB bus.
the common case causes ip sleep failure is that after all ports
enter U3 but before ip enters sleep mode, a port receives a resume
signal('K'). this will happens when such as clicks mouse to try to
do remote-wakeup to stop system enter suspend.
so stop polling root hubs to avoid access xHCI register on bus
suspend, and restart it when bus resumes.
Signed-off-by: Chunfeng Yun
---
drivers/usb/host/xhci-mtk.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c
index c9ab6a4..9532f5a 100644
--- a/drivers/usb/host/xhci-mtk.c
+++ b/drivers/usb/host/xhci-mtk.c
@@ -696,9 +696,24 @@ static int xhci_mtk_remove(struct platform_device *dev)
}
#ifdef CONFIG_PM_SLEEP
+/*
+ * if ip sleep fails, and all clocks are disabled, access register will hang
+ * AHB bus, so stop polling roothubs to avoid regs access on bus suspend.
+ * and no need to check whether ip sleep failed or not; this will cause SPM
+ * to wake up system immediately after system suspend complete if ip sleep
+ * fails, it is what we wanted.
+ */
static int xhci_mtk_suspend(struct device *dev)
{
struct xhci_hcd_mtk *mtk = dev_get_drvdata(dev);
+ struct usb_hcd *hcd = mtk->hcd;
+ struct xhci_hcd *xhci = hcd_to_xhci(hcd);
+
+ xhci_dbg(xhci, "%s: stop port polling\n", __func__);
+ clear_bit(HCD_FLAG_POLL_RH, >flags);
+ del_timer_sync(>rh_timer);
+ clear_bit(HCD_FLAG_POLL_RH, >shared_hcd->flags);
+ del_timer_sync(>shared_hcd->rh_timer);
xhci_mtk_host_disable(mtk);
xhci_mtk_phy_power_off(mtk);
@@ -710,11 +725,19 @@ static int xhci_mtk_suspend(struct device *dev)
static int xhci_mtk_resume(struct device *dev)
{
struct xhci_hcd_mtk *mtk = dev_get_drvdata(dev);
+ struct usb_hcd *hcd = mtk->hcd;
+ struct xhci_hcd *xhci = hcd_to_xhci(hcd);
usb_wakeup_disable(mtk);
xhci_mtk_clks_enable(mtk);
xhci_mtk_phy_power_on(mtk);
xhci_mtk_host_enable(mtk);
+
+ xhci_dbg(xhci, "%s: restart port polling\n", __func__);
+ set_bit(HCD_FLAG_POLL_RH, >flags);
+ usb_hcd_poll_rh_status(hcd);
+ set_bit(HCD_FLAG_POLL_RH, >shared_hcd->flags);
+ usb_hcd_poll_rh_status(xhci->shared_hcd);
return 0;
}
--
1.8.1.1.dirty
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] usb: xhci-mtk: fix AHB bus hang up caused by roothubs polling
Hi,
On Fri, 2015-12-04 at 16:24 +0300, Sergei Shtylyov wrote:
> Hello.
>
> Sorry for the grammar nitpicking but since it's in the comments, I felt
> the necessity to comment.
>
> On 12/4/2015 5:40 AM, Chunfeng Yun wrote:
>
> > when ip fail to enter sleep mode, register access protection will
>
> Fails.
>
> > be disabed, at the same time if all clocks are disabled, access
> ^^^ disabled
>
> > register will hang up AHB bus.
> > the common case causes ip sleep fail is that after all ports enter
>
> Failure.
>
> > U3 but before ip enters sleep mode, a port receives a resume
> > signal('K'). this will happens when such as clicks mouse to try to
> > do remote wakeup to stop system enter suspend.
>
> Wake up.
>
> > so stop polling roothubs to avoid access xHCI register on bus
>
> Root hubs. Accessing.
>
> > suspend, and restart it when bus resume.
>
> Resumes. Or "is resumed", maybe?
>
> > Signed-off-by: Chunfeng Yun
> > ---
> > drivers/usb/host/xhci-mtk.c | 23 +++
> > 1 file changed, 23 insertions(+)
> >
> > diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c
> > index c9ab6a4..38635fb 100644
> > --- a/drivers/usb/host/xhci-mtk.c
> > +++ b/drivers/usb/host/xhci-mtk.c
> > @@ -696,9 +696,24 @@ static int xhci_mtk_remove(struct platform_device *dev)
> > }
> >
> > #ifdef CONFIG_PM_SLEEP
> > +/*
> > + * if ip sleep fail, and all clocks are disabled, access register will hang
>
> Fails.
>
> > + * AHB bus, so stop poll roothubs to avoid regs access on bus suspend.
>
> Polling.
>
> > + * and no need to check whether ip sleep fail or not; this will cause SPM
> > to
>
> Failed.
>
> > + * wakeup system immediately after system suspend complete if ip sleep
>
> Wake up.
>
> > + * fail, it is what we wanted.
>
> Fails.
>
I do need to pay more attention to the grammar from now on.
Thanks a lot
> > + */
> [...]
>
> MBR, Sergei
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 4/5] clk: shmobile: Add new CPG/MSSR driver core
Hi Geert,
Thank you for the patch.
On Thursday 12 November 2015 16:54:45 Geert Uytterhoeven wrote:
> Add the common core for the new Renesas Clock Pulse Generator / Module
> Standby and Software Reset driver.
>
> Signed-off-by: Geert Uytterhoeven
> ---
> v6:
> - No changes,
>
> v5:
> - Convert from CLK_OF_DECLARE() to a real platform_driver, initialized
> using platform_driver_probe() from subsys_initcall().
> Note that arch_initcall() would be OK for arm32, but not for arm64:
> - arm32 calls of_platform_populate() from arch_initcall(),
> - arm64 calls of_platform_populate() from arch_initcall_sync().
> - Implement handling of core clocks that are suitable for power
> management (not needed for R-Car, but useful for SH-Mobile AG5 and
> R-Mobile APE6),
> - Add cpg_mssr_info.init(), as initialization is now done from the
> core driver,
> - Move conversion from Module Clock numbers to IDs from run time (C
> code) to compile time (CPP macros for filling in tables),
> - Unify some code to handle CLK_TYPE_IN and CLK_TYPE_FF,
> - Rename from clk-cpg-mssr to renesas-cpg-mssr,
> - Add include guards to clk-cpg-mssr.h,
> - Improve struct documentation,
> - Clean up debugging code,
> - Drop RFC state,
>
> v4:
> - New.
> ---
> drivers/clk/shmobile/renesas-cpg-mssr.c | 587 +
> drivers/clk/shmobile/renesas-cpg-mssr.h | 131 +++
> 2 files changed, 718 insertions(+)
> create mode 100644 drivers/clk/shmobile/renesas-cpg-mssr.c
> create mode 100644 drivers/clk/shmobile/renesas-cpg-mssr.h
>
> diff --git a/drivers/clk/shmobile/renesas-cpg-mssr.c
> b/drivers/clk/shmobile/renesas-cpg-mssr.c new file mode 100644
> index ..e4382ba4e1e31aca
> --- /dev/null
> +++ b/drivers/clk/shmobile/renesas-cpg-mssr.c
[snip]
> +static inline int cpg_mssr_add_clk_domain(struct device *dev,
> + const unsigned int *core_pm_clks,
> + unsigned int num_core_pm_clks) {}
The function is missing a return statement.
> +#endif /* !CONFIG_PM_GENERIC_DOMAINS_OF */
[snip]
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm/memcontrol.c: use list_{first,next}_entry
On Thu, Dec 03, 2015 at 05:27:18PM +0100, Michal Hocko wrote:
> On Thu 03-12-15 22:16:55, Geliang Tang wrote:
> > To make the intention clearer, use list_{first,next}_entry instead
> > of list_entry.
>
> Does this really help readability? This function simply uncharges the
> given list of pages. Why cannot we simply use list_for_each_entry
> instead...
I have tested it, list_for_each_entry can't work. Dose it mean that my
patch is OK? Or please give me some other advices.
Thanks.
- Geliang
> > Signed-off-by: Geliang Tang
> > ---
> > mm/memcontrol.c | 9 +++--
> > 1 file changed, 3 insertions(+), 6 deletions(-)
> >
> > diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> > index 79a29d5..a6301ea 100644
> > --- a/mm/memcontrol.c
> > +++ b/mm/memcontrol.c
> > @@ -5395,16 +5395,12 @@ static void uncharge_list(struct list_head
> > *page_list)
> > unsigned long nr_file = 0;
> > unsigned long nr_huge = 0;
> > unsigned long pgpgout = 0;
> > - struct list_head *next;
> > struct page *page;
> >
> > - next = page_list->next;
> > + page = list_first_entry(page_list, struct page, lru);
> > do {
> > unsigned int nr_pages = 1;
> >
> > - page = list_entry(next, struct page, lru);
> > - next = page->lru.next;
> > -
> > VM_BUG_ON_PAGE(PageLRU(page), page);
> > VM_BUG_ON_PAGE(page_count(page), page);
> >
> > @@ -5440,7 +5436,8 @@ static void uncharge_list(struct list_head *page_list)
> > page->mem_cgroup = NULL;
> >
> > pgpgout++;
> > - } while (next != page_list);
> > + } while (!list_is_last(>lru, page_list) &&
> > +(page = list_next_entry(page, lru)));
> >
> > if (memcg)
> > uncharge_batch(memcg, pgpgout, nr_anon, nr_file,
> > --
> > 2.5.0
> >
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] mm/slab.c: use list_{empty_careful,last_entry} in drain_freelist
On Fri, Dec 04, 2015 at 10:16:38AM -0600, Christoph Lameter wrote:
> On Fri, 4 Dec 2015, Geliang Tang wrote:
>
> > On Thu, Dec 03, 2015 at 08:53:21AM -0600, Christoph Lameter wrote:
> > > On Thu, 3 Dec 2015, Geliang Tang wrote:
> > >
> > > > while (nr_freed < tofree && !list_empty(>slabs_free)) {
> > > >
> > > > spin_lock_irq(>list_lock);
> > > > - p = n->slabs_free.prev;
> > > > - if (p == >slabs_free) {
> > > > + if (list_empty_careful(>slabs_free)) {
> > >
> > > We have taken the lock. Why do we need to be "careful"? list_empty()
> > > shoudl work right?
> >
> > Yes. list_empty() is OK.
> >
> > >
> > > > spin_unlock_irq(>list_lock);
> > > > goto out;
> > > > }
> > > >
> > > > - page = list_entry(p, struct page, lru);
> > > > + page = list_last_entry(>slabs_free, struct page,
> > > > lru);
> > >
> > > last???
> >
> > The original code delete the page from the tail of slabs_free list.
>
> Maybe make the code clearer by using another method to get the page
> pointer?
>
> > >
> > > Would the the other new function that returns NULL on the empty list or
> > > the pointer not be useful here too and save some code?
> >
> > Sorry, I don't really understand what do you mean. Can you please specify
> > it a little bit?
>
> I take that back. list_empty is the best choice here.
If we use list_empty(), there will be two list_empty() in the code:
while (nr_freed < tofree && !list_empty(>slabs_free)) {
spin_lock_irq(>list_lock);
if (list_empty(>slabs_free)) {
spin_unlock_irq(>list_lock);
goto out;
}
page = list_last_entry(>slabs_free, struct page, lru);
list_del(>lru);
spin_unlock_irq(>list_lock);
}
Or can we drop the first list_empty() like this? It will function the same as
the above code.
while (nr_freed < tofree) {
spin_lock_irq(>list_lock);
if (list_empty(>slabs_free)) {
spin_unlock_irq(>list_lock);
goto out;
}
page = list_last_entry(>slabs_free, struct page, lru);
list_del(>lru);
spin_unlock_irq(>list_lock);
}
Please let me know which one is better?
Thanks.
- Geliang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 76/71] ncr5380: Enable PDMA for DTC chips
Hi Finn,
On Sat, Dec 5, 2015 at 1:12 PM, Finn Thain wrote:
>
> On Sat, 5 Dec 2015, Julian Calaby wrote:
>
>> Hi Finn,
>>
>> On Fri, Dec 4, 2015 at 7:38 PM, Finn Thain
>> wrote:
>> >
>> > On Fri, 4 Dec 2015, Julian Calaby wrote:
>> >
>> >> > - if (overrides[current_override].board ==
>> >> > BOARD_NCR53C400A) {
>> >> > + if (overrides[current_override].board ==
>> >> > BOARD_NCR53C400A ||
>> >> > + overrides[current_override].board ==
>> >> > BOARD_DTC3181E) {
>> >>
>> >> These if statements are starting to get a bit long, would it make
>> >> sense to replace them with a flag or equivalent?
>> >
>> > To what end? Shorter lines? As in,
>>
>> Pretty much, each expression is quite long and they seem to be growing
>> fairly rapidly as you and Ondrej discover similar boards.
>
> Each BOARD_* macro actually refers to a whole category of devices. No new
> boards, devices or categories of devices have been discovered.
>
> Ondrej is enabling and/or fixing PDMA functionality for three existing
> device categories, for which the driver already has a nominally compatible
> PDMA implementation.
I meant discovering boards which are similar.
Either way, I'm not sure it matters that much.
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 76/71] ncr5380: Enable PDMA for DTC chips
On Sat, 5 Dec 2015, Julian Calaby wrote:
> Hi Finn,
>
> On Fri, Dec 4, 2015 at 7:38 PM, Finn Thain wrote:
> >
> > On Fri, 4 Dec 2015, Julian Calaby wrote:
> >
> >> > - if (overrides[current_override].board ==
> >> > BOARD_NCR53C400A) {
> >> > + if (overrides[current_override].board ==
> >> > BOARD_NCR53C400A ||
> >> > + overrides[current_override].board == BOARD_DTC3181E)
> >> > {
> >>
> >> These if statements are starting to get a bit long, would it make
> >> sense to replace them with a flag or equivalent?
> >
> > To what end? Shorter lines? As in,
>
> Pretty much, each expression is quite long and they seem to be growing
> fairly rapidly as you and Ondrej discover similar boards.
Each BOARD_* macro actually refers to a whole category of devices. No new
boards, devices or categories of devices have been discovered.
Ondrej is enabling and/or fixing PDMA functionality for three existing
device categories, for which the driver already has a nominally compatible
PDMA implementation.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 5/7] PCI: irqdomain: Look up IRQ domain by fwnode_handle
Hi Jake,
[auto build test ERROR on pci/next]
[also build test ERROR on v4.4-rc3 next-20151203]
url:
https://github.com/0day-ci/linux/commits/jakeo-microsoft-com/PCI-hv-New-paravirtual-PCI-front-end-for-Hyper-V-VMs/20151205-083943
base: https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git next
config: arm64-defconfig (attached as .config)
reproduce:
wget
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
-O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm64
All error/warnings (new ones prefixed by >>):
drivers/pci/probe.c: In function 'pci_host_bridge_msi_domain':
>> drivers/pci/probe.c:682:10: error: implicit declaration of function
>> 'pci_root_bus_fwnode' [-Werror=implicit-function-declaration]
struct fwnode_handle *fwnode = pci_root_bus_fwnode(bus);
^
>> drivers/pci/probe.c:682:34: warning: initialization makes pointer from
>> integer without a cast
struct fwnode_handle *fwnode = pci_root_bus_fwnode(bus);
^
>> drivers/pci/probe.c:685:4: error: implicit declaration of function
>> 'irq_find_matching_fwnode' [-Werror=implicit-function-declaration]
d = irq_find_matching_fwnode(fwnode,
^
>> drivers/pci/probe.c:686:12: error: 'DOMAIN_BUS_PCI_MSI' undeclared (first
>> use in this function)
DOMAIN_BUS_PCI_MSI);
^
drivers/pci/probe.c:686:12: note: each undeclared identifier is reported
only once for each function it appears in
cc1: some warnings being treated as errors
vim +/pci_root_bus_fwnode +682 drivers/pci/probe.c
676 #ifdef CONFIG_PCI_MSI_IRQ_DOMAIN
677 /*
678 * If no IRQ domain was found via the OF tree, try looking it up
679 * directly through the fwnode_handle.
680 */
681 if (!d) {
> 682 struct fwnode_handle *fwnode = pci_root_bus_fwnode(bus);
683
684 if (fwnode)
> 685 d = irq_find_matching_fwnode(fwnode,
> 686
> DOMAIN_BUS_PCI_MSI);
687 }
688 #endif
689
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: Binary data
Re: [PATCH tip/core/rcu 1/8] documentation: Record RCU requirements
On Fri, Dec 04, 2015 at 04:38:42PM -0800, Josh Triplett wrote: > On Fri, Dec 04, 2015 at 04:33:32PM -0800, Paul E. McKenney wrote: > > On Fri, Dec 04, 2015 at 04:07:19PM -0800, Josh Triplett wrote: > > > On Fri, Dec 04, 2015 at 03:50:19PM -0800, Paul E. McKenney wrote: > > > > This commit adds RCU requirements as published in a 2015 LWN series. > > > > Bringing these requirements in-tree allows them to be updated as changes > > > > are discovered. > > > > > > > > Signed-off-by: Paul E. McKenney > > > > --- > > > > .../RCU/Design/Requirements/2013-08-is-it-dead.png | Bin 0 -> 100825 > > > > bytes > > > > .../Design/Requirements/GPpartitionReaders1.svg| 374 +++ > > > > .../RCU/Design/Requirements/RCUApplicability.svg | 237 ++ > > > > .../Design/Requirements/ReadersPartitionGP1.svg| 639 + > > > > .../RCU/Design/Requirements/Requirements.html | 2799 > > > > > > > > .../RCU/Design/Requirements/Requirements.htmlx | 2643 > > > > ++ > > > > Documentation/RCU/Design/htmlqqz.sh| 108 + > > > > 7 files changed, 6800 insertions(+) > > > > create mode 100644 > > > > Documentation/RCU/Design/Requirements/2013-08-is-it-dead.png > > > > create mode 100644 > > > > Documentation/RCU/Design/Requirements/GPpartitionReaders1.svg > > > > create mode 100644 > > > > Documentation/RCU/Design/Requirements/RCUApplicability.svg > > > > create mode 100644 > > > > Documentation/RCU/Design/Requirements/ReadersPartitionGP1.svg > > > > create mode 100644 > > > > Documentation/RCU/Design/Requirements/Requirements.html > > > > create mode 100644 > > > > Documentation/RCU/Design/Requirements/Requirements.htmlx > > > > > > If Requirements.html is machine-generated and shouldn't be hand-edited, > > > and it can be generated without any special tools, then I don't think it > > > should be committed in the tree; I'd suggest putting it in .gitignore > > > and generating it from one of the various "make docs" invocations. > > > > I considered doing that, but then decided that it is nice for people to > > be able train their browser directly on the file without having to know > > what scripts to run. > > > > Hmmm... I suppose I could construct a Makefile that dealt with that > > though... I will give this some thought, and if it looks good, I will > > add the Makefiles and "git rm" the .htmlx files. > > > > > Alternatively, if you want to make sure a usable version is in-tree, you > > > could make the script reversible (easy enough to do if the compiled > > > version includes some marker comments or similar), and then tell people > > > to run it in reverse mode, edit, and run it in forward mode. Then you > > > don't need the .htmlx file at all. :) > > > > Decades ago, back when I (against all evidence) believed I could > > consistently avoid making stupid mistakes, you might have been able to > > convince me that this was a good idea. ;-) > > Because you don't want to complicate the script, or because you don't > want to accidentally edit the wrong version? (Note that a carefully > written script would mean it doesn't matter which version you edit.) I prefer the simpler script. > A third alternative would be to include the answers inline right after > the questions, and optionally add a tiny bit of JavaScript that hides > them by default and lets you click to show the answer. :) That does have some advantages. I would welcome a patch that added the JavaScript. Thanx, Paul -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] RTC: RK808: Work around hardware bug on November 31st
> How would such a hook work? If userspace sees the system suspend on > Nov 30th and sees the system wake up on Dec 1st, how does it know > whether it should adjust? If it's truly Dec 1st then the kernel will > have adjusted the date from Nov 31st to Dec 1st. If it's truly Dec > 2nd then the kernel will not have adjusted the date and the RTC will > have ticked past Nov 31 and onto Dec 1st. Userspace can't tell. > Userspace could try to parse "dmesg" and look to see if the kernel > adjusted, but that's ugly. Good point, I didn't think that through far enough. I guess parsing dmesg would be an option, but a pretty ugly one and it wouldn't be guaranteed to work if you got an early boot kernel crash after the correction. So, really, it seems like there's no reliable way to fix this for S5 (unless we start doing crazy things like writing to disk from kernel code). -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH tip/core/rcu 1/8] documentation: Record RCU requirements
On Fri, Dec 04, 2015 at 04:34:43PM -0800, Josh Triplett wrote: > The content of the document seems fine; a few comments below on > meta-issues. > > On Fri, Dec 04, 2015 at 03:50:19PM -0800, Paul E. McKenney wrote: > > --- /dev/null > > +++ b/Documentation/RCU/Design/Requirements/Requirements.html > > @@ -0,0 +1,2799 @@ > > + > > + > > + > +"http://www.w3.org/TR/html4/loose.dtd;> > > Nit: these days, this should just be: > Will making this change mean that https://validator.w3.org/ will then require me to make a huge quantity of other changes? > > + > > +A Tour Through RCU's Requirements [LWN.net] > > + > > Is there a good reason to not use charset=utf-8 here? Beats me. Cargo-culted that one. ;-) > > + > > +A Tour Through RCU's Requirements > > + > > +Copyright IBM Corporation, 2015 > > If you're aiming for a properly formatted copyright notice, the year > typically comes first, followed by the copyright holder. That said, > your corporate guidelines presumably have a specific format; is this > that format? Indeed it is. Between you and IBM Legal, I unfortunately must follow IBM Legal's advice. ;-) > > +Author: Paul E.McKenney > > +The initial version of this document appeared in the > > +http://lwn.net/;>LWN articles > > +http://lwn.net/Articles/652156/;>here, > > +http://lwn.net/Articles/652677/;>here, and > > +http://lwn.net/Articles/653326/;>here. > > s/http/https/g Will change. > > + > > +All that aside, here are the categories of currently known RCU > > requirements: > > + > > + > > + > > + > > Anchors don't typically have spaces in them. This may work in some > browsers, but it doesn't validate. You should either use %20 or > (better) use a '-'. It did when I validated it via https://validator.w3.org/. Which is why I questioned your changes to the doctype directive. Alternatively, what are you using to validate this? > > + > > +This is followed by a summary, > > +which is in turn followed by the inevitable > > +answers to the quick quizzes. > > (Note: when editing anchors, don't forget to handle the target of this > in the generation script.) Good point! > > + > > +This scenario resembles one of the first uses of RCU in > > +http://en.wikipedia.org/wiki/DYNIX;>DYNIX/ptx, > > s/http/https/ Will change globally. > > + > > +However, this temptation must be resisted because there are a > > +surprisingly large number of ways that the compiler > > +(to say nothing of > > +http://www.openvms.compaq.com/wizard/wiz_2637.html;>DEC Alpha > > CPUs) > > This link sadly doesn't seem to work anymore; it redirects to HP's > general page on OpenVMS, not a copy of that specific article.o > Use this instead, assuming no current live version exists: > https://web.archive.org/web/20120720095054/http://www.openvms.compaq.com/wizard/wiz_2637.html Good catch! Its new home is http://h71000.www7.hp.com/wizard/wiz_2637.html. > > + It is also easy to forget to use rcu_assign_pointer() > > + and rcu_dereference(), perhaps (incorrectly) > > + substituting a simple assignment. > > + To catch this sort of error, a given RCU-protected pointer may be > > + tagged with __rcu, after which running sparse > > + with CONFIG_SPARSE_RCU_POINTER=y will complain > > + about simple-assignment accesses to that pointer. > > + Arnd Bergmann made me aware of this requirement, and also > > + supplied the needed > > + http://lwn.net/Articles/376011/;>patch series. > > s/http/https/ > > > + Open-coded use of rcu_assign_pointer() and > > + rcu_dereference() to create typical linked > > + data structures can be surprisingly error-prone. > > + Therefore, RCU-protected > > + http://lwn.net/Articles/609973/#RCU List APIs">linked lists > > s/http/https/ Will fix these. > > + > > +This all should be quite obvious, but the fact remains that > > +Linus Torvalds recently had to > > +http://marc.info/?l=linux-kernelm=142905739823385;>remind > > +me of this requirement. > > I'd suggest using the lkml.kernel.org redirector for this link, along > with a Message-Id. > > > + > > +The name notwithstanding, some Linux-kernel architectures > > +can have nested NMIs, which RCU must handle correctly. > > +Andy Lutomirski > > +https://lkml.org/lkml/2014/11/21/642;>surprised me > > +with this requirement; > > +he also kindly surprised me with > > +https://lkml.org/lkml/2014/11/22/1;>an algorithm > > +that meets this requirement. > > These links should both use lkml.kernel.org as well. Doubly important > because lkml.org is often down or has broken messages in its archive. Good point, will look into finding the Message-IDs... > > + > > +RCU therefore provides > > +http://lwn.net/Articles/217484/;>rcu_barrier(), > > s/http/https/ > > > + > > +This pair of mutual scheduler-RCU requirements came as a > > +http://lwn.net/Articles/453002/;>complete surprise. > > s/http/https/ > > > +This requirement made its presence known after users made it > >
[PATCH v3] MAINTAINERS: add myself as Renesas Ethernet drivers reviewer
Add myself as a reviewer for the Renesas Ethernet drivers -- hopefully I won't miss the buggy patches anymore. :-) Signed-off-by: Sergei Shtylyov --- The patch is against DaveM's 'net.git' repo. Changes in version 3: - removed the status entry; Changes in version 2: - removed garbage from the changelog. MAINTAINERS |7 +++ 1 file changed, 7 insertions(+) Index: net/MAINTAINERS === --- net.orig/MAINTAINERS +++ net/MAINTAINERS @@ -8929,6 +8929,13 @@ F: drivers/rpmsg/ F: Documentation/rpmsg.txt F: include/linux/rpmsg.h +RENESAS ETHERNET DRIVERS +R: Sergei Shtylyov +L: net...@vger.kernel.org +L: linux...@vger.kernel.org +F: drivers/net/ethernet/renesas/ +F: include/linux/sh_eth.h + RESET CONTROLLER FRAMEWORK M: Philipp Zabel S: Maintained -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ARM EFI stub and the EfiPersistentMemory type
Hi,
On Fri, Dec 04, 2015 at 09:51:22PM +, Elliott, Robert (Persistent Memory)
wrote:
> drivers/firmware/efi/libstub/efi-stub-helper.c get_dram_base()
> parses the UEFI memory map, but just looks at the EFI_MEMORY_WB
> attribute while searching for the base memory address,
> not the type:
>
> unsigned long get_dram_base(efi_system_table_t *sys_table_arg) {
> ...
> for_each_efi_memory_desc(, md)
> if (md->attribute & EFI_MEMORY_WB)
> if (membase > md->phys_addr)
> membase = md->phys_addr;
Checking the WB flag rather than the type was deliberate (though not
necessarily sufficient). The background here is:
(a) The arm64 kernel maps memory as Normal Cacheable, Outer Write-back
non-transient, Inner Write-back non-transient. This matches EFI_MEMORY_WB.
(b) When creating page tables, the arm64 kernel will map memory in 64KiB or
2MiB chunks, depending on the kernel's page size.
(c) To be able to use as much memory as possible, the kernel needs to be loaded
TEXT_OFFSET bytes from the first chunk of memory it can map in
(naturally-aligned) 2MiB chunks.
The rationale was so long as memory below TEXT_OFFSET could be mapped per
EFI_MEMORY_WB, so long as we didn't touch it we were fine, given it was
permitted to be mapped as EFI_MEMORY_WB.
For instance, were all memory below TEXT_OFFSET RuntimeServicesData with
EFI_MEMORY_WB attributes, this is perfectly fine.
> This is used by drivers/firmware/efi/libstub/arm-stub.c to
> decide where to place the kernel image:
>
> unsigned long efi_entry(void *handle, efi_system_table_t *sys_table, {
> ...
> dram_base = get_dram_base(sys_table);
> if (dram_base == EFI_ERROR) {
> pr_efi_err(sys_table, "Failed to find DRAM base\n");
> goto fail;
> }
> status = handle_kernel_image(sys_table, image_addr, _size,
> _addr,
> _size,
> dram_base, image);
>
> Most types, including EfiPersistentMemory (14) and
> EfiReservedMemoryType (0), end up with WB|WT|WC|UC attributes.
For EfiPersistentMemory, I understand that such allocations would be valid,
(given that such memory may be mapped as EFI_MEMORY_WB), but would be
suboptimal (i.e. that memory will be slower, and would be better suited for
other data).
Is that understanding correct?
Or are there correctness issues with placing the kernel in persistent memory,
even if using attributes consistent with EFI_MEMORY_WB?
Is AllocatePages expected to allocate EfiPersistentMemory? The spec seems vague
on this point.
Regarding EfiReservedMemory, the UEFI spec states that such regions should not
be allocated by UEFI applications, drivers, or OS loaders, so if we can
allocate from such regions, that is a bug that we should correct. I would hope
that AllocatePages would refuse to allocate from such regions, but I don't see
any guarantee to that effect.
Regardless, if it is unsafe to map such regions with WB attributes (e.g.
because this could trigger bus errors), I don't believe that the EFI_MEMORY_WB
flag should be set. The spec doesn't seem to be clear on the precedence of
types vs attributes, but I may have missed something.
> So, if persistent memory happened to be below conventional memory,
> it appears that this code would end up loading the kernel into
> persistent memory, which would not be good. The same for
> reserved memory ranges. I think it needs to check and only
> operate on EfiConventionalMemory (maybe with a few others).
I agree that we should place the kernel in EfiConventionalMemory.
As above, there may be (sub-2MiB) overlap with regions of other types, so long
as these can be mapped with EFI_MEMORY_WB attributes.
So we need to allocate a chunk of memory such that:
* The chunk is in EfiConventionalMemory.
* The chunk is least image_size bytes in size.
* The chunk starts TEXT_OFFSET from a 2MiB aligned base.
* Any page sharing a same naturally-aligned 2MiB region with said chunk has
EFI_MEMORY_WB attributes. Non-chunk pages might not have a
EfiConventionalMemory type.
* The chunk is the lowest chunk meeting the other requirements above.
Is there anything I've missed?
Thanks,
Mark.
>
> Example UEFI memory map (on an x86 system):
>
> efi: mem00: [Conventional Memory| | | | | | | | |WB|WT|WC|UC]
> range=[0x-0x00092fff] (0 B for 588 KiB)
> efi: mem01: [Reserved | | | | | | | | |WB|WT|WC|UC]
> range=[0x00093000-0x00093fff] (588 KiB for 4 KiB)
> efi: mem02: [Conventional Memory| | | | | | | | |WB|WT|WC|UC]
> range=[0x00094000-0x0009] (592 KiB for 48 KiB)
> efi: mem03: [Loader Data| | | | | | | | |WB|WT|WC|UC]
> range=[0x0010-0x013e8fff] (1 MiB for 19364 KiB)
> efi: mem04: [Conventional Memory| | |
Re: [PATCH V2 5/6] cpufreq: governor: replace per-cpu delayed work with timers
On Friday, December 04, 2015 11:41:01 AM Viresh Kumar wrote: > On 04-12-15, 02:18, Rafael J. Wysocki wrote: > > > + shared->skip_work--; > > > > Is there any reason for incrementing and decrementing this instead of > > setting > > it to either 0 or 1 (or maybe either 'true' or 'false' for that matter)? > > > > If my reading of the patch is correct, it can only be either 0 or 1 anyway, > > right? > > No. It can be 0, 1 or 2. > > If the timer handler is running on any CPU, we increment skip_work, so > its value is 1. If at the same time, we try to stop the governor, we > increment it again and its value is 2 now. > > Once timer-handler finishes, it decrements it and its value become 1. > Which guarantees that no other timer handler starts executing at this > point of time and we can safely do gov_cancel_timers(). And once we > are sure that we don't have any work/timer left, we make it 0 (as we > aren't sure of the current value, which can be 0 (if the timer handler > wasn't running when we stopped the governor) or 1 (if the timer > handler was running while stopping the governor)). > > Hope this clarifies it. Well, almost, but not quite yet, because now the question is what prevents gov_cancel_work() from racing with dbs_work_handler(). If you can guarantee that they'll never run in parallel with each other, you probably don't need the whole counter dance. Otherwise, dbs_work_handler() should decrement the counter under the spinlock after all I suppose. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RESEND v7] i40e: Look up MAC address in Open Firmware or IDPROM
On Fri, Dec 4, 2015 at 8:24 AM, Sowmini Varadhan
wrote:
>
> [Apologies for fat-fingering subject in the other attempt]
>
> This is the i40e equivalent of commit c762dff24c06 ("ixgbe: Look up MAC
> address in Open Firmware or IDPROM").
>
> As with that fix, attempt to look up the MAC address in Open Firmware
> on systems that support it, and use IDPROM on SPARC if no OF address
> is found.
>
> In the case of the i40e there is an assumption that the default mac
> address has already been set up as the primary mac filter on probe,
> so if this filter is obtained from the Open Firmware or IDPROM, an
> explicit write is needed via i40e_aq_mac_address_write() and
> i40e_aq_add_macvlan() invocation.
>
> The is_default_mac field in the platform-private i40e_pf structure
> tracks whether the mac address was default or not, and in the latter
> case, will trigger the calls to i40e_aq_mac_address_write() and
> i40e_aq_add_macvlan().
>
> Reviewed-by: Martin K. Petersen
> Signed-off-by: Sowmini Varadhan
> ---
> v2, v3: Andy Shevchenko comments
> v4: Shannon Nelson review: explicitly set up mac filters before
> register_netdev
> v5: Shannon Nelson code style comments
> v6: Shannon Nelson code style comments
> v7: Ensure that i40e_macaddr_init() is called only for VSI_MAIN, and only
> if the mac address is not the default. Some additional code-refactoring
> based on comments from Shannon Nelson
>
> drivers/net/ethernet/intel/i40e/i40e.h |2 +
> drivers/net/ethernet/intel/i40e/i40e_main.c | 87
> +++
> 2 files changed, 89 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/i40e/i40e.h
> b/drivers/net/ethernet/intel/i40e/i40e.h
> index 0b9537b..6d41757 100644
> --- a/drivers/net/ethernet/intel/i40e/i40e.h
> +++ b/drivers/net/ethernet/intel/i40e/i40e.h
> @@ -420,6 +420,8 @@ struct i40e_pf {
>
> u32 ioremap_len;
> u32 fd_inv;
> +
> + u32 is_default_mac:1;
This driver doesn't use bitfield flags. Please look at how we use
pf->flags and create a new I40E_FLAG_ definition. Because I know
what's coming soon from our internal changes, I'd suggest using bit
50.
> };
>
> struct i40e_mac_filter {
> diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c
> b/drivers/net/ethernet/intel/i40e/i40e_main.c
> index 9e6268b..40a5d53 100644
> --- a/drivers/net/ethernet/intel/i40e/i40e_main.c
> +++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
> @@ -24,6 +24,15 @@
> *
>
> **/
>
> +#include
> +#include
> +#include
> +
> +#ifdef CONFIG_SPARC
> +#include
> +#include
> +#endif
> +
> /* Local includes */
> #include "i40e.h"
> #include "i40e_diag.h"
> @@ -9387,6 +9396,44 @@ static struct i40e_vsi *i40e_vsi_reinit_setup(struct
> i40e_vsi *vsi)
> }
>
> /**
> + * i40e_macaddr_init - explicitly write the mac address filters.
> + *
> + * @vsi: pointer to the vsi.
> + * @macaddr: the MAC address
> + *
> + * This is needed when the macaddr has been obtained by other
> + * means than the default, e.g., from Open Firmware or IDPROM.
> + * Returns 0 on success, negative on failure
> + **/
> +static int i40e_macaddr_init(struct i40e_vsi *vsi, u8 *macaddr)
> +{
> + int ret, aq_err;
> + struct i40e_aqc_add_macvlan_element_data element;
> +
> + ret = i40e_aq_mac_address_write(>back->hw,
> + I40E_AQC_WRITE_TYPE_LAA_WOL,
> + macaddr, NULL);
> + if (ret) {
> + dev_info(>back->pdev->dev,
> +"Addr change for VSI failed: %d\n", ret);
> + return -EADDRNOTAVAIL;
> + }
> +
> + memset(, 0, sizeof(element));
> + ether_addr_copy(element.mac_addr, macaddr);
> + element.flags = cpu_to_le16(I40E_AQC_MACVLAN_ADD_PERFECT_MATCH);
> + ret = i40e_aq_add_macvlan(>back->hw, vsi->seid, , 1,
> NULL);
> + aq_err = vsi->back->hw.aq.asq_last_status;
> + if (aq_err != I40E_AQ_RC_OK) {
> + dev_info(>back->pdev->dev,
> +"add filter failed err %s aq_err %s\n",
> +i40e_stat_str(>back->hw, ret),
> +i40e_aq_str(>back->hw, aq_err));
I'd write this just a little differently to match the rest of the driver:
ret = i40e_aq_add_macvlan(>back->hw, vsi->seid, , 1, NULL);
if (!ret) {
dev_info(>back->pdev->dev,
"add filter failed err %s aq_err %s\n",
i40e_stat_str(>back->hw, ret),
i40e_aq_str(>back->hw,
vsi->back->hw.aq.asq_last_status));
> + }
> + return ret;
> +}
> +
> +/**
> * i40e_vsi_setup - Set up a VSI by a given type
> * @pf: board private structure
> * @type: VSI type
> @@ -9510,6 +9557,14 @@ struct i40e_vsi *i40e_vsi_setup(struct i40e_pf *pf, u8
> type,
> switch
Re: [RFC PATCH 76/71] ncr5380: Enable PDMA for DTC chips
Hi Finn,
On Fri, Dec 4, 2015 at 7:38 PM, Finn Thain wrote:
>
> On Fri, 4 Dec 2015, Julian Calaby wrote:
>
>> > - if (overrides[current_override].board == BOARD_NCR53C400A)
>> > {
>> > + if (overrides[current_override].board == BOARD_NCR53C400A
>> > ||
>> > + overrides[current_override].board == BOARD_DTC3181E) {
>>
>> These if statements are starting to get a bit long, would it make
>> sense to replace them with a flag or equivalent?
>
> To what end? Shorter lines? As in,
Pretty much, each expression is quite long and they seem to be growing
fairly rapidly as you and Ondrej discover similar boards.
>
> if (board_is_ncr53c400a || board_is_dtc3181e) {
> /* ... */
> }
>
> I suppose that could be an improvement if new flags would entirely replace
> the override.board struct member and the existing switch statement,
>
> switch (overrides[current_override].board) {
> /* ... */
> }
>
> Or maybe you meant testing a new flag something like this,
>
> if (hostdata->ncr53c400_compatible) {
> /* ... */
> }
>
> If your concern is the Don't Repeat Yourself rule, I'm not sure that new
> flag would get tested more than once (?) And it would still have to be
> assigned using an "objectionably" long expression, e.g.
>
> hostdata->ncr53c400_compatible =
> overrides[current_override].board == BOARD_NCR53C400 ||
> overrides[current_override].board == BOARD_NCR53C400A ||
> overrides[current_override].board == BOARD_DTC3181E;
>
> Rather than add new flags, perhaps a 'switch' statement instead of an 'if'
> statement would be shorter (if the size of the expression is the problem).
I think switch statements would be cleaner in this particular
instance. I was thinking something like:
if (somthing->flags & NCR53C400_COMPATIBLE) {
/* ... */
}
but if it's only ever going to be used once, then it's pretty
pointless and switch statements are cleaner.
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] MAINTAINERS: add myself as Renesas Ethernet drivers reviewer
On Sat, 2015-12-05 at 04:13 +0300, Sergei Shtylyov wrote: > On 12/05/2015 04:02 AM, Joe Perches wrote: > > > Since you seem to be get_maintainers.pl maintainer, I (and not only I) > > > would like to propose a switch to suppress the committers/authors/etc. > > > It's > > > generally annoying and unhelpful to have the bunch of people listed, none > > > of > > > which usually are a good addressees for the patches... > > > > Done! > > > Add "--nogit" and "--nogit-fallback" > > Em, --nogit is the dafault, according to --help. --nogit-fallback is > enough but it's undocumented. :-/ umm $ ./scripts/get_maintainer.pl --help [...] --git-fallback => use git when no exact MAINTAINERS pattern (default: 1) [...] Most options have both positive and negative forms. The negative forms for -- are --no and --no-. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] power: bq27xxx_battery: Reorganize I2C into a module
Hi Andrew, On Mon, Nov 23, 2015 at 10:53:51AM -0600, Andrew F. Davis wrote: > Separate out I2C functionality into a module. This fixes several small > issues and simplifies the driver initialization. Thanks, queued. -- Sebastian signature.asc Description: PGP signature
Re: [PATCH] MAINTAINERS: add myself as Renesas Ethernet drivers reviewer
On 12/05/2015 04:02 AM, Joe Perches wrote: Since you seem to be get_maintainers.pl maintainer, I (and not only I) would like to propose a switch to suppress the committers/authors/etc. It's generally annoying and unhelpful to have the bunch of people listed, none of which usually are a good addressees for the patches... Done! Add "--nogit" and "--nogit-fallback" Em, --nogit is the dafault, according to --help. --nogit-fallback is enough but it's undocumented. :-/ Thanks anyway! MBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2] goldfish: add goldfish match node for dt driver probe
Hi, On Fri, Nov 06, 2015 at 03:12:40PM +0800, yalin wang wrote: > qemu use device tree to bootup linux kernel, > we need add device node match table to plaftorm driver, > so that can probe the goldfish driver correctly. > test by this qemu: > git clone https://android.googlesource.com/platform/external/qemu Your patch is missing the DT binding documentation part and should be splitted into multiple patches, at least one per kernel subsystem. Please read Documentation/SubmittingPatches and Documentation/devicetree/bindings/submitting-patches.txt -- Sebastian signature.asc Description: PGP signature
Re: Strange PF_NETLINK NETLINK_ROUTE stall: netlink: Fix autobind race condition that leads to zero port ID
On Fri, Nov 27, 2015 at 04:23:54PM +0100, Philipp Hahn wrote: > > I observed a strange stall in a multi-threaded process (originally > OpenLDAP slapd), which stalls during a call to getaddrinfo() after > upgrading the kernel from 3.16.x to 4.1.12: Can you try to see if the latest kernel still has this problem. Unfortunately a number of fixes seem to not have made it into 4.1 so anything could happen there. Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Asterisk deadlocks since Kernel 4.1
On Fri, Dec 04, 2015 at 07:26:12PM +0100, Stefan Priebe wrote: > > * 9f87e0c - (2 months ago) netlink: Replace rhash_portid with bound > - Herbert Xu > * 35e9890 - (3 months ago) netlink: Fix autobind race condition that > leads to zero port ID - Herbert Xu > * 30c6472 - (7 months ago) netlink: Use random autobind rover - Herbert Xu These three patches are absolutely required in any kernel where the netlink insertion is lockless. So yes they should be applied to 4.1. Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH tip/core/rcu 0/10] Expedited-grace-period changes for 4.5
On Fri, Dec 04, 2015 at 03:58:51PM -0800, Paul E. McKenney wrote: > Hello! > > This series contains follow-on cleanup changes to RCU's expedited > grace-period functionality. The patches in this series are as follows: > > 1.Short-circuit synchronize_sched_expedited() if there is only one CPU. > > 2.Update comment to clarify the role of ->expmaskinitnext. > > 3.Separate concerns by moving smp_mb() from rcu_seq_snap() to > rcu_exp_gp_seq_snap(). > > 4.Safe a few lines of code by inverting the sense of > sync_rcu_exp_select_cpus() "if" statement. > > 5.Reduce expedited GP memory contention via per-CPU variables. > > 6.Get rid of (some) empty stall-warning messages by resolving > stall-warning ties. > > 7.Add more diagnostics to expedited stall warning messages. > > 8.Add rcu_normal kernel parameter to suppress expediting for > the benefit of aggressive real-time systems. > > 9-10. Allow expedited grace periods to be disabled just before init > is spawned, allowing them to speed up boot without interfering > with run-time real-time workloads. This cover letter doesn't seem to match the patch series that shows up as replies to it. The patch series has 13 patches, numbered 01/13 to 13/13. You sent a separate cover letter, not part of this thread, that seems to match up. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH tip/core/rcu 0/8] Torture-test updates for 4.5
On Fri, Dec 04, 2015 at 04:23:31PM -0800, Paul E. McKenney wrote: > Hello! > > This series contains torture-test updates: > > 1.Add batch number to script printout to allow easier estimation > of test duration. > > 2.Dump stack when RCU's grace-period kthread stalls. > > 3.Set the scripting's default test-hang "grace period" to three > minutes, and allow this to be overridden. > > 4.Remove the obsolete CONFIG_RCU_USER_QS Kconfig option from > the rcutorture selftest documentation, courtesy of Yang Shi. > > 5.Print symbolic name for rcu_torture_writer_state, saving the > time otherwise required to manually translate from integer > to symbol. > > 6.Print symbolic name for ->gp_state, again saving the time > otherwise required to manually translate from integer to symbol. > > 7.Abbreviate console error dump, allowing the results of an > rcutorture script run to be observed with less back-scrolling. > > 8.Place console.log files correctly from the get-go, preventing > multiple qemu instances from outputting to the same file. I sent comments on patches 2, 5, and 6; for the rest: Reviewed-by: Josh Triplett -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Crypto Fixes for 4.4
Hi Linus: This push fixes a couple of crypto drivers that were using memcmp to verify authentication tags. They now use crypto_memneq instead. Please pull from git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git linus David Gstir (2): crypto: nx - Fix timing leak in GCM and CCM decryption crypto: talitos - Fix timing leak in ESP ICV verification drivers/crypto/nx/nx-aes-ccm.c |2 +- drivers/crypto/nx/nx-aes-gcm.c |3 ++- drivers/crypto/talitos.c |2 +- 3 files changed, 4 insertions(+), 3 deletions(-) Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH tip/core/rcu 6/8] rcutorture: Print symbolic name for ->gp_state
On Fri, Dec 04, 2015 at 04:23:50PM -0800, Paul E. McKenney wrote:
> Currently, ->gp_state is printed as an integer, which slows debugging.
> This commit therefore prints a symbolic name in addition to the integer.
>
> Signed-off-by: Paul E. McKenney
> [ Updated to fix relational operator called out by Dan Carpenter. ]
> ---
> kernel/rcu/tree.c | 15 +--
> kernel/rcu/tree.h | 9 +
> 2 files changed, 22 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
> index 7b78c88e19a3..491c99a73996 100644
> --- a/kernel/rcu/tree.c
> +++ b/kernel/rcu/tree.c
> @@ -1187,6 +1187,16 @@ static void record_gp_stall_check_time(struct
> rcu_state *rsp)
> }
>
> /*
> + * Convert a ->gp_state value to a character string.
> + */
> +static char *gp_state_getname(short gs)
Same comment about "const char *"
> +{
> + if (gs < 0 || gs >= ARRAY_SIZE(gp_state_names))
> + return "???";
> + return gp_state_names[gs];
> +}
> +
> +/*
> * Complain about starvation of grace-period kthread.
> */
> static void rcu_check_gp_kthread_starvation(struct rcu_state *rsp)
> @@ -1197,10 +1207,11 @@ static void rcu_check_gp_kthread_starvation(struct
> rcu_state *rsp)
> j = jiffies;
> gpa = READ_ONCE(rsp->gp_activity);
> if (j - gpa > 2 * HZ) {
> - pr_err("%s kthread starved for %ld jiffies! g%lu c%lu f%#x s%d
> ->state=%#lx\n",
> + pr_err("%s kthread starved for %ld jiffies! g%lu c%lu f%#x
> %s(%d) ->state=%#lx\n",
> rsp->name, j - gpa,
> rsp->gpnum, rsp->completed,
> -rsp->gp_flags, rsp->gp_state,
> +rsp->gp_flags,
> +gp_state_getname(rsp->gp_state), rsp->gp_state,
> rsp->gp_kthread ? rsp->gp_kthread->state : ~0);
> if (rsp->gp_kthread)
> sched_show_task(rsp->gp_kthread);
> diff --git a/kernel/rcu/tree.h b/kernel/rcu/tree.h
> index f32bebb6bc90..f0304988e3f8 100644
> --- a/kernel/rcu/tree.h
> +++ b/kernel/rcu/tree.h
> @@ -544,6 +544,15 @@ struct rcu_state {
> #define RCU_GP_DOING_FQS 4 /* Wait done for force-quiescent-state time. */
> #define RCU_GP_CLEANUP 5 /* Grace-period cleanup started. */
> #define RCU_GP_CLEANED 6 /* Grace-period cleanup complete. */
> +static char * const gp_state_names[] = {
Same comment about "const char * const", but also, should this really go
in a header file? Do any circumstances exist where this header could
get included in more than one source file in a given build? If so,
multiple copies of this array could potentially end up in the binary, if
the compiler fails to merge them.
> + "RCU_GP_IDLE",
> + "RCU_GP_WAIT_GPS",
> + "RCU_GP_DONE_GPS",
> + "RCU_GP_WAIT_FQS",
> + "RCU_GP_DOING_FQS",
> + "RCU_GP_CLEANUP",
> + "RCU_GP_CLEANED",
> +};
>
> extern struct list_head rcu_struct_flavors;
>
> --
> 2.5.2
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] memcg, vmscan: Do not wait for writeback if killed
On Thu, 3 Dec 2015 10:08:26 +0100 Michal Hocko wrote: > So you think a comment would be sufficient? > --- > diff --git a/mm/vmscan.c b/mm/vmscan.c > index 98a1934493af..2e8ee9e5fcb5 100644 > --- a/mm/vmscan.c > +++ b/mm/vmscan.c > @@ -1031,9 +1031,12 @@ static unsigned long shrink_page_list(struct list_head > *page_list, > /* >* We've got killed while waiting here so >* expedite our way out from the reclaim > + * > + * Our callers should make sure we do not > + * get here with fatal signals again. >*/ Seems OK. s/should/must/ Please resend it all after the usual exhaustive testing ;) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH tip/core/rcu 5/8] rcutorture: Print symbolic name for rcu_torture_writer_state
On Fri, Dec 04, 2015 at 04:23:49PM -0800, Paul E. McKenney wrote:
> Currently, rcu_torture_writer_state is printed as an integer, which slows
> debugging. This commit therefore prints a symbolic name in addition to
> the integer.
>
> Signed-off-by: Paul E. McKenney
> ---
> kernel/rcu/rcutorture.c | 24 +++-
> 1 file changed, 23 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/rcu/rcutorture.c b/kernel/rcu/rcutorture.c
> index d89328e260df..adbb194e2b5d 100644
> --- a/kernel/rcu/rcutorture.c
> +++ b/kernel/rcu/rcutorture.c
> @@ -162,6 +162,27 @@ static int rcu_torture_writer_state;
> #define RTWS_SYNC7
> #define RTWS_STUTTER 8
> #define RTWS_STOPPING9
> +static char * const rcu_torture_writer_state_names[] = {
Shouldn't this use "static const char * const"? Also, see below.
> + "RTWS_FIXED_DELAY",
> + "RTWS_DELAY",
> + "RTWS_REPLACE",
> + "RTWS_DEF_FREE",
> + "RTWS_EXP_SYNC",
> + "RTWS_COND_GET",
> + "RTWS_COND_SYNC",
> + "RTWS_SYNC",
> + "RTWS_STUTTER",
> + "RTWS_STOPPING",
> +};
> +
> +char *rcu_torture_writer_state_getname(void)
This should return "const char *", I think.
> +{
> + unsigned int i = READ_ONCE(rcu_torture_writer_state);
> +
> + if (i >= ARRAY_SIZE(rcu_torture_writer_state_names))
> + return "???";
> + return rcu_torture_writer_state_names[i];
> +}
>
> #if defined(MODULE) || defined(CONFIG_RCU_TORTURE_TEST_RUNNABLE)
> #define RCUTORTURE_RUNNABLE_INIT 1
> @@ -1307,7 +1328,8 @@ rcu_torture_stats_print(void)
>
> rcutorture_get_gp_data(cur_ops->ttype,
> , , );
> - pr_alert("??? Writer stall state %d g%lu c%lu f%#x\n",
> + pr_alert("??? Writer stall state %s(%d) g%lu c%lu f%#x\n",
> + rcu_torture_writer_state_getname(),
>rcu_torture_writer_state,
>gpnum, completed, flags);
> show_rcu_gp_kthreads();
> --
> 2.5.2
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] MAINTAINERS: add myself as Renesas Ethernet drivers reviewer
On Sat, 2015-12-05 at 03:57 +0300, Sergei Shtylyov wrote: > Since you seem to be get_maintainers.pl maintainer, I (and not only I) > would like to propose a switch to suppress the committers/authors/etc. It's > generally annoying and unhelpful to have the bunch of people listed, none of > which usually are a good addressees for the patches... Done! Add "--nogit" and "--nogit-fallback" -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH tip/core/rcu 2/8] rcutorture: Dump stack when GP kthread stalls
On Fri, Dec 04, 2015 at 04:23:46PM -0800, Paul E. McKenney wrote:
> This commit increases debug information in the case where the grace-period
> kthread is being prevented from running by dumping that kthread's stack.
That's not everything this patch does; see below.
> Signed-off-by: Paul E. McKenney
> ---
> kernel/rcu/tree.c | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
> index 81aa1cdc6bc9..7b78c88e19a3 100644
> --- a/kernel/rcu/tree.c
> +++ b/kernel/rcu/tree.c
> @@ -1196,12 +1196,15 @@ static void rcu_check_gp_kthread_starvation(struct
> rcu_state *rsp)
>
> j = jiffies;
> gpa = READ_ONCE(rsp->gp_activity);
> - if (j - gpa > 2 * HZ)
> + if (j - gpa > 2 * HZ) {
> pr_err("%s kthread starved for %ld jiffies! g%lu c%lu f%#x s%d
> ->state=%#lx\n",
> rsp->name, j - gpa,
> rsp->gpnum, rsp->completed,
> rsp->gp_flags, rsp->gp_state,
> -rsp->gp_kthread ? rsp->gp_kthread->state : 0);
> +rsp->gp_kthread ? rsp->gp_kthread->state : ~0);
The commit message doesn't explain this change. Could you please 1)
document this change in the commit message, and 2) split it into a
separate patch unless it directly relates to the other change (which
doesn't seem like the case)?
> + if (rsp->gp_kthread)
> + sched_show_task(rsp->gp_kthread);
> + }
> }
>
> /*
> --
> 2.5.2
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] power: Fix unmet dependency on POWER_SUPPLY by POWER_RESET by uncoupling them
Hi, On Wed, Dec 02, 2015 at 02:59:06PM +0900, Krzysztof Kozlowski wrote: > Actually reset/power off handlers do not really depend on power supply. > Move the power reset out of power supply block so it will appear in main > drivers section. This fixes following build warning (encountered on ARM > exynos defconfig when POWER_SUPPLY is disabled manually): > > warning: (ARCH_HISI && ARCH_INTEGRATOR && ARCH_EXYNOS && ARCH_VEXPRESS && > REALVIEW_DT) selects POWER_RESET which has unmet direct dependencies > (POWER_SUPPLY) > warning: (ARCH_EXYNOS) selects POWER_RESET_SYSCON which has unmet direct > dependencies (POWER_SUPPLY && POWER_RESET && OF) > warning: (ARCH_EXYNOS) selects POWER_RESET_SYSCON_POWEROFF which has unmet > direct dependencies (POWER_SUPPLY && POWER_RESET && OF) nice catch. I don't really like the Makefile changes, though. I think it would be better to make the power/ entry in drivers/Makefile into "obj-y" and handle the details in drivers/power/Makefile. -- Sebastian signature.asc Description: PGP signature
Re: [PATCH] RTC: RK808: Work around hardware bug on November 31st
Julius, On Fri, Dec 4, 2015 at 4:25 PM, Julius Werner wrote: >> If a device is in S3 for the whole day that the glitch occurs and then >> we wake up then we'll end up thinking it's Dec 1st instead of Dec 2nd, >> right? That case _could_ be handled by knowing that the last time we >> read the clock it was before 12/1 and that this time it is after >> 11/30. Then we add the extra day. In order to do this, we'd have to >> know that we're on hardware with the glitch, which I guess could >> either be done with a device tree property or by spending 1 second >> probing the device at bootup (that would be a bit of a pain...). >> >> Obviously the trick above wouldn't handle if the clock ticked when the >> device was in S5, but I'd imagine that most systems treat the RTC as >> slightly questionable on an initial bootup anyway (though I'd imagine >> that they rely on it working across S3). > > True, we could do that. I don't think it makes much sense to > differentiate between S3 and S5 like that, though... the problem can > happen just the same after both, and I don't think there's a practical > difference in how systems treat that (if userspace has ways to > double-check the system time, such as syncing to a network time > source, it should really be doing that after both resume and reboot). > Of course, building a work-around like that for S5 will become more > complicated and requires persistent storage. Right, the need for persistent storage is what makes S5 hard... > For Chromium OS, we're already planning to improve tlsdated such that > I don't think this will be an issue anymore (making it schedule a > resync after resume, not just after reboot, which is a probably a good > idea in general). For other systems that don't have any kind of > network time sync, I think the best solution would be to handle this > completely with a small userspace hook on boot and resume (because you > probably need to access the file system to keep track of the last seen > time anyway, you can do the device identification through > /proc/device-tree just as well, and this avoids putting too much hacky > workaround logic into the kernel). How would such a hook work? If userspace sees the system suspend on Nov 30th and sees the system wake up on Dec 1st, how does it know whether it should adjust? If it's truly Dec 1st then the kernel will have adjusted the date from Nov 31st to Dec 1st. If it's truly Dec 2nd then the kernel will not have adjusted the date and the RTC will have ticked past Nov 31 and onto Dec 1st. Userspace can't tell. Userspace could try to parse "dmesg" and look to see if the kernel adjusted, but that's ugly. We could add a sysfs entry, but it seems pretty hard to imagine that all Linux distros using rk808 will add this type of hook... > The other thing that would worry me about this approach is that it > requires perfect identification of the problem, and Rockchip will > hopefully eventually be able to fix this either in RK808 or a > successor chip that might use the same RTC interface (and thus > driver). Detecting it at boot is probably a bad idea because a > crash/brownout at the wrong moment will permanently leave you with a > bad time. I really think fixing this as best as we easily can and > leaving the hard edge-cases to userspace is the best approach here. Yes, you're right. Detecting is a bit scary. Chris: any chance there's an RK808 revision hiding somewhere in the i2c register banks that we could rely on? Adding a device tree hook doesn't seem insane, but you're right that Rockchip could start producing new revisions of rk808 with this fixed and all of sudden we'd be adjusting the wrong way. ...so you're probably right that this is a bad idea... So I guess my #1 choice would be to find a revision somewhere in the rk808 i2c register space. If that's not there, then I guess you're patch is probably better than trying to adjust and maybe being wrong when newer rk808 revisions fix this... -Doug -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] MAINTAINERS: add myself as Renesas Ethernet drivers reviewer
Hello. On 12/05/2015 03:41 AM, Joe Perches wrote: liAdd myself as a reviewer for the Renesas Ethernet drivers -- hopefully I won't miss the buggy patches anymore. :-) Signed-off-by: Sergei Shtylyov --- The patch is against DaveM's 'net.git' repo. MAINTAINERS |8 1 file changed, 8 insertions(+) Index: net/MAINTAINERS === --- net.orig/MAINTAINERS +++ net/MAINTAINERS @@ -8929,6 +8929,14 @@ F: drivers/rpmsg/ F:Documentation/rpmsg.txt F:include/linux/rpmsg.h +RENESAS ETHERNET DRIVERS +R: Sergei Shtylyov +L: net...@vger.kernel.orgc +L: linux...@vger.kernel.org +S: Maintained +F: drivers/net/ethernet/renesas/ +F: include/linux/sh_eth.h Hello Sergei Typically a reviewer isn't a maintainer. Yeah, I didn't take courage to become a real maintainer, being always short of time... But I was annoyed by dubious quality patches being merged recently. Does anyone actually maintain this? Only DaveM. I suggest you mark this "S: Odd fixes" or remove the "S:" line altogether unless you really want to become the maintainer. OK, will remove, if that's OK. PS: Since you seem to be get_maintainers.pl maintainer, I (and not only I) would like to propose a switch to suppress the committers/authors/etc. It's generally annoying and unhelpful to have the bunch of people listed, none of which usually are a good addressees for the patches... MBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: account pglazyfreed exactly
On Thu, 3 Dec 2015 21:51:04 +0900 Minchan Kim wrote:
> If anon pages are zapped by unmapping between page_mapped check
> and try_to_unmap in shrink_page_list, they could be !PG_dirty
> although thre are not MADV_FREEed pages so that VM accoutns it
> as pglazyfreed wrongly.
>
> To fix, this patch counts the number of lazyfree ptes in
> try_to_unmap_one and try_to_unmap returns SWAP_LZFREE only if
> the count is not zero, page is !PG_dirty and SWAP_SUCCESS.
A few tiny things...
diff -puN mm/rmap.c~mm-support-madvisemadv_free-fix-2-fix mm/rmap.c
--- a/mm/rmap.c~mm-support-madvisemadv_free-fix-2-fix
+++ a/mm/rmap.c
@@ -1605,7 +1605,7 @@ int try_to_unmap(struct page *page, enum
struct rmap_walk_control rwc = {
.rmap_one = try_to_unmap_one,
- .arg = (void *),
+ .arg = ,
.done = page_not_mapped,
.anon_lock = page_lock_anon_vma_read,
};
@@ -1651,7 +1651,6 @@ int try_to_unmap(struct page *page, enum
int try_to_munlock(struct page *page)
{
int ret;
-
struct rmap_private rp = {
.flags = TTU_MUNLOCK,
.lazyfreed = 0,
@@ -1659,7 +1658,7 @@ int try_to_munlock(struct page *page)
struct rmap_walk_control rwc = {
.rmap_one = try_to_unmap_one,
- .arg = (void *),
+ .arg = ,
.done = page_not_mapped,
.anon_lock = page_lock_anon_vma_read,
diff -puN mm/vmscan.c~mm-support-madvisemadv_free-fix-2-fix mm/vmscan.c
_
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC RFT 0/3] clk: detect per-user enable imbalances and implement hand-off
Heiko Stübner wrote: > Hi Mike, > > Am Freitag, 7. August 2015, 12:09:27 schrieb Michael Turquette: > > This is an alternative solution to Lee's "clk: Provide support for > > always-on clocks" series[0]. > > > > The first two patches introduce run-time checks to ensure that clock > > consumer drivers are respecting the clk.h api. The former patch checks > > for prepare and enable imbalances. The latter checks for calls to > > clk_put without first disabling and unpreparing the clk. > > > > The third patch introduces a new flag, CLK_ENABLE_HAND_OFF, which > > prepares and enables a clk at registration-time. The reference counts > > (prepare & enable) are transferred to the first clock consumer driver > > that clk_get's the clk with this flag set AND calls clk_prepare or > > clk_enable. > > > > The net result is that a clock with this flag set will be enabled at > > boot and neither the clk_disable_unused garbage collector or the > > "sibling clock disables a shared parent" scenario will cause the flagged > > clock to be disabled. The first driver to come along and explicitly > > claim, prepare and enable this clock will inherit those reference > > counts. No change to clock consumer drivers is required for this to > > work. Please continue to use the clk.h api properly. > > just out of curiosity, did this move anywhere yet? (Last message from october > 1st it seems) > > It looks like it is needed to fix the orphan-deferral I need on Rockchip that > breaks sunxi in its current state. Yes, I'm preparing another version. Sorry for high latency, but I've been traveling for more than 2 months non-stop. Regards, Mike > > > Thanks > Heiko -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] drivers: power: set IRQF_ONESHOT if no primary handler is specified
Hi, On Thu, Nov 19, 2015 at 12:42:59PM +0530, Saurabh Sengar wrote: > If no primary handler is specified for threaded_irq then a > default one is assigned which always returns IRQ_WAKE_THREAD. > This handler requires the IRQF_ONESHOT, because the source of > interrupt is not disabled. Thanks, queued. -- Sebastian signature.asc Description: PGP signature
Re: [PATCH tip/core/rcu 0/8] Documentation updates for 4.5
On Fri, Dec 04, 2015 at 03:49:52PM -0800, Paul E. McKenney wrote: > Hello! > > This series contains documentation updates, perhaps most notably a first > installment of RCU design documentation, which first appeared on LWN > (http://lwn.net/Articles/652156/, http://lwn.net/Articles/652677/, and > http://lwn.net/Articles/653326/). The individual patches are as follows: > > 1.Add RCU requirements design document. > > 2-7. Updates to the RCU requirements. > > 8.Fix memory-barrier.txt typo, courtesy of Chris Metcalf. I sent two mails worth of feedback to patch 1 that effectively apply to the whole series; one covers the checkin of a generated file, and the other covers various mechanical issues in the document. With those two fixed: Reviewed-by: Josh Triplett for the whole series -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] power/reset: at91-reset: add missing of_node_put
Hi,
On Wed, Nov 18, 2015 at 11:04:14PM +0100, Julia Lawall wrote:
> for_each_matching_node performs an of_node_get on each iteration, so
> a break out of the loop requires an of_node_put.
>
> A simplified version of the semantic patch that fixes this problem is as
> follows (http://coccinelle.lip6.fr):
>
> //
> @@
> expression e,e1;
> local idexpression np;
> @@
>
> for_each_matching_node(np, e1) {
>... when != of_node_put(np)
>when != e = np
> (
>return np;
> |
> + of_node_put(np);
> ? return ...;
> )
>...
> }
> //
>
> Signed-off-by: Julia Lawall
Thanks, queued.
-- Sebastian
signature.asc
Description: PGP signature
Re: [PATCH] ds2782_battery: constify ds278x_battery_ops structure
Hi, On Fri, Nov 13, 2015 at 07:41:34PM +0100, Julia Lawall wrote: > The ds278x_battery_ops structure is never modified, so declare it as const. > > Done with the help of Coccinelle. > > Signed-off-by: Julia Lawall Thanks, queued. -- Sebastian signature.asc Description: PGP signature
Re: [PATCH] MAINTAINERS: add myself as Renesas Ethernet drivers reviewer
On Sat, 2015-12-05 at 03:03 +0300, Sergei Shtylyov wrote: > liAdd myself as a reviewer for the Renesas Ethernet drivers -- > hopefully I > won't miss the buggy patches anymore. :-) > > Signed-off-by: Sergei Shtylyov > > --- > The patch is against DaveM's 'net.git' repo. > > MAINTAINERS |8 > 1 file changed, 8 insertions(+) > > Index: net/MAINTAINERS > === > --- net.orig/MAINTAINERS > +++ net/MAINTAINERS > @@ -8929,6 +8929,14 @@ F: drivers/rpmsg/ > F: Documentation/rpmsg.txt > F: include/linux/rpmsg.h > > +RENESAS ETHERNET DRIVERS > +R: Sergei Shtylyov > +L: net...@vger.kernel.orgc > +L: linux...@vger.kernel.org > +S: Maintained > +F: drivers/net/ethernet/renesas/ > +F: include/linux/sh_eth.h Hello Sergei Typically a reviewer isn't a maintainer. Does anyone actually maintain this? I suggest you mark this "S: Odd fixes" or remove the "S:" line altogether unless you really want to become the maintainer. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 3/3] UBSAN: run-time undefined behavior sanity checker
On Fri, 4 Dec 2015 22:27:36 +0800 kbuild test robot wrote:
> [auto build test WARNING on next-20151203]
> [cannot apply to tip/x86/core kbuild/rc-fixes v4.4-rc3 v4.4-rc2 v4.4-rc1
> v4.4-rc3]
>
> url:
> https://github.com/0day-ci/linux/commits/Andrey-Ryabinin/UBSAN-run-time-undefined-behavior-sanity-checker/20151204-202547
> config: i386-allmodconfig (attached as .config)
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=i386
>
> All warnings (new ones prefixed by >>):
>
>lib/ubsan.c: In function 'val_to_string':
> >> lib/ubsan.c:121:8: warning: unused variable 'val' [-Wunused-variable]
> u_max val = get_unsigned_val(type, value);
I did this.
--- a/lib/ubsan.c~ubsan-run-time-undefined-behavior-sanity-checker-fix
+++ a/lib/ubsan.c
@@ -118,11 +118,11 @@ static u_max get_unsigned_val(struct typ
static void val_to_string(char *str, size_t size, struct type_descriptor *type,
unsigned long value)
{
- u_max val = get_unsigned_val(type, value);
-
if (type_is_int(type)) {
if (type_bit_width(type) == 128) {
#ifdef CONFIG_ARCH_SUPPORTS_INT128
+ u_max val = get_unsigned_val(type, value);
+
scnprintf(str, size, "0x%08x%08x%08x%08x",
(u32)(val >> 96),
(u32)(val >> 64),
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v7 3/7] PCI: Make it possible to implement a PCI MSI IRQ Domain in a module.
From: Jake Oshins
The Linux kernel already has the concpet of IRQ domain, wherein a
component can expose a set of IRQs which are managed by a particular
interrupt controller chip or other subsystem. The PCI driver exposes
the notion of an IRQ domain for Message-Signaled Interrupts (MSI) from
PCI Express devices. This patch exposes the functions which are
necessary for making an MSI IRQ domain within a module.
Signed-off-by: Jake Oshins
---
arch/x86/include/asm/msi.h| 6 ++
arch/x86/kernel/apic/msi.c| 8 +---
arch/x86/kernel/apic/vector.c | 2 ++
drivers/pci/msi.c | 4
kernel/irq/chip.c | 1 +
kernel/irq/irqdomain.c| 4
6 files changed, 22 insertions(+), 3 deletions(-)
diff --git a/arch/x86/include/asm/msi.h b/arch/x86/include/asm/msi.h
index 93724cc..eb4b09b 100644
--- a/arch/x86/include/asm/msi.h
+++ b/arch/x86/include/asm/msi.h
@@ -1,7 +1,13 @@
#ifndef _ASM_X86_MSI_H
#define _ASM_X86_MSI_H
#include
+#include
typedef struct irq_alloc_info msi_alloc_info_t;
+int pci_msi_prepare(struct irq_domain *domain, struct device *dev, int nvec,
+ msi_alloc_info_t *arg);
+
+void pci_msi_set_desc(msi_alloc_info_t *arg, struct msi_desc *desc);
+
#endif /* _ASM_X86_MSI_H */
diff --git a/arch/x86/kernel/apic/msi.c b/arch/x86/kernel/apic/msi.c
index 5f1feb6..ade2532 100644
--- a/arch/x86/kernel/apic/msi.c
+++ b/arch/x86/kernel/apic/msi.c
@@ -96,8 +96,8 @@ static irq_hw_number_t pci_msi_get_hwirq(struct
msi_domain_info *info,
return arg->msi_hwirq;
}
-static int pci_msi_prepare(struct irq_domain *domain, struct device *dev,
- int nvec, msi_alloc_info_t *arg)
+int pci_msi_prepare(struct irq_domain *domain, struct device *dev, int nvec,
+ msi_alloc_info_t *arg)
{
struct pci_dev *pdev = to_pci_dev(dev);
struct msi_desc *desc = first_pci_msi_entry(pdev);
@@ -113,11 +113,13 @@ static int pci_msi_prepare(struct irq_domain *domain,
struct device *dev,
return 0;
}
+EXPORT_SYMBOL_GPL(pci_msi_prepare);
-static void pci_msi_set_desc(msi_alloc_info_t *arg, struct msi_desc *desc)
+void pci_msi_set_desc(msi_alloc_info_t *arg, struct msi_desc *desc)
{
arg->msi_hwirq = pci_msi_domain_calc_hwirq(arg->msi_dev, desc);
}
+EXPORT_SYMBOL_GPL(pci_msi_set_desc);
static struct msi_domain_ops pci_msi_domain_ops = {
.get_hwirq = pci_msi_get_hwirq,
diff --git a/arch/x86/kernel/apic/vector.c b/arch/x86/kernel/apic/vector.c
index 861bc59..908cb37 100644
--- a/arch/x86/kernel/apic/vector.c
+++ b/arch/x86/kernel/apic/vector.c
@@ -29,6 +29,7 @@ struct apic_chip_data {
};
struct irq_domain *x86_vector_domain;
+EXPORT_SYMBOL_GPL(x86_vector_domain);
static DEFINE_RAW_SPINLOCK(vector_lock);
static cpumask_var_t vector_cpumask;
static struct irq_chip lapic_controller;
@@ -66,6 +67,7 @@ struct irq_cfg *irqd_cfg(struct irq_data *irq_data)
return data ? >cfg : NULL;
}
+EXPORT_SYMBOL_GPL(irqd_cfg);
struct irq_cfg *irq_cfg(unsigned int irq)
{
diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index 53e4632..3915a99 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -257,6 +257,7 @@ void pci_msi_mask_irq(struct irq_data *data)
{
msi_set_mask_bit(data, 1);
}
+EXPORT_SYMBOL_GPL(pci_msi_mask_irq);
/**
* pci_msi_unmask_irq - Generic irq chip callback to unmask PCI/MSI interrupts
@@ -266,6 +267,7 @@ void pci_msi_unmask_irq(struct irq_data *data)
{
msi_set_mask_bit(data, 0);
}
+EXPORT_SYMBOL_GPL(pci_msi_unmask_irq);
void default_restore_msi_irqs(struct pci_dev *dev)
{
@@ -1126,6 +1128,7 @@ struct pci_dev *msi_desc_to_pci_dev(struct msi_desc *desc)
{
return to_pci_dev(desc->dev);
}
+EXPORT_SYMBOL(msi_desc_to_pci_dev);
void *msi_desc_to_pci_sysdata(struct msi_desc *desc)
{
@@ -1285,6 +1288,7 @@ struct irq_domain *pci_msi_create_irq_domain(struct
fwnode_handle *fwnode,
domain->bus_token = DOMAIN_BUS_PCI_MSI;
return domain;
}
+EXPORT_SYMBOL_GPL(pci_msi_create_irq_domain);
/**
* pci_msi_domain_alloc_irqs - Allocate interrupts for @dev in @domain
diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
index 05e29de..5797909 100644
--- a/kernel/irq/chip.c
+++ b/kernel/irq/chip.c
@@ -950,6 +950,7 @@ void irq_chip_ack_parent(struct irq_data *data)
data = data->parent_data;
data->chip->irq_ack(data);
}
+EXPORT_SYMBOL_GPL(irq_chip_ack_parent);
/**
* irq_chip_mask_parent - Mask the parent interrupt
diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
index 22aa961..aa6ac44 100644
--- a/kernel/irq/irqdomain.c
+++ b/kernel/irq/irqdomain.c
@@ -60,6 +60,7 @@ struct fwnode_handle *irq_domain_alloc_fwnode(void *data)
fwid->fwnode.type = FWNODE_IRQCHIP;
return >fwnode;
}
+EXPORT_SYMBOL_GPL(irq_domain_alloc_fwnode);
/**
* irq_domain_free_fwnode - Free a non-OF-backed fwnode_handle
@@ -77,6 +78,7 @@ void irq_domain_free_fwnode(struct fwnode_handle
[PATCH v7 4/7] PCI: Add fwnode_handle to pci_sysdata
From: Jake Oshins
This patch adds an fwnode_handle to struct pci_sysdata, which is
used by the next patch in the series when trying to locate an
IRQ domain associated with a root PCI bus.
Signed-off-by: Jake Oshins
---
arch/x86/include/asm/pci.h | 15 +++
include/asm-generic/pci.h | 4
2 files changed, 19 insertions(+)
diff --git a/arch/x86/include/asm/pci.h b/arch/x86/include/asm/pci.h
index 4625943..6fc3c7c 100644
--- a/arch/x86/include/asm/pci.h
+++ b/arch/x86/include/asm/pci.h
@@ -20,6 +20,9 @@ struct pci_sysdata {
#ifdef CONFIG_X86_64
void*iommu; /* IOMMU private data */
#endif
+#ifdef CONFIG_PCI_MSI_IRQ_DOMAIN
+ void*fwnode;/* IRQ domain for MSI assignment */
+#endif
};
extern int pci_routeirq;
@@ -32,6 +35,7 @@ extern int noioapicreroute;
static inline int pci_domain_nr(struct pci_bus *bus)
{
struct pci_sysdata *sd = bus->sysdata;
+
return sd->domain;
}
@@ -41,6 +45,17 @@ static inline int pci_proc_domain(struct pci_bus *bus)
}
#endif
+#ifdef CONFIG_PCI_MSI_IRQ_DOMAIN
+static inline void *_pci_root_bus_fwnode(struct pci_bus *bus)
+{
+ struct pci_sysdata *sd = bus->sysdata;
+
+ return sd->fwnode;
+}
+
+#define pci_root_bus_fwnode_pci_root_bus_fwnode
+#endif
+
/* Can be used to override the logic in pci_scan_bus for skipping
already-configured bus numbers - to be used for buggy BIOSes
or architectures with incomplete PCI setup by the loader */
diff --git a/include/asm-generic/pci.h b/include/asm-generic/pci.h
index f24bc51..4092886 100644
--- a/include/asm-generic/pci.h
+++ b/include/asm-generic/pci.h
@@ -21,4 +21,8 @@ static inline int pci_get_legacy_ide_irq(struct pci_dev *dev,
int channel)
#define PCI_DMA_BUS_IS_PHYS(1)
#endif
+#ifndef pci_root_bus_fwnode
+#define pci_root_bus_fwnode(bus) ((void)(bus), NULL)
+#endif
+
#endif /* _ASM_GENERIC_PCI_H */
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH tip/core/rcu 1/8] documentation: Record RCU requirements
On Fri, Dec 04, 2015 at 04:33:32PM -0800, Paul E. McKenney wrote: > On Fri, Dec 04, 2015 at 04:07:19PM -0800, Josh Triplett wrote: > > On Fri, Dec 04, 2015 at 03:50:19PM -0800, Paul E. McKenney wrote: > > > This commit adds RCU requirements as published in a 2015 LWN series. > > > Bringing these requirements in-tree allows them to be updated as changes > > > are discovered. > > > > > > Signed-off-by: Paul E. McKenney > > > --- > > > .../RCU/Design/Requirements/2013-08-is-it-dead.png | Bin 0 -> 100825 > > > bytes > > > .../Design/Requirements/GPpartitionReaders1.svg| 374 +++ > > > .../RCU/Design/Requirements/RCUApplicability.svg | 237 ++ > > > .../Design/Requirements/ReadersPartitionGP1.svg| 639 + > > > .../RCU/Design/Requirements/Requirements.html | 2799 > > > > > > .../RCU/Design/Requirements/Requirements.htmlx | 2643 > > > ++ > > > Documentation/RCU/Design/htmlqqz.sh| 108 + > > > 7 files changed, 6800 insertions(+) > > > create mode 100644 > > > Documentation/RCU/Design/Requirements/2013-08-is-it-dead.png > > > create mode 100644 > > > Documentation/RCU/Design/Requirements/GPpartitionReaders1.svg > > > create mode 100644 > > > Documentation/RCU/Design/Requirements/RCUApplicability.svg > > > create mode 100644 > > > Documentation/RCU/Design/Requirements/ReadersPartitionGP1.svg > > > create mode 100644 > > > Documentation/RCU/Design/Requirements/Requirements.html > > > create mode 100644 > > > Documentation/RCU/Design/Requirements/Requirements.htmlx > > > > If Requirements.html is machine-generated and shouldn't be hand-edited, > > and it can be generated without any special tools, then I don't think it > > should be committed in the tree; I'd suggest putting it in .gitignore > > and generating it from one of the various "make docs" invocations. > > I considered doing that, but then decided that it is nice for people to > be able train their browser directly on the file without having to know > what scripts to run. > > Hmmm... I suppose I could construct a Makefile that dealt with that > though... I will give this some thought, and if it looks good, I will > add the Makefiles and "git rm" the .htmlx files. > > > Alternatively, if you want to make sure a usable version is in-tree, you > > could make the script reversible (easy enough to do if the compiled > > version includes some marker comments or similar), and then tell people > > to run it in reverse mode, edit, and run it in forward mode. Then you > > don't need the .htmlx file at all. :) > > Decades ago, back when I (against all evidence) believed I could > consistently avoid making stupid mistakes, you might have been able to > convince me that this was a good idea. ;-) Because you don't want to complicate the script, or because you don't want to accidentally edit the wrong version? (Note that a carefully written script would mean it doesn't matter which version you edit.) A third alternative would be to include the answers inline right after the questions, and optionally add a tiny bit of JavaScript that hides them by default and lets you click to show the answer. :) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 0/3] UBSAN: run-time undefined behavior sanity checker
On Thu, 3 Dec 2015 18:50:04 +0300 Andrey Ryabinin wrote: > UBSAN is run-time undefined behaviour checker. It uses compile-time > instrumentation to catch undefined behavior (UB). Compiler inserts code > that perform certain kinds of checks before operations that could cause UB. > If check fails (i.e. UB detected) __ubsan_handle_* function called to print > error message. What I'd like to see in this changelog is a description of any kernel issues which this checker has already identified: what were they and what was their potential impact at runtime. This info will help us to understand the value of the proposed feature. Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v7 5/7] PCI: irqdomain: Look up IRQ domain by fwnode_handle
From: Jake Oshins
This patch adds a second way of finding an IRQ domain associated with
a root PCI bus. After looking to see if one can be found through
the OF tree, it attempts to look up the IRQ domain through an
fwnode_handle stored in the pci_sysdata struct.
Signed-off-by: Jake Oshins
---
drivers/pci/probe.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index edb1984..8f3d056 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -673,6 +673,20 @@ static struct irq_domain
*pci_host_bridge_msi_domain(struct pci_bus *bus)
*/
d = pci_host_bridge_of_msi_domain(bus);
+#ifdef CONFIG_PCI_MSI_IRQ_DOMAIN
+ /*
+* If no IRQ domain was found via the OF tree, try looking it up
+* directly through the fwnode_handle.
+*/
+ if (!d) {
+ struct fwnode_handle *fwnode = pci_root_bus_fwnode(bus);
+
+ if (fwnode)
+ d = irq_find_matching_fwnode(fwnode,
+DOMAIN_BUS_PCI_MSI);
+ }
+#endif
+
return d;
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v7 0/7] PCI: hv: New paravirtual PCI front-end for Hyper-V VMs
From: Jake Oshins This version of the patch series incorporates feedback from Gerry Liu. First, export functions that allow correlating Hyper-V virtual processors and Linux cpus, along with the means for invoking a hypercall that targets interrupts at chosen vectors on specific cpus. Second, mark various parts of IRQ domain related code as exported, so that this PCI front-end can implement an IRQ domain as part of a module. (The alternative would be to pull all tyhis into the kernel, which would pull in a lot of other Hyper-V related code, as this IRQ domain depends on vmbus.ko.) Third, modify PCI so that new root PCI buses can be marked with an associated fwnode_handle, and so that root PCI buses can look up their associated IRQ domain by that handle. Fourth, introduce a new driver, hv_pcifront, which exposes root PCI buses in a Hyper-V VM. These root PCI buses expose real PCIe device, or PCI Virtual Functions. Jake Oshins (7): drivers:hv: Export a function that maps Linux CPU num onto Hyper-V proc num drivers:hv: Export hv_do_hypercall() PCI: Make it possible to implement a PCI MSI IRQ Domain in a module. PCI: Add fwnode_handle to pci_sysdata PCI: irqdomain: Look up IRQ domain by fwnode_handle drivers:hv: Define the channel type of Hyper-V PCI Express pass-through PCI: hv: New paravirtual PCI front-end for Hyper-V VMs MAINTAINERS|1 + arch/x86/include/asm/msi.h |6 + arch/x86/include/asm/pci.h | 15 + arch/x86/kernel/apic/msi.c |8 +- arch/x86/kernel/apic/vector.c |2 + drivers/hv/hv.c| 20 +- drivers/hv/hyperv_vmbus.h |2 +- drivers/hv/vmbus_drv.c | 17 + drivers/pci/Kconfig|7 + drivers/pci/host/Makefile |1 + drivers/pci/host/hv_pcifront.c | 2241 drivers/pci/msi.c |4 + drivers/pci/probe.c| 14 + include/asm-generic/pci.h |4 + include/linux/hyperv.h | 14 + kernel/irq/chip.c |1 + kernel/irq/irqdomain.c |4 + 17 files changed, 2347 insertions(+), 14 deletions(-) create mode 100644 drivers/pci/host/hv_pcifront.c -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v7 6/7] drivers:hv: Define the channel type of Hyper-V PCI Express pass-through
From: Jake Oshins
This defines the channel type for PCI front-ends in Hyper-V VMs.
Signed-off-by: Jake Oshins
---
include/linux/hyperv.h | 11 +++
1 file changed, 11 insertions(+)
diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h
index 24d0b65..c9a9eed 100644
--- a/include/linux/hyperv.h
+++ b/include/linux/hyperv.h
@@ -1141,6 +1141,17 @@ u64 hv_do_hypercall(u64 control, void *input, void
*output);
}
/*
+ * PCI Express Pass Through
+ * {44C4F61D--4400-9D52-802E27EDE19F}
+ */
+
+#define HV_PCIE_GUID \
+ .guid = { \
+ 0x1D, 0xF6, 0xC4, 0x44, 0x44, 0x44, 0x00, 0x44, \
+ 0x9D, 0x52, 0x80, 0x2E, 0x27, 0xED, 0xE1, 0x9F \
+ }
+
+/*
* Common header for Hyper-V ICs
*/
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v7 7/7] PCI: hv: New paravirtual PCI front-end for Hyper-V VMs
From: Jake Oshins
This patch introduces a new driver which exposes a root PCI bus whenever a
PCI Express device is passed through to a guest VM under Hyper-V. The
device can be single- or multi-function. The interrupts for the devices
are managed by an IRQ domain, implemented within the driver.
Signed-off-by: Jake Oshins
---
MAINTAINERS|1 +
drivers/pci/Kconfig|7 +
drivers/pci/host/Makefile |1 +
drivers/pci/host/hv_pcifront.c | 2241
4 files changed, 2250 insertions(+)
create mode 100644 drivers/pci/host/hv_pcifront.c
diff --git a/MAINTAINERS b/MAINTAINERS
index f3de001..9fd37fc 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5126,6 +5126,7 @@ F:arch/x86/kernel/cpu/mshyperv.c
F: drivers/hid/hid-hyperv.c
F: drivers/hv/
F: drivers/input/serio/hyperv-keyboard.c
+F: drivers/pci/host/hv_pcifront.c
F: drivers/net/hyperv/
F: drivers/scsi/storvsc_drv.c
F: drivers/video/fbdev/hyperv_fb.c
diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
index 73de4ef..9b82d93 100644
--- a/drivers/pci/Kconfig
+++ b/drivers/pci/Kconfig
@@ -118,4 +118,11 @@ config PCI_LABEL
def_bool y if (DMI || ACPI)
select NLS
+config HYPERV_VPCI
+tristate "Hyper-V PCI Frontend"
+depends on PCI && X86 && HYPERV && PCI_MSI && PCI_MSI_IRQ_DOMAIN
+help
+ The PCI device frontend driver allows the kernel to import arbitrary
+ PCI devices from a PCI backend to support PCI driver domains.
+
source "drivers/pci/host/Kconfig"
diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
index 9d4d3c6..d9abd2a 100644
--- a/drivers/pci/host/Makefile
+++ b/drivers/pci/host/Makefile
@@ -2,6 +2,7 @@ obj-$(CONFIG_PCIE_DW) += pcie-designware.o
obj-$(CONFIG_PCI_DRA7XX) += pci-dra7xx.o
obj-$(CONFIG_PCI_EXYNOS) += pci-exynos.o
obj-$(CONFIG_PCI_IMX6) += pci-imx6.o
+obj-$(CONFIG_HYPERV_VPCI) += hv_pcifront.o
obj-$(CONFIG_PCI_MVEBU) += pci-mvebu.o
obj-$(CONFIG_PCI_TEGRA) += pci-tegra.o
obj-$(CONFIG_PCI_RCAR_GEN2) += pci-rcar-gen2.o
diff --git a/drivers/pci/host/hv_pcifront.c b/drivers/pci/host/hv_pcifront.c
new file mode 100644
index 000..6023dea
--- /dev/null
+++ b/drivers/pci/host/hv_pcifront.c
@@ -0,0 +1,2241 @@
+/*
+ * Copyright (c) Microsoft Corporation.
+ *
+ * Author:
+ * Jake Oshins
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE, GOOD TITLE or
+ * NON INFRINGEMENT. See the GNU General Public License for more
+ * details.
+ *
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/*
+ * Protocol versions. The low word is the minor version, the high word the
major
+ * version.
+ */
+
+#define PCI_MAKE_VERSION(major, minor) ((__u32)(((major) << 16) | (major)))
+#define PCI_MAJOR_VERSION(version) ((__u32)(version) >> 16)
+#define PCI_MINOR_VERSION(version) ((__u32)(version) & 0xff)
+
+enum {
+ PCI_PROTOCOL_VERSION_1_1 = PCI_MAKE_VERSION(1, 1),
+ PCI_PROTOCOL_VERSION_CURRENT = PCI_PROTOCOL_VERSION_1_1
+};
+
+#define PCI_CONFIG_MMIO_LENGTH 0x2000
+#define MAX_SUPPORTED_MSI_MESSAGES 0x400
+
+/*
+ * Message Types
+ */
+
+enum pci_message_type {
+ /*
+* Version 1.1
+*/
+ PCI_MESSAGE_BASE= 0x4249,
+ PCI_BUS_RELATIONS = PCI_MESSAGE_BASE + 0,
+ PCI_QUERY_BUS_RELATIONS = PCI_MESSAGE_BASE + 1,
+ PCI_POWER_STATE_CHANGE = PCI_MESSAGE_BASE + 4,
+ PCI_QUERY_RESOURCE_REQUIREMENTS = PCI_MESSAGE_BASE + 5,
+ PCI_QUERY_RESOURCE_RESOURCES= PCI_MESSAGE_BASE + 6,
+ PCI_BUS_D0ENTRY = PCI_MESSAGE_BASE + 7,
+ PCI_BUS_D0EXIT = PCI_MESSAGE_BASE + 8,
+ PCI_READ_BLOCK = PCI_MESSAGE_BASE + 9,
+ PCI_WRITE_BLOCK = PCI_MESSAGE_BASE + 0xA,
+ PCI_EJECT = PCI_MESSAGE_BASE + 0xB,
+ PCI_QUERY_STOP = PCI_MESSAGE_BASE + 0xC,
+ PCI_REENABLE= PCI_MESSAGE_BASE + 0xD,
+ PCI_QUERY_STOP_FAILED = PCI_MESSAGE_BASE + 0xE,
+ PCI_EJECTION_COMPLETE = PCI_MESSAGE_BASE + 0xF,
+ PCI_RESOURCES_ASSIGNED = PCI_MESSAGE_BASE + 0x10,
+ PCI_RESOURCES_RELEASED = PCI_MESSAGE_BASE + 0x11,
+ PCI_INVALIDATE_BLOCK= PCI_MESSAGE_BASE + 0x12,
+ PCI_QUERY_PROTOCOL_VERSION = PCI_MESSAGE_BASE + 0x13,
+ PCI_CREATE_INTERRUPT_MESSAGE= PCI_MESSAGE_BASE + 0x14,
+ PCI_DELETE_INTERRUPT_MESSAGE=
[PATCH v7 1/7] drivers:hv: Export a function that maps Linux CPU num onto Hyper-V proc num
From: Jake Oshins
This patch exposes the mapping between Linux CPU number and Hyper-V
virtual processor number. This is necessary because the hypervisor needs
to know which virtual processor to target when making a mapping in the
Interrupt Redirection Table in the I/O MMU.
Signed-off-by: Jake Oshins
---
drivers/hv/vmbus_drv.c | 17 +
include/linux/hyperv.h | 2 ++
2 files changed, 19 insertions(+)
diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
index f19b6f7..c89d0e5 100644
--- a/drivers/hv/vmbus_drv.c
+++ b/drivers/hv/vmbus_drv.c
@@ -1191,6 +1191,23 @@ int vmbus_allocate_mmio(struct resource **new, struct
hv_device *device_obj,
}
EXPORT_SYMBOL_GPL(vmbus_allocate_mmio);
+/**
+ * vmbus_cpu_number_to_vp_number() - Map CPU to VP.
+ * @cpu_number: CPU number in Linux terms
+ *
+ * This function returns the mapping between the Linux processor
+ * number and the hypervisor's virtual processor number, useful
+ * in making hypercalls and such that talk about specific
+ * processors.
+ *
+ * Return: Virtual processor number in Hyper-V terms
+ */
+int vmbus_cpu_number_to_vp_number(int cpu_number)
+{
+ return hv_context.vp_index[cpu_number];
+}
+EXPORT_SYMBOL_GPL(vmbus_cpu_number_to_vp_number);
+
static int vmbus_acpi_add(struct acpi_device *device)
{
acpi_status result;
diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h
index 8fdc17b..fddb3e0 100644
--- a/include/linux/hyperv.h
+++ b/include/linux/hyperv.h
@@ -983,6 +983,8 @@ int vmbus_allocate_mmio(struct resource **new, struct
hv_device *device_obj,
resource_size_t size, resource_size_t align,
bool fb_overlap_ok);
+int vmbus_cpu_number_to_vp_number(int cpu_number);
+
/**
* VMBUS_DEVICE - macro used to describe a specific hyperv vmbus device
*
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v7 2/7] drivers:hv: Export hv_do_hypercall()
From: Jake Oshins
This patch exposes the function that hv_vmbus.ko uses to make hypercalls.
This is necessary for retargeting an interrupt when it is given a new
affinity and vector.
Signed-off-by: Jake Oshins
---
drivers/hv/hv.c | 20 ++--
drivers/hv/hyperv_vmbus.h | 2 +-
include/linux/hyperv.h| 1 +
3 files changed, 12 insertions(+), 11 deletions(-)
diff --git a/drivers/hv/hv.c b/drivers/hv/hv.c
index 6341be8..7a06933 100644
--- a/drivers/hv/hv.c
+++ b/drivers/hv/hv.c
@@ -89,9 +89,9 @@ static int query_hypervisor_info(void)
}
/*
- * do_hypercall- Invoke the specified hypercall
+ * hv_do_hypercall- Invoke the specified hypercall
*/
-static u64 do_hypercall(u64 control, void *input, void *output)
+u64 hv_do_hypercall(u64 control, void *input, void *output)
{
u64 input_address = (input) ? virt_to_phys(input) : 0;
u64 output_address = (output) ? virt_to_phys(output) : 0;
@@ -132,6 +132,7 @@ static u64 do_hypercall(u64 control, void *input, void
*output)
return hv_status_lo | ((u64)hv_status_hi << 32);
#endif /* !x86_64 */
}
+EXPORT_SYMBOL_GPL(hv_do_hypercall);
#ifdef CONFIG_X86_64
static cycle_t read_hv_clock_tsc(struct clocksource *arg)
@@ -315,7 +316,7 @@ int hv_post_message(union hv_connection_id connection_id,
{
struct hv_input_post_message *aligned_msg;
- u16 status;
+ u64 status;
if (payload_size > HV_MESSAGE_PAYLOAD_BYTE_COUNT)
return -EMSGSIZE;
@@ -329,11 +330,10 @@ int hv_post_message(union hv_connection_id connection_id,
aligned_msg->payload_size = payload_size;
memcpy((void *)aligned_msg->payload, payload, payload_size);
- status = do_hypercall(HVCALL_POST_MESSAGE, aligned_msg, NULL)
- & 0x;
+ status = hv_do_hypercall(HVCALL_POST_MESSAGE, aligned_msg, NULL);
put_cpu();
- return status;
+ return status & 0x;
}
@@ -343,13 +343,13 @@ int hv_post_message(union hv_connection_id connection_id,
*
* This involves a hypercall.
*/
-u16 hv_signal_event(void *con_id)
+int hv_signal_event(void *con_id)
{
- u16 status;
+ u64 status;
- status = (do_hypercall(HVCALL_SIGNAL_EVENT, con_id, NULL) & 0x);
+ status = hv_do_hypercall(HVCALL_SIGNAL_EVENT, con_id, NULL);
- return status;
+ return status & 0x;
}
static int hv_ce_set_next_event(unsigned long delta,
diff --git a/drivers/hv/hyperv_vmbus.h b/drivers/hv/hyperv_vmbus.h
index 3782636..cc2fb53 100644
--- a/drivers/hv/hyperv_vmbus.h
+++ b/drivers/hv/hyperv_vmbus.h
@@ -582,7 +582,7 @@ extern int hv_post_message(union hv_connection_id
connection_id,
enum hv_message_type message_type,
void *payload, size_t payload_size);
-extern u16 hv_signal_event(void *con_id);
+extern int hv_signal_event(void *con_id);
extern int hv_synic_alloc(void);
diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h
index fddb3e0..24d0b65 100644
--- a/include/linux/hyperv.h
+++ b/include/linux/hyperv.h
@@ -984,6 +984,7 @@ int vmbus_allocate_mmio(struct resource **new, struct
hv_device *device_obj,
bool fb_overlap_ok);
int vmbus_cpu_number_to_vp_number(int cpu_number);
+u64 hv_do_hypercall(u64 control, void *input, void *output);
/**
* VMBUS_DEVICE - macro used to describe a specific hyperv vmbus device
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH tip/core/rcu 1/8] documentation: Record RCU requirements
The content of the document seems fine; a few comments below on meta-issues. On Fri, Dec 04, 2015 at 03:50:19PM -0800, Paul E. McKenney wrote: > --- /dev/null > +++ b/Documentation/RCU/Design/Requirements/Requirements.html > @@ -0,0 +1,2799 @@ > + > + > + +"http://www.w3.org/TR/html4/loose.dtd;> Nit: these days, this should just be: > + > +A Tour Through RCU's Requirements [LWN.net] > + Is there a good reason to not use charset=utf-8 here? > + > +A Tour Through RCU's Requirements > + > +Copyright IBM Corporation, 2015 If you're aiming for a properly formatted copyright notice, the year typically comes first, followed by the copyright holder. That said, your corporate guidelines presumably have a specific format; is this that format? > +Author: Paul E.McKenney > +The initial version of this document appeared in the > +http://lwn.net/;>LWN articles > +http://lwn.net/Articles/652156/;>here, > +http://lwn.net/Articles/652677/;>here, and > +http://lwn.net/Articles/653326/;>here. s/http/https/g > + > +All that aside, here are the categories of currently known RCU requirements: > + > + > + > + Anchors don't typically have spaces in them. This may work in some browsers, but it doesn't validate. You should either use %20 or (better) use a '-'. > + > +This is followed by a summary, > +which is in turn followed by the inevitable > +answers to the quick quizzes. (Note: when editing anchors, don't forget to handle the target of this in the generation script.) > + > +This scenario resembles one of the first uses of RCU in > +http://en.wikipedia.org/wiki/DYNIX;>DYNIX/ptx, s/http/https/ > + > +However, this temptation must be resisted because there are a > +surprisingly large number of ways that the compiler > +(to say nothing of > +http://www.openvms.compaq.com/wizard/wiz_2637.html;>DEC Alpha > CPUs) This link sadly doesn't seem to work anymore; it redirects to HP's general page on OpenVMS, not a copy of that specific article.o Use this instead, assuming no current live version exists: https://web.archive.org/web/20120720095054/http://www.openvms.compaq.com/wizard/wiz_2637.html > + It is also easy to forget to use rcu_assign_pointer() > + and rcu_dereference(), perhaps (incorrectly) > + substituting a simple assignment. > + To catch this sort of error, a given RCU-protected pointer may be > + tagged with __rcu, after which running sparse > + with CONFIG_SPARSE_RCU_POINTER=y will complain > + about simple-assignment accesses to that pointer. > + Arnd Bergmann made me aware of this requirement, and also > + supplied the needed > + http://lwn.net/Articles/376011/;>patch series. s/http/https/ > + Open-coded use of rcu_assign_pointer() and > + rcu_dereference() to create typical linked > + data structures can be surprisingly error-prone. > + Therefore, RCU-protected > + http://lwn.net/Articles/609973/#RCU List APIs">linked lists s/http/https/ > + > +This all should be quite obvious, but the fact remains that > +Linus Torvalds recently had to > +http://marc.info/?l=linux-kernelm=142905739823385;>remind > +me of this requirement. I'd suggest using the lkml.kernel.org redirector for this link, along with a Message-Id. > + > +The name notwithstanding, some Linux-kernel architectures > +can have nested NMIs, which RCU must handle correctly. > +Andy Lutomirski > +https://lkml.org/lkml/2014/11/21/642;>surprised me > +with this requirement; > +he also kindly surprised me with > +https://lkml.org/lkml/2014/11/22/1;>an algorithm > +that meets this requirement. These links should both use lkml.kernel.org as well. Doubly important because lkml.org is often down or has broken messages in its archive. > + > +RCU therefore provides > +http://lwn.net/Articles/217484/;>rcu_barrier(), s/http/https/ > + > +This pair of mutual scheduler-RCU requirements came as a > +http://lwn.net/Articles/453002/;>complete surprise. s/http/https/ > +This requirement made its presence known after users made it > +clear that an earlier > +http://lwn.net/Articles/107930/;>real-time patch s/http/https/ > +did not meet their needs, in conjunction with some > +https://lkml.org/lkml/2005/3/17/199;>RCU issues lkml.kernel.org > + > +The > +http://lwn.net/Articles/609973/#RCU Per-Flavor API Table">RCU-bh > API s/http/https/ (and the same for all later lwn links in the document) - Josh Triplett -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH tip/core/rcu 1/8] documentation: Record RCU requirements
On Fri, Dec 04, 2015 at 04:07:19PM -0800, Josh Triplett wrote: > On Fri, Dec 04, 2015 at 03:50:19PM -0800, Paul E. McKenney wrote: > > This commit adds RCU requirements as published in a 2015 LWN series. > > Bringing these requirements in-tree allows them to be updated as changes > > are discovered. > > > > Signed-off-by: Paul E. McKenney > > --- > > .../RCU/Design/Requirements/2013-08-is-it-dead.png | Bin 0 -> 100825 bytes > > .../Design/Requirements/GPpartitionReaders1.svg| 374 +++ > > .../RCU/Design/Requirements/RCUApplicability.svg | 237 ++ > > .../Design/Requirements/ReadersPartitionGP1.svg| 639 + > > .../RCU/Design/Requirements/Requirements.html | 2799 > > > > .../RCU/Design/Requirements/Requirements.htmlx | 2643 > > ++ > > Documentation/RCU/Design/htmlqqz.sh| 108 + > > 7 files changed, 6800 insertions(+) > > create mode 100644 > > Documentation/RCU/Design/Requirements/2013-08-is-it-dead.png > > create mode 100644 > > Documentation/RCU/Design/Requirements/GPpartitionReaders1.svg > > create mode 100644 > > Documentation/RCU/Design/Requirements/RCUApplicability.svg > > create mode 100644 > > Documentation/RCU/Design/Requirements/ReadersPartitionGP1.svg > > create mode 100644 Documentation/RCU/Design/Requirements/Requirements.html > > create mode 100644 Documentation/RCU/Design/Requirements/Requirements.htmlx > > If Requirements.html is machine-generated and shouldn't be hand-edited, > and it can be generated without any special tools, then I don't think it > should be committed in the tree; I'd suggest putting it in .gitignore > and generating it from one of the various "make docs" invocations. I considered doing that, but then decided that it is nice for people to be able train their browser directly on the file without having to know what scripts to run. Hmmm... I suppose I could construct a Makefile that dealt with that though... I will give this some thought, and if it looks good, I will add the Makefiles and "git rm" the .htmlx files. > Alternatively, if you want to make sure a usable version is in-tree, you > could make the script reversible (easy enough to do if the compiled > version includes some marker comments or similar), and then tell people > to run it in reverse mode, edit, and run it in forward mode. Then you > don't need the .htmlx file at all. :) Decades ago, back when I (against all evidence) believed I could consistently avoid making stupid mistakes, you might have been able to convince me that this was a good idea. ;-) Thanx, Paul -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] add new platform driver for PCI RC
[+cc DT guys]
Hi Joao,
On Tue, Nov 24, 2015 at 02:32:05PM +, Joao Pinto wrote:
> This patch adds a new driver that will be the reference platform driver for
> all
> PCI RC IP Protoyping Kits based on ARC SDP. This patch is composed by:
>
> -Changes to pcie-designware driver add a function that enables the feature
> of starting the LTSSM (Link Train Status State) used by the new driver
> -MAINTAINERS file was updated to include the new driver
> -Documentation/devicetree/bindings/pci was updated to include the new driver
> documentation
> -New driver called pcie-snpsdev
>
> Signed-off-by: Joao Pinto
> ---
> .../devicetree/bindings/pci/pcie-snpsdev.txt | 28 ++
> MAINTAINERS| 7 +
> drivers/pci/host/Kconfig | 5 +
> drivers/pci/host/Makefile | 1 +
> drivers/pci/host/pcie-designware.c | 15 +
> drivers/pci/host/pcie-designware.h | 1 +
> drivers/pci/host/pcie-snpsdev.c| 342
> +
> 7 files changed, 399 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/pci/pcie-snpsdev.txt
> create mode 100644 drivers/pci/host/pcie-snpsdev.c
>
> diff --git a/Documentation/devicetree/bindings/pci/pcie-snpsdev.txt
> b/Documentation/devicetree/bindings/pci/pcie-snpsdev.txt
> new file mode 100644
> index 000..b833c8f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pci/pcie-snpsdev.txt
> @@ -0,0 +1,28 @@
> +Synopsys PCI RC IP Prototyping Kit
> +--
> +
> +This is the reference platform driver to be used in the Synopsys PCI RC IP
> +Prototyping Kits.
> +
> +Required properties:
> +- compatible: "snps,pcie-snpsdev";
> +- reg: A list of physical regions to access the device.
> +- interrupts: interrupt for the device.
> +- #address-cells: must be 3.
> +- #size-cells: must be 2.
> +
> +Example configuration:
> +
> + pcie: pcie@0xd000 {
> + #interrupt-cells = <1>;
> + compatible = "snps,pcie-snpsdev";
> + reg = <0xd000 0x1000>;
> + interrupts = <25>, <24>;
> + #address-cells = <3>;
> + #size-cells = <2>;
> + device_type = "pci";
> + ranges = <0x0800 0 0xd000 0xd000 0 0x2000
> + 0x8100 0 0x 0xde00 0 0x0001
> + 0x8200 0 0xd040 0xd040 0 0x0d00>;
> + num-lanes = <1>;
> + };
It'd be nice to get an ack from the DT guys (cc'd).
> diff --git a/MAINTAINERS b/MAINTAINERS
> index e9caa4b..d2e4506 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -8230,6 +8230,13 @@ S: Maintained
> F: Documentation/devicetree/bindings/pci/hisilicon-pcie.txt
> F: drivers/pci/host/pcie-hisi.c
>
> +PCI DRIVER FOR SYNOPSYS PROTOTYPING DEVICE
> +M: Joao Pinto
> +L: linux-...@vger.kernel.org
> +S: Maintained
> +F: Documentation/devicetree/bindings/pci/pcie-snpsdev.txt
> +F: drivers/pci/host/pcie-snpsdev.c
> +
> PCMCIA SUBSYSTEM
> P: Linux PCMCIA Team
> L: linux-pcm...@lists.infradead.org
> diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
> index f131ba9..a874b1e 100644
> --- a/drivers/pci/host/Kconfig
> +++ b/drivers/pci/host/Kconfig
> @@ -172,4 +172,9 @@ config PCI_HISI
> help
> Say Y here if you want PCIe controller support on HiSilicon HIP05 SoC
>
> +config PCIE_SNPSDEV
> + bool "Platform Driver for Synopsys Device"
> + select PCIEPORTBUS
> + select PCIE_DW
> +
> endmenu
> diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
> index 9d4d3c6..e422f65 100644
> --- a/drivers/pci/host/Makefile
> +++ b/drivers/pci/host/Makefile
> @@ -20,3 +20,4 @@ obj-$(CONFIG_PCIE_IPROC_BCMA) += pcie-iproc-bcma.o
> obj-$(CONFIG_PCIE_ALTERA) += pcie-altera.o
> obj-$(CONFIG_PCIE_ALTERA_MSI) += pcie-altera-msi.o
> obj-$(CONFIG_PCI_HISI) += pcie-hisi.o
> +obj-$(CONFIG_PCIE_SNPSDEV) += pcie-snpsdev.o
> diff --git a/drivers/pci/host/pcie-designware.c
> b/drivers/pci/host/pcie-designware.c
> index 540f077..3251695 100644
> --- a/drivers/pci/host/pcie-designware.c
> +++ b/drivers/pci/host/pcie-designware.c
> @@ -22,9 +22,15 @@
> #include
> #include
> #include
> +#include
> +#include
>
> #include "pcie-designware.h"
>
> +/* Synopsys Default PCIE Control and Status Register Memory-Mapped */
> +#define LINK_CONTROL_LINK_STATUS_REG 0x80
> +#define PCIE_RETRAIN_LINK_MASK(1<<5)
> +
> /* Synopsis specific PCIE configuration registers */
> #define PCIE_PORT_LINK_CONTROL 0x710
> #define PORT_LINK_MODE_MASK (0x3f << 16)
> @@ -706,6 +712,15 @@ static struct pci_ops dw_pcie_ops = {
> .write = dw_pcie_wr_conf,
> };
>
> +void dw_pcie_link_retrain(struct pcie_port *pp)
> +{
> + u32 val = 0;
> +
> + dw_pcie_readl_rc(pp, LINK_CONTROL_LINK_STATUS_REG, );
> + val = val |
Re: [PATCH] RTC: RK808: Work around hardware bug on November 31st
> If a device is in S3 for the whole day that the glitch occurs and then > we wake up then we'll end up thinking it's Dec 1st instead of Dec 2nd, > right? That case _could_ be handled by knowing that the last time we > read the clock it was before 12/1 and that this time it is after > 11/30. Then we add the extra day. In order to do this, we'd have to > know that we're on hardware with the glitch, which I guess could > either be done with a device tree property or by spending 1 second > probing the device at bootup (that would be a bit of a pain...). > > Obviously the trick above wouldn't handle if the clock ticked when the > device was in S5, but I'd imagine that most systems treat the RTC as > slightly questionable on an initial bootup anyway (though I'd imagine > that they rely on it working across S3). True, we could do that. I don't think it makes much sense to differentiate between S3 and S5 like that, though... the problem can happen just the same after both, and I don't think there's a practical difference in how systems treat that (if userspace has ways to double-check the system time, such as syncing to a network time source, it should really be doing that after both resume and reboot). Of course, building a work-around like that for S5 will become more complicated and requires persistent storage. For Chromium OS, we're already planning to improve tlsdated such that I don't think this will be an issue anymore (making it schedule a resync after resume, not just after reboot, which is a probably a good idea in general). For other systems that don't have any kind of network time sync, I think the best solution would be to handle this completely with a small userspace hook on boot and resume (because you probably need to access the file system to keep track of the last seen time anyway, you can do the device identification through /proc/device-tree just as well, and this avoids putting too much hacky workaround logic into the kernel). The other thing that would worry me about this approach is that it requires perfect identification of the problem, and Rockchip will hopefully eventually be able to fix this either in RK808 or a successor chip that might use the same RTC interface (and thus driver). Detecting it at boot is probably a bad idea because a crash/brownout at the wrong moment will permanently leave you with a bad time. I really think fixing this as best as we easily can and leaving the hard edge-cases to userspace is the best approach here. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
