Re: [PATCH 1/6] scsi_dh: get module reference outside of device handler
On 10/19/2014 05:59 PM, Christoph Hellwig wrote:
We need to grab a reference to the module before calling the attach
routines to avoid a small race vs module removal. It also cleans up
the code significantly as a side effect.
Signed-off-by: Christoph Hellwig h...@lst.de
---
drivers/scsi/device_handler/scsi_dh.c | 31
-
drivers/scsi/device_handler/scsi_dh_alua.c | 4
drivers/scsi/device_handler/scsi_dh_emc.c | 4
drivers/scsi/device_handler/scsi_dh_hp_sw.c | 4
drivers/scsi/device_handler/scsi_dh_rdac.c | 4
5 files changed, 22 insertions(+), 25 deletions(-)
diff --git a/drivers/scsi/device_handler/scsi_dh.c
b/drivers/scsi/device_handler/scsi_dh.c
index 33e422e..1a8dbf3 100644
--- a/drivers/scsi/device_handler/scsi_dh.c
+++ b/drivers/scsi/device_handler/scsi_dh.c
@@ -102,23 +102,36 @@ static int scsi_dh_handler_attach(struct scsi_device
*sdev,
if (sdev-scsi_dh_data) {
if (sdev-scsi_dh_data-scsi_dh != scsi_dh)
- err = -EBUSY;
- else
- kref_get(sdev-scsi_dh_data-kref);
- } else if (scsi_dh-attach) {
+ return -EBUSY;
+
+ kref_get(sdev-scsi_dh_data-kref);
+ return 0;
+ }
+
+ if (scsi_dh-attach) {
+ if (!try_module_get(scsi_dh-module))
+ return -EINVAL;
+
err = scsi_dh-attach(sdev);
- if (!err) {
- kref_init(sdev-scsi_dh_data-kref);
- sdev-scsi_dh_data-sdev = sdev;
+ if (err) {
+ module_put(scsi_dh-module);
+ return err;
}
+
+ kref_init(sdev-scsi_dh_data-kref);
+ sdev-scsi_dh_data-sdev = sdev;
}
return err;
}
static void __detach_handler (struct kref *kref)
{
- struct scsi_dh_data *scsi_dh_data = container_of(kref, struct
scsi_dh_data, kref);
- scsi_dh_data-scsi_dh-detach(scsi_dh_data-sdev);
+ struct scsi_dh_data *scsi_dh_data =
+ container_of(kref, struct scsi_dh_data, kref);
+ struct scsi_device_handler *scsi_dh = scsi_dh_data-scsi_dh;
+
+ scsi_dh-detach(scsi_dh_data-sdev);
+ module_put(scsi_dh-module);
}
/*
Is it guaranteed that you cannot call -attach() for devices which
already have a device_handler attached?
You've skipped the case
scsi_dh != sdev-scsi_dh_data-scsi_dh
IE someone called 'attach()' on a device which already has a
different device_handler attached to it.
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries Storage
h...@suse.de +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
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 05/16] usb: dwc3: add quirks support to be compatible for kinds of SoCs
On Fri, Oct 17, 2014 at 09:41:44AM -0500, Felipe Balbi wrote:
HI,
On Fri, Oct 17, 2014 at 04:53:30PM +0800, Huang Rui wrote:
This patch adds a quirks flag at dwc3 structure, and SoCs platform vendor is
able to define this flag in platform data at bus glue layer. Then do some
independent behaviors at dwc3 core level.
Signed-off-by: Huang Rui ray.hu...@amd.com
---
drivers/usb/dwc3/core.c | 2 ++
drivers/usb/dwc3/core.h | 3 +++
drivers/usb/dwc3/dwc3-pci.c | 9 +
drivers/usb/dwc3/platform_data.h | 2 ++
4 files changed, 16 insertions(+)
snip
diff --git a/drivers/usb/dwc3/platform_data.h
b/drivers/usb/dwc3/platform_data.h
index 7db34f0..1d3d65f 100644
--- a/drivers/usb/dwc3/platform_data.h
+++ b/drivers/usb/dwc3/platform_data.h
@@ -24,4 +24,6 @@ struct dwc3_platform_data {
enum usb_device_speed maximum_speed;
enum usb_dr_mode dr_mode;
bool tx_fifo_resize;
+
+ u32 quirks;
I prefer to have one-bit fields like we already have for delayed_status,
ep0_bounced, ep0_expect_in, and so on. That makes it easier to support
the same quirks through devicetree as well.
So it should define like below:
struct dwc3_platform_data {
...
unsigned one_quirk:1;
}
Then also defined it in dwc3 structure. And when dwc3 probed, put this
value from glue layer to dwc3, right?
Thanks,
Rui
--
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 2/6] scsi: use container_of to get at device handler private data
On 10/19/2014 06:00 PM, Christoph Hellwig wrote: Signed-off-by: Christoph Hellwig h...@lst.de Reviewed-by: Hannes Reinecke h...@suse.de Cheers, Hannes -- Dr. Hannes Reinecke zSeries Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- 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 3/6] scsi: remove struct scsi_dh_devlist
On 10/19/2014 06:00 PM, Christoph Hellwig wrote:
All drivers now do their own matching, so there is no more need to expose
a device list as part of the interface.
Signed-off-by: Christoph Hellwig h...@lst.de
---
drivers/scsi/device_handler/scsi_dh_emc.c | 6 --
drivers/scsi/device_handler/scsi_dh_hp_sw.c | 6 --
drivers/scsi/device_handler/scsi_dh_rdac.c | 6 --
include/scsi/scsi_device.h | 6 --
4 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/scsi/device_handler/scsi_dh_emc.c
b/drivers/scsi/device_handler/scsi_dh_emc.c
index c2e26cd..800deb7 100644
--- a/drivers/scsi/device_handler/scsi_dh_emc.c
+++ b/drivers/scsi/device_handler/scsi_dh_emc.c
@@ -622,7 +622,10 @@ done:
return result;
}
-static const struct scsi_dh_devlist clariion_dev_list[] = {
+static const struct {
+ char *vendor;
+ char *model;
+} clariion_dev_list[] = {
{DGC, RAID},
{DGC, DISK},
{DGC, VRAID},
@@ -653,7 +656,6 @@ static void clariion_bus_detach(struct scsi_device *sdev);
static struct scsi_device_handler clariion_dh = {
.name = CLARIION_NAME,
.module = THIS_MODULE,
- .devlist= clariion_dev_list,
.attach = clariion_bus_attach,
.detach = clariion_bus_detach,
.check_sense= clariion_check_sense,
diff --git a/drivers/scsi/device_handler/scsi_dh_hp_sw.c
b/drivers/scsi/device_handler/scsi_dh_hp_sw.c
index 040998c..aa40fcb 100644
--- a/drivers/scsi/device_handler/scsi_dh_hp_sw.c
+++ b/drivers/scsi/device_handler/scsi_dh_hp_sw.c
@@ -311,7 +311,10 @@ static int hp_sw_activate(struct scsi_device *sdev,
return 0;
}
-static const struct scsi_dh_devlist hp_sw_dh_data_list[] = {
+static const struct {
+ char *vendor;
+ char *model;
+} hp_sw_dh_data_list[] = {
{COMPAQ, MSA1000 VOLUME},
{COMPAQ, HSV110},
{HP, HSV100},
@@ -343,7 +346,6 @@ static void hp_sw_bus_detach(struct scsi_device *sdev);
static struct scsi_device_handler hp_sw_dh = {
.name = HP_SW_NAME,
.module = THIS_MODULE,
- .devlist= hp_sw_dh_data_list,
.attach = hp_sw_bus_attach,
.detach = hp_sw_bus_detach,
.activate = hp_sw_activate,
diff --git a/drivers/scsi/device_handler/scsi_dh_rdac.c
b/drivers/scsi/device_handler/scsi_dh_rdac.c
index ef8caaa..8b09528 100644
--- a/drivers/scsi/device_handler/scsi_dh_rdac.c
+++ b/drivers/scsi/device_handler/scsi_dh_rdac.c
@@ -778,7 +778,10 @@ static int rdac_check_sense(struct scsi_device *sdev,
return SCSI_RETURN_NOT_HANDLED;
}
-static const struct scsi_dh_devlist rdac_dev_list[] = {
+static const struct {
+ char *vendor;
+ char *model;
+} rdac_dev_list[] = {
{IBM, 1722},
{IBM, 1724},
{IBM, 1726},
@@ -830,7 +833,6 @@ static void rdac_bus_detach(struct scsi_device *sdev);
static struct scsi_device_handler rdac_dh = {
.name = RDAC_NAME,
.module = THIS_MODULE,
- .devlist = rdac_dev_list,
.prep_fn = rdac_prep_fn,
.check_sense = rdac_check_sense,
.attach = rdac_bus_attach,
diff --git a/include/scsi/scsi_device.h b/include/scsi/scsi_device.h
index fb46864..ba6c9b7 100644
--- a/include/scsi/scsi_device.h
+++ b/include/scsi/scsi_device.h
@@ -201,11 +201,6 @@ struct scsi_device {
unsigned long sdev_data[0];
} __attribute__((aligned(sizeof(unsigned long;
-struct scsi_dh_devlist {
- char *vendor;
- char *model;
-};
-
typedef void (*activate_complete)(void *, int);
struct scsi_device_handler {
/* Used by the infrastructure */
@@ -214,7 +209,6 @@ struct scsi_device_handler {
/* Filled by the hardware handler */
struct module *module;
const char *name;
- const struct scsi_dh_devlist *devlist;
int (*check_sense)(struct scsi_device *, struct scsi_sense_hdr *);
int (*attach)(struct scsi_device *);
void (*detach)(struct scsi_device *);
Reviewed-by: Hannes Reinecke h...@suse.de
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries Storage
h...@suse.de +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
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/6] scsi: device handlers must have attach and detach methods
On 10/19/2014 06:00 PM, Christoph Hellwig wrote:
Signed-off-by: Christoph Hellwig h...@lst.de
---
drivers/scsi/device_handler/scsi_dh.c | 25 +
1 file changed, 13 insertions(+), 12 deletions(-)
diff --git a/drivers/scsi/device_handler/scsi_dh.c
b/drivers/scsi/device_handler/scsi_dh.c
index 1a8dbf3..d8a8aac 100644
--- a/drivers/scsi/device_handler/scsi_dh.c
+++ b/drivers/scsi/device_handler/scsi_dh.c
@@ -108,19 +108,17 @@ static int scsi_dh_handler_attach(struct scsi_device
*sdev,
return 0;
}
- if (scsi_dh-attach) {
- if (!try_module_get(scsi_dh-module))
- return -EINVAL;
-
- err = scsi_dh-attach(sdev);
- if (err) {
- module_put(scsi_dh-module);
- return err;
- }
+ if (!try_module_get(scsi_dh-module))
+ return -EINVAL;
- kref_init(sdev-scsi_dh_data-kref);
- sdev-scsi_dh_data-sdev = sdev;
+ err = scsi_dh-attach(sdev);
+ if (err) {
+ module_put(scsi_dh-module);
+ return err;
}
+
+ kref_init(sdev-scsi_dh_data-kref);
+ sdev-scsi_dh_data-sdev = sdev;
return err;
}
@@ -154,7 +152,7 @@ static void scsi_dh_handler_detach(struct scsi_device
*sdev,
if (!scsi_dh)
scsi_dh = sdev-scsi_dh_data-scsi_dh;
- if (scsi_dh scsi_dh-detach)
+ if (scsi_dh)
kref_put(sdev-scsi_dh_data-kref, __detach_handler);
}
@@ -343,6 +341,9 @@ int scsi_register_device_handler(struct
scsi_device_handler *scsi_dh)
if (get_device_handler(scsi_dh-name))
return -EBUSY;
+ if (!scsi_dh-attach || !scsi_dh-detach)
+ return -EINVAL;
+
spin_lock(list_lock);
list_add(scsi_dh-list, scsi_dh_list);
spin_unlock(list_lock);
Reviewed-by: Hannes Reinecke h...@suse.de
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries Storage
h...@suse.de +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
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 5/6] scsi_dh_hp_sw: fix return value on failed allocation
On 10/19/2014 06:00 PM, Christoph Hellwig wrote:
Signed-off-by: Christoph Hellwig h...@lst.de
---
drivers/scsi/device_handler/scsi_dh_hp_sw.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/scsi/device_handler/scsi_dh_hp_sw.c
b/drivers/scsi/device_handler/scsi_dh_hp_sw.c
index aa40fcb..471ffd1 100644
--- a/drivers/scsi/device_handler/scsi_dh_hp_sw.c
+++ b/drivers/scsi/device_handler/scsi_dh_hp_sw.c
@@ -363,7 +363,7 @@ static int hp_sw_bus_attach(struct scsi_device *sdev)
if (!h) {
sdev_printk(KERN_ERR, sdev, %s: Attach Failed\n,
HP_SW_NAME);
- return 0;
+ return -ENOMEM;
}
h-dh_data.scsi_dh = hp_sw_dh;
Reviewed-by: Hannes Reinecke h...@suse.de
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries Storage
h...@suse.de +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
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 6/6] scsi: handle more device handler setup/teardown in common code
On 10/19/2014 06:00 PM, Christoph Hellwig wrote: Move all code to set up and tear down sdev-scsi_dh_data to common code. Signed-off-by: Christoph Hellwig h...@lst.de Reviewed-by: Hannes Reinecke h...@suse.de Cheers, Hannes -- Dr. Hannes Reinecke zSeries Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- 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: [RESUBMIT PATCH v4 7/8] regulator: sky81452: Add compatible string for device binding
On Fri, Oct 17, 2014 at 04:26:05PM +0200, Mark Brown wrote: On Fri, Oct 17, 2014 at 07:43:09PM +0900, Gyungoh Yoo wrote: Are you talking about simplification using of_regulator_match()? This driver has only one regulator. Is the API also useful for this driver? The thing I'm seeing is that the binding for your device with the subnode looks very much like the device trees of devices with multiple regulators. The fact that you only have one regulator is a bit difference but not that much. It seems like drivers should fit into one of two patterns: either the regulator is described in the root node for the device for single purpose devices or there should be a collection of regulators like is supported with this helper API. Having a collection with only one node doesn't seem to be a problem in any way. Like reg-fixed-voltage, how about using of_get_fixed_voltage_config()? The driver doesn't seem to need any property parsing of its own so it shoudn't need anything beyond basic calls into the core. Thank you for your kind comments. My understanding is getting better. For my clear understanding: I think the original designed which I wanted to design is similar with arizona-ldo1.c It seems that this is 1st pattern your explained above. Can I ask what is different between arizona-ldo1.c and this sky81452-regulator.c? I think both are designed under root node. Thank you. -- 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] cpufreq: qoriq: Make the driver usable on all QorIQ platforms
Thanks for your comments. Your comments will be addressed in next version.
Some explanations inline.
Thanks,
Yuantian
-Original Message-
From: Viresh Kumar [mailto:viresh.ku...@linaro.org]
Sent: Friday, October 17, 2014 4:09 PM
To: Tang Yuantian-B29983
Cc: Rafael J. Wysocki; Linux Kernel Mailing List; linux...@vger.kernel.org;
linuxppc-...@ozlabs.org; Tang Yuantian-B29983
Subject: Re: [PATCH] cpufreq: qoriq: Make the driver usable on all QorIQ
platforms
On 17 October 2014 08:43, b29...@freescale.com wrote:
Hi B29983 :)
From: Tang Yuantian yuantian.t...@freescale.com
Freescale introduced new ARM core-based SoCs which support dynamic
frequency switch feature. DFS on new SoCs are compatible with current
PowerPC CoreNet platforms. In order to support those new platforms,
this driver needs to be slightly adjusted. The main changes include:
1. Changed the names of driver and functions in driver.
2. Added two new functions get_cpu_physical_id() and get_bus_freq().
3. Used a new way to get all the CPUs which sharing clock wire.
Signed-off-by: Tang Yuantian yuantian.t...@freescale.com
---
drivers/cpufreq/Kconfig.arm| 8 ++
drivers/cpufreq/Kconfig.powerpc| 11 +-
drivers/cpufreq/Makefile | 2 +-
.../{ppc-corenet-cpufreq.c = qoriq-cpufreq.c} | 150
++---
4 files changed, 114 insertions(+), 57 deletions(-) rename
drivers/cpufreq/{ppc-corenet-cpufreq.c = qoriq-cpufreq.c} (72%)
diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index 83a75dc..1925ae94 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -247,3 +247,11 @@ config ARM_TEGRA_CPUFREQ
default y
help
This adds the CPUFreq driver support for TEGRA SOCs.
+
+config QORIQ_CPUFREQ
+ tristate CPU frequency scaling driver for Freescale QorIQ SoCs
+ depends on OF COMMON_CLK
+ select CLK_PPC_CORENET
+ help
+ This adds the CPUFreq driver support for Freescale QorIQ SoCs
+ which are capable of changing the CPU's frequency dynamically.
diff --git a/drivers/cpufreq/Kconfig.powerpc
b/drivers/cpufreq/Kconfig.powerpc index 72564b7..3a34248 100644
--- a/drivers/cpufreq/Kconfig.powerpc
+++ b/drivers/cpufreq/Kconfig.powerpc
@@ -23,14 +23,13 @@ config CPU_FREQ_MAPLE
This adds support for frequency switching on Maple 970FX
Evaluation Board and compatible boards (IBM JS2x blades).
-config PPC_CORENET_CPUFREQ
- tristate CPU frequency scaling driver for Freescale E500MC SoCs
- depends on PPC_E500MC OF COMMON_CLK
+config QORIQ_CPUFREQ
+ tristate CPU frequency scaling driver for Freescale QorIQ SoCs
+ depends on OF COMMON_CLK
select CLK_PPC_CORENET
help
- This adds the CPUFreq driver support for Freescale e500mc,
- e5500 and e6500 series SoCs which are capable of changing
- the CPU's frequency dynamically.
+ This adds the CPUFreq driver support for Freescale QorIQ SoCs
+ which are capable of changing the CPU's frequency dynamically.
config CPU_FREQ_PMAC
bool Support for Apple PowerBooks
Don't need this duplication at all. Just move this to Kconfig instead of .arm
and
ppc.
diff --git a/drivers/cpufreq/ppc-corenet-cpufreq.c
b/drivers/cpufreq/qoriq-cpufreq.c
/**
* struct cpu_data - per CPU data struct @@ -69,9 +68,6 @@ static
const u32 *fmask;
static DEFINE_PER_CPU(struct cpu_data *, cpu_data);
-/* cpumask in a cluster */
-static DEFINE_PER_CPU(cpumask_var_t, cpu_mask);
-
#ifndef CONFIG_SMP
static inline const struct cpumask *cpu_core_mask(int cpu) { @@
-79,6 +75,79 @@ static inline const struct cpumask *cpu_core_mask(int
cpu) } #endif
+#if defined(CONFIG_PPC_E500MC)
+static int get_cpu_physical_id(int cpu) {
+ return get_hard_smp_processor_id(cpu); } #elif
+defined(CONFIG_ARM)
Wouldn't a #else work here as there are just two platforms we are talking
about ?
+static int get_cpu_physical_id(int cpu) {
+ return topology_core_id(cpu);
+}
+#endif
+
+static u32 get_bus_freq(void)
+{
+ struct device_node *soc;
+ u32 sysfreq;
+
+ soc = of_find_node_by_type(NULL, soc);
+ if (!soc)
+ return 0;
+
+ if (of_property_read_u32(soc, bus-frequency, sysfreq))
+ sysfreq = 0;
+
+ of_node_put(soc);
+
+ return sysfreq;
+}
+
+static struct device_node *cpu_to_clk_node(int cpu) {
+ struct device_node *np, *clk_np;
+
+ if (!cpu_present(cpu))
+ return NULL;
+
+ np = of_get_cpu_node(cpu, NULL);
+ if (!np)
+ return NULL;
+
+ clk_np = of_parse_phandle(np, clocks, 0);
+ if
To Erich Schubert of Debian: What have you done? Male-Fminist fggt.
A few thousands of downloads of packages larger than some linux distros say otherwise. Testimony of those who have enjoyed my work aswell. But you don't know the half of it. You've created a few scripts, small programs. Atleast it's more than your female co-patriots. How many terabytes have you moved? Of that which is your own. Erich Schubert Your contributions are useless crap. Nobody is interested in them, and that's why you have these mental issues.\ufeff -- 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 v5 10/12] gpio: Support for unified device properties interface
On Sat, Oct 18, 2014 at 6:47 PM, Arnd Bergmann a...@arndb.de wrote: On Friday 17 October 2014 20:09:51 Arnd Bergmann wrote: On October 17, 2014 2:16:00 PM CEST, Rafael J. Wysocki r...@rjwysocki.net wrote: From: Mika Westerberg mika.westerb...@linux.intel.com Some drivers need to deal with only firmware representation of its GPIOs. An example would be a GPIO button array driver where each button is described as a separate firmware node in device tree. Typically these child nodes do not have physical representation in the Linux device model. In order to help device drivers to handle such firmware child nodes we add dev[m]_get_named_gpiod_from_child() that takes a child firmware node pointer as its second argument (the first one is the parent device itself), finds the GPIO using whatever is the underlying firmware method, and requests the GPIO properly. Could we also have a wrapper around this function without a name argument, using just the index? Expanding on this thought: I think we should mandate for new bindings that they use either a name and no index, or an index but not name, I'm afraid this could forbid some useful use-cases, namely the ones where several GPIOs serve the same function (and are typically set together). We had a few patch proposals to handle such GPIO groups, and even though one was in pretty good shape the submitter did not push it until the end. :/ But my concern is that instead of having this: enable-gpio = gpio 0 GPIO_ACTIVE_HIGH; value-gpios = gpio 1 GPIO_ACTIVE_HIGH ... gpio 8 GPIO_ACTIVE_HIGH; We would force this: enable-gpio = gpio 0 GPIO_ACTIVE_HIGH; value0-gpio = gpio 1 GPIO_ACTIVE_HIGH; ... value7-gpio = gpio 8 GPIO_ACTIVE_HIGH; Or this: // First GPIO is enable, other GPIOs are value gpios = gpio 0 GPIO_ACTIVE_HIGH gpio 1 GPIO_ACTIVE_HIGH ... gpio 8 GPIO_ACTIVE_HIGH; Most bindings don't need that much sophistication, and for these we should indeed make sure that they stick to using either the names or index (and in a consistent manner), but closing the possibility to use both together may bite us in the end. and I also think that for named gpios, we should try to converge on a common naming scheme. As discussed, we will probably want to support all the existing ways to do this even with ACPI and with the unified interface, but it doesn't have to be the obvious way. Personally, I like the idea that each GPIO has a function, so now that ACPI fully supports this I'd suggest the policy of using names for each GPIO (e.g. never use the fallback gpios or gpio property), and only ressort to indexes if several GPIOs happen to serve the same function. I know we haven't reached consensus about this so far, but it would be nice it we could discuss this point again in the light of the new ACPI capabilities and come with something to write as a guideline in the GPIO documentation. -- 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 1/1][v2] IFC: Change IO accessor based on endianness
From: Jaiprakash Singh b44...@freescale.com
IFC registers can be of type Little Endian
or big Endian depending upon Freescale SoC.
Here SoC defines the register type of
IFC IP.So update accessors functions with
common IFC accessors functions to take
care both type of endianness.
IFC IO accressor are set at run time based
on IFC IP registers endianness.IFC node in
DTS file contains information about
endianness.
Signed-off-by: Jaiprakash Singh b44...@freescale.com
---
Changes for v2
- Moved IFC accessor function to fsl_ifc.h
from fsl_ifc.c and make them inline static
.../bindings/memory-controllers/fsl/ifc.txt|2 +
drivers/memory/fsl_ifc.c | 72 ++
drivers/mtd/nand/fsl_ifc_nand.c| 151 +++-
include/linux/fsl_ifc.h| 42 ++
4 files changed, 167 insertions(+), 100 deletions(-)
diff --git a/Documentation/devicetree/bindings/memory-controllers/fsl/ifc.txt
b/Documentation/devicetree/bindings/memory-controllers/fsl/ifc.txt
index d5e3704..ee6226b 100644
--- a/Documentation/devicetree/bindings/memory-controllers/fsl/ifc.txt
+++ b/Documentation/devicetree/bindings/memory-controllers/fsl/ifc.txt
@@ -18,6 +18,8 @@ Properties:
interrupt (NAND_EVTER_STAT). If there is only one,
that interrupt reports both types of event.
+- little-endian : If this property is absent, the big-endian mode will
+ be in use as default for registers.
- ranges : Each range corresponds to a single chipselect, and covers
the entire access window as configured.
diff --git a/drivers/memory/fsl_ifc.c b/drivers/memory/fsl_ifc.c
index 3d5d792..5689e9b 100644
--- a/drivers/memory/fsl_ifc.c
+++ b/drivers/memory/fsl_ifc.c
@@ -62,7 +62,8 @@ int fsl_ifc_find(phys_addr_t addr_base)
return -ENODEV;
for (i = 0; i ARRAY_SIZE(fsl_ifc_ctrl_dev-regs-cspr_cs); i++) {
- u32 cspr = in_be32(fsl_ifc_ctrl_dev-regs-cspr_cs[i].cspr);
+ u32 cspr = ifc_in32(
+ fsl_ifc_ctrl_dev-regs-cspr_cs[i].cspr);
if (cspr CSPR_V (cspr CSPR_BA) ==
convert_ifc_address(addr_base))
return i;
@@ -79,16 +80,16 @@ static int fsl_ifc_ctrl_init(struct fsl_ifc_ctrl *ctrl)
/*
* Clear all the common status and event registers
*/
- if (in_be32(ifc-cm_evter_stat) IFC_CM_EVTER_STAT_CSER)
- out_be32(ifc-cm_evter_stat, IFC_CM_EVTER_STAT_CSER);
+ if (ifc_in32(ifc-cm_evter_stat) IFC_CM_EVTER_STAT_CSER)
+ ifc_out32(IFC_CM_EVTER_STAT_CSER, ifc-cm_evter_stat);
/* enable all error and events */
- out_be32(ifc-cm_evter_en, IFC_CM_EVTER_EN_CSEREN);
+ ifc_out32(IFC_CM_EVTER_EN_CSEREN, ifc-cm_evter_en);
/* enable all error and event interrupts */
- out_be32(ifc-cm_evter_intr_en, IFC_CM_EVTER_INTR_EN_CSERIREN);
- out_be32(ifc-cm_erattr0, 0x0);
- out_be32(ifc-cm_erattr1, 0x0);
+ ifc_out32(IFC_CM_EVTER_INTR_EN_CSERIREN, ifc-cm_evter_intr_en);
+ ifc_out32(0x0, ifc-cm_erattr0);
+ ifc_out32(0x0, ifc-cm_erattr1);
return 0;
}
@@ -127,9 +128,9 @@ static u32 check_nand_stat(struct fsl_ifc_ctrl *ctrl)
spin_lock_irqsave(nand_irq_lock, flags);
- stat = in_be32(ifc-ifc_nand.nand_evter_stat);
+ stat = ifc_in32(ifc-ifc_nand.nand_evter_stat);
if (stat) {
- out_be32(ifc-ifc_nand.nand_evter_stat, stat);
+ ifc_out32(stat, ifc-ifc_nand.nand_evter_stat);
ctrl-nand_stat = stat;
wake_up(ctrl-nand_wait);
}
@@ -161,36 +162,37 @@ static irqreturn_t fsl_ifc_ctrl_irq(int irqno, void *data)
irqreturn_t ret = IRQ_NONE;
/* read for chip select error */
- cs_err = in_be32(ifc-cm_evter_stat);
+ cs_err = ifc_in32(ifc-cm_evter_stat);
if (cs_err) {
- dev_err(ctrl-dev, transaction sent to IFC is not mapped to
- any memory bank 0x%08X\n, cs_err);
+ dev_err(ctrl-dev, transaction sent to IFC is not mapped to);
+ dev_err(ctrl-dev, any memory bank 0x%08X\n, cs_err);
+
/* clear the chip select error */
- out_be32(ifc-cm_evter_stat, IFC_CM_EVTER_STAT_CSER);
+ ifc_out32(IFC_CM_EVTER_STAT_CSER, ifc-cm_evter_stat);
/* read error attribute registers print the error information */
- status = in_be32(ifc-cm_erattr0);
- err_addr = in_be32(ifc-cm_erattr1);
-
- if (status IFC_CM_ERATTR0_ERTYP_READ)
- dev_err(ctrl-dev, Read transaction error
- CM_ERATTR0 0x%08X\n, status);
- else
- dev_err(ctrl-dev, Write transaction error
- CM_ERATTR0
INFO: task echo:622 blocked for more than 120 seconds. - 3.18.0-0.rc0.git
02:00.0 VGA compatible controller:
NVIDIA Corporation G98 [GeForce 8400 GS Rev. 2] (rev a1)
Chipset: G98 (NV98)
Family : NV50
The same for all four kernel:
- 3.18.0-0.rc0.git8.1.fc22.x86_64
- 3.18.0-0.rc0.git9.1.fc22.x86_64
- 3.18.0-0.rc0.git9.3.fc22.x86_64
- 3.18.0-0.rc0.git9.4.fc22.x86_64
after
fb: switching to nouveaufb from VESA VGA
display is powered off.
The magic SysRq key sequence is necessary to reboot.
Yet reached this this one recital:
...
[5.860996] [drm] Initialized nouveau 1.2.1 20120801 for :02:00.0 on
minor 0
...
[ 240.229058] INFO: task echo:622 blocked for more than 120 seconds.
[ 240.229594] Not tainted 3.18.0-0.rc0.git9.3.fc22.x86_64 #1
[ 240.230149] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this
message.
[ 240.230661] echoD 8800c82a3480 12472 622 1 0x0004
[ 240.231230] 8800ca2e3ac8 0096 8800c82a3480
001d5f00
[ 240.231784] 8800ca2e3fd8 001d5f00 880128bf
8800c82a3480
[ 240.232344] 82c30990 7fff 81ee2698
81ee2690
[ 240.232931] Call Trace:
[ 240.233467] [8185baf9] schedule+0x29/0x70
[ 240.234025] [81860d1c] schedule_timeout+0x26c/0x410
[ 240.234562] [81028c4a] ? native_sched_clock+0x2a/0xa0
[ 240.235118] [811078bc] ? mark_held_locks+0x7c/0xb0
[ 240.235645] [81861da0] ? _raw_spin_unlock_irq+0x30/0x50
[ 240.236198] [81107a4d] ? trace_hardirqs_on_caller+0x15d/0x200
[ 240.236729] [8185d52c] wait_for_completion+0x10c/0x150
[ 240.237290] [810e51f0] ? wake_up_state+0x20/0x20
[ 240.237842] [8112a559] _rcu_barrier+0x159/0x200
[ 240.238375] [8112a655] rcu_barrier+0x15/0x20
[ 240.238913] [8171813f] netdev_run_todo+0x6f/0x310
[ 240.239449] [817251ae] rtnl_unlock+0xe/0x10
[ 240.23] [8170ea35] unregister_netdev+0x25/0x30
[ 240.240546] [a00222d2] rtl_remove_one+0x62/0x230 [r8169]
[ 240.241104] [814682cf] pci_device_remove+0x3f/0xc0
[ 240.241642] [8155b34f] __device_release_driver+0x7f/0xf0
[ 240.242180] [8155b3e5] device_release_driver+0x25/0x40
[ 240.242712] [8146234c] pci_stop_bus_device+0x9c/0xb0
[ 240.243259] [8146248e]
pci_stop_and_remove_bus_device_locked+0x1e/0x40
[ 240.243785] [8146b44c] remove_store+0x7c/0x90
[ 240.244321] [81555f98] dev_attr_store+0x18/0x30
[ 240.244858] [81302789] sysfs_kf_write+0x49/0x60
[ 240.245375] [81301ac9] kernfs_fop_write+0xf9/0x180
[ 240.245921] [8127305a] vfs_write+0xba/0x200
[ 240.246439] [8186379c] ? retint_swapgs+0x13/0x1b
[ 240.246978] [81273bac] SyS_write+0x5c/0xd0
[ 240.247491] [81862b69] system_call_fastpath+0x12/0x17
[ 240.248025] 6 locks held by echo/622:
[ 240.248532] #0: (sb_writers#3){.+.+.+}, at: [81273143]
vfs_write+0x1a3/0x200
[ 240.249104] #1: (of-mutex){+.+.+.}, at: [81301a97]
kernfs_fop_write+0xc7/0x180
[ 240.249651] #2: (s_active#131){++}, at: [81300ce4]
kernfs_remove_self+0xf4/0x170
[ 240.250229] #3: (pci_rescan_remove_lock){+.+.+.}, at: [8145f167]
pci_lock_rescan_remove+0x17/0x20
[ 240.250779] #4: (dev-mutex){..}, at: [8155b3dd]
device_release_driver+0x1d/0x40
[ 240.251358] #5: (rcu_sched_state.barrier_mutex){+.+...}, at:
[8112a435] _rcu_barrier+0x35/0x200
[ 241.303095] systemd[1]: start request repeated too quickly for
lightdm.service
[ 241.323052] systemd[1]: Unit lightdm.service entered failed state.
[ 241.333101] systemd[1]: lightdm.service failed.
[ 359.038325] INFO: task kworker/u16:2:81 blocked for more than 120 seconds.
[ 359.039475] Not tainted 3.18.0-0.rc0.git9.3.fc22.x86_64 #1
[ 359.040004] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this
message.
[ 359.040571] kworker/u16:2 D 880128131a40 1089681 2 0x
[ 359.041162] Workqueue: netns cleanup_net
[ 359.041701] 8801275bba88 0096 880128131a40
001d5f00
[ 359.042280] 8801275bbfd8 001d5f00 880128bf3480
880128131a40
[ 359.042856] 880128131a40 81ee25e8 0246
880128131a40
[ 359.043436] Call Trace:
[ 359.043975] [8185c0a1] schedule_preempt_disabled+0x31/0x80
[ 359.044542] [8185d8f3] mutex_lock_nested+0x183/0x440
[ 359.045108] [8112a435] ? _rcu_barrier+0x35/0x200
[ 359.045647] [81028c4a] ? native_sched_clock+0x2a/0xa0
[ 359.046218] [8112a435] ? _rcu_barrier+0x35/0x200
[ 359.046767] [8185f914] ? __mutex_unlock_slowpath+0xc4/0x1c0
[ 359.047333] [8112a435] _rcu_barrier+0x35/0x200
[ 359.047875] [8112a655] rcu_barrier+0x15/0x20
[ 359.048433] [8171813f] netdev_run_todo+0x6f/0x310
[ 359.048969] [8170cd35] ? rollback_registered_many+0x265/0x2e0
[ 359.049528]
A sng Lennart Poettering et al should consider (I am the highway - Audioslave)
A song Lennart Poettering et al should consider (I am the highway - Audioslave) I am not your rolling wheels - I am the highway I am not your carpet ride - I am the sky as it pertains to he and his vis a vis the free software community, which was here. youtu.be/hWlkmkZW2hk -- 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 06/16] usb: dwc3: add disscramble quirk
On Fri, Oct 17, 2014 at 09:45:32AM -0500, Felipe Balbi wrote:
Hi,
On Fri, Oct 17, 2014 at 04:53:31PM +0800, Huang Rui wrote:
AMD NL fpga needs to enable disscramble quirk. And this quirk doesn't need
on
the true soc.
Signed-off-by: Huang Rui ray.hu...@amd.com
---
drivers/usb/dwc3/core.c | 8 +++-
drivers/usb/dwc3/dwc3-pci.c | 5 +
drivers/usb/dwc3/platform_data.h | 4
3 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 50c0eae..819e501 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -422,7 +422,6 @@ static int dwc3_core_init(struct dwc3 *dwc)
reg = dwc3_readl(dwc-regs, DWC3_GCTL);
reg = ~DWC3_GCTL_SCALEDOWN_MASK;
- reg = ~DWC3_GCTL_DISSCRAMBLE;
switch (DWC3_GHWPARAMS1_EN_PWROPT(dwc-hwparams.hwparams1)) {
case DWC3_GHWPARAMS1_EN_PWROPT_CLK:
@@ -461,6 +460,13 @@ static int dwc3_core_init(struct dwc3 *dwc)
dwc-is_fpga = true;
}
+ if ((dwc-quirks DWC3_QUIRK_AMD_NL) dwc-is_fpga)
+ dwc-quirks |= DWC3_QUIRK_DISSCRAMBLE;
+
+ if (dwc-quirks DWC3_QUIRK_DISSCRAMBLE)
this should only be set if is_fpga, and this quirk should be a 1-bit
flag, so here's what you should do:
WARN_ONCE(dwc-disable_scramble_quirk !dwc-is_fpga,
disable_scramble cannot be used on non-FPGA builds\n);
if (dwc-disable_scramble dwc-is_fpga)
reg |= DWC3_GCTL_DISSCRAMBLE;
else
reg = ~DWC3_GCTL_DISSCRAMBLE;
OK, will update it in V3.
+ reg |= DWC3_GCTL_DISSCRAMBLE;
+ else
+ reg = ~DWC3_GCTL_DISSCRAMBLE;
add a blank line here, to aid readability.
OK, will add it.
/*
* WORKAROUND: DWC3 revisions 1.90a have a bug
* where the device can fail to connect at SuperSpeed
diff --git a/drivers/usb/dwc3/dwc3-pci.c b/drivers/usb/dwc3/dwc3-pci.c
index 18569a4..a89db6c 100644
--- a/drivers/usb/dwc3/dwc3-pci.c
+++ b/drivers/usb/dwc3/dwc3-pci.c
@@ -146,6 +146,11 @@ static int dwc3_pci_probe(struct pci_dev *pci,
res[1].name = dwc_usb3;
res[1].flags= IORESOURCE_IRQ;
+ if (pci-vendor == PCI_VENDOR_ID_AMD pci-device ==
+ PCI_DEVICE_ID_AMD_NL) {
+ dwc3_pdata.quirks |= DWC3_QUIRK_AMD_NL;
+ }
should be part of another patch and the quirk is
disable_scramble_quirk, not AMD.
Got it, you would like to keep this patch just for fpga disscramble
quirk and do not add any 3rd platform info, right?
Thanks,
Rui
--
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: base: update cpu offline info when do hotplug
Greg,
-Original Message-
From: Greg KH [mailto:gre...@linuxfoundation.org]
Sent: 2014年10月20日 12:44
To: Neil Zhang
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] drivers: base: update cpu offline info when do hotplug
On Mon, Oct 20, 2014 at 11:29:08AM +0800, Neil Zhang wrote:
The current per-cpu offline info won't be updated if it is hotplugged
in/out by a kernel governer.
Let's update it via cpu notifier.
Signed-off-by: Neil Zhang zhan...@marvell.com
---
drivers/base/cpu.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/drivers/base/cpu.c b/drivers/base/cpu.c index
006b1bc..9d61824 100644
--- a/drivers/base/cpu.c
+++ b/drivers/base/cpu.c
@@ -418,10 +418,35 @@ static void __init
cpu_dev_register_generic(void) #endif }
+static int device_hotplug_notifier(struct notifier_block *nfb,
+ unsigned long action, void *hcpu) {
+ unsigned int cpu = (unsigned long)hcpu;
+ struct device *dev = get_cpu_device(cpu);
+ int ret;
+
+ switch (action ~CPU_TASKS_FROZEN) {
+ case CPU_ONLINE:
+ dev-offline = false;
+ ret = NOTIFY_OK;
+ break;
+ case CPU_DYING:
+ dev-offline = true;
+ ret = NOTIFY_OK;
+ break;
+ default:
+ ret = NOTIFY_DONE;
+ break;
+ }
+
+ return ret;
+}
+
void __init cpu_dev_init(void)
{
if (subsys_system_register(cpu_subsys, cpu_root_attr_groups))
panic(Failed to register CPU subsystem);
cpu_dev_register_generic();
+ cpu_notifier(device_hotplug_notifier, 0);
}
How much noise is this going to cause on a big/little system that constantly
hot unplug/plugs processors all of the time?
Can you explain more what kind of noise will be introduced on a big/little
system?
As I know IKS on arm will use cpu_suspend way to power down a core.
But I don't know well about other architectures.
Please give your suggestions.
Thanks!
greg k-h
Best Regards,
Neil Zhang
N�Р骒r��yb�X�肚�v�^�)藓{.n�+�伐�{��赙zXФ�≤�}��财�z�j:+v�����赙zZ+��+zf＂�h���~i���z� �wア�?�ㄨ���)撷f��^j谦y�m��@A�a囤�
0鹅h���i
Re: [PATCH 0/2] s390 vs. kprobes on ftrace
Hi Masami, On Mon, Oct 20, 2014 at 11:02:49AM +0900, Masami Hiramatsu wrote: (2014/10/17 17:19), Heiko Carstens wrote: On Thu, Oct 16, 2014 at 02:49:56PM +0900, Masami Hiramatsu wrote: Hi Heiko, (2014/10/16 0:46), Heiko Carstens wrote: Hi all, we would like to implement an architecture specific variant of kprobes on ftrace without using the current HAVE_KPROBES_ON_FTRACE infrastructure which is currently only used by x86. [...] I'm not sure about s390 nor have the machine, so it is very helpful if you give us a command line level test and show us the result with this patch :) Fortunately, we already have ftracetest under tools/tesitng/selftest/ftrace/. You can add the testcase for checking co-existence of kprobes and ftrace on an entry of a function. So how about something like below? Yes! :) And could you add the results before and after to patch 2/2, so that we can see what it changes on s390 ? The output of the testcase is identical before and after patch 2/2. Maybe I didn't explain my intention good enough. Just to explain how mcount/ftrace works on s390 today: if we pass the -pg flag to the compiler a 24 byte(!) block will be added in front of every function. We patch that block to match the ftrace needs. So an ftrace nop looks like this (simplified): 0: load return address 24 into register 6: jump to 24 12: nop 18: nop 24: function code If the function gets enabled for ftrace we will patch the instruction at offset 6: 0: load return address 24 into register 6: jump to ftrace_caller 12: nop 18: nop 24: function code So in fact kprobes and ftrace do work nicely together, since we only patch the second instruction, while kprobes will put a breakpoint on the first instruction. However, what I want to achieve with patch 2/2 is that the code will look like this: ftrace disabled: 0: jump to 24 6: nop 12: nop 18: nop 24: function code ftrace enabled: 0: branch to ftrace_caller and save return address into register 6: nop 12: nop 18: nop 24: function code So, with patch 2/2 the ftrace location of a function now matches the first instruction of a function and the check within kprobes.c which prevents putting a kprobe on an ftrace location triggers. So kprobes and ftrace work with and without patch 2/2, all I want to achieve is that the overhead of the mcount block gets reduced to a single instruction. Ultimately we want also a compiler change which only emits a single instruction, which we can patch; probably similar to -pg -mfentry on x86. -- 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 08/16] usb: dwc3: add u2exit lfps quirk
On Fri, Oct 17, 2014 at 09:50:00AM -0500, Felipe Balbi wrote:
Hi,
On Fri, Oct 17, 2014 at 04:53:33PM +0800, Huang Rui wrote:
AMD NL needs to enable u2exit lfps quirk.
Signed-off-by: Huang Rui ray.hu...@amd.com
---
drivers/usb/dwc3/core.c | 4
drivers/usb/dwc3/core.h | 1 +
drivers/usb/dwc3/dwc3-pci.c | 3 ++-
drivers/usb/dwc3/platform_data.h | 1 +
4 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 25db533..7322d85 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -467,6 +467,10 @@ static int dwc3_core_init(struct dwc3 *dwc)
reg |= DWC3_GCTL_DISSCRAMBLE;
else
reg = ~DWC3_GCTL_DISSCRAMBLE;
+
+ if (dwc-quirks DWC3_QUIRK_U2EXIT_LFPS)
this should be:
if (dwc-u2_exit_lfps_quirk)
OK, will update it in V3.
+ reg |= DWC3_GCTL_U2EXIT_LFPS;
+
/*
* WORKAROUND: DWC3 revisions 1.90a have a bug
* where the device can fail to connect at SuperSpeed
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index d58479e..3d27f10 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -166,6 +166,7 @@
#define DWC3_GCTL_SCALEDOWN(n) ((n) 4)
#define DWC3_GCTL_SCALEDOWN_MASK DWC3_GCTL_SCALEDOWN(3)
#define DWC3_GCTL_DISSCRAMBLE (1 3)
+#define DWC3_GCTL_U2EXIT_LFPS (1 2)
#define DWC3_GCTL_GBLHIBERNATIONEN (1 1)
#define DWC3_GCTL_DSBLCLKGTNG (1 0)
diff --git a/drivers/usb/dwc3/dwc3-pci.c b/drivers/usb/dwc3/dwc3-pci.c
index bbe946c..cdb9b04 100644
--- a/drivers/usb/dwc3/dwc3-pci.c
+++ b/drivers/usb/dwc3/dwc3-pci.c
@@ -149,7 +149,8 @@ static int dwc3_pci_probe(struct pci_dev *pci,
if (pci-vendor == PCI_VENDOR_ID_AMD pci-device ==
PCI_DEVICE_ID_AMD_NL) {
dwc3_pdata.has_lpm_erratum = true;
- dwc3_pdata.quirks |= DWC3_QUIRK_AMD_NL;
+ dwc3_pdata.quirks |= DWC3_QUIRK_AMD_NL
+ | DWC3_QUIRK_U2EXIT_LFPS;
}
should be combined and the last patch in the series.
You want to make all the AMD quirks enablement info and device id at
last patch, right?
Thanks,
Rui
--
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 2/3] input: stmpe: enforce device tree only mode
On Sat, 18 Oct 2014, Linus Walleij wrote:
The STMPE keypad controller is only used with device tree
configured systems, so force the configuration to come from
device tree only, and now actually get the rows and cols from
the device tree too.
Signed-off-by: Linus Walleij linus.wall...@linaro.org
---
.../devicetree/bindings/input/stmpe-keypad.txt | 2 +
drivers/input/keyboard/Kconfig | 1 +
drivers/input/keyboard/stmpe-keypad.c | 104
+
include/linux/mfd/stmpe.h | 20
4 files changed, 48 insertions(+), 79 deletions(-)
Acked-by: Lee Jones lee.jo...@linaro.org
diff --git a/Documentation/devicetree/bindings/input/stmpe-keypad.txt
b/Documentation/devicetree/bindings/input/stmpe-keypad.txt
index 1b97222e8a0b..12bb771d66d4 100644
--- a/Documentation/devicetree/bindings/input/stmpe-keypad.txt
+++ b/Documentation/devicetree/bindings/input/stmpe-keypad.txt
@@ -8,6 +8,8 @@ Optional properties:
- debounce-interval: Debouncing interval time in milliseconds
- st,scan-count: Scanning cycles elapsed before key data is
updated
- st,no-autorepeat : If specified device will not autorepeat
+ - keypad,num-rows : See ./matrix-keymap.txt
+ - keypad,num-columns : See ./matrix-keymap.txt
Example:
diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
index a3958c63d7d5..753d61c0a3a9 100644
--- a/drivers/input/keyboard/Kconfig
+++ b/drivers/input/keyboard/Kconfig
@@ -559,6 +559,7 @@ config KEYBOARD_SH_KEYSC
config KEYBOARD_STMPE
tristate STMPE keypad support
depends on MFD_STMPE
+ depends on OF
select INPUT_MATRIXKMAP
help
Say Y here if you want to use the keypad controller on STMPE I/O
diff --git a/drivers/input/keyboard/stmpe-keypad.c
b/drivers/input/keyboard/stmpe-keypad.c
index ef5e67fb567e..d46391f48310 100644
--- a/drivers/input/keyboard/stmpe-keypad.c
+++ b/drivers/input/keyboard/stmpe-keypad.c
@@ -45,7 +45,7 @@
#define STMPE_KEYPAD_MAX_ROWS8
#define STMPE_KEYPAD_MAX_COLS8
#define STMPE_KEYPAD_ROW_SHIFT 3
-#define STMPE_KEYPAD_KEYMAP_SIZE \
+#define STMPE_KEYPAD_KEYMAP_MAX_SIZE \
(STMPE_KEYPAD_MAX_ROWS * STMPE_KEYPAD_MAX_COLS)
/**
@@ -99,16 +99,30 @@ static const struct stmpe_keypad_variant
stmpe_keypad_variants[] = {
},
};
+/**
+ * struct stmpe_keypad - STMPE keypad state container
+ * @stmpe: pointer to parent STMPE device
+ * @input: spawned input device
+ * @variant: STMPE variant
+ * @debounce_ms: debounce interval, in ms. Maximum is
+ *%STMPE_KEYPAD_MAX_DEBOUNCE.
+ * @scan_count: number of key scanning cycles to confirm key data.
+ * Maximum is %STMPE_KEYPAD_MAX_SCAN_COUNT.
+ * @no_autorepeat: disable key autorepeat
+ * @rows: bitmask for the rows
+ * @cols: bitmask for the columns
+ * @keymap: the keymap
+ */
struct stmpe_keypad {
struct stmpe *stmpe;
struct input_dev *input;
const struct stmpe_keypad_variant *variant;
- const struct stmpe_keypad_platform_data *plat;
-
+ unsigned int debounce_ms;
+ unsigned int scan_count;
+ bool no_autorepeat;
unsigned int rows;
unsigned int cols;
-
- unsigned short keymap[STMPE_KEYPAD_KEYMAP_SIZE];
+ unsigned short keymap[STMPE_KEYPAD_KEYMAP_MAX_SIZE];
};
static int stmpe_keypad_read_data(struct stmpe_keypad *keypad, u8 *data)
@@ -208,15 +222,14 @@ static int stmpe_keypad_altfunc_init(struct
stmpe_keypad *keypad)
static int stmpe_keypad_chip_init(struct stmpe_keypad *keypad)
{
- const struct stmpe_keypad_platform_data *plat = keypad-plat;
const struct stmpe_keypad_variant *variant = keypad-variant;
struct stmpe *stmpe = keypad-stmpe;
int ret;
- if (plat-debounce_ms STMPE_KEYPAD_MAX_DEBOUNCE)
+ if (keypad-debounce_ms STMPE_KEYPAD_MAX_DEBOUNCE)
return -EINVAL;
- if (plat-scan_count STMPE_KEYPAD_MAX_SCAN_COUNT)
+ if (keypad-scan_count STMPE_KEYPAD_MAX_SCAN_COUNT)
return -EINVAL;
ret = stmpe_enable(stmpe, STMPE_BLOCK_KEYPAD);
@@ -245,7 +258,7 @@ static int stmpe_keypad_chip_init(struct stmpe_keypad
*keypad)
ret = stmpe_set_bits(stmpe, STMPE_KPC_CTRL_MSB,
STMPE_KPC_CTRL_MSB_SCAN_COUNT,
- plat-scan_count 4);
+ keypad-scan_count 4);
if (ret 0)
return ret;
@@ -253,17 +266,18 @@ static int stmpe_keypad_chip_init(struct stmpe_keypad
*keypad)
STMPE_KPC_CTRL_LSB_SCAN |
STMPE_KPC_CTRL_LSB_DEBOUNCE,
STMPE_KPC_CTRL_LSB_SCAN |
- (plat-debounce_ms 1));
+ (keypad-debounce_ms 1));
}
Re: [PATCH 1/3] mfd: stmpe: add pull up/down register offsets for STMPE
On Sat, 18 Oct 2014, Linus Walleij wrote:
This adds the register offsets for pull up/down for the STMPE
1601, 1801 and 24xx expanders. This is used to bias GPIO lines
and keypad lines.
Signed-off-by: Linus Walleij linus.wall...@linaro.org
---
Hi Sam, Lee: I think you should just ACK this so Dmitry can take the
patch series through the input tree, where the registers need to be
used to enable the keypad on the STMPE2401.
---
drivers/mfd/stmpe.c | 4
drivers/mfd/stmpe.h | 3 +++
include/linux/mfd/stmpe.h | 2 ++
3 files changed, 9 insertions(+)
Does this need to go in with the other patches in the set?
I'm _guessing_ that, as you've sent them separately, they can be
applied separately?
This needs to go in via MFD, but for my own reference:
Acked-by: Lee Jones lee.jo...@linaro.org
diff --git a/drivers/mfd/stmpe.c b/drivers/mfd/stmpe.c
index 3004d5ba0b82..497505bad4c4 100644
--- a/drivers/mfd/stmpe.c
+++ b/drivers/mfd/stmpe.c
@@ -547,6 +547,7 @@ static const u8 stmpe1601_regs[] = {
[STMPE_IDX_GPDR_LSB]= STMPE1601_REG_GPIO_SET_DIR_LSB,
[STMPE_IDX_GPRER_LSB] = STMPE1601_REG_GPIO_RE_LSB,
[STMPE_IDX_GPFER_LSB] = STMPE1601_REG_GPIO_FE_LSB,
+ [STMPE_IDX_GPPUR_LSB] = STMPE1601_REG_GPIO_PU_LSB,
[STMPE_IDX_GPAFR_U_MSB] = STMPE1601_REG_GPIO_AF_U_MSB,
[STMPE_IDX_IEGPIOR_LSB] = STMPE1601_REG_INT_EN_GPIO_MASK_LSB,
[STMPE_IDX_ISGPIOR_MSB] = STMPE1601_REG_INT_STA_GPIO_MSB,
@@ -695,6 +696,7 @@ static const u8 stmpe1801_regs[] = {
[STMPE_IDX_GPDR_LSB]= STMPE1801_REG_GPIO_SET_DIR_LOW,
[STMPE_IDX_GPRER_LSB] = STMPE1801_REG_GPIO_RE_LOW,
[STMPE_IDX_GPFER_LSB] = STMPE1801_REG_GPIO_FE_LOW,
+ [STMPE_IDX_GPPUR_LSB] = STMPE1801_REG_GPIO_PULL_UP_LOW,
[STMPE_IDX_IEGPIOR_LSB] = STMPE1801_REG_INT_EN_GPIO_MASK_LOW,
[STMPE_IDX_ISGPIOR_LSB] = STMPE1801_REG_INT_STA_GPIO_LOW,
};
@@ -778,6 +780,8 @@ static const u8 stmpe24xx_regs[] = {
[STMPE_IDX_GPDR_LSB]= STMPE24XX_REG_GPDR_LSB,
[STMPE_IDX_GPRER_LSB] = STMPE24XX_REG_GPRER_LSB,
[STMPE_IDX_GPFER_LSB] = STMPE24XX_REG_GPFER_LSB,
+ [STMPE_IDX_GPPUR_LSB] = STMPE24XX_REG_GPPUR_LSB,
+ [STMPE_IDX_GPPDR_LSB] = STMPE24XX_REG_GPPDR_LSB,
[STMPE_IDX_GPAFR_U_MSB] = STMPE24XX_REG_GPAFR_U_MSB,
[STMPE_IDX_IEGPIOR_LSB] = STMPE24XX_REG_IEGPIOR_LSB,
[STMPE_IDX_ISGPIOR_MSB] = STMPE24XX_REG_ISGPIOR_MSB,
diff --git a/drivers/mfd/stmpe.h b/drivers/mfd/stmpe.h
index bee0abf82040..84adb46b3e2f 100644
--- a/drivers/mfd/stmpe.h
+++ b/drivers/mfd/stmpe.h
@@ -188,6 +188,7 @@ int stmpe_remove(struct stmpe *stmpe);
#define STMPE1601_REG_GPIO_ED_MSB0x8A
#define STMPE1601_REG_GPIO_RE_LSB0x8D
#define STMPE1601_REG_GPIO_FE_LSB0x8F
+#define STMPE1601_REG_GPIO_PU_LSB0x91
#define STMPE1601_REG_GPIO_AF_U_MSB 0x92
#define STMPE1601_SYS_CTRL_ENABLE_GPIO (1 3)
@@ -276,6 +277,8 @@ int stmpe_remove(struct stmpe *stmpe);
#define STMPE24XX_REG_GPEDR_MSB 0x8C
#define STMPE24XX_REG_GPRER_LSB 0x91
#define STMPE24XX_REG_GPFER_LSB 0x94
+#define STMPE24XX_REG_GPPUR_LSB 0x97
+#define STMPE24XX_REG_GPPDR_LSB 0x9a
#define STMPE24XX_REG_GPAFR_U_MSB0x9B
#define STMPE24XX_SYS_CTRL_ENABLE_GPIO (1 3)
diff --git a/include/linux/mfd/stmpe.h b/include/linux/mfd/stmpe.h
index af9e1b07a630..976e1a390177 100644
--- a/include/linux/mfd/stmpe.h
+++ b/include/linux/mfd/stmpe.h
@@ -50,6 +50,8 @@ enum {
STMPE_IDX_GPEDR_MSB,
STMPE_IDX_GPRER_LSB,
STMPE_IDX_GPFER_LSB,
+ STMPE_IDX_GPPUR_LSB,
+ STMPE_IDX_GPPDR_LSB,
STMPE_IDX_GPAFR_U_MSB,
STMPE_IDX_IEGPIOR_LSB,
STMPE_IDX_ISGPIOR_LSB,
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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 RFC v3 0/3] virtio_net: enabling tx interrupts
RFC patches to enable tx interrupts. This is to demonstrate how this can be done without core virtio changes, and to make sure I understand the new APIs correctly. Testing TBD, I was asked for a version for early testing. Applies on top of patch: virtio_net: fix use after free that I recently sent. Changes from v3: clean up code, address issues raised by Jason Changes from v1: address comments by Jason Wang, use delayed cb everywhere rebased Jason's patch on top of mine and include it (with some tweaks) Jason Wang (1): virtio-net: optimize free_old_xmit_skbs stats Michael S. Tsirkin (2): virtio_net: enable tx interrupt virtio_net: bql drivers/net/virtio_net.c | 144 +-- 1 file changed, 101 insertions(+), 43 deletions(-) -- MST -- 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 RFC v3 2/3] virtio_net: bql
Improve tx batching using byte queue limits.
Should be especially effective for MQ.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
drivers/net/virtio_net.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 14f4cda..b83d39d 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -227,6 +227,7 @@ static unsigned int free_old_xmit_skbs(struct netdev_queue
*txq,
struct virtnet_info *vi = sq-vq-vdev-priv;
struct virtnet_stats *stats = this_cpu_ptr(vi-stats);
unsigned int packets = 0;
+ unsigned int bytes = 0;
while (packets budget
(skb = virtqueue_get_buf(sq-vq, len)) != NULL) {
@@ -234,6 +235,7 @@ static unsigned int free_old_xmit_skbs(struct netdev_queue
*txq,
u64_stats_update_begin(stats-tx_syncp);
stats-tx_bytes += skb-len;
+ bytes += skb-len;
stats-tx_packets++;
u64_stats_update_end(stats-tx_syncp);
@@ -241,6 +243,8 @@ static unsigned int free_old_xmit_skbs(struct netdev_queue
*txq,
packets++;
}
+ netdev_tx_completed_queue(txq, packets, bytes);
+
if (sq-vq-num_free = 2+MAX_SKB_FRAGS)
netif_tx_start_queue(txq);
@@ -959,6 +963,7 @@ static netdev_tx_t start_xmit(struct sk_buff *skb, struct
net_device *dev)
int err;
struct netdev_queue *txq = netdev_get_tx_queue(dev, qnum);
bool kick = !skb-xmit_more;
+ unsigned int bytes = skb-len;
virtqueue_disable_cb(sq-vq);
@@ -976,6 +981,8 @@ static netdev_tx_t start_xmit(struct sk_buff *skb, struct
net_device *dev)
return NETDEV_TX_OK;
}
+ netdev_tx_sent_queue(txq, bytes);
+
/* Apparently nice girls don't return TX_BUSY; stop the queue
* before it gets out of hand. Naturally, this wastes entries. */
if (sq-vq-num_free 2+MAX_SKB_FRAGS)
--
MST
--
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: base: update cpu offline info when do hotplug
On Sun, Oct 19, 2014 at 11:39:23PM -0700, Neil Zhang wrote: How much noise is this going to cause on a big/little system that constantly hot unplug/plugs processors all of the time? Can you explain more what kind of noise will be introduced on a big/little system? Have you tested this on such a machine? As I know IKS on arm will use cpu_suspend way to power down a core. Are you sure that it also doesn't use that same functionality to drop a processor to save power? Why do you need/want this notification? What are you going to do with this information that you don't already have? thanks, greg k-h -- 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 RFC v3 3/3] virtio-net: optimize free_old_xmit_skbs stats
From: Jason Wang jasow...@redhat.com
We already have counters for sent packets and sent bytes.
Use them to reduce the number of u64_stats_update_begin/end().
Take care not to bother with stats update when called
speculatively.
Based on a patch by Jason Wang.
Cc: Rusty Russell ru...@rustcorp.com.au
Signed-off-by: Jason Wang jasow...@redhat.com
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
drivers/net/virtio_net.c | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index b83d39d..c2b69f8 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -233,16 +233,22 @@ static unsigned int free_old_xmit_skbs(struct
netdev_queue *txq,
(skb = virtqueue_get_buf(sq-vq, len)) != NULL) {
pr_debug(Sent skb %p\n, skb);
- u64_stats_update_begin(stats-tx_syncp);
- stats-tx_bytes += skb-len;
bytes += skb-len;
- stats-tx_packets++;
- u64_stats_update_end(stats-tx_syncp);
+ packets++;
dev_kfree_skb_any(skb);
- packets++;
}
+ /* Avoid overhead when no packets have been processed
+* happens when called speculatively from start_xmit. */
+ if (!packets)
+ return 0;
+
+ u64_stats_update_begin(stats-tx_syncp);
+ stats-tx_bytes += bytes;
+ stats-tx_packets += packets;
+ u64_stats_update_end(stats-tx_syncp);
+
netdev_tx_completed_queue(txq, packets, bytes);
if (sq-vq-num_free = 2+MAX_SKB_FRAGS)
--
MST
--
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 RFC v3 1/3] virtio_net: enable tx interrupt
On newer hosts that support delayed tx interrupts,
we probably don't have much to gain from orphaning
packets early.
Based on patch by Jason Wang.
Note: this might degrade performance for
hosts without event idx support.
Should be addressed by the next patch.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
drivers/net/virtio_net.c | 133 +++
1 file changed, 89 insertions(+), 44 deletions(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 13d0a8b..14f4cda 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -72,6 +72,8 @@ struct send_queue {
/* Name of the send queue: output.$index */
char name[40];
+
+ struct napi_struct napi;
};
/* Internal representation of a receive virtqueue */
@@ -217,15 +219,41 @@ static struct page *get_a_page(struct receive_queue *rq,
gfp_t gfp_mask)
return p;
}
+static unsigned int free_old_xmit_skbs(struct netdev_queue *txq,
+ struct send_queue *sq, int budget)
+{
+ struct sk_buff *skb;
+ unsigned int len;
+ struct virtnet_info *vi = sq-vq-vdev-priv;
+ struct virtnet_stats *stats = this_cpu_ptr(vi-stats);
+ unsigned int packets = 0;
+
+ while (packets budget
+ (skb = virtqueue_get_buf(sq-vq, len)) != NULL) {
+ pr_debug(Sent skb %p\n, skb);
+
+ u64_stats_update_begin(stats-tx_syncp);
+ stats-tx_bytes += skb-len;
+ stats-tx_packets++;
+ u64_stats_update_end(stats-tx_syncp);
+
+ dev_kfree_skb_any(skb);
+ packets++;
+ }
+
+ if (sq-vq-num_free = 2+MAX_SKB_FRAGS)
+ netif_tx_start_queue(txq);
+
+ return packets;
+}
+
static void skb_xmit_done(struct virtqueue *vq)
{
struct virtnet_info *vi = vq-vdev-priv;
+ struct send_queue *sq = vi-sq[vq2txq(vq)];
- /* Suppress further interrupts. */
- virtqueue_disable_cb(vq);
-
- /* We were probably waiting for more output buffers. */
- netif_wake_subqueue(vi-dev, vq2txq(vq));
+ virtqueue_disable_cb(sq-vq);
+ napi_schedule(sq-napi);
}
static unsigned int mergeable_ctx_to_buf_truesize(unsigned long mrg_ctx)
@@ -774,6 +802,31 @@ again:
return received;
}
+static int virtnet_poll_tx(struct napi_struct *napi, int budget)
+{
+ struct send_queue *sq =
+ container_of(napi, struct send_queue, napi);
+ struct virtnet_info *vi = sq-vq-vdev-priv;
+ struct netdev_queue *txq = netdev_get_tx_queue(vi-dev, vq2txq(sq-vq));
+ unsigned int sent;
+
+ __netif_tx_lock(txq, smp_processor_id());
+ sent = free_old_xmit_skbs(txq, sq, budget);
+ if (sent budget) {
+ napi_complete(napi);
+ /* Note: we must enable cb *after* napi_complete, because
+* napi_schedule calls from callbacks that trigger before
+* napi_complete are ignored.
+*/
+ if (unlikely(!virtqueue_enable_cb_delayed(sq-vq))) {
+ virtqueue_disable_cb(sq-vq);
+ napi_schedule(sq-napi);
+ }
+ }
+ __netif_tx_unlock(txq);
+ return sent;
+}
+
#ifdef CONFIG_NET_RX_BUSY_POLL
/* must be called with local_bh_disable()d */
static int virtnet_busy_poll(struct napi_struct *napi)
@@ -822,30 +875,12 @@ static int virtnet_open(struct net_device *dev)
if (!try_fill_recv(vi-rq[i], GFP_KERNEL))
schedule_delayed_work(vi-refill, 0);
virtnet_napi_enable(vi-rq[i]);
+ napi_enable(vi-sq[i].napi);
}
return 0;
}
-static void free_old_xmit_skbs(struct send_queue *sq)
-{
- struct sk_buff *skb;
- unsigned int len;
- struct virtnet_info *vi = sq-vq-vdev-priv;
- struct virtnet_stats *stats = this_cpu_ptr(vi-stats);
-
- while ((skb = virtqueue_get_buf(sq-vq, len)) != NULL) {
- pr_debug(Sent skb %p\n, skb);
-
- u64_stats_update_begin(stats-tx_syncp);
- stats-tx_bytes += skb-len;
- stats-tx_packets++;
- u64_stats_update_end(stats-tx_syncp);
-
- dev_kfree_skb_any(skb);
- }
-}
-
static int xmit_skb(struct send_queue *sq, struct sk_buff *skb)
{
struct skb_vnet_hdr *hdr;
@@ -911,7 +946,9 @@ static int xmit_skb(struct send_queue *sq, struct sk_buff
*skb)
sg_set_buf(sq-sg, hdr, hdr_len);
num_sg = skb_to_sgvec(skb, sq-sg + 1, 0, skb-len) + 1;
}
- return virtqueue_add_outbuf(sq-vq, sq-sg, num_sg, skb, GFP_ATOMIC);
+
+ return virtqueue_add_outbuf(sq-vq, sq-sg, num_sg, skb,
+ GFP_ATOMIC);
}
static netdev_tx_t start_xmit(struct sk_buff *skb, struct net_device *dev)
@@ -923,8 +960,7 @@ static
Re: [PATCH v3 0/2] shrink virtio baloon on OOM in guest
On Wed, Oct 15, 2014 at 07:47:42PM +0400, Denis V. Lunev wrote: Excessive virtio_balloon inflation can cause invocation of OOM-killer, when Linux is under severe memory pressure. Various mechanisms are responsible for correct virtio_balloon memory management. Nevertheless it is often the case that these control tools does not have enough time to react on fast changing memory load. As a result OS runs out of memory and invokes OOM-killer. The balancing of memory by use of the virtio balloon should not cause the termination of processes while there are pages in the balloon. Now there is no way for virtio balloon driver to free memory at the last moment before some process get killed by OOM-killer. This does not provide a security breach as baloon itself is running inside guest OS and is working in the cooperation with the host. Thus some improvements from guest side should be considered as normal. To solve the problem, introduce a virtio_balloon callback which is expected to be called from the oom notifier call chain in out_of_memory() function. If virtio balloon could release some memory, it will make the system to return and retry the allocation that forced the out of memory killer to run. Patch 1 of this series adds support for implementation of virtio_balloon callback, so now leak_balloon() function returns number of freed pages. Patch 2 implements virtio_balloon callback itself. Changes from v2: - added feature bit to control OOM baloon behavior from host Changes from v1: - minor cosmetic tweaks suggested by rusty@ Signed-off-by: Raushaniya Maksudova rmaksud...@parallels.com Signed-off-by: Denis V. Lunev d...@openvz.org CC: Rusty Russell ru...@rustcorp.com.au CC: Michael S. Tsirkin m...@redhat.com With the feature bit, I think it's fine. Acked-by: Michael S. Tsirkin m...@redhat.com -- 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/6] scsi_dh: get module reference outside of device handler
On Mon, Oct 20, 2014 at 08:01:20AM +0200, Hannes Reinecke wrote: Is it guaranteed that you cannot call -attach() for devices which already have a device_handler attached? You've skipped the case scsi_dh != sdev-scsi_dh_data-scsi_dh No. Just instead of an if / else it's an if with an early return in the new 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 v2 5/5] Numachip: use 2GB memory block size
On 19/10/2014 17:23, Ingo Molnar wrote:
* Daniel J Blueman dan...@numascale.com wrote:
Use appropriate memory block size to reduce sysfs entry creation time
by 16x.
Boot-tested with the four permutations of X86_UV and X86_NUMACHIP.
Signed-off-by: Daniel J Blueman dan...@numascale.com
---
arch/x86/mm/init_64.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
index 5621c47..22ea6de 100644
--- a/arch/x86/mm/init_64.c
+++ b/arch/x86/mm/init_64.c
@@ -53,6 +53,7 @@
#include asm/cacheflush.h
#include asm/init.h
#include asm/uv/uv.h
+#include asm/numachip/numachip.h
#include asm/setup.h
#include mm_internal.h
@@ -1235,9 +1236,9 @@ static unsigned long probe_memory_block_size(void)
/* start from 2g */
unsigned long bz = 1UL31;
-#ifdef CONFIG_X86_UV
- if (is_uv_system()) {
- printk(KERN_INFO UV: memory block size 2GB\n);
+#ifdef CONFIG_X86_64
+ if (is_uv_system() || is_numachip_system()) {
+ pr_info(Memory block size 2GB for large-SMP system\n);
return 2UL * 1024 * 1024 * 1024;
It would be a lot cleaner and more robust to have a more
intelligent decision here.
Is there a reliable indicator for large 'sysfs entry creation
time', such as a lot of RAM present?
Yes, agreed exactly.
Also, it would be nice to list the pros/cons of this change, an
advantage is reduced overhead - what are the disadvantages?
The single disadvantage is that small-memory systems won't be able to
have finer control of memory offlining, though the impact of that depend
on why the user is offlining memory of course.
If it seems reasonable for x86-64 systems with 64GB memory to have 2GB
memory block sizes, I could prepare that change instead and document the
above if preferred?
Thanks,
Daniel
--
Daniel J Blueman
Principal Software Engineer, Numascale
--
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 3/5] video: fbdev: uvesafb.c: Cleaning up missing null-terminate by switching from strncpy to strzcpy
On Sun, Oct 19, 2014 at 12:14 AM, Rickard Strandqvist
rickard_strandqv...@spectrumdigital.se wrote:
Ensures that the string is null-terminate in connection with the
use of strncpy, by switching from strncpy to strzcpy.
Signed-off-by: Rickard Strandqvist rickard_strandqv...@spectrumdigital.se
---
drivers/video/fbdev/uvesafb.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/uvesafb.c b/drivers/video/fbdev/uvesafb.c
index 509d452..3383b34 100644
--- a/drivers/video/fbdev/uvesafb.c
+++ b/drivers/video/fbdev/uvesafb.c
@@ -1892,7 +1892,7 @@ static ssize_t show_v86d(struct device_driver *dev,
char *buf)
static ssize_t store_v86d(struct device_driver *dev, const char *buf,
size_t count)
{
- strncpy(v86d_path, buf, PATH_MAX);
+ strzcpy(v86d_path, buf, sizeof(v86d_path));
I think strlcpy() should be good enough here?
Or am I missing a reason why the rest of the buffer should be zero-filled?
Nevertheless, I think this (or an alternative) change should be applied to
stable, as call_usermodehelper() might crash by writing to sysfs.
return count;
}
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
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] mmc: dw_mmc: Add IDMAC 64-bit address mode support
Synopsys DW_MMC IP core supports Internal DMA Controller with 64-bit address
mode from IP version 2.70a onwards.
Updated the driver to support IDMAC 64-bit addressing mode.
Signed-off-by: Prabu Thangamuthu prab...@synopsys.com
---
Change log v7:
- Initialized reserved fileds and buffer size filed to zero.
- Removed warnings.
Change log v6:
- Updated with review comment.
Change log v5:
- Recreated the patch against linux-next as this patch is required for
another patch http://www.spinics.net/lists/arm-kernel/msg357985.html
drivers/mmc/host/dw_mmc.c | 199 +++-
drivers/mmc/host/dw_mmc.h | 11 +++
include/linux/mmc/dw_mmc.h |2 +
3 files changed, 174 insertions(+), 38 deletions(-)
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 69f0cc6..b64393b 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -62,6 +62,24 @@
SDMMC_IDMAC_INT_FBE | SDMMC_IDMAC_INT_RI | \
SDMMC_IDMAC_INT_TI)
+struct idmac_desc_64addr {
+ u32 des0; /* Control Descriptor */
+
+ u32 des1; /* Reserved */
+
+ u32 des2; /*Buffer sizes */
+#define IDMAC_64ADDR_SET_BUFFER1_SIZE(d, s) \
+ ((d)-des2 = ((d)-des2 0x03ffe000) | ((s) 0x1fff))
+
+ u32 des3; /* Reserved */
+
+ u32 des4; /* Lower 32-bits of Buffer Address Pointer 1*/
+ u32 des5; /* Upper 32-bits of Buffer Address Pointer 1*/
+
+ u32 des6; /* Lower 32-bits of Next Descriptor Address */
+ u32 des7; /* Upper 32-bits of Next Descriptor Address */
+};
+
struct idmac_desc {
u32 des0; /* Control Descriptor */
#define IDMAC_DES0_DIC BIT(1)
@@ -414,30 +432,66 @@ static void dw_mci_translate_sglist(struct dw_mci *host,
struct mmc_data *data,
unsigned int sg_len)
{
int i;
- struct idmac_desc *desc = host-sg_cpu;
+ if (host-dma_64bit_address == 1) {
+ struct idmac_desc_64addr *desc = host-sg_cpu;
- for (i = 0; i sg_len; i++, desc++) {
- unsigned int length = sg_dma_len(data-sg[i]);
- u32 mem_addr = sg_dma_address(data-sg[i]);
+ for (i = 0; i sg_len; i++, desc++) {
+ unsigned int length = sg_dma_len(data-sg[i]);
+ u64 mem_addr = sg_dma_address(data-sg[i]);
- /* Set the OWN bit and disable interrupts for this descriptor */
- desc-des0 = IDMAC_DES0_OWN | IDMAC_DES0_DIC | IDMAC_DES0_CH;
+ /*
+* Set the OWN bit and disable interrupts for this
+* descriptor
+*/
+ desc-des0 = IDMAC_DES0_OWN | IDMAC_DES0_DIC |
+ IDMAC_DES0_CH;
+ /* Buffer length */
+ IDMAC_64ADDR_SET_BUFFER1_SIZE(desc, length);
+
+ /* Physical address to DMA to/from */
+ desc-des4 = mem_addr 0x;
+ desc-des5 = mem_addr 32;
+ }
- /* Buffer length */
- IDMAC_SET_BUFFER1_SIZE(desc, length);
+ /* Set first descriptor */
+ desc = host-sg_cpu;
+ desc-des0 |= IDMAC_DES0_FD;
- /* Physical address to DMA to/from */
- desc-des2 = mem_addr;
- }
+ /* Set last descriptor */
+ desc = host-sg_cpu + (i - 1) *
+ sizeof(struct idmac_desc_64addr);
+ desc-des0 = ~(IDMAC_DES0_CH | IDMAC_DES0_DIC);
+ desc-des0 |= IDMAC_DES0_LD;
+
+ } else {
+ struct idmac_desc *desc = host-sg_cpu;
+
+ for (i = 0; i sg_len; i++, desc++) {
+ unsigned int length = sg_dma_len(data-sg[i]);
+ u32 mem_addr = sg_dma_address(data-sg[i]);
+
+ /*
+* Set the OWN bit and disable interrupts for this
+* descriptor
+*/
+ desc-des0 = IDMAC_DES0_OWN | IDMAC_DES0_DIC |
+ IDMAC_DES0_CH;
+ /* Buffer length */
+ IDMAC_SET_BUFFER1_SIZE(desc, length);
+
+ /* Physical address to DMA to/from */
+ desc-des2 = mem_addr;
+ }
- /* Set first descriptor */
- desc = host-sg_cpu;
- desc-des0 |= IDMAC_DES0_FD;
+ /* Set first descriptor */
+ desc = host-sg_cpu;
+ desc-des0 |= IDMAC_DES0_FD;
- /* Set last descriptor */
- desc = host-sg_cpu + (i -
Re: [PATCH] MIPS: ath79: fix compilation error when CONFIG_PCI is disabled
On Sun, Oct 19, 2014 at 7:43 PM, Stefan Hengelein
stefan.hengel...@fau.de wrote:
When CONFIG_PCI is disabled, 'db120_pci_init()' had a different
signature than when was enabled. Therefore, compilation failed when
CONFIG_PCI was not present.
arch/mips/ath79/mach-db120.c:132: error: too many arguments to function
'db120_pci_init'
Signed-off-by: Stefan Hengelein stefan.hengel...@fau.de
---
arch/mips/ath79/mach-db120.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/mips/ath79/mach-db120.c b/arch/mips/ath79/mach-db120.c
index 4d661a1..d1a783d 100644
--- a/arch/mips/ath79/mach-db120.c
+++ b/arch/mips/ath79/mach-db120.c
@@ -112,8 +112,6 @@ static void __init db120_pci_init(u8 *eeprom)
ath79_pci_set_plat_dev_init(db120_pci_plat_dev_init);
ath79_register_pci();
}
-#else
-static inline void db120_pci_init(void) {}
Please fix the prototype above, instead of removing it and its caller.
#endif /* CONFIG_PCI */
static void __init db120_setup(void)
@@ -129,7 +127,9 @@ static void __init db120_setup(void)
ARRAY_SIZE(db120_spi_info));
ath79_register_usb();
ath79_register_wmac(art + DB120_WMAC_CALDATA_OFFSET);
+#ifdef CONFIG_PCI
db120_pci_init(art + DB120_PCIE_CALDATA_OFFSET);
+#endif
}
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
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] MIPS: MSP71xx: remove compilation error
On Sun, Oct 19, 2014 at 8:04 PM, Stefan Hengelein
stefan.hengel...@fau.de wrote:
When CONFIG_MIPS_MT_SMP is enabled, the following compilation error
occurs:
arch/mips/pmcs-msp71xx/msp_irq_cic.c:134: error: ‘irq’ undeclared
This code clearly never saw a compiler.
The surrounding code suggests, that 'd-irq' was intended, not
'irq'.
This error was found with vampyr.
Signed-off-by: Stefan Hengelein stefan.hengel...@fau.de
Acked-by: Geert Uytterhoeven ge...@linux-m68k.org
Fixes: d7881fbdf866d7d0 (MIPS: msp71xx: Convert to new irq_chip functions)
(from 2011 ;-)
---
arch/mips/pmcs-msp71xx/msp_irq_cic.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/mips/pmcs-msp71xx/msp_irq_cic.c
b/arch/mips/pmcs-msp71xx/msp_irq_cic.c
index b8df2f7..1207ec4 100644
--- a/arch/mips/pmcs-msp71xx/msp_irq_cic.c
+++ b/arch/mips/pmcs-msp71xx/msp_irq_cic.c
@@ -131,11 +131,11 @@ static int msp_cic_irq_set_affinity(struct irq_data *d,
int cpu;
unsigned long flags;
unsigned int mtflags;
- unsigned long imask = (1 (irq - MSP_CIC_INTBASE));
+ unsigned long imask = (1 (d-irq - MSP_CIC_INTBASE));
volatile u32 *cic_mask = (volatile u32 *)CIC_VPE0_MSK_REG;
/* timer balancing should be disabled in kernel code */
- BUG_ON(irq == MSP_INT_VPE0_TIMER || irq == MSP_INT_VPE1_TIMER);
+ BUG_ON(d-irq == MSP_INT_VPE0_TIMER || d-irq == MSP_INT_VPE1_TIMER);
LOCK_CORE(flags, mtflags);
/* enable if any of each VPE's TCs require this IRQ */
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
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 6/7] mfd: qcom-smd-rpm: Driver for the Qualcomm RPM over SMD
On Fri, 17 Oct 2014, Bjorn Andersson wrote:
On Wed 08 Oct 01:40 PDT 2014, Lee Jones wrote:
[...]
+static struct qcom_smd_driver qcom_smd_rpm_driver = {
+ .probe = qcom_smd_rpm_probe,
+ .remove = qcom_smd_rpm_remove,
+ .callback = qcom_smd_rpm_callback,
+ .driver = {
+ .name = qcom_smd_rpm,
+ .owner = THIS_MODULE,
+ .of_match_table = qcom_smd_rpm_of_match,
+ },
+};
+
+module_qcom_smd_driver(qcom_smd_rpm_driver);
I don't like this. What's wrong with the existing platform driver
code?
I started off with having smd child devices as platform drivers and had some
accessor functions to find the open handles that triggered the probe() and
register the callback with those. But this didn't feel very sane, so I did
implemented a custom driver struct and probe prototype to simplify writing
drivers.
May I ask why you dislike this? This is how it's done in so many other places
in the kernel...
I don't believe that's the case. All owners of their own
module_*_driver() registration calls are busses (see below), whereas
'qcom_smd' is just a driver. Things would soon get out of control if
we allowed every driver in the kernel to supply their own driver
registration information variants.
$ git grep ^module_.*_driver( | \
cut -d: -f2 | cut -d'(' -f1 | sort | uniq
module_acpi_driver
module_amba_driver
module_comedi_driver
module_comedi_pci_driver
module_comedi_pcmcia_driver
module_comedi_usb_driver
module_gameport_driver
module_hid_driver
module_i2c_driver
module_mcb_driver
module_mipi_dsi_driver
module_pci_driver
module_pcmcia_driver
module_platform_driver
module_serio_driver
module_spi_driver
module_spmi_driver
module_usb_composite_driver
module_usb_driver
module_usb_serial_driver
module_virtio_driver
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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 5/5] tty/serial: Add earlycon support for Spreadtrum serial driver
2014-10-17 21:03 GMT+08:00 Mark Rutland mark.rutl...@arm.com: On Fri, Oct 17, 2014 at 10:54:25AM +0100, Chunyan Zhang wrote: Add serial driver for spreadtrum sharkl platform with earlycon support at first. Signed-off-by: Chunyan Zhang chunyan.zh...@spreadtrum.com --- drivers/tty/serial/Kconfig | 24 ++ drivers/tty/serial/Makefile |1 + drivers/tty/serial/sprd-serial.c | 64 ++ 3 files changed, 89 insertions(+) create mode 100644 drivers/tty/serial/sprd-serial.c diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig index 26cec64..33b8f90 100644 --- a/drivers/tty/serial/Kconfig +++ b/drivers/tty/serial/Kconfig @@ -113,6 +113,30 @@ config SERIAL_SB1250_DUART_CONSOLE If unsure, say Y. +config SERIAL_SPRD + tristate Support for SPRD serial + depends on ARM || ARM64 + select SERIAL_CORE + help + This enables the driver for the Spreadtrum's serial. + +config SERIAL_SPRD_NR +int Maximum number of sprd serial ports +depends on SERIAL_SPRD +default 4 This is not used below. Ok, I'll remove it in v3. + +config SERIAL_SPRD_CONSOLE +bool SPRD UART console support +depends on SERIAL_SPRD=y +select SERIAL_CORE_CONSOLE + select SERIAL_EARLYCON +help + Support for early debug console using Spreadtrum's serial. This enables + the console before standard serial driver is probed. This is enabled + with earlycon=serial_sprd on the kernel command line. The console is + enabled when early_param is processed. There only appears to be an earlycon driver, and not standard serial driver. What happens after earlycon? Surely there should be a real driver to take ownership of the UART? As far as I can see it won't be possible to boot your platform to a prompt, because earlycon will have gone before that. Thanks, Mark. We are planed to add standard serial driver after this patch-set is approved. In the first patch we contribute to the upstream, I'd like to add architecture related code of Spreadtrum's Sharkl, and then we will add more functions about Sharkl3 SoC step by step. I'm very glad to read your comments, if you have any suggestions, feel free to tell us. Thanks, Chunyan -- 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: cma: split cma-reserved in dmesg log
When the system boots up, in the dmesg logs we can see
the memory statistics along with total reserved as below.
Memory: 458840k/458840k available, 65448k reserved, 0K highmem
When CMA is enabled, still the total reserved memory remains the same.
However, the CMA memory is not considered as reserved.
But, when we see /proc/meminfo, the CMA memory is part of free memory.
This creates confusion.
This patch corrects the problem by properly substracting the CMA reserved
memory from the total reserved memory in dmesg logs.
Below is the dmesg snaphot from an arm based device with 512MB RAM and
12MB single CMA region.
Before this change:
Memory: 458840k/458840k available, 65448k reserved, 0K highmem
After this change:
Memory: 458840k/458840k available, 53160k reserved, 12288k cma-reserved, 0K
highmem
Signed-off-by: Pintu Kumar pint...@samsung.com
Signed-off-by: Vishnu Pratap Singh vishnu...@samsung.com
---
include/linux/swap.h | 3 +++
mm/cma.c | 2 ++
mm/page_alloc.c | 8
3 files changed, 13 insertions(+)
diff --git a/include/linux/swap.h b/include/linux/swap.h
index 37a585b..beb84be 100644
--- a/include/linux/swap.h
+++ b/include/linux/swap.h
@@ -295,6 +295,9 @@ static inline void workingset_node_shadows_dec(struct
radix_tree_node *node)
/* linux/mm/page_alloc.c */
extern unsigned long totalram_pages;
extern unsigned long totalreserve_pages;
+#ifdef CONFIG_CMA
+extern unsigned long totalcma_pages;
+#endif
extern unsigned long dirty_balance_reserve;
extern unsigned long nr_free_buffer_pages(void);
extern unsigned long nr_free_pagecache_pages(void);
diff --git a/mm/cma.c b/mm/cma.c
index 963bc4a..73fe7be 100644
--- a/mm/cma.c
+++ b/mm/cma.c
@@ -45,6 +45,7 @@ struct cma {
static struct cma cma_areas[MAX_CMA_AREAS];
static unsigned cma_area_count;
static DEFINE_MUTEX(cma_mutex);
+unsigned long totalcma_pages __read_mostly;
phys_addr_t cma_get_base(struct cma *cma)
{
@@ -288,6 +289,7 @@ int __init cma_declare_contiguous(phys_addr_t base,
if (ret)
goto err;
+ totalcma_pages += (size / PAGE_SIZE);
pr_info(Reserved %ld MiB at %08lx\n, (unsigned long)size / SZ_1M,
(unsigned long)base);
return 0;
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index dd73f9a..c6165ac 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -5521,6 +5521,9 @@ void __init mem_init_print_info(const char *str)
pr_info(Memory: %luK/%luK available
(%luK kernel code, %luK rwdata, %luK rodata,
%luK init, %luK bss, %luK reserved
+#ifdef CONFIG_CMA
+ , %luK cma-reserved
+#endif
#ifdef CONFIG_HIGHMEM
, %luK highmem
#endif
@@ -5528,7 +5531,12 @@ void __init mem_init_print_info(const char *str)
nr_free_pages() (PAGE_SHIFT-10), physpages (PAGE_SHIFT-10),
codesize 10, datasize 10, rosize 10,
(init_data_size + init_code_size) 10, bss_size 10,
+#ifdef CONFIG_CMA
+ (physpages - totalram_pages - totalcma_pages) (PAGE_SHIFT-10),
+ totalcma_pages (PAGE_SHIFT-10),
+#else
(physpages - totalram_pages) (PAGE_SHIFT-10),
+#endif
#ifdef CONFIG_HIGHMEM
totalhigh_pages (PAGE_SHIFT-10),
#endif
--
1.8.3.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] drivers: base: update cpu offline info when do hotplug
Greg, -Original Message- From: Greg KH [mailto:gre...@linuxfoundation.org] Sent: 2014年10月20日 14:48 To: Neil Zhang Cc: linux-kernel@vger.kernel.org Subject: Re: [PATCH] drivers: base: update cpu offline info when do hotplug On Sun, Oct 19, 2014 at 11:39:23PM -0700, Neil Zhang wrote: How much noise is this going to cause on a big/little system that constantly hot unplug/plugs processors all of the time? Can you explain more what kind of noise will be introduced on a big/little system? Have you tested this on such a machine? I didn't have such kind of machine on hand. Can anyone has such machine to verify it? Thanks! As I know IKS on arm will use cpu_suspend way to power down a core. Are you sure that it also doesn't use that same functionality to drop a processor to save power? As I know it use cpu_suspend to switch out a processor in IKS and there is no cpu hotplug notifier in this procedure. Why do you need/want this notification? What are you going to do with this information that you don't already have? The offline won't be updated if an in kernel hotplug governor plug in / out a core which cause the sysfs interface report a wrong status. thanks, greg k-h Best Regards, Neil Zhang
Re: [PATCH 1/2] drivers/misc/eeprom/men_eeprod: Introduce MEN Board Information EEPROM driver
On Thu, Oct 16, 2014 at 01:44:02PM +0200, Andreas Werner wrote: On Thu, Oct 16, 2014 at 11:59:10AM +0200, Wolfram Sang wrote: * PGP Signed by an unknown key I do not want to parse the things in userspace because this EEPROM data are related to the hardware and i want to give our customer the easiest way to access the data without installing any tool. I understand that point of view. From an upstream point of view, things may look different, though. I also understand your point of view :-). Most customers wants just to have a running system without installing anything. And for me an EEPROM is so simple and should not need a complicated way to access it. The current state to read the eeprom data is, that customer needs to install a big environment where the tool is integrated to have access to those kind of simple data or they have to write their own code. i2cget from i2c-tools? You could do a simple shell script to parse the data. Or do a board specific hook which reads the data and prints it to the logfiles... Yes of course there are a lot of possibilities. This was just an example what we currently use and what was developed years ago. With a driver like this you can also define read only attributes to prevent customer to write or modify the data in the production section. With i2ctools you can just write any data to it you want. Consider how bloated the sysfs-ABI might get if every vendor who uses an eeprom wants to expose the data this way? Yes and no. The possible sysfs entries gets bloated if every vendor will do it like this way, but normally there is just one Board EEPROM on the board, therefore only one driver gets loaded. I am not talking about runtime here, I don't care about that. I am talking about the ABI we create and we have to maintain basically forever. And with vendor specific configuartion data I have doubts with that being stable. Ok, but i do not think that we can make a general ABI definition for those kind of devices because every vendor will have its own data in the EEPROM which he want to have. I mean its the same for every i2c device like a temperature sensor, I can also read it from userspace without any special hwmon driver. These is a HUGE difference. If I read tempX_input, I don't need to care if the sensor is I2C or SPI or whatever. The kernel abstracts that away. The files you create are for your I2C EEPROM only. Data gets reformatted and access gets hidden, but nothing is abstracted away. It would be different if we had a generic convention for serial_id or stuff like that. But as configuration data is highly specific I don't see this coming. For a standard sysfs interface it is a huge difference yes. At the point of few from the EEPROM device it is a device like a temp sensor which could be different from vendor to vendor. Regards Andy Greg what do you think about that driver as a Maintainer of the sysfs? To we have other ways to get those kind of drivers in the mainline kernel? Regards Andy * Unknown Key * 0x14A029B6 -- 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] arm: dma-mapping: fix compilation error when CONFIG_MMU is not present
Hello,
On 2014-10-19 17:59, Stefan Hengelein wrote:
When CONFIG_MMU is not present, the variable 'atomic_pool' and the
function '__in_atomic_pool' are undeclared but used in part of the
code. Therefore, the compilation breaks.
Now, they are defined to dummy values when CONFIG_MMU is undefined.
This error was found with vampyr.
Frankly, those variables are used only when CONFIG_MMU or
CONFIG_ARM_DMA_USE_IOMMU are set. The latter imho makes only sense
together with CONFIG_MMU, so the issue reported here doesn't really
happen in real world.
Signed-off-by: Stefan Hengelein stefan.hengel...@fau.de
---
arch/arm/mm/dma-mapping.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index c245d90..7d04cf7 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -573,12 +573,14 @@ static inline pgprot_t __get_dma_pgprot(struct dma_attrs
*attrs, pgprot_t prot)
#else /* !CONFIG_MMU */
#define nommu() 1
+#define atomic_pool 0
#define __get_dma_pgprot(attrs, prot) __pgprot(0)
#define __alloc_remap_buffer(dev, size, gfp, prot, ret, c)NULL
#define __alloc_from_pool(size, ret_page) NULL
#define __alloc_from_contiguous(dev, size, prot, ret, c) NULL
#define __free_from_pool(cpu_addr, size) 0
+#define __in_atomic_pool(start, size) 0
#define __free_from_contiguous(dev, page, cpu_addr, size) do { } while (0)
#define __dma_free_remap(cpu_addr, size) do { } while (0)
Best regards
--
Marek Szyprowski, PhD
Samsung RD Institute Poland
--
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/
[GIT PULL] s390 patches for 3.18-rc2
Hi Linus,
please pull from the 'for-linus' branch of
git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git for-linus
to receive the following updates:
One patch to enable the BPF system call and three more bug fixes.
Dominik Dingel (1):
s390/mm: fixing calls of pte_unmap_unlock
Heiko Carstens (1):
s390: wire up bpf syscall
Jan Willeke (1):
s390/uprobes: fix kprobes dependency
Josh Boyer (1):
s390/hmcdrv: Restrict s390 HMC driver to S390 arch
arch/s390/include/uapi/asm/unistd.h | 3 ++-
arch/s390/kernel/compat_wrapper.c | 1 +
arch/s390/kernel/syscalls.S | 1 +
arch/s390/kernel/uprobes.c | 2 +-
arch/s390/lib/probes.c | 2 +-
arch/s390/mm/pgtable.c | 6 +++---
drivers/s390/char/Kconfig | 2 +-
7 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/arch/s390/include/uapi/asm/unistd.h
b/arch/s390/include/uapi/asm/unistd.h
index 940ac49..4197c89 100644
--- a/arch/s390/include/uapi/asm/unistd.h
+++ b/arch/s390/include/uapi/asm/unistd.h
@@ -286,7 +286,8 @@
#define __NR_seccomp 348
#define __NR_getrandom 349
#define __NR_memfd_create 350
-#define NR_syscalls 351
+#define __NR_bpf 351
+#define NR_syscalls 352
/*
* There are some system calls that are not present on 64 bit, some
diff --git a/arch/s390/kernel/compat_wrapper.c
b/arch/s390/kernel/compat_wrapper.c
index faf6caa..c4f7a3d 100644
--- a/arch/s390/kernel/compat_wrapper.c
+++ b/arch/s390/kernel/compat_wrapper.c
@@ -217,3 +217,4 @@ COMPAT_SYSCALL_WRAP5(renameat2, int, olddfd, const char
__user *, oldname, int,
COMPAT_SYSCALL_WRAP3(seccomp, unsigned int, op, unsigned int, flags, const
char __user *, uargs)
COMPAT_SYSCALL_WRAP3(getrandom, char __user *, buf, size_t, count, unsigned
int, flags)
COMPAT_SYSCALL_WRAP2(memfd_create, const char __user *, uname, unsigned int,
flags)
+COMPAT_SYSCALL_WRAP3(bpf, int, cmd, union bpf_attr *, attr, unsigned int,
size);
diff --git a/arch/s390/kernel/syscalls.S b/arch/s390/kernel/syscalls.S
index 6fe886a..9f7087f 100644
--- a/arch/s390/kernel/syscalls.S
+++ b/arch/s390/kernel/syscalls.S
@@ -359,3 +359,4 @@ SYSCALL(sys_renameat2,sys_renameat2,compat_sys_renameat2)
SYSCALL(sys_seccomp,sys_seccomp,compat_sys_seccomp)
SYSCALL(sys_getrandom,sys_getrandom,compat_sys_getrandom)
SYSCALL(sys_memfd_create,sys_memfd_create,compat_sys_memfd_create) /* 350 */
+SYSCALL(sys_bpf,sys_bpf,compat_sys_bpf)
diff --git a/arch/s390/kernel/uprobes.c b/arch/s390/kernel/uprobes.c
index 956f4f7..f6b3cd0 100644
--- a/arch/s390/kernel/uprobes.c
+++ b/arch/s390/kernel/uprobes.c
@@ -5,13 +5,13 @@
*Author(s): Jan Willeke,
*/
-#include linux/kprobes.h
#include linux/uaccess.h
#include linux/uprobes.h
#include linux/compat.h
#include linux/kdebug.h
#include asm/switch_to.h
#include asm/facility.h
+#include asm/kprobes.h
#include asm/dis.h
#include entry.h
diff --git a/arch/s390/lib/probes.c b/arch/s390/lib/probes.c
index c5d64a0..ae90e1a 100644
--- a/arch/s390/lib/probes.c
+++ b/arch/s390/lib/probes.c
@@ -4,7 +4,7 @@
*Copyright IBM Corp. 2014
*/
-#include linux/kprobes.h
+#include asm/kprobes.h
#include asm/dis.h
int probe_is_prohibited_opcode(u16 *insn)
diff --git a/arch/s390/mm/pgtable.c b/arch/s390/mm/pgtable.c
index 296b61a..1b79ca6 100644
--- a/arch/s390/mm/pgtable.c
+++ b/arch/s390/mm/pgtable.c
@@ -656,7 +656,7 @@ void __gmap_zap(struct gmap *gmap, unsigned long gaddr)
}
pgste_set_unlock(ptep, pgste);
out_pte:
- pte_unmap_unlock(*ptep, ptl);
+ pte_unmap_unlock(ptep, ptl);
}
EXPORT_SYMBOL_GPL(__gmap_zap);
@@ -943,7 +943,7 @@ retry:
}
if (!(pte_val(*ptep) _PAGE_INVALID)
(pte_val(*ptep) _PAGE_PROTECT)) {
- pte_unmap_unlock(*ptep, ptl);
+ pte_unmap_unlock(ptep, ptl);
if (fixup_user_fault(current, mm, addr, FAULT_FLAG_WRITE)) {
up_read(mm-mmap_sem);
return -EFAULT;
@@ -974,7 +974,7 @@ retry:
pgste_val(new) |= PGSTE_UC_BIT;
pgste_set_unlock(ptep, new);
- pte_unmap_unlock(*ptep, ptl);
+ pte_unmap_unlock(ptep, ptl);
up_read(mm-mmap_sem);
return 0;
}
diff --git a/drivers/s390/char/Kconfig b/drivers/s390/char/Kconfig
index dc24ecf..db2cb1f 100644
--- a/drivers/s390/char/Kconfig
+++ b/drivers/s390/char/Kconfig
@@ -105,7 +105,7 @@ config SCLP_ASYNC
config HMC_DRV
def_tristate m
prompt Support for file transfers from HMC drive CD/DVD-ROM
- depends on 64BIT
+ depends on S390 64BIT
select CRC16
help
This option enables support for file transfers from a Hardware
--
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] sched/fair: Care divide error in update_task_scan_period()
Could you review this patch?
(2014/10/16 18:48), Yasuaki Ishimatsu wrote:
While offling node by hot removing memory, the following divide error
occurs:
divide error: [#1] SMP
[...]
Call Trace:
[...] handle_mm_fault
[...] ? try_to_wake_up
[...] ? wake_up_state
[...] __do_page_fault
[...] ? do_futex
[...] ? put_prev_entity
[...] ? __switch_to
[...] do_page_fault
[...] page_fault
[...]
RIP [810a7081] task_numa_fault
RSP 88084eb2bcb0
The issue occurs as follows:
1. When page fault occurs and page is allocated from node 1,
task_struct-numa_faults_buffer_memory[] of node 1 is
incremented and p-numa_faults_locality[] is also incremented
as follows:
o numa_faults_buffer_memory[] o numa_faults_locality[]
NR_NUMA_HINT_FAULT_TYPES
| 0 | 1 |
-- --
node 0 | 0 | 0 | remote | 0 |
node 1 | 0 | 1 | locale | 1 |
-- --
2. node 1 is offlined by hot removing memory.
3. When page fault occurs, fault_types[] is calculated by using
p-numa_faults_buffer_memory[] of all online nodes in
task_numa_placement(). But node 1 was offline by step 2. So
the fault_types[] is calculated by using only
p-numa_faults_buffer_memory[] of node 0. So both of fault_types[]
are set to 0.
4. The values(0) of fault_types[] pass to update_task_scan_period().
5. numa_faults_locality[1] is set to 1. So the following division is
calculated.
static void update_task_scan_period(struct task_struct *p,
unsigned long shared, unsigned long private){
...
ratio = DIV_ROUND_UP(private * NUMA_PERIOD_SLOTS, (private +
shared));
}
6. But both of private and shared are set to 0. So divide error
occurs here.
The divide error is rare case because the trigger is node offline.
By this patch, when both of private and shared are set to 0,
denominator is set to 1 for avoiding divide error.
Signed-off-by: Yasuaki Ishimatsu isimatu.yasu...@jp.fujitsu.com
CC: Wanpeng Li kernel...@gmail.com
CC: Rik van Riel r...@redhat.com
CC: Peter Zijlstra pet...@infradead.org
---
kernel/sched/fair.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index bfa3c86..580fc74 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -1466,6 +1466,7 @@ static void update_task_scan_period(struct task_struct
*p,
unsigned long remote = p-numa_faults_locality[0];
unsigned long local = p-numa_faults_locality[1];
+ unsigned long total_faults = shared + private;
/*
* If there were no record hinting faults then either the task is
@@ -1496,6 +1497,14 @@ static void update_task_scan_period(struct task_struct
*p,
slot = 1;
diff = slot * period_slot;
} else {
+ /*
+ * This is a rare case. total_faults might become 0 after
+ * offlining node. In this case, total_faults is set to 1
+ * for avoiding divide error.
+ */
+ if (unlikely(total_faults == 0))
+ total_faults = 1;
+
diff = -(NUMA_PERIOD_THRESHOLD - ratio) * period_slot;
/*
@@ -1506,7 +1515,7 @@ static void update_task_scan_period(struct task_struct
*p,
* scanning faster if shared accesses dominate as it may
* simply bounce migrations uselessly
*/
- ratio = DIV_ROUND_UP(private * NUMA_PERIOD_SLOTS, (private +
shared));
+ ratio = DIV_ROUND_UP(private * NUMA_PERIOD_SLOTS,
(total_faults));
diff = (diff * ratio) / NUMA_PERIOD_SLOTS;
}
--
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: [GIT] Networking
On Sun, Oct 19, 2014 at 09:03:14PM -0400, David Miller wrote: From: Linus Torvalds torva...@linux-foundation.org Date: Sun, 19 Oct 2014 17:32:15 -0700 Looks like the module license issue was just overlooked when moving the code out in commit c8d7b98bec43 (netfilter: move nf_send_resetX() code to nf_reject_ipvX modules). I think Pablo has a patch pending to address this, and indeed he does: http://marc.info/?l=linux-netdevm=141293491712312w=2 Pablo please push this to me soon, thanks. I'll send you this batch today. 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/
[GIT PULL] pwm: Changes for v3.18-rc1
Hi Linus, I was one of the people taking your statements at face value, so here's my belated pull request for the PWM tree which I had planned to send in today anyway. There isn't anything major in this, mostly bug fixes and cleanup. The following changes since commit 7d1311b93e58ed55f3a31cc8f94c4b8fe988a2b9: Linux 3.17-rc1 (2014-08-16 10:40:26 -0600) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm.git tags/pwm/for-3.18-rc1 for you to fetch changes up to dec02f98ae2e341a2e0bb25f27e84867e5f9f64a: pwm: Let PWM_CLPS711X depend on HAS_IOMEM (2014-10-20 09:39:44 +0200) Thanks, Thierry pwm: Changes for v3.18-rc1 There are no new drivers here, only a couple of fixes all over the place. Alan Cox (1): pwm: lpss: Add ACPI and PCI IDs for Intel Braswell Andy Shevchenko (3): pwm: lpss: Properly split driver to parts pwm: lpss: pci: Move to use pcim_enable_device() pwm: lpss: make it buildable only on X86 Chen Gang (1): pwm: Let PWM_CLPS711X depend on HAS_IOMEM Doug Anderson (1): pwm: rockchip: Allow polarity invert on rk3288 Fabio Estevam (1): pwm: fsl-ftm: Select REGMAP_MMIO Geert Uytterhoeven (2): pwm: Fix period and polarity in pwm_get() for non-perfect matches pwm: Fix uninitialized warnings in pwm_get() Julia Lawall (1): pwm: lpss: use c99 initializers in structures Liu Ying (3): pwm: imx: Fix the macro MX3_PWMCR_PRESCALER(x) definition pwm: imx: Cleanup indentation for register definitions pwm: imx: Avoid sample FIFO overflow for i.MX PWM version2 Nikolaus Voss (1): pwm: atmel: Fix calculation of prescale value Thierry Reding (1): pwm: lpss: Fix build failure on PowerPC Xiubo Li (4): pwm: fsl-ftm: Clean up the code pwm: fsl-ftm: Convert to direct regmap API usage pwm: fsl-ftm: Document 'big-endian' property pwm: Fix possible ZERO_SIZE_PTR pointer dereferencing error. .../devicetree/bindings/pwm/pwm-fsl-ftm.txt| 19 ++- .../devicetree/bindings/pwm/pwm-rockchip.txt | 4 +- drivers/pwm/Kconfig| 22 +++- drivers/pwm/Makefile | 2 + drivers/pwm/core.c | 27 ++-- drivers/pwm/pwm-atmel.c| 24 ++-- drivers/pwm/pwm-fsl-ftm.c | 90 +++--- drivers/pwm/pwm-imx.c | 71 --- drivers/pwm/pwm-lpss-pci.c | 64 ++ drivers/pwm/pwm-lpss-platform.c| 68 ++ drivers/pwm/pwm-lpss.c | 137 +++-- drivers/pwm/pwm-lpss.h | 32 + drivers/pwm/pwm-rockchip.c | 57 +++-- 13 files changed, 399 insertions(+), 218 deletions(-) create mode 100644 drivers/pwm/pwm-lpss-pci.c create mode 100644 drivers/pwm/pwm-lpss-platform.c create mode 100644 drivers/pwm/pwm-lpss.h pgpQ8yT6wzmQz.pgp Description: PGP signature
Re: [PATCH 1/8] perf, tools: Support handling complete branch stacks as histograms
On Fri, Sep 26, 2014 at 04:37:09PM -0700, Andi Kleen wrote:
SNIP
OPT_BOOLEAN('x', exclude-other, symbol_conf.exclude_other,
Only display entries with parent-match),
- OPT_CALLBACK_DEFAULT('g', call-graph, report,
output_type,min_percent[,print_limit],call_order,
- Display callchains using output_type (graph, flat,
fractal, or none) , min percent threshold, optional print limit, callchain
order, key (function or address).
+ OPT_CALLBACK_DEFAULT('g', call-graph, report,
output_type,min_percent[,print_limit],call_order[,branch],
+ Display callchains using output_type (graph, flat,
fractal, or none) , min percent threshold, optional print limit, callchain
order, key (function or address), add branches.
Default: fractal,0.5,callee,function,
report_parse_callchain_opt, callchain_default_opt),
OPT_BOOLEAN(0, children, symbol_conf.cumulate_callchain,
Accumulate callchains of children and show total overhead
as well),
diff --git a/tools/perf/util/callchain.c b/tools/perf/util/callchain.c
index 08f0fbf..265457c 100644
--- a/tools/perf/util/callchain.c
+++ b/tools/perf/util/callchain.c
@@ -61,6 +61,8 @@ parse_callchain_report_opt(const char *arg)
callchain_param.key = CCKEY_FUNCTION;
else if (!strncmp(tok, address, strlen(tok)))
callchain_param.key = CCKEY_ADDRESS;
+ else if (!strncmp(tok, branch, strlen(tok)))
+ callchain_param.branch_callstack = 1;
this needs to be rebased to latest Namhyung's changes
which got in..
could you please rebase on Arnaldo's perf/core?
jirka
--
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 2/8] perf, tools: Add --branch-history option to report
On Fri, Sep 26, 2014 at 04:37:10PM -0700, Andi Kleen wrote:
SNIP
+ const char *str __maybe_unused, int unset)
+{
+ int *branch_mode = opt-value;
+
+ *branch_mode = !unset;
+ return 0;
+}
+
+static int
parse_percent_limit(const struct option *opt, const char *str,
int unset __maybe_unused)
{
@@ -564,7 +575,7 @@ int cmd_report(int argc, const char **argv, const char
*prefix __maybe_unused)
struct perf_session *session;
struct stat st;
bool has_br_stack = false;
- int branch_mode = -1;
+ int branch_mode = -1, branch_call_mode = -1;
this one no longer applies as well
jirka
--
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/6] scsi_dh: get module reference outside of device handler
On 10/20/2014 08:53 AM, Christoph Hellwig wrote: On Mon, Oct 20, 2014 at 08:01:20AM +0200, Hannes Reinecke wrote: Is it guaranteed that you cannot call -attach() for devices which already have a device_handler attached? You've skipped the case scsi_dh != sdev-scsi_dh_data-scsi_dh No. Just instead of an if / else it's an if with an early return in the new code. right. Indeed. Reviewed-by: Hannes Reinecke h...@suse.de Cheers, Hannes -- Dr. Hannes Reinecke zSeries Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- 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 4/4] pinctrl: berlin: use the generic node to map function
A generic node to map function has been added into the pinctrl
framework. It is provieded by GENERIC_PINCONF. Use it in the Berlin
pinctrl driver as it fits the needs.
Signed-off-by: Antoine Tenart antoine.ten...@free-electrons.com
---
drivers/pinctrl/berlin/Kconfig | 1 +
drivers/pinctrl/berlin/berlin.c | 53 ++---
2 files changed, 3 insertions(+), 51 deletions(-)
diff --git a/drivers/pinctrl/berlin/Kconfig b/drivers/pinctrl/berlin/Kconfig
index b18322bc7bf9..b38c0abf1790 100644
--- a/drivers/pinctrl/berlin/Kconfig
+++ b/drivers/pinctrl/berlin/Kconfig
@@ -2,6 +2,7 @@ if ARCH_BERLIN
config PINCTRL_BERLIN
bool
+ select GENERIC_PINCONF
select PINMUX
select REGMAP_MMIO
diff --git a/drivers/pinctrl/berlin/berlin.c b/drivers/pinctrl/berlin/berlin.c
index 86db2235ab00..da98efae8d8f 100644
--- a/drivers/pinctrl/berlin/berlin.c
+++ b/drivers/pinctrl/berlin/berlin.c
@@ -15,6 +15,7 @@
#include linux/of.h
#include linux/of_address.h
#include linux/of_device.h
+#include linux/pinctrl/pinconf-generic.h
#include linux/pinctrl/pinctrl.h
#include linux/pinctrl/pinmux.h
#include linux/platform_device.h
@@ -49,56 +50,6 @@ static const char *berlin_pinctrl_get_group_name(struct
pinctrl_dev *pctrl_dev,
return pctrl-desc-groups[group].name;
}
-static int berlin_pinctrl_dt_node_to_map(struct pinctrl_dev *pctrl_dev,
-struct device_node *node,
-struct pinctrl_map **map,
-unsigned *num_maps)
-{
- struct berlin_pinctrl *pctrl = pinctrl_dev_get_drvdata(pctrl_dev);
- struct property *prop;
- const char *function_name, *group_name;
- unsigned reserved_maps = 0;
- int ret, ngroups;
-
- *map = NULL;
- *num_maps = 0;
-
- ret = of_property_read_string(node, function, function_name);
- if (ret) {
- dev_err(pctrl-dev,
- missing function property in node %s\n,
- node-name);
- return -EINVAL;
- }
-
- ngroups = of_property_count_strings(node, groups);
- if (ngroups 0) {
- dev_err(pctrl-dev,
- missing groups property in node %s\n,
- node-name);
- return -EINVAL;
- }
-
- ret = pinctrl_utils_reserve_map(pctrl_dev, map, reserved_maps,
- num_maps, ngroups);
- if (ret) {
- dev_err(pctrl-dev, can't reserve map: %d\n, ret);
- return ret;
- }
-
- of_property_for_each_string(node, groups, prop, group_name) {
- ret = pinctrl_utils_add_map_mux(pctrl_dev, map, reserved_maps,
- num_maps, group_name,
- function_name);
- if (ret) {
- dev_err(pctrl-dev, can't add map: %d\n, ret);
- return ret;
- }
- }
-
- return 0;
-}
-
static void berlin_pinctrl_dt_free_map(struct pinctrl_dev *pctrl_dev,
struct pinctrl_map *map,
unsigned nmaps)
@@ -121,7 +72,7 @@ static void berlin_pinctrl_dt_free_map(struct pinctrl_dev
*pctrl_dev,
static const struct pinctrl_ops berlin_pinctrl_ops = {
.get_groups_count = berlin_pinctrl_get_group_count,
.get_group_name = berlin_pinctrl_get_group_name,
- .dt_node_to_map = berlin_pinctrl_dt_node_to_map,
+ .dt_node_to_map =
pinconf_generic_function_groups_dt_node_to_map,
.dt_free_map= berlin_pinctrl_dt_free_map,
};
--
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 3/4] pinctrl: add a generic way to map node to map for group based drivers
This patch add a generic function to use a standard callback to
.dt_node_to_map for group based pinctrl drivers.
It parses nodes of the form:
foo_pmux: foo-pmux {
function = foo;
groups = g0, g1, g2;
}
Signed-off-by: Antoine Tenart antoine.ten...@free-electrons.com
---
drivers/pinctrl/pinconf-generic.c | 36 +
include/linux/pinctrl/pinconf-generic.h | 3 +++
2 files changed, 39 insertions(+)
diff --git a/drivers/pinctrl/pinconf-generic.c
b/drivers/pinctrl/pinconf-generic.c
index 29ff77f90fcb..456902150226 100644
--- a/drivers/pinctrl/pinconf-generic.c
+++ b/drivers/pinctrl/pinconf-generic.c
@@ -336,4 +336,40 @@ int pinconf_generic_dt_node_to_map(struct pinctrl_dev
*pctldev,
}
EXPORT_SYMBOL_GPL(pinconf_generic_dt_node_to_map);
+int pinconf_generic_function_groups_dt_node_to_map(struct pinctrl_dev *pctldev,
+ struct device_node *node, struct pinctrl_map **map,
+ unsigned *num_maps)
+{
+ struct property *prop;
+ unsigned reserved_maps = 0;
+ const char *function_name, *group_name;
+ int ngroups, ret;
+
+ *map = NULL;
+ *num_maps = 0;
+
+ ret = of_pinctrl_utils_read_function(pctldev, node, function_name,
+ngroups);
+ if (ret)
+ return ret;
+
+ ret = pinctrl_utils_reserve_map(pctldev, map, reserved_maps, num_maps,
+ ngroups);
+ if (ret)
+ return ret;
+
+ of_pinctrl_for_each_function_group(node, prop, group_name) {
+ ret = pinctrl_utils_add_map_mux(pctldev, map, reserved_maps,
+ num_maps, group_name,
+ function_name);
+ if (ret) {
+ dev_err(pctldev-dev, cannot add map: %d\n, ret);
+ return ret;
+ }
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(pinconf_generic_function_groups_dt_node_to_map);
+
#endif
diff --git a/include/linux/pinctrl/pinconf-generic.h
b/include/linux/pinctrl/pinconf-generic.h
index a15f10727eb8..acda4b89596d 100644
--- a/include/linux/pinctrl/pinconf-generic.h
+++ b/include/linux/pinctrl/pinconf-generic.h
@@ -157,6 +157,9 @@ int pinconf_generic_dt_subnode_to_map(struct pinctrl_dev
*pctldev,
int pinconf_generic_dt_node_to_map(struct pinctrl_dev *pctldev,
struct device_node *np_config, struct pinctrl_map **map,
unsigned *num_maps, enum pinctrl_map_type type);
+int pinconf_generic_function_groups_dt_node_to_map(struct pinctrl_dev *pctldev,
+ struct device_node *node, struct pinctrl_map **map,
+ unsigned *num_maps);
static inline int pinconf_generic_dt_node_to_map_group(
struct pinctrl_dev *pctldev, struct device_node *np_config,
--
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 1/4] Documentation: bindings: pinctrl: document the generic groups property
Group-based drivers use a groups property to define on which groups a mux function is applied to. Document it. Signed-off-by: Antoine Tenart antoine.ten...@free-electrons.com --- Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt index fa40a177164c..7a1adc08b366 100644 --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt @@ -141,6 +141,7 @@ Supported generic properties are: pins - the list of pins that properties in the node apply to function - the mux function to select +groups - a list of groups a mux function is applied to bias-disable - disable any pin bias bias-high-impedance- high impedance mode (third-state, floating) bias-bus-hold - latch weakly -- 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 2/4] pinctrl: add helpers for group based drivers
Since the group based drivers have their dt properties documented in the
generic pinctrl documentation, add generic helpers to avoid duplicating
code and to be sure new drivers won't use specific bindings for a known
purpose.
This patch add two functions to help group based drivers map their
nodes:
- of_pinctrl_utils_read_function(): reads the function name of a
specified node, and gets the number of groups it should be
applied to.
- of_pinctrl_for_each_function_group(): navigates through the groups of
a specified node, reading at each iteration the name of the current
group.
Signed-off-by: Antoine Tenart antoine.ten...@free-electrons.com
---
drivers/pinctrl/pinctrl-utils.c | 26 ++
drivers/pinctrl/pinctrl-utils.h | 9 +
2 files changed, 35 insertions(+)
diff --git a/drivers/pinctrl/pinctrl-utils.c b/drivers/pinctrl/pinctrl-utils.c
index d77693f2cc1b..0ce44ff70197 100644
--- a/drivers/pinctrl/pinctrl-utils.c
+++ b/drivers/pinctrl/pinctrl-utils.c
@@ -140,3 +140,29 @@ void pinctrl_utils_dt_free_map(struct pinctrl_dev *pctldev,
kfree(map);
}
EXPORT_SYMBOL_GPL(pinctrl_utils_dt_free_map);
+
+#ifdef CONFIG_OF
+int of_pinctrl_utils_read_function(struct pinctrl_dev *pctldev,
+ struct device_node *node, const char **function_name,
+ int *ngroups)
+{
+ int ret;
+
+ ret = of_property_read_string(node, function, function_name);
+ if (ret) {
+ dev_err(pctldev-dev, missing function property in node %s\n,
+ node-name);
+ return -EINVAL;
+ }
+
+ *ngroups = of_property_count_strings(node, groups);
+ if (ngroups = 0) {
+ dev_err(pctldev-dev, missing groups property in node %s\n,
+ node-name);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(of_pinctrl_utils_read_function);
+#endif
diff --git a/drivers/pinctrl/pinctrl-utils.h b/drivers/pinctrl/pinctrl-utils.h
index d0ffe1ce200f..d768dfe5daee 100644
--- a/drivers/pinctrl/pinctrl-utils.h
+++ b/drivers/pinctrl/pinctrl-utils.h
@@ -40,4 +40,13 @@ int pinctrl_utils_add_config(struct pinctrl_dev *pctldev,
void pinctrl_utils_dt_free_map(struct pinctrl_dev *pctldev,
struct pinctrl_map *map, unsigned num_maps);
+#ifdef CONFIG_OF
+int of_pinctrl_utils_read_function(struct pinctrl_dev *pctrldev,
+ struct device_node *node, const char **function_name,
+ int *ngroups);
+
+#define of_pinctrl_for_each_function_group(node, prop, group_name) \
+ of_property_for_each_string(node, groups, prop, group_name)
+#endif
+
#endif /* __PINCTRL_UTILS_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/
[PATCH 0/4] pinctrl: add helpers for group based drivers
Linus, Sebastian, As discussed earlier this year[1], this series introduce helpers for group based pinctrl drivers: - of_pinctrl_utils_read_function(): reads the function name of a specified node, and gets the number of groups it should be applied to. - of_pinctrl_for_each_function_group(): navigates through the groups of a specified node, reading at each iteration the name of the current group. A generic function to parse nodes for group based drivers is also added, and then used in the Berlin pinctrl driver: - pinconf_generic_function_groups_dt_node_to_map() [1] https://lkml.org/lkml/2014/5/17/38 Antoine Tenart (4): Documentation: bindings: pinctrl: document the generic groups property pinctrl: add helpers for group based drivers pinctrl: add a generic way to map node to map for group based drivers pinctrl: berlin: use the generic node to map function .../bindings/pinctrl/pinctrl-bindings.txt | 1 + drivers/pinctrl/berlin/Kconfig | 1 + drivers/pinctrl/berlin/berlin.c| 53 +- drivers/pinctrl/pinconf-generic.c | 36 +++ drivers/pinctrl/pinctrl-utils.c| 26 +++ drivers/pinctrl/pinctrl-utils.h| 9 include/linux/pinctrl/pinconf-generic.h| 3 ++ 7 files changed, 78 insertions(+), 51 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/
Re: [PATCH 1/2] drivers/misc/eeprom/men_eeprod: Introduce MEN Board Information EEPROM driver
Most customers wants just to have a running system without installing anything. And for me an EEPROM is so simple and should not need a complicated way to access it. As I pointed out, there are ways to do it other than a seperate driver. Yes of course there are a lot of possibilities. This was just an example what we currently use and what was developed years ago. And please notice that this solution you chose is not acceptible for upstream. We can't have n copies of the at24 driver with just some minor differences. This is a maintenance nightmare. Yes, I know it was easiest to start with and it works, but that does not help here. With a driver like this you can also define read only attributes to prevent customer to write or modify the data in the production section. With i2ctools you can just write any data to it you want. i2cget won't modify any data. i2cset does, if anyone wants to do that. BTW it does that also after you removed your driver, so basically no big difference here. I am not talking about runtime here, I don't care about that. I am talking about the ABI we create and we have to maintain basically forever. And with vendor specific configuartion data I have doubts with that being stable. Ok, but i do not think that we can make a general ABI definition for those kind of devices because every vendor will have its own data in the EEPROM which he want to have. Exactly, that was what I was saying. What we probably should have in at24 is regions which should not be exposed to userspace, because they contain config data. That would be nice. I'm not sure if we can add table based decoding to at24, that needs some experiments. But it will really need such experiments and some more effort. These is a HUGE difference. If I read tempX_input, I don't need to care if the sensor is I2C or SPI or whatever. The kernel abstracts that away. The files you create are for your I2C EEPROM only. Data gets reformatted and access gets hidden, but nothing is abstracted away. It would be different if we had a generic convention for serial_id or stuff like that. But as configuration data is highly specific I don't see this coming. For a standard sysfs interface it is a huge difference yes. At the point of few from the EEPROM device it is a device like a temp sensor which could be different from vendor to vendor. Here it gets frustrating. It seems you have no idea what an OS is for, not even after I tried to describe it :( signature.asc Description: Digital signature
[PATCH] drivers: net: xgene: Add missing initialization in xgene_enet_ecc_init()
drivers/net/ethernet/apm/xgene/xgene_enet_sgmac.c: In function
‘xgene_enet_ecc_init’:
drivers/net/ethernet/apm/xgene/xgene_enet_sgmac.c:126: warning: ‘data’ may be
used uninitialized in this function
Depending on the arbitrary value on the stack, the loop may terminate
too early, and cause a bogus -ENODEV failure.
Signed-off-by: Geert Uytterhoeven ge...@linux-m68k.org
---
drivers/net/ethernet/apm/xgene/xgene_enet_sgmac.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_sgmac.c
b/drivers/net/ethernet/apm/xgene/xgene_enet_sgmac.c
index e6d24c2101982444..19e13583b4259cd4 100644
--- a/drivers/net/ethernet/apm/xgene/xgene_enet_sgmac.c
+++ b/drivers/net/ethernet/apm/xgene/xgene_enet_sgmac.c
@@ -123,7 +123,7 @@ static u32 xgene_enet_rd_mac(struct xgene_enet_pdata *p,
u32 rd_addr)
static int xgene_enet_ecc_init(struct xgene_enet_pdata *p)
{
struct net_device *ndev = p-ndev;
- u32 data;
+ u32 data = 0;
int i;
xgene_enet_wr_diag_csr(p, ENET_CFG_MEM_RAM_SHUTDOWN_ADDR, 0);
--
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: [bisected] e341694e3eb5 netlink_lookup() rcu conversion causes latencies
On Sat, Oct 11, 2014 at 11:25:14PM +0100, Thomas Graf wrote: On 10/11/14 at 12:32pm, Eric Dumazet wrote: On Sat, 2014-10-11 at 10:36 +0200, Heiko Carstens wrote: Hi all, it just came to my attention that commit e341694e3eb5 netlink: Convert netlink_lookup() to use RCU protected hash table causes network latencies for me on s390. The testcase is quite simple and 100% reproducible on s390: Simply login via ssh to a remote system which has the above mentioned patch applied. Any action like pressing return now has significant latencies. Or in other words, working via such a connection becomes a pain ;) I haven't debugged it, however I assume the problem is that a) the commit introduces a synchronize_net() call und b) s390 kernels usually get compiled with CONFIG_HZ_100 while most other architectures use CONFIG_HZ_1000. If I change the kernel config to CONFIG_HZ_1000 the problem goes away, however I don't consider this a fix... Another reason why this hasn't been observed on x86 may or may not be that we haven't implemented CONFIG_HAVE_CONTEXT_TRACKING on s390 (yet). But that's just guessing... CC Paul and Sasha I think the issue here is obvious and a fix is on the way to move the insertion and removal to a worker to no longer require the synchronize_rcu(). What bothers me is that the synchronize_rcu() should only occur on expand/shrink and not for every table update. The default table size is 64. *ping* ... is there already any patch available? -- 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] drivers/misc/eeprom/men_eeprod: Introduce MEN Board Information EEPROM driver
Here it gets frustrating. It seems you have no idea what an OS is for, not even after I tried to describe it :( Sorry, that might have been too strong. Still, we can't map any hardware which is out there 1:1 into userspace, we need abstraction. If you want to help with this abstraction, this is more than appreciated. If you want to keep your driver, this will have to stay out-of-tree, I'm afraid. Regards, Wolfram signature.asc Description: Digital signature
[PATCH 1/2] Thermal:Fix memory leak if occur goto unregister
Signed-off-by:yaodongd...@huawei.com --- drivers/thermal/thermal_core.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c index 71b0ec0..5b7d466 100644 --- a/drivers/thermal/thermal_core.c +++ b/drivers/thermal/thermal_core.c @@ -1574,6 +1574,7 @@ struct thermal_zone_device *thermal_zone_device_register(const char *type, unregister: release_idr(thermal_tz_idr, thermal_idr_lock, tz-id); device_unregister(tz-device); + kfree(tz); return ERR_PTR(result); } EXPORT_SYMBOL_GPL(thermal_zone_device_register); -- 1.8.0.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 2/2] Thermal:Remove usless if(!result) before return tz
result is always zero when comes here. Signed-off-by:yaodongd...@huawei.com --- drivers/thermal/thermal_core.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c index 5b7d466..19cac8e 100644 --- a/drivers/thermal/thermal_core.c +++ b/drivers/thermal/thermal_core.c @@ -1568,8 +1568,7 @@ struct thermal_zone_device *thermal_zone_device_register(const char *type, thermal_zone_device_update(tz); - if (!result) - return tz; + return tz; unregister: release_idr(thermal_tz_idr, thermal_idr_lock, tz-id); -- 1.8.0.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: [uml-devel] [UM] Long loop in __getnsdayoftime() after resume from ram
On Sun, Oct 19, 2014 at 2:39 PM, Thomas Meyer tho...@m3y3r.de wrote: Hello, in UML kernel I get a long cpu using loop in __getnstimeofday() (kernel/time/timekeeping.c:315) in the call of timespec_add_ns(), when I left the host kernel suspended to ram for a few hours and resume again. this is because it seems like the tk-xtime_sec wasn't updated yet, but the nsecs were. nsecs can be as high as 8111000111000111000l the function timespec_add_ns() (include/linux/time.h:266) will call __iter_div_u64_rem() which has an optimized loop for the case that the dividend is not much bigger as the divisior. but this isn't the case for resume from ram on the host kernel. any ideas how to fix this? is it possible to intercept the resume from ram and update the timekeeper-xtime_sec somehow? or can the um arch somehow overwrite timespec_add_ns() to always use div_u64_rem() instead? Hmm, does this always happen? At least on my notebook it did not happen. I've started an UML yesterday suspended it and after more than 12h it worked fine today. BTW: Do you see the issue also then freezing UML using the freezer cgroup? Would be easier to debug. :) -- Thanks, //richard -- 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: [GIT PULL for v3.18-rc1] media updates
Mauro, On Thu, 2014-10-09 at 14:18 -0300, Mauro Carvalho Chehab wrote: Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media tags/media/v3.18-rc1 [...] Mauro Carvalho Chehab (180): [...] [media] omap: be sure that MMU is there for COMPILE_TEST This became commit 38a073116525 ([media] omap: be sure that MMU is there for COMPILE_TEST). As I reported in http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/82299 it adds an (optional) test for a Kconfig symbol HAS_MMU. There's no such symbol. So that test will always fail. Did you perhaps mean simply MMU? Paul Bolle -- 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 5/5] x86,perf: Only allow rdpmc if a perf_event is mapped
On Sun, Oct 19, 2014 at 03:57:54PM -0700, Andy Lutomirski wrote: Maybe, but at that point we commit to yet another ABI... I'd rather just put a 'sane' implementation in a library or so. This cuts both ways, though. For vdso timekeeping, the underlying data structure has changed repeatedly, sometimes to add features, and sometimes for performance, and the vdso has done a good job insulating userspace from it. (In fact, until 3.16, even the same exact kernel version couldn't be relied on to have the same data structure with different configs, and even now, no one really wants to teach user libraries how to parse the pvclock data structures.) Fair enough, but as it stands we've already committed to the data structure exposed to userspace. I would certainly not suggest putting anything beyond the bare minimum into the vdso. Depends on what you really want to do I suppose, if you've got a pinned event and know there cannot be multiplexing, not doing the time reads the multiplications and all that saves a ton of cycles. But in generic I suppose you have to do all that. FWIW, something should probably specify exactly when it's safe to try a userspace rdpmc. I think that the answer is that, for a perf event watching a pid, only that pid can do it (in particular, other threads must not try). For a perf event monitoring a whole cpu, the answer is less clear to me. This all was really only meant to be used for self-monitoring, so where an event is attached to the very same task, anything else and I'm find disabling it. -- 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/
v3.18-rc1 bloat-o-meter
Hi all, Below is the bloat-o-meter output when comparing an m68k/atari_defconfig kernel for v3.17 and v3.18-rc1. Major culprit seems to be bpf. Can this become modular or optional? Currently it's always included if CONFIG_NET=y. Thanks! add/remove: 374/146 grow/shrink: 392/323 up/down: 57311/-24659 (32652) function old new delta do_check -4402 +4402 bpf_check -1976 +1976 sys_bpf-1238 +1238 SyS_bpf-1238 +1238 xfrm_hash_resize15302602 +1072 __skb_flow_dissect -1018 +1018 pcpu_balance_workfn- 954+954 policy_hash_direct 1181034+916 policy_hash_bysel1781094+916 check_mem_access - 834+834 udp6_gro_receive - 802+802 __ip_options_echo - 802+802 validate_xmit_skb - 746+746 bpf_prog_load - 670+670 udp4_gro_receive - 634+634 load_elf_binary 21282698+570 string_escape_mem - 568+568 __bioset_create- 556+556 pcpu_create_chunk - 432+432 xfrm_hash_rebuild - 424+424 bt_for_each- 416+416 iov_iter_zero - 394+394 pcpu_next_unpop- 390+390 pcpu_next_pop - 388+388 escaped_string - 364+364 tcp6_gso_segment - 362+362 __percpu_ref_switch_to_atomic - 344+344 alloc_skb_with_frags - 342+342 check_func_arg - 340+340 nlmsvc_lock 410 736+326 guard_bio_eod - 306+306 vm_pgprot_modify - 304+304 udp6_ufo_fragment470 768+298 sd_init_command 35963892+296 nfs_volume_list_show - 296+296 pcpu_alloc_area 502 790+288 map_lookup_elem- 280+280 push_insn - 276+276 tcp6_gro_receive 240 510+270 devkmsg_write - 258+258 is_state_visited - 254+254 t10_pi_verify - 252+252 dma_common_contiguous_remap- 250+250 copy_to_iter - 246+246 copy_from_iter - 246+246 bio_integrity_process - 244+244 generic_setlease 580 822+242 find_mergeable - 238+238 print_verifier_state - 230+230 skb_udp_tunnel_segment 716 944+228 dns_resolver_cmp - 224+224 copy_from_iter_bvec- 220+220 copy_to_iter_bvec - 218+218 tcp4_gro_receive 198 400+202 __kmalloc_track_caller - 202+202 check_stack_boundary - 200+200 __percpu_ref_switch_to_percpu - 200+200 do_mount20622260+198 tcp_recvmsg 21182308+190 __udp4_lib_rcv 21282314+186 sys_cacheflush 11361318+182 ethtool_set_tunable- 180+180 ethtool_get_tunable- 180+180 tty_send_xchar - 178+178 icmpv4_xrlim_allow - 176+176 __skb_flow_get_ports - 176+176 packet_sendmsg 30663240+174 nlm_end_grace_write- 170+170 path_setxattr - 168+168 scsi_probe_and_add_lun 22242388+164 bpf_prog_realloc - 164
Re: [patch 1/3] ipmi: Setup ipmi_devintf automatically if ipmi_msghandler gets loaded
On Fri, 2014-10-17 at 18:14 +0200, Corey Minyard wrote:
How about this. I did a little research, and there's something called soft
module dependencies. Apparently you can add:
MODULE_SOFTDEP(post: ipmi_devintf)
to ipmi_msghandler.c and modprobe would load ipmi_devintf after loading
ipmi_msghandler if it was available.
This is nice, but not commonly available in distro kernels so far.
AFAICS, out of the distros Fujitsu supports, only RHEL7 supports it.
I vote for MODULE_SOFTDEP for upstream, and modalias for distros that
don't support MODULE_SOFTDEP yet.
Martin
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�j:+v���zZ+��+zf���h���~i���z� �w���?��)ߢf��^jǫy�m��@A�a���
0��h���i
Re: [PATCH v2 16/16] usb: dwc3: enable usb suspend phy
On Fri, Oct 17, 2014 at 01:48:19PM -0500, Felipe Balbi wrote: Hi, On Fri, Oct 17, 2014 at 06:41:04PM +, Paul Zimmerman wrote: From: Felipe Balbi [mailto:ba...@ti.com] Sent: Friday, October 17, 2014 8:00 AM On Fri, Oct 17, 2014 at 04:53:41PM +0800, Huang Rui wrote: AMD NL needs to suspend usb3 ss phy, but this doesn't enable on simulation board. Signed-off-by: Huang Rui ray.hu...@amd.com --- drivers/usb/dwc3/core.c | 7 ++- drivers/usb/dwc3/dwc3-pci.c | 3 ++- drivers/usb/dwc3/platform_data.h | 1 + 3 files changed, 9 insertions(+), 2 deletions(-) diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c index 3ccfe41..4a98696 100644 --- a/drivers/usb/dwc3/core.c +++ b/drivers/usb/dwc3/core.c @@ -395,6 +395,9 @@ static void dwc3_phy_setup(struct dwc3 *dwc) if (dwc-quirks DWC3_QUIRK_TX_DEEPH) reg |= DWC3_GUSB3PIPECTL_TX_DEEPH(1); + if (dwc-quirks DWC3_QUIRK_SUSPHY) should be: if (!dwc-suspend_usb3_phy_quirk) + reg |= DWC3_GUSB3PIPECTL_SUSPHY; IIRC, databook asks us to set that bit anyway, so the quirk is disabling that bit. Am I missing something ? Paul ? It looks to me that Huang's patch is enabling that bit, not disabling it. right, but that's what's actually quirky right ? IIRC, Databook asks us to set usb2 and usb3 suspend phy bits and we're just not doing it. Currently the driver does not set either DWC3_GUSB3PIPECTL_SUSPHY or DWC3_GUSB2PHYCFG_SUSPHY (unless it has been added by that big patch series you just posted). According to the databook, both of those bits should be set to 1 after the core initialization has completed. there you go. So unless that quirk bit flag is set, we're safe of setting SUSPHY bit for everybody. So I can update to set these two suspend phy bits defaultly in my next patch set, is it OK? :) Thanks, Rui So I think the driver should be changed to enable both of those by default, and then maybe you want quirks to disable them if there is some platform out there which needs that. Yeah, that's what I thought too :-) Thanks for confirming -- balbi -- 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] Documentation: ptp: Fix build failure on MIPS cross builds
The MIPS system calls are defined based on the -mabi gcc option.
However, the testptp is built on the host using the unistd header
from the kernel sources which were built for the MIPS architecture
thus guarded with the __MIPS_SIM_{ABI64, ABI32, NABI32} definitions
leading to the following build problem:
Documentation/ptp/testptp.c: In function 'clock_adjtime':
Documentation/ptp/testptp.c:55: error: '__NR_clock_adjtime'
undeclared (first use in this function)
Documentation/ptp/testptp.c:55: error: (Each undeclared identifier is reported
only once Documentation/ptp/testptp.c:55: error: for each function it appears
in.)
This fix is similar to e9107f88c985bcda (samples/seccomp/Makefile: do not build
tests if cross-compiling for MIPS)
Cc: Richard Cochran richardcoch...@gmail.com
Cc: Jonathan Corbet cor...@lwn.net
Cc: net...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Markos Chandras markos.chand...@imgtec.com
---
Documentation/ptp/Makefile | 10 ++
1 file changed, 10 insertions(+)
diff --git a/Documentation/ptp/Makefile b/Documentation/ptp/Makefile
index 293d6c09a11f..397c1cd2eda7 100644
--- a/Documentation/ptp/Makefile
+++ b/Documentation/ptp/Makefile
@@ -1,5 +1,15 @@
# List of programs to build
+ifndef CROSS_COMPILE
hostprogs-y := testptp
+else
+# MIPS system calls are defined based on the -mabi that is passed
+# to the toolchain which may or may not be a valid option
+# for the host toolchain. So disable testptp if target architecture
+# is MIPS but the host isn't.
+ifndef CONFIG_MIPS
+hostprogs-y := testptp
+endif
+endif
# Tell kbuild to always build the programs
always := $(hostprogs-y)
--
2.1.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 v4] ARM: perf: save/restore pmu registers in pm notifier
-Original Message-
From: Will Deacon [mailto:will.dea...@arm.com]
Sent: 2014年7月4日 1:57
To: Neil Zhang
Cc: Sudeep Holla; 'li...@arm.linux.org.uk'; 'linux-arm-
ker...@lists.infradead.org'; 'linux-kernel@vger.kernel.org';
'devicet...@vger.kernel.org'
Subject: Re: [PATCH v4] ARM: perf: save/restore pmu registers in pm
notifier
On Mon, Jun 30, 2014 at 11:39:15AM +0100, Neil Zhang wrote:
I will prepare another patch to add DT description under PMU
since there is no generic power domain support for pm notifier
if no other
concerns.
We can change the manner if there is generic power domain
support for
pm notifier later.
Thanks.
No, please don't add any DT bindings for power domains specific
to
PMU node.
We can't change the DT bindings once added.
As I pointed out the DT bindings for generic power domains are
under discussion.
See if you can reuse it, if not help in extending it so that it
can be used.
Sorry for reply later.
As I said before the under discussed generic power domain is not
suitable for CPU peripherals since they are all known belong to CPU
or cluster power domain.
If we want to follow the way they are discussion, we need to
register core and cluster power provider, and need vfp/gic/pmu etc
to require them.
Is it really suitable?
Do you have any comments?
If no, I would like to put it under PMU node.
Sudeep is a better person to comment than me, but I'd still rather this
was handled more generically as opposed to a PMU-specific hack. I don't
see a problem including GIC and VFP here, but only when we actually
need to save/restore them (i.e. what the hardware guys went crazy with
the power domains).
Long time no follow up for this loop.
Sorry that I will pick it again.
Will,
I prefer to check always-on field under PMU node to check whether we need
Save/restore them.
Here is a sample for arch timer which also add under itself.
What do you think?
commit 82a5619410d4c4df65c04272db198eca5a867c18
Author: Lorenzo Pieralisi lorenzo.pieral...@arm.com
Date: Tue Apr 8 10:04:32 2014 +0100
clocksource: arch_arm_timer: Fix age-old arch timer C3STOP detection issue
Will
Best Regards,
Neil Zhang
N�Р骒r��yb�X�肚�v�^�)藓{.n�+�伐�{��赙zXФ�≤�}��财�z�j:+v�����赙zZ+��+zf＂�h���~i���z� �wア�?�ㄨ���)撷f��^j谦y�m��@A�a囤�
0鹅h���i
Re: [RFC 5/5] x86,perf: Only allow rdpmc if a perf_event is mapped
On Sun, Oct 19, 2014 at 05:08:08PM -0700, Andy Lutomirski wrote: Before I totally screw this up: is .event_idx used for anything except userspace rdpmc? It should only be used for that. There are a whole bunch of implementations of that callback: - perf_event_idx_default seems fishy I suppose I did that to encode the rule that 0 := disabled, figuring that if there is no actual instruction to access the data, all of this would be pointless anyhow. - power_pmu_event_idx seems even fishier Agreed, I preserved behaviour in 35edc2a5095e (perf, arch: Rework perf_event_index()) and at that time asked about why this is. Nobody replied, lets try again. Michael, Anton? - cpumsf_pmu_event_idx is the same as power_pmu_event_idx. Oh cute, lets ask the s390 people, do you guys have a userspace instruction to read the actual counter value? - perf_swevent_event_idx returns 0. Right, guaranteed no way to access any of that, maybe we should make the default like that too. etc. x86 is the only implementation of arch_perf_update_userpage, which makes me think that the .event_idx callback should just be removed and that arch_perf_update_userpage should be responsible for filling it in if needed. Its a per pmu thing, with the x86 hardware pmu being the only one that's actually 'known' working to me. All the other x86 pmus like the software, uncore, etc. don't support this. That said, there's definitely room for improvement 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/
[PATCH v4 4/4] mtd: nand: gpmi: add raw oob access functions
Implement raw OOB access functions to retrieve OOB bytes when accessing the
NAND in raw mode.
Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
---
drivers/mtd/nand/gpmi-nand/gpmi-nand.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
index bd4dedc..d7c483a 100644
--- a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
+++ b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
@@ -1473,6 +1473,22 @@ static int gpmi_ecc_write_page_raw(struct mtd_info *mtd,
return 0;
}
+static int gpmi_ecc_read_oob_raw(struct mtd_info *mtd, struct nand_chip *chip,
+int page)
+{
+ chip-cmdfunc(mtd, NAND_CMD_READ0, 0, page);
+
+ return gpmi_ecc_read_page_raw(mtd, chip, NULL, 1, page);
+}
+
+static int gpmi_ecc_write_oob_raw(struct mtd_info *mtd, struct nand_chip *chip,
+int page)
+{
+ chip-cmdfunc(mtd, NAND_CMD_SEQIN, 0, page);
+
+ return gpmi_ecc_write_page_raw(mtd, chip, NULL, 1);
+}
+
static int gpmi_block_markbad(struct mtd_info *mtd, loff_t ofs)
{
struct nand_chip *chip = mtd-priv;
@@ -1792,6 +1808,8 @@ static int gpmi_init_last(struct gpmi_nand_data *this)
ecc-write_oob = gpmi_ecc_write_oob;
ecc-read_page_raw = gpmi_ecc_read_page_raw;
ecc-write_page_raw = gpmi_ecc_write_page_raw;
+ ecc-read_oob_raw = gpmi_ecc_read_oob_raw;
+ ecc-write_oob_raw = gpmi_ecc_write_oob_raw;
ecc-mode = NAND_ECC_HW;
ecc-size = bch_geo-ecc_chunk_size;
ecc-strength = bch_geo-ecc_strength;
--
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 v2] sched/numa: fix unsafe get_task_struct() in task_numa_assign()
Unlocked access to dst_rq-curr in task_numa_compare() is racy.
If curr task is exiting this may be a reason of use-after-free:
task_numa_compare()do_exit()
rcu_read_lock()schedule()
cur = ACCESS_ONCE(dst_rq-curr)...
...rq-curr = next;
...context_switch()
...finish_task_switch()
...put_task_struct()
...__put_task_struct()
...
free_task_struct()
task_numa_assign() ...
get_task_struct() ...
As noted by Oleg:
The lockless get_task_struct(tsk) is only safe if tsk == current
and didn't pass exit_notify(), or if this tsk was found on a rcu
protected list (say, for_each_process() or find_task_by_vpid()).
IOW, it is only safe if release_task() was not called before we
take rcu_read_lock(), in this case we can rely on the fact that
delayed_put_pid() can not drop the (potentially) last reference
until rcu_read_unlock().
And as Kirill pointed out task_numa_compare()-task_numa_assign()
path does get_task_struct(dst_rq-curr) and this is not safe. The
task_struct itself can't go away, but rcu_read_lock() can't save
us from the final put_task_struct() in finish_task_switch(); this
reference goes away without rcu gp
The patch makes 3-stage check of dst_rq-curr; it ensures we've taken
the curr before delayed_put_task_struct() is called to put it. If so,
we may use the cur like we'd taken it from RCU-protected list.
Signed-off-by: Kirill Tkhai ktk...@parallels.com
Suggested-by: Oleg Nesterov o...@redhat.com
---
kernel/sched/fair.c | 43 +--
1 file changed, 41 insertions(+), 2 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 0b069bf..ffc7c3b 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -1147,6 +1147,44 @@ static bool load_too_imbalanced(long src_load, long
dst_load,
}
/*
+ * Return rq-curr if it is not exiting (delayed_put_task_struct() for it
+ * hasn't been called yet). If result is not NULL, it's safe to use it
+ * like it'd be picked from RCU-protected list (use get_task_struct() etc).
+ */
+static struct task_struct *rq_curr_if_not_exiting(struct rq *rq)
+{
+ struct task_struct *cur = ACCESS_ONCE(rq-curr);
+ unsigned int flags;
+
+ rcu_lockdep_assert(rcu_read_lock_held(), RCU lock must be held);
+
+ /* This memory may become unmapped, so we can't read it directly */
+ if (probe_kernel_read(flags, cur-flags, sizeof(flags)) 0)
+ return NULL;
+
+ if (flags PF_EXITING)
+ return NULL;
+
+ smp_rmb(); /* Pairs with smp_mb() in do_exit() */
+
+ /*
+* We've reached here. Three situations are possible:
+* 1)cur has gone, and dst_rq-curr is pointing to other memory.
+* In this case the check will fail;
+* 2)cur is pointing to a new task, which is using the memory of
+* just gone and freed cur (and it is new dst_rq-curr). It is
+* OK, because we've locked RCU even before the new task has been
+* created (so delayed_put_task_struct() hasn't been called yet);
+* 3)we've taken a not exiting task (likely case). No need to worry.
+* The above checks are necessary only for this case.
+*/
+ if (cur != ACCESS_ONCE(rq-curr))
+ cur = NULL;
+
+ return cur;
+}
+
+/*
* This checks if the overall compute and NUMA accesses of the system would
* be improved if the source tasks was migrated to the target dst_cpu taking
* into account that it might be best if task running on the dst_cpu should
@@ -1164,8 +1202,9 @@ static void task_numa_compare(struct task_numa_env *env,
long moveimp = imp;
rcu_read_lock();
- cur = ACCESS_ONCE(dst_rq-curr);
- if (cur-pid == 0) /* idle */
+ cur = rq_curr_if_not_exiting(dst_rq);
+
+ if (cur is_idle_task(cur))
cur = NULL;
/*
--
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 v4 0/4] mtd: nand: gpmi: add proper raw access support
Hello, This series provides an implementation for raw accesses taking care of hidding the specific layout used by the GPMI controller. I also updated the nand_ecc_ctrl struct documentation to clearly state that specific layouts should be hidden when accessing the NAND chip in raw mode. Best Regards, Boris Changes since v3: - add comments to the gpmi_move_bits function - extend raw read/write documentation - move last part of the raw_page_read function into a conditional block Changes since v2: - fixed a bug in gpmi_move_bits - add a raw_buffer field to be used when using raw access methods (experienced memory corruptions when directly using page_buffer_virt buffer) - add raw OOB access functions Boris Brezillon (4): mtd: nand: provide detailed description for raw read/write page methods mtd: nand: gpmi: add gpmi_move_bits function mtd: nand: gpmi: add proper raw access support mtd: nand: gpmi: add raw oob access functions drivers/mtd/nand/gpmi-nand/gpmi-lib.c | 129 + drivers/mtd/nand/gpmi-nand/gpmi-nand.c | 146 + drivers/mtd/nand/gpmi-nand/gpmi-nand.h | 6 ++ include/linux/mtd/nand.h | 17 +++- 4 files changed, 296 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 v4 1/4] mtd: nand: provide detailed description for raw read/write page methods
read_page_raw and write_page_raw method description is not clear enough.
It clearly specifies that ECC correction should not be involved but does
not talk about specific layout (by layout I mean where in-band and
out-of-band data are stored on the NAND media) used by NAND/ECC
controllers.
Those specific layouts might impact MTD users and thus should be hidden (as
already done in the standard NAND_ECC_HW_SYNDROME implementation).
Clearly state this constraint in the nand_ecc_ctrl struct documentation.
Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
---
include/linux/mtd/nand.h | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
index e4d451e..b14d190 100644
--- a/include/linux/mtd/nand.h
+++ b/include/linux/mtd/nand.h
@@ -455,8 +455,21 @@ struct nand_hw_control {
* be provided if an hardware ECC is available
* @calculate: function for ECC calculation or readback from ECC hardware
* @correct: function for ECC correction, matching to ECC generator (sw/hw)
- * @read_page_raw: function to read a raw page without ECC
- * @write_page_raw:function to write a raw page without ECC
+ * @read_page_raw: function to read a raw page without ECC. This function
+ * should hide the specific layout used by the ECC
+ * controller and always return contiguous in-band and
+ * out-of-band data even if they're not stored
+ * contiguously on the NAND chip (e.g.
+ * NAND_ECC_HW_SYNDROME interleaves in-band and
+ * out-of-band data).
+ * @write_page_raw:function to write a raw page without ECC. This function
+ * should hide the specific layout used by the ECC
+ * controller and consider the passed data as contiguous
+ * in-band and out-of-band data. ECC controller is
+ * responsible for doing the appropriate transformations
+ * to adapt to its specific layout (e.g.
+ * NAND_ECC_HW_SYNDROME interleaves in-band and
+ * out-of-band data).
* @read_page: function to read a page according to the ECC generator
* requirements; returns maximum number of bitflips corrected in
* any single ECC step, 0 if bitflips uncorrectable, -EIO hw error
--
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: linux-next: contact change for the osd tree
On 10/20/2014 01:56 AM, Stephen Rothwell wrote: Hi Boaz, I noticed your commits changing your email address, so I have updated the contact address for the osd tree. Thanks Stephen Sorry I forgot to CC You, thank you for picking this up Boaz -- 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 v4 2/4] mtd: nand: gpmi: add gpmi_move_bits function
Add a new function to move bits (not bytes) from a memory region to
another one.
This function is similar to memmove except it acts at bit level.
This function is needed to implement GPMI raw access functions, given the
fact that ECC engine does not pad ECC bits to the next byte boundary.
Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
---
drivers/mtd/nand/gpmi-nand/gpmi-lib.c | 129 +
drivers/mtd/nand/gpmi-nand/gpmi-nand.h | 4 +
2 files changed, 133 insertions(+)
diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-lib.c
b/drivers/mtd/nand/gpmi-nand/gpmi-lib.c
index 87e658c..5d4f140 100644
--- a/drivers/mtd/nand/gpmi-nand/gpmi-lib.c
+++ b/drivers/mtd/nand/gpmi-nand/gpmi-lib.c
@@ -1353,3 +1353,132 @@ int gpmi_read_page(struct gpmi_nand_data *this,
set_dma_type(this, DMA_FOR_READ_ECC_PAGE);
return start_dma_with_bch_irq(this, desc);
}
+
+void gpmi_move_bits(u8 *dst, size_t dst_bit_off,
+ const u8 *src, size_t src_bit_off,
+ size_t nbits)
+{
+ size_t i;
+ size_t nbytes;
+ u32 src_byte = 0;
+
+ /*
+* Move src and dst pointers to the closest byte pointer and store bit
+* offsets within a byte.
+*/
+ src += src_bit_off / 8;
+ src_bit_off %= 8;
+
+ dst += dst_bit_off / 8;
+ dst_bit_off %= 8;
+
+ /*
+* Initialize the src_byte value with bits available in the first byte
+* of data so that we end up with a byte aligned src pointer.
+*/
+ if (src_bit_off) {
+ src_byte = src[0] src_bit_off;
+ nbits -= 8 - src_bit_off;
+ src++;
+ }
+
+ /* Calculate the number of bytes that can be copied from src to dst. */
+ nbytes = nbits / 8;
+
+ /* Try to align dst to a byte boundary. */
+ if (dst_bit_off) {
+ if (src_bit_off = dst_bit_off) {
+ dst[0] = GENMASK(dst_bit_off - 1, 0);
+ dst[0] |= src_byte dst_bit_off;
+ src_bit_off += (8 - dst_bit_off);
+ src_byte = (8 - dst_bit_off);
+ dst_bit_off = 0;
+ dst++;
+ } else if (nbytes) {
+ src_byte |= src[0] (8 - src_bit_off);
+ dst[0] = GENMASK(dst_bit_off - 1, 0);
+ dst[0] |= src_byte dst_bit_off;
+ src_bit_off += dst_bit_off;
+ src_byte = (8 - dst_bit_off);
+ dst_bit_off = 0;
+ dst++;
+ nbytes--;
+ src++;
+ if (src_bit_off 7) {
+ src_bit_off -= 8;
+ dst[0] = src_byte;
+ dst++;
+ src_byte = 8;
+ }
+ }
+ }
+
+ if (!src_bit_off !dst_bit_off) {
+ /*
+* Both src and dst pointers are byte aligned, thus we can
+* just use the optimized memcpy function.
+*/
+ if (nbytes)
+ memcpy(dst, src, nbytes);
+ } else {
+ /*
+* src buffer is not byte aligned, hence we have to copy each
+* src byte to the src_byte variable before extracting a byte
+* to store in dst.
+*/
+ for (i = 0; i nbytes; i++) {
+ src_byte |= src[i] (8 - src_bit_off);
+ dst[i] = src_byte;
+ src_byte = 8;
+ }
+ }
+
+ /* Update dst and src pointers */
+ dst += nbytes;
+ src += nbytes;
+
+ /*
+* nbits is the number of remaining bits. It should not exceed 8 as
+* we've already copied as much bytes as possible.
+*/
+ nbits %= 8;
+
+ /*
+* If there's no more bits to copy to the destination and src buffer
+* was already byte aligned, then we're done.
+*/
+ if (!nbits !src_bit_off)
+ return;
+
+ /* Copy the remaining bits to src_byte */
+ if (nbits)
+ src_byte |= (*src GENMASK(nbits - 1, 0))
+ ((8 - src_bit_off) % 8);
+ nbits += (8 - src_bit_off) % 8;
+
+ /*
+* In case there were not enough bits to get a byte aligned dst buffer
+* prepare the src_byte variable to match the dst organization (shift
+* src_byte by dst_bit_off and retrieve the least significant bits from
+* dst).
+*/
+ if (dst_bit_off)
+ src_byte = (src_byte dst_bit_off) |
+ (*dst GENMASK(dst_bit_off - 1, 0));
+ nbits += dst_bit_off;
+
+ /*
+* Keep most significant bits from dst if we end up with an
[PATCH v4 3/4] mtd: nand: gpmi: add proper raw access support
Several MTD users (either in user or kernel space) expect a valid raw
access support to NAND chip devices.
This is particularly true for testing tools which are often touching the
data stored in a NAND chip in raw mode to artificially generate errors.
The GPMI drivers do not implemenent raw access functions, and thus rely on
default HW_ECC scheme implementation.
The default implementation consider the data and OOB area as properly
separated in their respective NAND section, which is not true for the GPMI
controller.
In this driver/controller some OOB data are stored at the beginning of the
NAND data area (these data are called metadata in the driver), then ECC
bytes are interleaved with data chunk (which is similar to the
HW_ECC_SYNDROME scheme), and eventually the remaining bytes are used as
OOB data.
Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
---
drivers/mtd/nand/gpmi-nand/gpmi-nand.c | 128 +
drivers/mtd/nand/gpmi-nand/gpmi-nand.h | 2 +
2 files changed, 130 insertions(+)
diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
index 959cb9b..bd4dedc 100644
--- a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
+++ b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
@@ -791,6 +791,7 @@ static void gpmi_free_dma_buffer(struct gpmi_nand_data
*this)
this-page_buffer_phys);
kfree(this-cmd_buffer);
kfree(this-data_buffer_dma);
+ kfree(this-raw_buffer);
this-cmd_buffer= NULL;
this-data_buffer_dma = NULL;
@@ -837,6 +838,9 @@ static int gpmi_alloc_dma_buffer(struct gpmi_nand_data
*this)
if (!this-page_buffer_virt)
goto error_alloc;
+ this-raw_buffer = kzalloc(mtd-writesize + mtd-oobsize, GFP_KERNEL);
+ if (!this-raw_buffer)
+ goto error_alloc;
/* Slice up the page buffer. */
this-payload_virt = this-page_buffer_virt;
@@ -1347,6 +1351,128 @@ gpmi_ecc_write_oob(struct mtd_info *mtd, struct
nand_chip *chip, int page)
return status NAND_STATUS_FAIL ? -EIO : 0;
}
+static int gpmi_ecc_read_page_raw(struct mtd_info *mtd,
+ struct nand_chip *chip, uint8_t *buf,
+ int oob_required, int page)
+{
+ struct gpmi_nand_data *this = chip-priv;
+ struct bch_geometry *nfc_geo = this-bch_geometry;
+ int eccsize = nfc_geo-ecc_chunk_size;
+ int eccbits = nfc_geo-ecc_strength * nfc_geo-gf_len;
+ u8 *tmp_buf = this-raw_buffer;
+ size_t src_bit_off;
+ size_t oob_bit_off;
+ size_t oob_byte_off;
+ uint8_t *oob = chip-oob_poi;
+ int step;
+
+ chip-read_buf(mtd, tmp_buf,
+ mtd-writesize + mtd-oobsize);
+
+ if (this-swap_block_mark) {
+ u8 swap = tmp_buf[0];
+
+ tmp_buf[0] = tmp_buf[mtd-writesize];
+ tmp_buf[mtd-writesize] = swap;
+ }
+
+ if (oob_required)
+ memcpy(oob, tmp_buf, nfc_geo-metadata_size);
+
+ oob_bit_off = nfc_geo-metadata_size * 8;
+ src_bit_off = oob_bit_off;
+
+ for (step = 0; step nfc_geo-ecc_chunk_count; step++) {
+ if (buf)
+ gpmi_move_bits(buf, step * eccsize * 8,
+ tmp_buf, src_bit_off,
+ eccsize * 8);
+ src_bit_off += eccsize * 8;
+
+ if (oob_required)
+ gpmi_move_bits(oob, oob_bit_off,
+ tmp_buf, src_bit_off,
+ eccbits);
+
+ src_bit_off += eccbits;
+ oob_bit_off += eccbits;
+ }
+
+ if (oob_required) {
+ if (oob_bit_off % 8)
+ oob[oob_bit_off / 8] = GENMASK(oob_bit_off - 1, 0);
+
+ oob_byte_off = DIV_ROUND_UP(oob_bit_off, 8);
+
+ if (oob_byte_off mtd-oobsize)
+ memcpy(oob + oob_byte_off,
+ tmp_buf + mtd-writesize + oob_byte_off,
+ mtd-oobsize - oob_byte_off);
+ }
+
+ return 0;
+}
+
+static int gpmi_ecc_write_page_raw(struct mtd_info *mtd,
+ struct nand_chip *chip,
+ const uint8_t *buf,
+ int oob_required)
+{
+ struct gpmi_nand_data *this = chip-priv;
+ struct bch_geometry *nfc_geo = this-bch_geometry;
+ int eccsize = nfc_geo-ecc_chunk_size;
+ int eccbits = nfc_geo-ecc_strength * nfc_geo-gf_len;
+ u8 *tmp_buf = this-raw_buffer;
+ uint8_t *oob = chip-oob_poi;
+ size_t dst_bit_off;
+ size_t oob_bit_off;
+ size_t oob_byte_off;
+ int step;
+
+ if (!buf || !oob_required)
+ memset(tmp_buf, 0xff, mtd-writesize + mtd-oobsize);
+
+
Re: [PATCH] sched/numa: fix unsafe get_task_struct() in task_numa_assign()
В Вс, 19/10/2014 в 23:38 +0200, Peter Zijlstra пишет: On Sun, Oct 19, 2014 at 03:13:31AM +0400, Kirill Tkhai wrote: I'm too tired for all this, but: + smp_rmb(); /* Pairs with dst_rq-lock unlocking which implies smp_wmb */ RELEASE does not imply a WMB. Thanks, please see, I've sent new version. -- 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] sched/numa: fix unsafe get_task_struct() in task_numa_assign()
В Вс, 19/10/2014 в 21:24 +0200, Oleg Nesterov пишет: On 10/19, Kirill Tkhai wrote: 19.10.2014, 00:59, Oleg Nesterov o...@redhat.com: No, I don't think this can work. Let's look at the current code: rcu_read_lock(); cur = ACCESS_ONCE(dst_rq-curr); if (cur-pid == 0) /* idle */ And any dereference, even reading -pid is not safe. This memory can be freed, unmapped, reused, etc. Looks like, task_numa_compare() needs to take dst_rq-lock and get the refernce first. Yeah, detection of idle is not save. If we reorder the checks almost all problems will be gone. All except unmapping. JFI, is it possible with such kernel structures as task_struct? Yes, if DEBUG_PAGEALLOC. See kernel_map_pages() in arch/x86/mm/pageattr.c kernel_map_pages(enable = false) clears PAGE_PRESENT if slab returns the pages to system. Thanks, Oleg! --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -1165,7 +1165,30 @@ static void task_numa_compare(struct task_numa_env *env, rcu_read_lock(); cur = ACCESS_ONCE(dst_rq-curr); - if (cur-pid == 0) /* idle */ + /* +* No need to move the exiting task, and this ensures that -curr +* wasn't reaped and thus get_task_struct() in task_numa_assign() +* is safe; note that rcu_read_lock() can't protect from the final +* put_task_struct() after the last schedule(). +*/ + if (cur-flags PF_EXITING) + cur = NULL; so this needs probe_kernel_read(cur-flags). + if (cur != ACCESS_ONCE(dst_rq-curr)) + cur = NULL; Yes, if this task_struct was freed in between we do not care if this memory was reused (except PF_EXITING can be false positive). If it was freed and now the same memory is -curr again we know that delayed_put_task_struct() can't be called until we drop rcu lock, even if PF_EXITING is already set again. I won't argue, but you need to convince Peter to accept this hack ;) Just sent a new version with all of you suggestions :) Thanks! Or, perhaps, we need to change the rules to ensure that any task_struct * pointer is rcu-safe. Perhaps we have more similar problems... I'd like to avoid this if possible. RT tree has: https://git.kernel.org/cgit/linux/kernel/git/paulg/3.10-rt-patches.git/ tree/patches/sched-delay-put-task.patch Yes, and this obviously implies more rcu callbacks in flight, and another gp before __put_task_struct(). but may be we will need to do this anyway... Kirill -- 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 16/16] usb: dwc3: enable usb suspend phy
On Mon, Oct 20, 2014 at 04:41:54PM +0800, Huang Rui wrote: On Fri, Oct 17, 2014 at 01:48:19PM -0500, Felipe Balbi wrote: Hi, On Fri, Oct 17, 2014 at 06:41:04PM +, Paul Zimmerman wrote: From: Felipe Balbi [mailto:ba...@ti.com] Sent: Friday, October 17, 2014 8:00 AM On Fri, Oct 17, 2014 at 04:53:41PM +0800, Huang Rui wrote: AMD NL needs to suspend usb3 ss phy, but this doesn't enable on simulation board. Signed-off-by: Huang Rui ray.hu...@amd.com --- drivers/usb/dwc3/core.c | 7 ++- drivers/usb/dwc3/dwc3-pci.c | 3 ++- drivers/usb/dwc3/platform_data.h | 1 + 3 files changed, 9 insertions(+), 2 deletions(-) diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c index 3ccfe41..4a98696 100644 --- a/drivers/usb/dwc3/core.c +++ b/drivers/usb/dwc3/core.c @@ -395,6 +395,9 @@ static void dwc3_phy_setup(struct dwc3 *dwc) if (dwc-quirks DWC3_QUIRK_TX_DEEPH) reg |= DWC3_GUSB3PIPECTL_TX_DEEPH(1); + if (dwc-quirks DWC3_QUIRK_SUSPHY) should be: if (!dwc-suspend_usb3_phy_quirk) + reg |= DWC3_GUSB3PIPECTL_SUSPHY; IIRC, databook asks us to set that bit anyway, so the quirk is disabling that bit. Am I missing something ? Paul ? It looks to me that Huang's patch is enabling that bit, not disabling it. right, but that's what's actually quirky right ? IIRC, Databook asks us to set usb2 and usb3 suspend phy bits and we're just not doing it. Currently the driver does not set either DWC3_GUSB3PIPECTL_SUSPHY or DWC3_GUSB2PHYCFG_SUSPHY (unless it has been added by that big patch series you just posted). According to the databook, both of those bits should be set to 1 after the core initialization has completed. there you go. So unless that quirk bit flag is set, we're safe of setting SUSPHY bit for everybody. I read the databook again, below words (DWC3_GUSB3PIPECTL_SUSPHY) is copied from databook: For DRD/OTG configurations, it is recommended that this bit is set to‘ 0’ during coreConsultant configuration. If it is set to ’1’, then the application should clear this bit after power-on reset. Application needs to set it to ’1’ after the core initialization is completed. For all other configurations, this bit can be set to ’1’ during core configuration. I see it's recommended to set '0' if on DRD/OTG configuration. Thanks, Rui -- 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] sched/numa: fix unsafe get_task_struct() in task_numa_assign()
В Вс, 19/10/2014 в 21:43 +0200, Oleg Nesterov пишет: On 10/19, Oleg Nesterov wrote: Forgot to mention... Or we can make task_struct_cachep SLAB_DESTROY_BY_RCU, in this case -curr (or any other task_struct * ponter) can not go away under rcu_read_lock(). task_numa_compare() still needs the PF_EXITING check, but we do not need to recheck -curr or probe_kernel_read(). Damn, please ignore ;) we still need to recheck -curr. Yeah, this bug like collect puzzle :) -- 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 v4 0/3] ARM: rk3288 : Add PM Domain support
From: jinkun.hong jinkun.h...@rock-chips.com Add power domain drivers based on generic power domain for Rockchip platform, and support RK3288. Based on: - [PATCH v1 1/4] PM / clock_ops: Add pm_clk_add_clk() http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg735599.html Changes in v4: - use list storage dev Changes in v3: - change use pm_clk_resume() and pm_clk_suspend() - DT structure has changed - Decomposition power-controller, changed to multiple controller (gpu-power-controller, hevc-power-controller) Changes in v2: - remove the pd-pd.of_node = np - move clocks to optional - make pd_vio clocks all one entry per line and alphabetize. - power: power-controller move back to pinctrl: pinctrl. jinkun.hong (3): power-domain: add power domain drivers for Rockchip platform dt-bindings: add document of Rockchip power domain ARM: dts: add rk3288 power-domain node .../bindings/arm/rockchip/power_domain.txt | 46 +++ arch/arm/boot/dts/rk3288.dtsi | 24 ++ arch/arm/mach-rockchip/Kconfig |1 + arch/arm/mach-rockchip/Makefile|1 + arch/arm/mach-rockchip/pm_domains.c| 360 5 files changed, 432 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/rockchip/power_domain.txt create mode 100644 arch/arm/mach-rockchip/pm_domains.c -- 1.7.9.5 -- 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 v4 2/3] dt-bindings: add document of Rockchip power domain
From: jinkun.hong jinkun.h...@rock-chips.com
Signed-off-by: Jack Dai jack@rock-chips.com
Signed-off-by: jinkun.hong jinkun.h...@rock-chips.com
---
Changes in v4: None
Changes in v3:
- DT structure has changed
Changes in v2:
- move clocks to optional
.../bindings/arm/rockchip/power_domain.txt | 46
1 file changed, 46 insertions(+)
create mode 100644
Documentation/devicetree/bindings/arm/rockchip/power_domain.txt
diff --git a/Documentation/devicetree/bindings/arm/rockchip/power_domain.txt
b/Documentation/devicetree/bindings/arm/rockchip/power_domain.txt
new file mode 100644
index 000..f8357b3
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/rockchip/power_domain.txt
@@ -0,0 +1,46 @@
+* Rockchip Power Domains
+
+Rockchip processors include support for multiple power domains which can be
+powered up/down by software based on different application scenes to save
power.
+
+Required properties for power domain controller:
+- compatible: should be one of the following.
+* rockchip,rk3288-power-gpu - for rk3288 type gpu power domain.
+* rockchip,rk3288-power-hevc - for rk3288 type hevc power domain.
+* rockchip,rk3288-power-video - for rk3288 type video power domain.
+* rockchip,rk3288-power-vio - for rk3288 type vio power domain.
+- rockchip,pmu: phandle referencing a syscon providing the pmu registers
+- #power-domain-cells: Number of cells in a power-domain specifier.
+ should be 0.
+
+Example:
+
+ gpu_power: gpu-power-controller {
+ compatible = rockchip,rk3288-power-gpu;
+ rockchip,pmu = pmu;
+ #power-domain-cells = 0;
+ };
+
+ hevc_power: hevc-power-controller {
+ compatible = rockchip,rk3288-power-hevc;
+ rockchip,pmu = pmu;
+ #power-domain-cells = 0;
+ };
+
+ video_power: video-power-controller {
+ compatible = rockchip,rk3288-power-video;
+ rockchip,pmu = pmu;
+ #power-domain-cells = 0;
+ };
+
+ vio_power: vio-power-controller {
+ compatible = rockchip,rk3288-power-vio;
+ rockchip,pmu = pmu;
+ #power-domain-cells = 0;
+ };
+
+ gpu: gpu@0xffa3 {
+ ...
+ power-domains = gpu_power;
+ ...
+ };
--
1.7.9.5
--
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 v4 1/3] power-domain: add power domain drivers for Rockchip platform
From: jinkun.hong jinkun.h...@rock-chips.com
Add power domain drivers based on generic power domain for Rockchip platform,
and support RK3288.
Signed-off-by: Jack Dai jack@rock-chips.com
Signed-off-by: jinkun.hong jinkun.h...@rock-chips.com
---
Changes in v4:
- use list storage dev
Changes in v3:
- change use pm_clk_resume() and pm_clk_suspend()
Changes in v2:
- remove the pd-pd.of_node = np
arch/arm/mach-rockchip/Kconfig |1 +
arch/arm/mach-rockchip/Makefile |1 +
arch/arm/mach-rockchip/pm_domains.c | 360 +++
3 files changed, 362 insertions(+)
create mode 100644 arch/arm/mach-rockchip/pm_domains.c
diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig
index d168669..4920a88 100644
--- a/arch/arm/mach-rockchip/Kconfig
+++ b/arch/arm/mach-rockchip/Kconfig
@@ -12,6 +12,7 @@ config ARCH_ROCKCHIP
select DW_APB_TIMER_OF
select ARM_GLOBAL_TIMER
select CLKSRC_ARM_GLOBAL_TIMER_SCHED_CLOCK
+ select PM_GENERIC_DOMAINS if PM
help
Support for Rockchip's Cortex-A9 Single-to-Quad-Core-SoCs
containing the RK2928, RK30xx and RK31xx series.
diff --git a/arch/arm/mach-rockchip/Makefile b/arch/arm/mach-rockchip/Makefile
index b29d8ea..805268d 100644
--- a/arch/arm/mach-rockchip/Makefile
+++ b/arch/arm/mach-rockchip/Makefile
@@ -2,3 +2,4 @@ CFLAGS_platsmp.o := -march=armv7-a
obj-$(CONFIG_ARCH_ROCKCHIP) += rockchip.o
obj-$(CONFIG_SMP) += headsmp.o platsmp.o
+obj-$(CONFIG_PM_GENERIC_DOMAINS) += pm_domains.o
diff --git a/arch/arm/mach-rockchip/pm_domains.c
b/arch/arm/mach-rockchip/pm_domains.c
new file mode 100644
index 000..28f32a5
--- /dev/null
+++ b/arch/arm/mach-rockchip/pm_domains.c
@@ -0,0 +1,360 @@
+/*
+ * Rockchip Generic power domain support.
+ *
+ * Copyright (c) 2014 ROCKCHIP, Co. Ltd.
+ * Author: Hong Jinkun jinkun.h...@rock-chips.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include linux/module.h
+#include linux/io.h
+#include linux/err.h
+#include linux/slab.h
+#include linux/pm_domain.h
+#include linux/of_address.h
+#include linux/of_platform.h
+#include linux/sched.h
+#include linux/clk.h
+#include linux/regmap.h
+#include linux/mfd/syscon.h
+#include linux/spinlock.h
+#include linux/pm_clock.h
+
+#define PWR_OFFSET 0x08
+#define STATUS_OFFSET 0x0c
+#define REQ_OFFSET 0x10
+#define IDLE_OFFSET0x14
+#define ACK_OFFSET 0x14
+
+struct rockchip_dev_entry {
+ struct list_head node;
+ struct device *dev;
+};
+
+struct rockchip_domain {
+ struct generic_pm_domain base;
+ struct device *dev;
+ struct regmap *regmap_pmu;
+ struct list_head dev_list;
+ spinlock_t idle_lock;
+ spinlock_t pmu_lock;
+ spinlock_t dev_lock;
+ u32 pwr_shift;
+ u32 status_shift;
+ u32 req_shift;
+ u32 idle_shift;
+ u32 ack_shift;
+};
+
+#define to_rockchip_pd(_gpd) container_of(_gpd, struct rockchip_domain, base)
+
+static int rockchip_pmu_set_idle_request(struct rockchip_domain *pd,
+bool idle)
+{
+ u32 idle_mask = BIT(pd-idle_shift);
+ u32 idle_target = idle (pd-idle_shift);
+ u32 ack_mask = BIT(pd-ack_shift);
+ u32 ack_target = idle (pd-ack_shift);
+ unsigned int mask = BIT(pd-req_shift);
+ unsigned int val;
+ unsigned long flags;
+
+ spin_lock_irqsave(pd-idle_lock, flags);
+ val = (idle) ? mask : 0;
+ regmap_update_bits(pd-regmap_pmu, REQ_OFFSET, mask, val);
+ dsb();
+
+ do {
+ regmap_read(pd-regmap_pmu, ACK_OFFSET, val);
+ } while ((val ack_mask) != ack_target);
+
+ do {
+ regmap_read(pd-regmap_pmu, IDLE_OFFSET, val);
+ } while ((val idle_mask) != idle_target);
+
+ spin_unlock_irqrestore(pd-idle_lock, flags);
+
+ return 0;
+}
+
+static bool rockchip_pmu_power_domain_is_on(struct rockchip_domain *pd)
+{
+ unsigned int val;
+
+ regmap_read(pd-regmap_pmu, STATUS_OFFSET, val);
+
+ /* 1'b0: power on, 1'b1: power off */
+ return !(val BIT(pd-status_shift));
+}
+
+static void rockchip_do_pmu_set_power_domain(
+ struct rockchip_domain *pd, bool on)
+{
+ unsigned int mask = BIT(pd-pwr_shift);
+ unsigned int val;
+
+ val = (on) ? 0 : mask;
+ regmap_update_bits(pd-regmap_pmu, PWR_OFFSET, mask, val);
+ dsb();
+
+ do {
+ regmap_read(pd-regmap_pmu, STATUS_OFFSET, val);
+ } while ((val BIT(pd-status_shift)) == on);
+}
+
+static int rockchip_pmu_set_power_domain(struct rockchip_domain *pd,
+bool on)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(pd-pmu_lock, flags);
+ if
[PATCH v4 3/3] ARM: dts: add rk3288 power-domain node
From: jinkun.hong jinkun.h...@rock-chips.com
Signed-off-by: Jack Dai jack@rock-chips.com
Signed-off-by: jinkun.hong jinkun.h...@rock-chips.com
---
Changes in v4: None
Changes in v3:
- Decomposition power-controller, changed to multiple controller
(gpu-power-controller, hevc-power-controller)
Changes in v2:
- make pd_vio clocks all one entry per line and alphabetize.
- power: power-controller move back to pinctrl: pinctrl.
arch/arm/boot/dts/rk3288.dtsi | 24
1 file changed, 24 insertions(+)
diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index 5950b0a..6a9b313 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -592,4 +592,28 @@
};
};
};
+
+ gpu_power: gpu-power-controller {
+ compatible = rockchip,rk3288-power-gpu;
+ rockchip,pmu = pmu;
+ #power-domain-cells = 0;
+ };
+
+ hevc_power: hevc-power-controller {
+ compatible = rockchip,rk3288-power-hevc;
+ rockchip,pmu = pmu;
+ #power-domain-cells = 0;
+ };
+
+ video_power: video-power-controller {
+ compatible = rockchip,rk3288-power-video;
+ rockchip,pmu = pmu;
+ #power-domain-cells = 0;
+ };
+
+ vio_power: vio-power-controller {
+ compatible = rockchip,rk3288-power-vio;
+ rockchip,pmu = pmu;
+ #power-domain-cells = 0;
+ };
};
--
1.7.9.5
--
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 v8 1/5] PM / Runtime: Add getter for querying the IRQ safe option
Add a simple getter pm_runtime_is_irq_safe() for querying whether runtime
PM IRQ safe was set or not.
Various bus drivers implementing runtime PM may use choose to suspend
differently based on IRQ safeness status of child driver (e.g. do not
unprepare the clock if IRQ safe is not set).
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
Reviewed-by: Ulf Hansson ulf.hans...@linaro.org
---
Documentation/power/runtime_pm.txt | 4
include/linux/pm_runtime.h | 6 ++
2 files changed, 10 insertions(+)
diff --git a/Documentation/power/runtime_pm.txt
b/Documentation/power/runtime_pm.txt
index f32ce5419573..397b81593142 100644
--- a/Documentation/power/runtime_pm.txt
+++ b/Documentation/power/runtime_pm.txt
@@ -468,6 +468,10 @@ drivers/base/power/runtime.c and
include/linux/pm_runtime.h:
- set the power.irq_safe flag for the device, causing the runtime-PM
callbacks to be invoked with interrupts off
+ bool pm_runtime_is_irq_safe(struct device *dev);
+- return true if power.irq_safe flag was set for the device, causing
+ the runtime-PM callbacks to be invoked with interrupts off
+
void pm_runtime_mark_last_busy(struct device *dev);
- set the power.last_busy field to the current time
diff --git a/include/linux/pm_runtime.h b/include/linux/pm_runtime.h
index 367f49b9a1c9..44d74f0f182e 100644
--- a/include/linux/pm_runtime.h
+++ b/include/linux/pm_runtime.h
@@ -128,6 +128,11 @@ static inline void pm_runtime_mark_last_busy(struct device
*dev)
ACCESS_ONCE(dev-power.last_busy) = jiffies;
}
+static inline bool pm_runtime_is_irq_safe(struct device *dev)
+{
+ return dev-power.irq_safe;
+}
+
#else /* !CONFIG_PM_RUNTIME */
static inline int __pm_runtime_idle(struct device *dev, int rpmflags)
@@ -167,6 +172,7 @@ static inline bool pm_runtime_enabled(struct device *dev) {
return false; }
static inline void pm_runtime_no_callbacks(struct device *dev) {}
static inline void pm_runtime_irq_safe(struct device *dev) {}
+static inline bool pm_runtime_is_irq_safe(struct device *dev) { return false; }
static inline bool pm_runtime_callbacks_present(struct device *dev) { return
false; }
static inline void pm_runtime_mark_last_busy(struct device *dev) {}
--
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 v8 4/5] dma: pl330: add Power Management support
This patch adds both normal PM suspend/resume support and runtime PM
support to pl330 DMA engine driver.
The runtime power management for pl330 DMA driver allows gating of AMBA
clock (PDMA) in FSYS clock domain, when the device is not processing any
requests. This is necessary to enter low power modes on Exynos SoCs
(e.g. LPA on Exynos4x12 or W-AFTR on Exynos3250).
Runtime PM resuming of the device may happen in atomic context (during
call device_issue_pending()) so pm_runtime_irq_safe() is used. This will
lead only to disabling/enabling of the clock but this is sufficient for
gating the clock and for reducing energy usage.
During system sleep the AMBA bus clock is also unprepared.
Suggested-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
Reviewed-by: Ulf Hansson ulf.hans...@linaro.org
---
drivers/dma/pl330.c | 94 ++---
1 file changed, 90 insertions(+), 4 deletions(-)
diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index 4839bfa74a10..b123431e62ed 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -27,6 +27,7 @@
#include linux/of.h
#include linux/of_dma.h
#include linux/err.h
+#include linux/pm_runtime.h
#include dmaengine.h
#define PL330_MAX_CHAN 8
@@ -265,6 +266,9 @@ static unsigned cmd_line;
#define NR_DEFAULT_DESC16
+/* Delay for runtime PM autosuspend, ms */
+#define PL330_AUTOSUSPEND_DELAY 20
+
/* Populated by the PL330 core driver for DMA API driver's info */
struct pl330_config {
u32 periph_id;
@@ -1958,6 +1962,7 @@ static void pl330_tasklet(unsigned long data)
struct dma_pl330_chan *pch = (struct dma_pl330_chan *)data;
struct dma_pl330_desc *desc, *_dt;
unsigned long flags;
+ bool power_down = false;
spin_lock_irqsave(pch-lock, flags);
@@ -1972,10 +1977,17 @@ static void pl330_tasklet(unsigned long data)
/* Try to submit a req imm. next to the last completed cookie */
fill_queue(pch);
- /* Make sure the PL330 Channel thread is active */
- spin_lock(pch-thread-dmac-lock);
- _start(pch-thread);
- spin_unlock(pch-thread-dmac-lock);
+ if (list_empty(pch-work_list)) {
+ spin_lock(pch-thread-dmac-lock);
+ _stop(pch-thread);
+ spin_unlock(pch-thread-dmac-lock);
+ power_down = true;
+ } else {
+ /* Make sure the PL330 Channel thread is active */
+ spin_lock(pch-thread-dmac-lock);
+ _start(pch-thread);
+ spin_unlock(pch-thread-dmac-lock);
+ }
while (!list_empty(pch-completed_list)) {
dma_async_tx_callback callback;
@@ -1990,6 +2002,12 @@ static void pl330_tasklet(unsigned long data)
if (pch-cyclic) {
desc-status = PREP;
list_move_tail(desc-node, pch-work_list);
+ if (power_down) {
+ spin_lock(pch-thread-dmac-lock);
+ _start(pch-thread);
+ spin_unlock(pch-thread-dmac-lock);
+ power_down = false;
+ }
} else {
desc-status = FREE;
list_move_tail(desc-node, pch-dmac-desc_pool);
@@ -2004,6 +2022,12 @@ static void pl330_tasklet(unsigned long data)
}
}
spin_unlock_irqrestore(pch-lock, flags);
+
+ /* If work list empty, power down */
+ if (power_down) {
+ pm_runtime_mark_last_busy(pch-dmac-ddma.dev);
+ pm_runtime_put_autosuspend(pch-dmac-ddma.dev);
+ }
}
bool pl330_filter(struct dma_chan *chan, void *param)
@@ -2073,6 +2097,7 @@ static int pl330_control(struct dma_chan *chan, enum
dma_ctrl_cmd cmd, unsigned
switch (cmd) {
case DMA_TERMINATE_ALL:
+ pm_runtime_get_sync(pl330-ddma.dev);
spin_lock_irqsave(pch-lock, flags);
spin_lock(pl330-lock);
@@ -2099,10 +2124,15 @@ static int pl330_control(struct dma_chan *chan, enum
dma_ctrl_cmd cmd, unsigned
dma_cookie_complete(desc-txd);
}
+ if (!list_empty(pch-work_list))
+ pm_runtime_put(pl330-ddma.dev);
+
list_splice_tail_init(pch-submitted_list, pl330-desc_pool);
list_splice_tail_init(pch-work_list, pl330-desc_pool);
list_splice_tail_init(pch-completed_list, pl330-desc_pool);
spin_unlock_irqrestore(pch-lock, flags);
+ pm_runtime_mark_last_busy(pl330-ddma.dev);
+ pm_runtime_put_autosuspend(pl330-ddma.dev);
break;
case DMA_SLAVE_CONFIG:
slave_config = (struct dma_slave_config *)arg;
@@ -2138,6 +2168,7 @@ static void
[PATCH v8 2/5] amba: Add helpers for (un)preparing AMBA clock
Add amba_pclk_prepare() and amba_pclk_unprepare() inline functions for
handling the AMBA bus clock by device drivers.
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
---
include/linux/amba/bus.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/include/linux/amba/bus.h b/include/linux/amba/bus.h
index c324f5700d1a..ac02f9bd63dc 100644
--- a/include/linux/amba/bus.h
+++ b/include/linux/amba/bus.h
@@ -97,6 +97,16 @@ void amba_release_regions(struct amba_device *);
#define amba_pclk_disable(d) \
do { if (!IS_ERR((d)-pclk)) clk_disable((d)-pclk); } while (0)
+static inline int amba_pclk_prepare(struct amba_device *dev)
+{
+ return clk_prepare(dev-pclk);
+}
+
+static inline void amba_pclk_unprepare(struct amba_device *dev)
+{
+ clk_unprepare(dev-pclk);
+}
+
/* Some drivers don't use the struct amba_device */
#define AMBA_CONFIG_BITS(a) (((a) 24) 0xff)
#define AMBA_REV_BITS(a) (((a) 20) 0x0f)
--
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 v8 3/5] amba: Don't unprepare the clocks if device driver wants IRQ safe runtime PM
The AMBA bus driver defines runtime Power Management functions which
disable and unprepare AMBA bus clock. This is problematic for runtime PM
because unpreparing a clock might sleep so it is not interrupt safe.
However some drivers may want to implement runtime PM functions in
interrupt-safe way (see pm_runtime_irq_safe()). In such case the AMBA
bus driver should only disable/enable the clock in runtime suspend and
resume callbacks.
Detect the device driver behavior after calling its probe function and
store it. During runtime suspend/resume deal with clocks according to
stored value.
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
Reviewed-by: Ulf Hansson ulf.hans...@linaro.org
---
drivers/amba/bus.c | 29 +
include/linux/amba/bus.h | 1 +
2 files changed, 26 insertions(+), 4 deletions(-)
diff --git a/drivers/amba/bus.c b/drivers/amba/bus.c
index 47bbdc1b5be3..474434e1b1b9 100644
--- a/drivers/amba/bus.c
+++ b/drivers/amba/bus.c
@@ -95,8 +95,18 @@ static int amba_pm_runtime_suspend(struct device *dev)
struct amba_device *pcdev = to_amba_device(dev);
int ret = pm_generic_runtime_suspend(dev);
- if (ret == 0 dev-driver)
- clk_disable_unprepare(pcdev-pclk);
+ if (ret == 0 dev-driver) {
+ /*
+* Drivers should not change pm_runtime_irq_safe()
+* after probe.
+*/
+ WARN_ON(pcdev-irq_safe != pm_runtime_is_irq_safe(dev));
+
+ if (pcdev-irq_safe)
+ clk_disable(pcdev-pclk);
+ else
+ clk_disable_unprepare(pcdev-pclk);
+ }
return ret;
}
@@ -107,7 +117,16 @@ static int amba_pm_runtime_resume(struct device *dev)
int ret;
if (dev-driver) {
- ret = clk_prepare_enable(pcdev-pclk);
+ /*
+* Drivers should not change pm_runtime_irq_safe()
+* after probe.
+*/
+ WARN_ON(pcdev-irq_safe != pm_runtime_is_irq_safe(dev));
+
+ if (pcdev-irq_safe)
+ ret = clk_enable(pcdev-pclk);
+ else
+ ret = clk_prepare_enable(pcdev-pclk);
/* Failure is probably fatal to the system, but... */
if (ret)
return ret;
@@ -198,8 +217,10 @@ static int amba_probe(struct device *dev)
pm_runtime_enable(dev);
ret = pcdrv-probe(pcdev, id);
- if (ret == 0)
+ if (ret == 0) {
+ pcdev-irq_safe = pm_runtime_is_irq_safe(dev);
break;
+ }
pm_runtime_disable(dev);
pm_runtime_set_suspended(dev);
diff --git a/include/linux/amba/bus.h b/include/linux/amba/bus.h
index ac02f9bd63dc..c4bae79851fb 100644
--- a/include/linux/amba/bus.h
+++ b/include/linux/amba/bus.h
@@ -32,6 +32,7 @@ struct amba_device {
struct clk *pclk;
unsigned intperiphid;
unsigned intirq[AMBA_NR_IRQS];
+ unsigned intirq_safe:1;
};
struct amba_driver {
--
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 v8 5/5] amba: Remove unused amba_pclk_enable/disable macros
Remove the amba_pclk_enable and amba_pclk_disable macros because they
are not used by the drivers.
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
Reviewed-by: Ulf Hansson ulf.hans...@linaro.org
---
include/linux/amba/bus.h | 6 --
1 file changed, 6 deletions(-)
diff --git a/include/linux/amba/bus.h b/include/linux/amba/bus.h
index c4bae79851fb..566adf0e0412 100644
--- a/include/linux/amba/bus.h
+++ b/include/linux/amba/bus.h
@@ -92,12 +92,6 @@ struct amba_device *amba_find_device(const char *, struct
device *, unsigned int
int amba_request_regions(struct amba_device *, const char *);
void amba_release_regions(struct amba_device *);
-#define amba_pclk_enable(d)\
- (IS_ERR((d)-pclk) ? 0 : clk_enable((d)-pclk))
-
-#define amba_pclk_disable(d) \
- do { if (!IS_ERR((d)-pclk)) clk_disable((d)-pclk); } while (0)
-
static inline int amba_pclk_prepare(struct amba_device *dev)
{
return clk_prepare(dev-pclk);
--
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 v8 0/5] amba/dma: pl330: add Power Management support
Hi, Changes since v7: = 1. Add reviewed-by Ulf Hansson (patches 3, 4 and 5). 2. Patch 2/5: Fix missing return in amba_pclk_prepare() (suggested by Ulf Hansson). 3. Rebased on next-20141020. Changes since v6: = 1. Add patch 5 removing the amba_pclk_*able macros. 2. Patch 2/5: Remove IS_ERR, use static inline functions instead of macros. 3. Patch 4/5: Force runtime suspend/resume in system sleep callbacks. Put with autosuspend at end of probe instead of no_idle. Suggested by Ulf Hansson. Changes since v5: = 1. Patch 1/4: Add Ulf Hansson's reviewed-by. 2. Patch 4/4: Use PM runtime autosuspend (suggested by Ulf Hansson). 3. Rebase on next-20140922. Changes since v4: 1. Patch 3/4: Explicitly initialize amba_device.irq_safe field after probing driver (suggested by Russell King). Changes since v3: 1. Patch 1/4: Document new API in Documentation/power/runtime_pm.txt (pointed by Alan Stern). Changes since v2: 1. Add patch 1 (PM / Runtime: Add getter for querying the IRQ safe option) 2. Add patch 2 (amba: Add helper macros for (un)preparing AMBA clock) 3. Patch 3/4: Rewrite the idea. If IRQ safe runtime PM is set then do not unprepare/prepare the clocks. Suggested by Russell King. 4. Patch 4/4: During system sleep unprepare the clock. Changes since v1: 1. Add patch 1 (amba: Allow AMBA drivers to use their own runtime PM). 2. Patch 2/2: Apply Michal Simek's suggestions. 3. Patch 2/2: Fix atomic context safeness in pl330_issue_pending(). Description: This patchset adds runtime and system PM to the pl330 driver. The runtime PM of pl330 driver requires interrupt safe suspend/resume callbacks which is in conflict with current amba bus driver. The latter also unprepares and prepares the AMBA bus clock which is not safe for atomic context. The patchset solves this in patch 3/5 by handling clocks in different way if device driver set interrupt safe runtime PM. Any comments are welcome. Tested on board with pl330 DMA driver: - Trats2 (Exynos4212) TODO/ideas: === Consider renaming existing pm_runtime_irq_safe() function to keep up with naming convention after adding pm_runtime_is_irq_safe() in patch 1/5. This naming: - pm_runtime_irq_safe() as setter, - pm_runtime_is_irq_safe() as getter, is contradictory to naming of other PM runtime functions, e.g.: - pm_runtime_set_active() as setter, - pm_runtime_active() as getter. I didn't change the naming of pm_runtime_irq_safe() because I wanted to minimize the impact of the patches. Best regards, Krzysztof Kozlowski Krzysztof Kozlowski (5): PM / Runtime: Add getter for querying the IRQ safe option amba: Add helpers for (un)preparing AMBA clock amba: Don't unprepare the clocks if device driver wants IRQ safe runtime PM dma: pl330: add Power Management support amba: Remove unused amba_pclk_enable/disable macros Documentation/power/runtime_pm.txt | 4 ++ drivers/amba/bus.c | 29 ++-- drivers/dma/pl330.c| 94 -- include/linux/amba/bus.h | 13 -- include/linux/pm_runtime.h | 6 +++ 5 files changed, 134 insertions(+), 12 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/
Re: v3.18-rc1 bloat-o-meter
On Mon, Oct 20, 2014 at 10:37:19AM +0200, Geert Uytterhoeven wrote: Hi all, Below is the bloat-o-meter output when comparing an m68k/atari_defconfig kernel for v3.17 and v3.18-rc1. That looks cool, can I run this for other arches too? -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- 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: v3.18-rc1 bloat-o-meter
Hi Boris,
On Mon, Oct 20, 2014 at 11:06 AM, Borislav Petkov b...@alien8.de wrote:
On Mon, Oct 20, 2014 at 10:37:19AM +0200, Geert Uytterhoeven wrote:
Hi all,
Below is the bloat-o-meter output when comparing an m68k/atari_defconfig
kernel for v3.17 and v3.18-rc1.
That looks cool, can I run this for other arches too?
Sure. Compile two kernel images, and run
scripts/bloat-o-meter image1 image2
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
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] futex: Ensure get_futex_key_refs() always implies a barrier
On Sat, 18 Oct 2014, Davidlohr Bueso wrote: On Sat, 2014-10-18 at 13:50 -0700, Linus Torvalds wrote: On Sat, Oct 18, 2014 at 12:58 PM, Davidlohr Bueso d...@stgolabs.net wrote: And [get/put]_futex_keys() shouldn't even be called for private futexes. The following patch had some very minor testing on a 60 core box last night, but passes both Darren's and perf's tests. So I *think* this is right, but lack of sleep and I overall just don't trust them futexes! Hmm. I don't see the advantage of making the code more complex in order to avoid the functions that are no-ops for the !fshared case? IOW, as far as I can tell, this patch doesn't actually really *change* anything. Am I missing something? Right, all we do is avoid a NOP, but I don't see how this patch makes the code more complex. In fact, the whole idea is to make it easier to read and makes the key referencing differences between shared and private futexes crystal clear, hoping to mitigate future bugs. I tend to disagree. The current code is symetric versus get/drop and you make it unsymetric by avoiding the drop call with a pointless extra conditional in all call sites. I really had to look twice to figure out that the patch is correct, but I really cannot see any value and definitely have a hard time how this makes the code clearer and would prevent future bugs. I rather keep it symetric and document the NOP property for private futexes in both get and drop. Thanks, tglx -- 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] drivers/misc/eeprom/men_eeprod: Introduce MEN Board Information EEPROM driver
On Mon, Oct 20, 2014 at 10:33:45AM +0200, Andreas Werner wrote: On Thu, Oct 16, 2014 at 01:44:02PM +0200, Andreas Werner wrote: On Thu, Oct 16, 2014 at 11:59:10AM +0200, Wolfram Sang wrote: * PGP Signed by an unknown key I do not want to parse the things in userspace because this EEPROM data are related to the hardware and i want to give our customer the easiest way to access the data without installing any tool. I understand that point of view. From an upstream point of view, things may look different, though. I also understand your point of view :-). Most customers wants just to have a running system without installing anything. And for me an EEPROM is so simple and should not need a complicated way to access it. The current state to read the eeprom data is, that customer needs to install a big environment where the tool is integrated to have access to those kind of simple data or they have to write their own code. i2cget from i2c-tools? You could do a simple shell script to parse the data. Or do a board specific hook which reads the data and prints it to the logfiles... Yes of course there are a lot of possibilities. This was just an example what we currently use and what was developed years ago. With a driver like this you can also define read only attributes to prevent customer to write or modify the data in the production section. With i2ctools you can just write any data to it you want. Consider how bloated the sysfs-ABI might get if every vendor who uses an eeprom wants to expose the data this way? Yes and no. The possible sysfs entries gets bloated if every vendor will do it like this way, but normally there is just one Board EEPROM on the board, therefore only one driver gets loaded. I am not talking about runtime here, I don't care about that. I am talking about the ABI we create and we have to maintain basically forever. And with vendor specific configuartion data I have doubts with that being stable. Ok, but i do not think that we can make a general ABI definition for those kind of devices because every vendor will have its own data in the EEPROM which he want to have. I mean its the same for every i2c device like a temperature sensor, I can also read it from userspace without any special hwmon driver. These is a HUGE difference. If I read tempX_input, I don't need to care if the sensor is I2C or SPI or whatever. The kernel abstracts that away. The files you create are for your I2C EEPROM only. Data gets reformatted and access gets hidden, but nothing is abstracted away. It would be different if we had a generic convention for serial_id or stuff like that. But as configuration data is highly specific I don't see this coming. For a standard sysfs interface it is a huge difference yes. At the point of few from the EEPROM device it is a device like a temp sensor which could be different from vendor to vendor. Regards Andy Greg what do you think about that driver as a Maintainer of the sysfs? I maintain the sysfs core that drivers use, I don't dictate the policy that those drivers create and send to userspace, that is up to the maintainer of the subsystem. There are some basic rules of sysfs (one value per file), but other than that, please work with the maintainer to come up with an interface that will work for all types of this device, not just a one-off interface which does not scale at all, as Wolfram has pointed out. To we have other ways to get those kind of drivers in the mainline kernel? Yes, work on a common interface that your driver can use, and it can be accepted. Why do you not want to do that? thanks, greg k-h -- 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 1/3] power-domain: add power domain drivers for Rockchip platform
On 10/20/2014 02:33 PM, jinkun.hong wrote:
From: jinkun.hong jinkun.h...@rock-chips.com
Add power domain drivers based on generic power domain for Rockchip platform,
and support RK3288.
Signed-off-by: Jack Dai jack@rock-chips.com
Signed-off-by: jinkun.hong jinkun.h...@rock-chips.com
---
(...)
+static int rockchip_pd_power(struct rockchip_domain *pd, bool power_on)
+{
+ int i = 0;
+ int ret = 0;
+ struct rockchip_dev_entry *de;
+
+ spin_lock_irq(pd-dev_lock);
+
+ list_for_each_entry(de, pd-dev_list, node) {
+ i += 1;
+ pm_clk_resume(pd-dev);
+ }
+
+ /* no clk, set power domain will fail */
+ if (i == 0) {
+ pr_err(%s: failed to on/off power domain!, __func__);
Missed terminating new line :-)
+ spin_unlock_irq(pd-dev_lock);
+ return ret;
+ }
+
+ ret = rockchip_pmu_set_power_domain(pd, power_on);
+
+ list_for_each_entry(de, pd-dev_list, node) {
+ pm_clk_suspend(pd-dev);
+ }
+
+ spin_unlock_irq(pd-dev_lock);
+
+ return ret;
+}
+
(...)
+static int rockchip_pm_domain_probe(struct platform_device *pdev)
+{
+ struct device_node *node;
+ struct regmap *regmap_pmu;
+ struct rockchip_domain *pd;
+ const struct of_device_id *match;
+
+ match = of_match_node(rockchip_pm_domain_dt_match, pdev-dev.of_node);
+ pd = (struct rockchip_domain *)match-data;
+
Unnecessary one line space..
+ if (!pd)
+ return -ENOMEM;
+
+ node = of_parse_phandle(pdev-dev.of_node, rockchip,pmu, 0);
+ regmap_pmu = syscon_node_to_regmap(node);
+ of_node_put(node);
+ if (IS_ERR(regmap_pmu)) {
+ pr_err(%s: failed to get regmap_pmu, __func__);
Terminating new line missed... :-)
+ return PTR_ERR(regmap_pmu);
+ }
+
+ pd-regmap_pmu = regmap_pmu;
+ pd-dev = pdev-dev;
+
+ INIT_LIST_HEAD(pd-dev_list);
+
+ spin_lock_init(pd-idle_lock);
+ spin_lock_init(pd-pmu_lock);
+ spin_lock_init(pd-dev_lock);
+
+ pm_genpd_init(pd-base, NULL, false);
+
+ return of_genpd_add_provider_simple(pdev-dev.of_node, pd-base);
+}
+
--
Thanks and Regards,
Varka Bhadram.
--
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] sched/numa: fix unsafe get_task_struct() in task_numa_assign()
OK, I think I'm finally awake enough to see what you're all talking about :-) On Sun, Oct 19, 2014 at 09:37:44PM +0200, Oleg Nesterov wrote: RT tree has: https://git.kernel.org/cgit/linux/kernel/git/paulg/3.10-rt-patches.git/ tree/patches/sched-delay-put-task.patch (answering the other email asking about this) RT does this because we call put_task_struct() with preempt disabled and on RT the memory allocator has sleeping locks. Yes, and this obviously implies more rcu callbacks in flight, and another gp before __put_task_struct(). but may be we will need to do this anyway... Forgot to mention... Or we can make task_struct_cachep SLAB_DESTROY_BY_RCU, in this case -curr (or any other task_struct * ponter) can not go away under rcu_read_lock(). task_numa_compare() still needs the PF_EXITING check, but we do not need to recheck -curr or probe_kernel_read(). I think I would prefer SLAB_DESTROY_BY_RCU for this, because as you pointed out, I'm not sure mainline would like the extra callbacks. -- 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] drivers/misc/eeprom/men_eeprod: Introduce MEN Board Information EEPROM driver
On Mon, Oct 20, 2014 at 10:24:22AM +0200, Wolfram Sang wrote: * PGP Signed by an unknown key Here it gets frustrating. It seems you have no idea what an OS is for, not even after I tried to describe it :( I am pretty sure that i know what an OS is for. Sorry, that might have been too strong. Still, we can't map any hardware which is out there 1:1 into userspace, we need abstraction. If you want to help with this abstraction, this is more than appreciated. If you want to keep your driver, this will have to stay out-of-tree, I'm afraid. Yes, my goal is to find a good way to get hardware support upstream, and it is also nice to discuss my point of view with your upstream point of few. And yes, i want to help to find a way to develope an abstraction. Regards Andy Regards, Wolfram * Unknown Key * 0x14A029B6 -- 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] ARM: perf: save/restore pmu registers in pm notifier
Hi Neil, On 20/10/14 09:46, Neil Zhang wrote: -Original Message- From: Will Deacon [mailto:will.dea...@arm.com] Sent: 2014年7月4日 1:57 To: Neil Zhang Cc: Sudeep Holla; 'li...@arm.linux.org.uk'; 'linux-arm- ker...@lists.infradead.org'; 'linux-kernel@vger.kernel.org'; 'devicet...@vger.kernel.org' Subject: Re: [PATCH v4] ARM: perf: save/restore pmu registers in pm notifier On Mon, Jun 30, 2014 at 11:39:15AM +0100, Neil Zhang wrote: I will prepare another patch to add DT description under PMU since there is no generic power domain support for pm notifier if no other concerns. We can change the manner if there is generic power domain support for pm notifier later. Thanks. No, please don't add any DT bindings for power domains specific to PMU node. We can't change the DT bindings once added. As I pointed out the DT bindings for generic power domains are under discussion. See if you can reuse it, if not help in extending it so that it can be used. Sorry for reply later. As I said before the under discussed generic power domain is not suitable for CPU peripherals since they are all known belong to CPU or cluster power domain. If we want to follow the way they are discussion, we need to register core and cluster power provider, and need vfp/gic/pmu etc to require them. Is it really suitable? Do you have any comments? If no, I would like to put it under PMU node. Sudeep is a better person to comment than me, but I'd still rather this was handled more generically as opposed to a PMU-specific hack. I don't see a problem including GIC and VFP here, but only when we actually need to save/restore them (i.e. what the hardware guys went crazy with the power domains). Long time no follow up for this loop. Sorry that I will pick it again. Yes, the generic PD got added in v3.18-rc1, it's better to check if we can reuse it. I will also have a look at that and think about how we can use it. Will, I prefer to check always-on field under PMU node to check whether we need Save/restore them. But how do you handle it for different idle states. e.g. if CPU is in retention, PMU's *might be* retained. Also I don't think PMUs will be placed in always-on power domain like timers. So using always-on sounds incorrect to me. Regards, Sudeep -- 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/
[git pull] Please pull mpe.git for-linus branch (for powerpc)
Hi Linus, Here's some more updates for powerpc for 3.18. They are a bit late I know, though must are actually bug fixes. In my defence I nearly cut the top of my finger off last weekend in a gruesome bike maintenance accident, so I spent a good part of the week waiting around for doctors. True story, I can send photos if you like :) Probably the most interesting fix is the sys_call_table one, which enables syscall tracing for powerpc. There's a fix for HMI handling for old firmware, more endian fixes for firmware interfaces, more EEH fixes, Anton fixed our routine that gets the current stack pointer, and a few other misc bits. The following changes since commit d53ba6b3bba33432cc37b7101a86f8f3392c46e7: cxl: Fix afu_read() not doing finish_wait() on signal or non-blocking (2014-10-09 11:29:57 +1100) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/mpe/linux.git for-linus for you to fetch changes up to e89dafb5ca5022d3bc63602018adfc766c73bc2b: powerpc: Only do dynamic DMA zone limits on platforms that need it (2014-10-17 09:21:44 +1100) Anton Blanchard (5): powerpc: Reimplement __get_SP() as a function not a define powerpc: Rename __get_SP() to current_stack_pointer() powerpc/pseries: Use dump_stack instead of show_stack powerpc: Add printk levels to setup_system output powerpc: sync pseries_le_defconfig with pseries_defconfig Bharata B Rao (1): powerpc/pseries: Make CPU hotplug path endian safe Gavin Shan (7): powerpc/eeh: Fix condition for isolated state powerpc/eeh: Rename flag EEH_PE_RESET to EEH_PE_CFG_BLOCKED powerpc/powernv: Drop config requests in EEH accessors powerpc/pseries: Drop config requests in EEH accessors powerpc/eeh: Block PCI config access upon frozen PE powerpc/eeh: Don't collect logs on PE with blocked config space powerpc/eeh: Block CFG upon frozen Shiner adapter Greg Kurz (1): powerpc/vphn: NUMA node code expects big-endian Mahesh Salgaonkar (2): powerpc/book3s: Don't clear MSR_RI in hmi handler. powerpc/powernv: Fallback to old HMI handling behavior for old firmware Michael Ellerman (3): powerpc/msi: Fix the msi bitmap alignment tests powerpc/msi: Use WARN_ON() in msi bitmap selftests powerpc: Only do dynamic DMA zone limits on platforms that need it Nishanth Aravamudan (2): powerpc/numa: check error return from proc_create powerpc/numa: Add ability to disable and debug topology updates Romeo Cane (1): powerpc: Fix sys_call_table declaration to enable syscall tracing Documentation/kernel-parameters.txt | 6 +++ arch/powerpc/configs/pseries_le_defconfig| 7 ++- arch/powerpc/include/asm/eeh.h | 3 +- arch/powerpc/include/asm/perf_event.h| 2 +- arch/powerpc/include/asm/reg.h | 3 +- arch/powerpc/include/asm/syscall.h | 2 +- arch/powerpc/kernel/dma.c| 8 arch/powerpc/kernel/eeh.c| 19 +--- arch/powerpc/kernel/eeh_driver.c | 12 ++--- arch/powerpc/kernel/eeh_pe.c | 10 - arch/powerpc/kernel/exceptions-64s.S | 5 --- arch/powerpc/kernel/irq.c| 2 +- arch/powerpc/kernel/misc.S | 4 ++ arch/powerpc/kernel/ppc_ksyms.c | 2 + arch/powerpc/kernel/process.c| 2 +- arch/powerpc/kernel/rtas_pci.c | 30 + arch/powerpc/kernel/setup_64.c | 32 +++--- arch/powerpc/kernel/stacktrace.c | 2 +- arch/powerpc/mm/numa.c | 41 - arch/powerpc/platforms/powernv/eeh-ioda.c| 2 +- arch/powerpc/platforms/powernv/eeh-powernv.c | 57 +++- arch/powerpc/platforms/powernv/opal.c| 21 + arch/powerpc/platforms/powernv/pci.c | 2 +- arch/powerpc/platforms/pseries/dlpar.c | 22 +- arch/powerpc/platforms/pseries/hotplug-cpu.c | 4 +- arch/powerpc/platforms/pseries/iommu.c | 11 +++-- arch/powerpc/platforms/pseries/pseries.h | 3 +- arch/powerpc/sysdev/msi_bitmap.c | 66 +++- 28 files changed, 261 insertions(+), 119 deletions(-) signature.asc Description: This is a digitally signed message part
[PATCH] net: Remove trailing whitespace in tcp.h icmp.c syncookies.c
Remove trailing whitespace in tcp.h icmp.c syncookies.c
Signed-off-by: Kenjiro Nakayama nakayamakenj...@gmail.com
---
include/net/tcp.h | 12 ++--
net/ipv6/icmp.c | 1 -
net/ipv6/syncookies.c | 1 -
3 files changed, 6 insertions(+), 8 deletions(-)
diff --git a/include/net/tcp.h b/include/net/tcp.h
index 4062b4f..c73fc14 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -55,9 +55,9 @@ void tcp_time_wait(struct sock *sk, int state, int timeo);
#define MAX_TCP_HEADER (128 + MAX_HEADER)
#define MAX_TCP_OPTION_SPACE 40
-/*
+/*
* Never offer a window over 32767 without using window scaling. Some
- * poor stacks do signed 16bit maths!
+ * poor stacks do signed 16bit maths!
*/
#define MAX_TCP_WINDOW 32767U
@@ -167,7 +167,7 @@ void tcp_time_wait(struct sock *sk, int state, int timeo);
/*
* TCP option
*/
-
+
#define TCPOPT_NOP 1 /* Padding */
#define TCPOPT_EOL 0 /* End of options */
#define TCPOPT_MSS 2 /* Segment size negotiating */
@@ -1104,16 +1104,16 @@ static inline int tcp_win_from_space(int space)
space - (spacesysctl_tcp_adv_win_scale);
}
-/* Note: caller must be prepared to deal with negative returns */
+/* Note: caller must be prepared to deal with negative returns */
static inline int tcp_space(const struct sock *sk)
{
return tcp_win_from_space(sk-sk_rcvbuf -
atomic_read(sk-sk_rmem_alloc));
-}
+}
static inline int tcp_full_space(const struct sock *sk)
{
- return tcp_win_from_space(sk-sk_rcvbuf);
+ return tcp_win_from_space(sk-sk_rcvbuf);
}
static inline void tcp_openreq_init(struct request_sock *req,
diff --git a/net/ipv6/icmp.c b/net/ipv6/icmp.c
index 97ae700..62c1037 100644
--- a/net/ipv6/icmp.c
+++ b/net/ipv6/icmp.c
@@ -1009,4 +1009,3 @@ struct ctl_table * __net_init
ipv6_icmp_sysctl_init(struct net *net)
return table;
}
#endif
-
diff --git a/net/ipv6/syncookies.c b/net/ipv6/syncookies.c
index 2f25cb6..0e26e79 100644
--- a/net/ipv6/syncookies.c
+++ b/net/ipv6/syncookies.c
@@ -269,4 +269,3 @@ out_free:
reqsk_free(req);
return NULL;
}
-
--
1.9.3
--
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: v3.18-rc1 bloat-o-meter
On Mon, Oct 20, 2014 at 11:09:28AM +0200, Geert Uytterhoeven wrote: Sure. Compile two kernel images, and run scripts/bloat-o-meter image1 image2 Ha, that's even upstream :-) Thanks Geert! -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- 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] virtio: Fix comment typo 'CONFIG_S_FAILED'
Without the VIRTIO_ prefix CONFIG_S_FAILED looks like a Kconfig macro. So use that prefix here too. Signed-off-by: Paul Bolle pebo...@tiscali.nl --- Introduced in commit c6716bae52f9 (virtio-pci: move freeze/restore to virtio core). Tested with git grep only. include/linux/virtio.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/virtio.h b/include/linux/virtio.h index 65261a7244fc..abafae783058 100644 --- a/include/linux/virtio.h +++ b/include/linux/virtio.h @@ -78,7 +78,7 @@ bool virtqueue_is_broken(struct virtqueue *vq); /** * virtio_device - representation of a device using virtio * @index: unique position on the virtio bus - * @failed: saved value for CONFIG_S_FAILED bit (for restore) + * @failed: saved value for VIRTIO_CONFIG_S_FAILED bit (for restore) * @config_enabled: configuration change reporting enabled * @config_change_pending: configuration change reported while disabled * @config_lock: protects configuration change reporting -- 1.9.3 -- 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] drivers/misc/eeprom/men_eeprod: Introduce MEN Board Information EEPROM driver
On Mon, Oct 20, 2014 at 05:11:41PM +0800, Greg KH wrote: On Mon, Oct 20, 2014 at 10:33:45AM +0200, Andreas Werner wrote: On Thu, Oct 16, 2014 at 01:44:02PM +0200, Andreas Werner wrote: On Thu, Oct 16, 2014 at 11:59:10AM +0200, Wolfram Sang wrote: * PGP Signed by an unknown key I do not want to parse the things in userspace because this EEPROM data are related to the hardware and i want to give our customer the easiest way to access the data without installing any tool. I understand that point of view. From an upstream point of view, things may look different, though. I also understand your point of view :-). Most customers wants just to have a running system without installing anything. And for me an EEPROM is so simple and should not need a complicated way to access it. The current state to read the eeprom data is, that customer needs to install a big environment where the tool is integrated to have access to those kind of simple data or they have to write their own code. i2cget from i2c-tools? You could do a simple shell script to parse the data. Or do a board specific hook which reads the data and prints it to the logfiles... Yes of course there are a lot of possibilities. This was just an example what we currently use and what was developed years ago. With a driver like this you can also define read only attributes to prevent customer to write or modify the data in the production section. With i2ctools you can just write any data to it you want. Consider how bloated the sysfs-ABI might get if every vendor who uses an eeprom wants to expose the data this way? Yes and no. The possible sysfs entries gets bloated if every vendor will do it like this way, but normally there is just one Board EEPROM on the board, therefore only one driver gets loaded. I am not talking about runtime here, I don't care about that. I am talking about the ABI we create and we have to maintain basically forever. And with vendor specific configuartion data I have doubts with that being stable. Ok, but i do not think that we can make a general ABI definition for those kind of devices because every vendor will have its own data in the EEPROM which he want to have. I mean its the same for every i2c device like a temperature sensor, I can also read it from userspace without any special hwmon driver. These is a HUGE difference. If I read tempX_input, I don't need to care if the sensor is I2C or SPI or whatever. The kernel abstracts that away. The files you create are for your I2C EEPROM only. Data gets reformatted and access gets hidden, but nothing is abstracted away. It would be different if we had a generic convention for serial_id or stuff like that. But as configuration data is highly specific I don't see this coming. For a standard sysfs interface it is a huge difference yes. At the point of few from the EEPROM device it is a device like a temp sensor which could be different from vendor to vendor. Regards Andy Greg what do you think about that driver as a Maintainer of the sysfs? I maintain the sysfs core that drivers use, I don't dictate the policy that those drivers create and send to userspace, that is up to the maintainer of the subsystem. There are some basic rules of sysfs (one value per file), but other than that, please work with the maintainer to come up with an interface that will work for all types of this device, not just a one-off interface which does not scale at all, as Wolfram has pointed out. Ok. To we have other ways to get those kind of drivers in the mainline kernel? Yes, work on a common interface that your driver can use, and it can be accepted. Why do you not want to do that? thanks, greg k-h I have never talked about that I do not want to do it. I just want to discuss it with you. Right now we are at a point that i know that those kind of drivers can't be upstream and i will try to find a way of abstraction to get it upstream. Thanks Andy -- 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] ARM: perf: save/restore pmu registers in pm notifier
On Mon, Oct 20, 2014 at 10:16:16AM +0100, Sudeep Holla wrote: On 20/10/14 09:46, Neil Zhang wrote: Will, I prefer to check always-on field under PMU node to check whether we need Save/restore them. But how do you handle it for different idle states. e.g. if CPU is in retention, PMU's *might be* retained. Also I don't think PMUs will be placed in always-on power domain like timers. So using always-on sounds incorrect to me. Adding Mathieu to CC, since I spoke to him at LPC about this and he was talking about implementing proper PM domain descriptions for coresight components. Will -- 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/
