* [PATCH] sh_eth: add R8A7791 support
From: Sergei Shtylyov @ 2013-11-14 22:12 UTC (permalink / raw)
To: linux-arm-kernel
Add support for yet another ARM member of the R-Car family, R-Car M2, also known
as R8A7791 -- it will share the code and data with previously added R8A7790.
Since the Ether devices in these SoCs are indistinguishable at least from the
driver's point of view, do not introduce a new platform device ID but modify
device name "r8a7790-ether" to "r8a779x-ether" throughout the files (and also
'r8a7790_data' to 'r8a779x_data' in the driver), just like the names used for
R8A7778/9 SoCs.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
This patch is atop of 'renesas-devel-v3.12-20131112' tag of Simon Horman's
'renesas.git' repo and I intend to push it thru this tree in order to satisfy
runtime dependencies of the R8A7791/Koelsch Ether support patches to follow.
Not posting this to netdev@vger.kernel.org since Dave has closed 'net-next.git'
for now; Dave, I hope you'll ACK this patch...
arch/arm/mach-shmobile/board-lager.c | 12 ++++++------
arch/arm/mach-shmobile/clock-r8a7790.c | 2 +-
drivers/net/ethernet/renesas/Kconfig | 2 +-
drivers/net/ethernet/renesas/sh_eth.c | 6 +++---
4 files changed, 11 insertions(+), 11 deletions(-)
Index: renesas/arch/arm/mach-shmobile/board-lager.c
=================================--- renesas.orig/arch/arm/mach-shmobile/board-lager.c
+++ renesas/arch/arm/mach-shmobile/board-lager.c
@@ -186,13 +186,13 @@ static const struct pinctrl_map lager_pi
PIN_MAP_MUX_GROUP_DEFAULT("sh_mmcif.1", "pfc-r8a7790",
"mmc1_ctrl", "mmc1"),
/* Ether */
- PIN_MAP_MUX_GROUP_DEFAULT("r8a7790-ether", "pfc-r8a7790",
+ PIN_MAP_MUX_GROUP_DEFAULT("r8a779x-ether", "pfc-r8a7790",
"eth_link", "eth"),
- PIN_MAP_MUX_GROUP_DEFAULT("r8a7790-ether", "pfc-r8a7790",
+ PIN_MAP_MUX_GROUP_DEFAULT("r8a779x-ether", "pfc-r8a7790",
"eth_mdio", "eth"),
- PIN_MAP_MUX_GROUP_DEFAULT("r8a7790-ether", "pfc-r8a7790",
+ PIN_MAP_MUX_GROUP_DEFAULT("r8a779x-ether", "pfc-r8a7790",
"eth_rmii", "eth"),
- PIN_MAP_MUX_GROUP_DEFAULT("r8a7790-ether", "pfc-r8a7790",
+ PIN_MAP_MUX_GROUP_DEFAULT("r8a779x-ether", "pfc-r8a7790",
"intc_irq0", "intc"),
};
@@ -217,7 +217,7 @@ static void __init lager_add_standard_de
mmcif1_resources, ARRAY_SIZE(mmcif1_resources),
&mmcif1_pdata, sizeof(mmcif1_pdata));
- platform_device_register_resndata(&platform_bus, "r8a7790-ether", -1,
+ platform_device_register_resndata(&platform_bus, "r8a779x-ether", -1,
ether_resources,
ARRAY_SIZE(ether_resources),
ðer_pdata, sizeof(ether_pdata));
@@ -246,7 +246,7 @@ static void __init lager_init(void)
{
lager_add_standard_devices();
- phy_register_fixup_for_id("r8a7790-ether-ff:01", lager_ksz8041_fixup);
+ phy_register_fixup_for_id("r8a779x-ether-ff:01", lager_ksz8041_fixup);
}
static const char * const lager_boards_compat_dt[] __initconst = {
Index: renesas/arch/arm/mach-shmobile/clock-r8a7790.c
=================================--- renesas.orig/arch/arm/mach-shmobile/clock-r8a7790.c
+++ renesas/arch/arm/mach-shmobile/clock-r8a7790.c
@@ -285,7 +285,7 @@ static struct clk_lookup lookups[] = {
CLKDEV_DEV_ID("e6518000.i2c", &mstp_clks[MSTP930]),
CLKDEV_DEV_ID("e6530000.i2c", &mstp_clks[MSTP929]),
CLKDEV_DEV_ID("e6540000.i2c", &mstp_clks[MSTP928]),
- CLKDEV_DEV_ID("r8a7790-ether", &mstp_clks[MSTP813]),
+ CLKDEV_DEV_ID("r8a779x-ether", &mstp_clks[MSTP813]),
CLKDEV_DEV_ID("rcar_thermal", &mstp_clks[MSTP522]),
CLKDEV_DEV_ID("ee200000.mmc", &mstp_clks[MSTP315]),
CLKDEV_DEV_ID("sh_mmcif.0", &mstp_clks[MSTP315]),
Index: renesas/drivers/net/ethernet/renesas/Kconfig
=================================--- renesas.orig/drivers/net/ethernet/renesas/Kconfig
+++ renesas/drivers/net/ethernet/renesas/Kconfig
@@ -13,4 +13,4 @@ config SH_ETH
Renesas SuperH Ethernet device driver.
This driver supporting CPUs are:
- SH7619, SH7710, SH7712, SH7724, SH7734, SH7763, SH7757,
- R8A7740, R8A777x and R8A7790.
+ R8A7740, R8A777x and R8A779x.
Index: renesas/drivers/net/ethernet/renesas/sh_eth.c
=================================--- renesas.orig/drivers/net/ethernet/renesas/sh_eth.c
+++ renesas/drivers/net/ethernet/renesas/sh_eth.c
@@ -395,8 +395,8 @@ static struct sh_eth_cpu_data r8a777x_da
.hw_swap = 1,
};
-/* R8A7790 */
-static struct sh_eth_cpu_data r8a7790_data = {
+/* R8A7790/1 */
+static struct sh_eth_cpu_data r8a779x_data = {
.set_duplex = sh_eth_set_duplex,
.set_rate = sh_eth_set_rate_r8a777x,
@@ -2807,7 +2807,7 @@ static struct platform_device_id sh_eth_
{ "sh7763-gether", (kernel_ulong_t)&sh7763_data },
{ "r8a7740-gether", (kernel_ulong_t)&r8a7740_data },
{ "r8a777x-ether", (kernel_ulong_t)&r8a777x_data },
- { "r8a7790-ether", (kernel_ulong_t)&r8a7790_data },
+ { "r8a779x-ether", (kernel_ulong_t)&r8a779x_data },
{ }
};
MODULE_DEVICE_TABLE(platform, sh_eth_id_table);
^ permalink raw reply
* Re: [PATCH 0/9] genetlink: reduce ops size and complexity (v2)
From: David Miller @ 2013-11-14 22:12 UTC (permalink / raw)
To: johannes
Cc: netdev, linux-wimax, bsingharora, netfilter-devel,
alex.bluesman.smirnov, dbaryshkov
In-Reply-To: <1384445687-30948-1-git-send-email-johannes@sipsolutions.net>
From: Johannes Berg <johannes@sipsolutions.net>
Date: Thu, 14 Nov 2013 17:14:38 +0100
> As before - reduce the complexity and data/code size of genetlink ops
> by making them an array rather than a linked list. Most users already
> use an array thanks to genl_register_family_with_ops(), so convert the
> remaining ones allowing us to get rid of the list head in each op.
>
> Also make them const, this just makes sense at that point and the security
> people like making function pointers const as well :-)
I have to say, this is an absolutely fantastic space usage and
complexity improvement.
Applied, thanks a lot.
^ permalink raw reply
* Re: [PATCH 1/3] statxat: Provide IOC flags for Windows fs attributes [ver #2]
From: Dave Chinner @ 2013-11-14 22:11 UTC (permalink / raw)
To: David Howells
Cc: viro, linux-cifs, linux-nfs, libc-alpha, linux-api,
andreas.gruenbacher, samba-technical, linux-fsdevel
In-Reply-To: <20131112184134.2880.9974.stgit@warthog.procyon.org.uk>
On Tue, Nov 12, 2013 at 06:41:35PM +0000, David Howells wrote:
> Provide IOC flags for Windows fs attributes so that they can be retrieved (or
> even altered) using the FS_IOC_[GS]ETFLAGS ioctl and read using statxat().
If you're adding FAT specific flags here into the generic xstat
interface, can we get a bunch of common XFS specific flags into this
interface as well so people don't need to use xfs_io to get/set
them?
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
^ permalink raw reply
* [PATCH v2 3/4] ipc: Handle error conditions in ipc command
From: David Cohen @ 2013-11-14 22:15 UTC (permalink / raw)
To: matthew.garrett
Cc: platform-driver-x86, linux-kernel, gnomes, david.a.cohen,
sathyanarayanan.kuppuswamy, eric.ernst
In-Reply-To: <1384467307-18556-1-git-send-email-david.a.cohen@linux.intel.com>
From: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Handle error conditions in intel_scu_ipc_command() and
pwr_reg_rdwr().
Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Signed-off-by: David Cohen <david.a.cohen@linux.intel.com>
---
drivers/platform/x86/intel_scu_ipc.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/platform/x86/intel_scu_ipc.c b/drivers/platform/x86/intel_scu_ipc.c
index 86b6ce2a7a47..e26830f6c8dd 100644
--- a/drivers/platform/x86/intel_scu_ipc.c
+++ b/drivers/platform/x86/intel_scu_ipc.c
@@ -235,7 +235,7 @@ static int pwr_reg_rdwr(u16 *addr, u8 *data, u32 count, u32 op, u32 id)
}
err = busy_loop();
- if (id == IPC_CMD_PCNTRL_R) { /* Read rbuf */
+ if (!err && id == IPC_CMD_PCNTRL_R) { /* Read rbuf */
/* Workaround: values are read as 0 without memcpy_fromio */
memcpy_fromio(cbuf, ipcdev.ipc_base + 0x90, 16);
for (nc = 0; nc < count; nc++)
@@ -465,8 +465,10 @@ int intel_scu_ipc_command(int cmd, int sub, u32 *in, int inlen,
ipc_command((inlen << 16) | (sub << 12) | cmd);
err = busy_loop();
- for (i = 0; i < outlen; i++)
- *out++ = ipc_data_readl(4 * i);
+ if (!err) {
+ for (i = 0; i < outlen; i++)
+ *out++ = ipc_data_readl(4 * i);
+ }
mutex_unlock(&ipclock);
return err;
--
1.8.4.2
^ permalink raw reply related
* [PATCH v2 2/4] ipc: Enabled ipc support for additional intel platforms
From: David Cohen @ 2013-11-14 22:15 UTC (permalink / raw)
To: matthew.garrett
Cc: platform-driver-x86, linux-kernel, gnomes, david.a.cohen,
sathyanarayanan.kuppuswamy, eric.ernst
In-Reply-To: <1384467307-18556-1-git-send-email-david.a.cohen@linux.intel.com>
From: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Enabled ipc support for penwell, clovertrail & tangier platforms.
Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Cc: David Cohen <david.a.cohen@linux.intel.com>
---
drivers/platform/x86/intel_scu_ipc.c | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/drivers/platform/x86/intel_scu_ipc.c b/drivers/platform/x86/intel_scu_ipc.c
index 39ff57bdf18f..86b6ce2a7a47 100644
--- a/drivers/platform/x86/intel_scu_ipc.c
+++ b/drivers/platform/x86/intel_scu_ipc.c
@@ -63,6 +63,9 @@
enum {
SCU_IPC_LINCROFT,
+ SCU_IPC_PENWELL,
+ SCU_IPC_CLOVERVIEW,
+ SCU_IPC_TANGIER,
};
/* intel scu ipc driver data*/
@@ -80,6 +83,24 @@ static struct intel_scu_ipc_pdata_t intel_scu_ipc_pdata[] = {
.ipc_len = 0x100,
.i2c_len = 0x10,
},
+ [SCU_IPC_PENWELL] = {
+ .ipc_base = 0xff11c000,
+ .i2c_base = 0xff12b000,
+ .ipc_len = 0x100,
+ .i2c_len = 0x10,
+ },
+ [SCU_IPC_CLOVERVIEW] = {
+ .ipc_base = 0xff11c000,
+ .i2c_base = 0xff12b000,
+ .ipc_len = 0x100,
+ .i2c_len = 0x10,
+ },
+ [SCU_IPC_TANGIER] = {
+ .ipc_base = 0xff009000,
+ .i2c_base = 0xff00d000,
+ .ipc_len = 0x100,
+ .i2c_len = 0x10,
+ },
};
static int ipc_probe(struct pci_dev *dev, const struct pci_device_id *id);
@@ -586,6 +607,9 @@ static void ipc_remove(struct pci_dev *pdev)
static DEFINE_PCI_DEVICE_TABLE(pci_ids) = {
{PCI_VDEVICE(INTEL, 0x082a), SCU_IPC_LINCROFT},
+ {PCI_VDEVICE(INTEL, 0x080e), SCU_IPC_PENWELL},
+ {PCI_VDEVICE(INTEL, 0x08ea), SCU_IPC_CLOVERVIEW},
+ {PCI_VDEVICE(INTEL, 0x11a0), SCU_IPC_TANGIER},
{ 0,}
};
MODULE_DEVICE_TABLE(pci, pci_ids);
--
1.8.4.2
^ permalink raw reply related
* [PATCH v2 0/4] Enable more Intel Mid platforms on IPC driver
From: David Cohen @ 2013-11-14 22:15 UTC (permalink / raw)
To: matthew.garrett
Cc: platform-driver-x86, linux-kernel, gnomes, david.a.cohen,
sathyanarayanan.kuppuswamy, eric.ernst
In-Reply-To: <1384373671-12814-1-git-send-email-david.a.cohen@linux.intel.com>
Hi,
I am resubmitting these patches to enable other Intel Mid platforms on IPC
driver.
This change is necessary prior to enable more features for Mid on upstream.
Changes from v1 to v2:
- Fixed bug on patch 1/4: changed PCI_DEVICE to PCI_VDEVICE
- Addressed Alan Cox'c comments:
* Added log message for timeouts
* Remove all #ifdefs from code
Br, David Cohen
---
Kuppuswamy Sathyanarayanan (4):
ipc: Added platform data structure
ipc: Enabled ipc support for additional intel platforms
ipc: Handle error conditions in ipc command
ipc: Added support for IPC interrupt mode
drivers/platform/x86/intel_scu_ipc.c | 117 ++++++++++++++++++++++++++++++-----
1 file changed, 103 insertions(+), 14 deletions(-)
--
1.8.4.2
^ permalink raw reply
* [PATCH v2 1/4] ipc: Added platform data structure
From: David Cohen @ 2013-11-14 22:15 UTC (permalink / raw)
To: matthew.garrett
Cc: platform-driver-x86, linux-kernel, gnomes, david.a.cohen,
sathyanarayanan.kuppuswamy, eric.ernst
In-Reply-To: <1384467307-18556-1-git-send-email-david.a.cohen@linux.intel.com>
From: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Since the same ipc driver can be used by many platforms, using
macros for defining ipc_base and i2c_base addresses is not
a scalable approach. So added a platform data structure to pass
this information.
Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Acked-by: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
Cc: David Cohen <david.a.cohen@linux.intel.com>
---
drivers/platform/x86/intel_scu_ipc.c | 37 ++++++++++++++++++++++++++++--------
1 file changed, 29 insertions(+), 8 deletions(-)
diff --git a/drivers/platform/x86/intel_scu_ipc.c b/drivers/platform/x86/intel_scu_ipc.c
index d654f831410d..39ff57bdf18f 100644
--- a/drivers/platform/x86/intel_scu_ipc.c
+++ b/drivers/platform/x86/intel_scu_ipc.c
@@ -58,12 +58,29 @@
* message handler is called within firmware.
*/
-#define IPC_BASE_ADDR 0xFF11C000 /* IPC1 base register address */
-#define IPC_MAX_ADDR 0x100 /* Maximum IPC regisers */
#define IPC_WWBUF_SIZE 20 /* IPC Write buffer Size */
#define IPC_RWBUF_SIZE 20 /* IPC Read buffer Size */
-#define IPC_I2C_BASE 0xFF12B000 /* I2C control register base address */
-#define IPC_I2C_MAX_ADDR 0x10 /* Maximum I2C regisers */
+
+enum {
+ SCU_IPC_LINCROFT,
+};
+
+/* intel scu ipc driver data*/
+struct intel_scu_ipc_pdata_t {
+ u32 ipc_base;
+ u32 i2c_base;
+ u32 ipc_len;
+ u32 i2c_len;
+};
+
+static struct intel_scu_ipc_pdata_t intel_scu_ipc_pdata[] = {
+ [SCU_IPC_LINCROFT] = {
+ .ipc_base = 0xff11c000,
+ .i2c_base = 0xff12b000,
+ .ipc_len = 0x100,
+ .i2c_len = 0x10,
+ },
+};
static int ipc_probe(struct pci_dev *dev, const struct pci_device_id *id);
static void ipc_remove(struct pci_dev *pdev);
@@ -504,12 +521,16 @@ static irqreturn_t ioc(int irq, void *dev_id)
*/
static int ipc_probe(struct pci_dev *dev, const struct pci_device_id *id)
{
- int err;
+ int err, pid;
+ struct intel_scu_ipc_pdata_t *pdata;
resource_size_t pci_resource;
if (ipcdev.pdev) /* We support only one SCU */
return -EBUSY;
+ pid = id->driver_data;
+ pdata = &intel_scu_ipc_pdata[pid];
+
ipcdev.pdev = pci_dev_get(dev);
err = pci_enable_device(dev);
@@ -527,11 +548,11 @@ static int ipc_probe(struct pci_dev *dev, const struct pci_device_id *id)
if (request_irq(dev->irq, ioc, 0, "intel_scu_ipc", &ipcdev))
return -EBUSY;
- ipcdev.ipc_base = ioremap_nocache(IPC_BASE_ADDR, IPC_MAX_ADDR);
+ ipcdev.ipc_base = ioremap_nocache(pdata->ipc_base, pdata->ipc_len);
if (!ipcdev.ipc_base)
return -ENOMEM;
- ipcdev.i2c_base = ioremap_nocache(IPC_I2C_BASE, IPC_I2C_MAX_ADDR);
+ ipcdev.i2c_base = ioremap_nocache(pdata->i2c_base, pdata->i2c_len);
if (!ipcdev.i2c_base) {
iounmap(ipcdev.ipc_base);
return -ENOMEM;
@@ -564,7 +585,7 @@ static void ipc_remove(struct pci_dev *pdev)
}
static DEFINE_PCI_DEVICE_TABLE(pci_ids) = {
- {PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x082a)},
+ {PCI_VDEVICE(INTEL, 0x082a), SCU_IPC_LINCROFT},
{ 0,}
};
MODULE_DEVICE_TABLE(pci, pci_ids);
--
1.8.4.2
^ permalink raw reply related
* [PATCH v2 4/4] ipc: Added support for IPC interrupt mode
From: David Cohen @ 2013-11-14 22:15 UTC (permalink / raw)
To: matthew.garrett
Cc: platform-driver-x86, linux-kernel, gnomes, david.a.cohen,
sathyanarayanan.kuppuswamy, eric.ernst
In-Reply-To: <1384467307-18556-1-git-send-email-david.a.cohen@linux.intel.com>
From: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
This patch adds support for ipc command interrupt mode.
Also added platform data option to select 'irq_mode'
irq_mode = 1: configure the driver to receive IOC interrupt
for each successful ipc_command.
irq_mode = 0: makes driver use polling method to
track the command completion status.
Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Signed-off-by: David Cohen <david.a.cohen@linux.intel.com>
---
drivers/platform/x86/intel_scu_ipc.c | 48 +++++++++++++++++++++++++++++++++---
1 file changed, 45 insertions(+), 3 deletions(-)
diff --git a/drivers/platform/x86/intel_scu_ipc.c b/drivers/platform/x86/intel_scu_ipc.c
index e26830f6c8dd..90521e9c6065 100644
--- a/drivers/platform/x86/intel_scu_ipc.c
+++ b/drivers/platform/x86/intel_scu_ipc.c
@@ -60,6 +60,7 @@
#define IPC_WWBUF_SIZE 20 /* IPC Write buffer Size */
#define IPC_RWBUF_SIZE 20 /* IPC Read buffer Size */
+#define IPC_IOC 0x100 /* IPC command register IOC bit */
enum {
SCU_IPC_LINCROFT,
@@ -74,6 +75,7 @@ struct intel_scu_ipc_pdata_t {
u32 i2c_base;
u32 ipc_len;
u32 i2c_len;
+ u8 irq_mode;
};
static struct intel_scu_ipc_pdata_t intel_scu_ipc_pdata[] = {
@@ -82,24 +84,28 @@ static struct intel_scu_ipc_pdata_t intel_scu_ipc_pdata[] = {
.i2c_base = 0xff12b000,
.ipc_len = 0x100,
.i2c_len = 0x10,
+ .irq_mode = 0,
},
[SCU_IPC_PENWELL] = {
.ipc_base = 0xff11c000,
.i2c_base = 0xff12b000,
.ipc_len = 0x100,
.i2c_len = 0x10,
+ .irq_mode = 1,
},
[SCU_IPC_CLOVERVIEW] = {
.ipc_base = 0xff11c000,
.i2c_base = 0xff12b000,
.ipc_len = 0x100,
.i2c_len = 0x10,
+ .irq_mode = 1,
},
[SCU_IPC_TANGIER] = {
.ipc_base = 0xff009000,
.i2c_base = 0xff00d000,
.ipc_len = 0x100,
.i2c_len = 0x10,
+ .irq_mode = 1,
},
};
@@ -110,6 +116,8 @@ struct intel_scu_ipc_dev {
struct pci_dev *pdev;
void __iomem *ipc_base;
void __iomem *i2c_base;
+ struct completion cmd_complete;
+ u8 irq_mode;
};
static struct intel_scu_ipc_dev ipcdev; /* Only one for now */
@@ -136,6 +144,10 @@ static DEFINE_MUTEX(ipclock); /* lock used to prevent multiple call to SCU */
*/
static inline void ipc_command(u32 cmd) /* Send ipc command */
{
+ if (ipcdev.irq_mode) {
+ INIT_COMPLETION(ipcdev.cmd_complete);
+ writel(cmd | IPC_IOC, ipcdev.ipc_base);
+ }
writel(cmd, ipcdev.ipc_base);
}
@@ -194,6 +206,30 @@ static inline int busy_loop(void) /* Wait till scu status is busy */
return 0;
}
+/* Wait till ipc ioc interrupt is received or timeout in 3 HZ */
+static inline int ipc_wait_for_interrupt(void)
+{
+ int status;
+
+ if (!wait_for_completion_timeout(&ipcdev.cmd_complete, 3 * HZ)) {
+ struct device *dev = &ipcdev.pdev->dev;
+ dev_err(dev, "IPC timed out\n");
+ return -ETIMEDOUT;
+ }
+
+ status = ipc_read_status();
+
+ if ((status >> 1) & 1)
+ return -EIO;
+
+ return 0;
+}
+
+int intel_scu_ipc_check_status(void)
+{
+ return ipcdev.irq_mode ? ipc_wait_for_interrupt() : busy_loop();
+}
+
/* Read/Write power control(PMIC in Langwell, MSIC in PenWell) registers */
static int pwr_reg_rdwr(u16 *addr, u8 *data, u32 count, u32 op, u32 id)
{
@@ -234,7 +270,7 @@ static int pwr_reg_rdwr(u16 *addr, u8 *data, u32 count, u32 op, u32 id)
ipc_command(4 << 16 | id << 12 | 0 << 8 | op);
}
- err = busy_loop();
+ err = intel_scu_ipc_check_status();
if (!err && id == IPC_CMD_PCNTRL_R) { /* Read rbuf */
/* Workaround: values are read as 0 without memcpy_fromio */
memcpy_fromio(cbuf, ipcdev.ipc_base + 0x90, 16);
@@ -429,7 +465,7 @@ int intel_scu_ipc_simple_command(int cmd, int sub)
return -ENODEV;
}
ipc_command(sub << 12 | cmd);
- err = busy_loop();
+ err = intel_scu_ipc_check_status();
mutex_unlock(&ipclock);
return err;
}
@@ -463,7 +499,7 @@ int intel_scu_ipc_command(int cmd, int sub, u32 *in, int inlen,
ipc_data_writel(*in++, 4 * i);
ipc_command((inlen << 16) | (sub << 12) | cmd);
- err = busy_loop();
+ err = intel_scu_ipc_check_status();
if (!err) {
for (i = 0; i < outlen; i++)
@@ -531,6 +567,9 @@ EXPORT_SYMBOL(intel_scu_ipc_i2c_cntrl);
*/
static irqreturn_t ioc(int irq, void *dev_id)
{
+ if (ipcdev.irq_mode)
+ complete(&ipcdev.cmd_complete);
+
return IRQ_HANDLED;
}
@@ -555,6 +594,7 @@ static int ipc_probe(struct pci_dev *dev, const struct pci_device_id *id)
pdata = &intel_scu_ipc_pdata[pid];
ipcdev.pdev = pci_dev_get(dev);
+ ipcdev.irq_mode = pdata->irq_mode;
err = pci_enable_device(dev);
if (err)
@@ -568,6 +608,8 @@ static int ipc_probe(struct pci_dev *dev, const struct pci_device_id *id)
if (!pci_resource)
return -ENOMEM;
+ init_completion(&ipcdev.cmd_complete);
+
if (request_irq(dev->irq, ioc, 0, "intel_scu_ipc", &ipcdev))
return -EBUSY;
--
1.8.4.2
^ permalink raw reply related
* Re: [PATCH] iommu/fsl_pamu: use physical cpu index to find the matched cpu nodes
From: Scott Wood @ 2013-11-14 22:10 UTC (permalink / raw)
To: Haiying Wang; +Cc: Varun Sethi, joro, linuxppc-dev, iommu
In-Reply-To: <1384457440.2144.15.camel@haiying-laptop>
On Thu, 2013-11-14 at 14:30 -0500, Haiying Wang wrote:
> In the case we miss to bring up some cpus, we need to make sure we can
> find the correct cpu nodes in the device tree based on the given logical
> cpu index from the caller.
>
> Signed-off-by: Haiying Wang <Haiying.Wang@freescale.com>
> ---
> drivers/iommu/fsl_pamu.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/iommu/fsl_pamu.c b/drivers/iommu/fsl_pamu.c
> index cba0498..a9ab57b 100644
> --- a/drivers/iommu/fsl_pamu.c
> +++ b/drivers/iommu/fsl_pamu.c
> @@ -539,6 +539,7 @@ u32 get_stash_id(u32 stash_dest_hint, u32 vcpu)
Should probably also s/vcpu/cpu/g as vcpu makes no sense outside of
virtualization code.
> u32 cache_level;
> int len, found = 0;
> int i;
> + u32 cpuid = get_hard_smp_processor_id(vcpu);
s/cpuid/phys_cpu/ or similar
-Scott
^ permalink raw reply
* Re: [PATCH] iommu/fsl_pamu: use physical cpu index to find the matched cpu nodes
From: Scott Wood @ 2013-11-14 22:10 UTC (permalink / raw)
To: Haiying Wang
Cc: Varun Sethi, linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA
In-Reply-To: <1384457440.2144.15.camel@haiying-laptop>
On Thu, 2013-11-14 at 14:30 -0500, Haiying Wang wrote:
> In the case we miss to bring up some cpus, we need to make sure we can
> find the correct cpu nodes in the device tree based on the given logical
> cpu index from the caller.
>
> Signed-off-by: Haiying Wang <Haiying.Wang-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
> ---
> drivers/iommu/fsl_pamu.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/iommu/fsl_pamu.c b/drivers/iommu/fsl_pamu.c
> index cba0498..a9ab57b 100644
> --- a/drivers/iommu/fsl_pamu.c
> +++ b/drivers/iommu/fsl_pamu.c
> @@ -539,6 +539,7 @@ u32 get_stash_id(u32 stash_dest_hint, u32 vcpu)
Should probably also s/vcpu/cpu/g as vcpu makes no sense outside of
virtualization code.
> u32 cache_level;
> int len, found = 0;
> int i;
> + u32 cpuid = get_hard_smp_processor_id(vcpu);
s/cpuid/phys_cpu/ or similar
-Scott
^ permalink raw reply
* Re: [PATCH] xfs_repair: correct docs for "-t" units
From: Dave Chinner @ 2013-11-14 22:09 UTC (permalink / raw)
To: Eric Sandeen; +Cc: xfs-oss
In-Reply-To: <528534B0.8070709@redhat.com>
On Thu, Nov 14, 2013 at 02:38:08PM -0600, Eric Sandeen wrote:
> usage() says that the xfs_repair -t reporting interval is
> in minutes, and the manpage says nothing at all about units.
>
> Actually, it's in seconds.
>
> Clarify in both places that the interval is specified in
> seconds.
>
> Signed-off-by: Eric Sandeen <sandeen@redhat.com>
> ---
Looks good.
Reviewed-by: Dave Chinner <dchinner@redhat.com>
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply
* [patch] perf_event_open.2 cpu/pid argument cleanup
From: Vince Weaver @ 2013-11-14 22:08 UTC (permalink / raw)
To: Michael Kerrisk (man-pages); +Cc: linux-man-u79uwXL29TY76Z2rM5mHXA
This patch attempts to clarify the pid and cpu options to
perf_event_open.
It does two things:
1. Tries to make clear that the "pid" argument can mean
process *or* thread. This is made confusing by
how Linux uses the terms mostly interchangably.
2. The cpu/pid documentation was confusing because of
how the parameters are interdependent. Since there
are only 6 possible combinations I broke out the
possibilities into a table.
I'm open to comments, especially on how the pid/cpu stuff was broken
out, I'm not sure if I got the style right for that part.
Reported-by: Manuel Selva <selva.manuel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Signed-off-by: Vince Weaver <vincent.weaver-e7X0jjDqjFGHXe+LvDLADg@public.gmane.org>
diff --git a/man2/perf_event_open.2 b/man2/perf_event_open.2
index 1889689..7d84389 100644
--- a/man2/perf_event_open.2
+++ b/man2/perf_event_open.2
@@ -75,54 +75,36 @@ be accessed via
.BR mmap (2) .
.SS Arguments
.P
-The argument
-.I pid
-allows events to be attached to processes in various ways.
-If
-.I pid
-is 0, measurements happen on the current thread, if
-.I pid
-is greater than 0, the process indicated by
-.I pid
-is measured, and if
-.I pid
-is \-1, all processes are counted.
-
The
-.I cpu
-argument allows measurements to be specific to a CPU.
-If
-.I cpu
-is greater than or equal to 0,
-measurements are restricted to the specified CPU;
-if
-.I cpu
-is \-1, the events are measured on all CPUs.
-.P
-Note that the combination of
-.IR pid " == \-1"
-and
-.IR cpu " == \-1"
-is not valid.
-.P
-A
-.IR pid " > 0"
-and
-.IR cpu " == \-1"
-setting measures per-process and follows that process to whatever CPU the
-process gets scheduled to.
-Per-process events can be created by any user.
-.P
-A
-.IR pid " == \-1"
+.I pid
and
-.IR cpu " >= 0"
-setting is per-CPU and measures all processes on the specified CPU.
-Per-CPU events need the
+.I cpu
+arguments allow specifying which process and CPU to monitor:
+.TP
+.BR pid==0 " and " cpu==\-1
+This measures the current process/thread on any CPU.
+.TP
+.BR pid==0 " and " cpu>=0
+This measures the current process/thread only
+when running on the specified CPU.
+.TP
+.BR pid>0 " and " cpu==\-1
+This measures the specified process/thread on any CPU.
+.TP
+.BR pid>0 " and " cpu>=0
+This measures the specified process/thread only
+when running on the specified CPU.
+.TP
+.BR pid==\-1 " and " cpu>=0
+This measures all processes/threads on the specified CPU.
+Measurements such as this require the
.B CAP_SYS_ADMIN
capability or a
.I /proc/sys/kernel/perf_event_paranoid
value of less than 1.
+.TP
+.BR pid==\-1 " and " cpu==\-1
+This setting is invalid and will return an error.
.P
The
.I group_fd
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH v5 00/14] New hash table implementation
From: Karsten Blees @ 2013-11-14 22:07 UTC (permalink / raw)
To: Git List, Junio C Hamano; +Cc: Thomas Rast, Jens Lehmann, Karsten Blees
In-Reply-To: <52851FB5.4050406@gmail.com>
Am 14.11.2013 20:08, schrieb Karsten Blees:
> Changes since v3:
s/v3/v4/
^ permalink raw reply
* Re: [Xen-devel] pvgrub2 is merged
From: Dario Faggioli @ 2013-11-14 9:48 UTC (permalink / raw)
To: Ian Campbell
Cc: Vladimir 'φ-coder/phcoder' Serbinenko,
xen-devel@lists.xen.org, The development of GRUB 2
In-Reply-To: <1384164632.3189.177.camel@kazak.uk.xensource.com>
[-- Attachment #1: Type: text/plain, Size: 1404 bytes --]
On lun, 2013-11-11 at 10:10 +0000, Ian Campbell wrote:
> On Sat, 2013-11-09 at 21:52 +0100, Vladimir 'φ-coder/phcoder' Serbinenko
> wrote:
> > Hello, all. pvgrub2 has just became part of upstream grub as ports i386-xen and x86_64-xen.
>
> This is super cool, thanks!
>
Indeed!
Actually, it would be great to have an entry about this in the
Xen-Project blog: http://blog.xen.org/
Vladimir, would you be interested? If yes, would you be up to writing
the blog post? I'm thinking about something like:
- what is this?
- what is this good for?
- how to enable/use it?
- how [hard] was it to do it? (if you like)
And, of course, whatever else you think could be interesting to have
there.
If not Vladimir, anyone else? If not, I can try to collect the info from
this thread and put something together, but it'll take longer (since I'm
not at all into this).
Anyway, if anyone is interested, please, contact me. I'll provide all
the necessary information either privately or on the @xen-publicity
mailing list (so that we also will stop bothering people in
@xen-devel :-)).
Thanks and Regards,
Dario
--
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH net-next 0/6] 6lowpan: udp compression/uncompression fix
From: David Miller @ 2013-11-14 22:06 UTC (permalink / raw)
To: eric.dumazet
Cc: alex.aring, alex.bluesman.smirnov, linux-zigbee-devel, werner,
jukka.rissanen, dbaryshkov, netdev
In-Reply-To: <1384445983.28716.1.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 14 Nov 2013 08:19:43 -0800
> On Thu, 2013-11-14 at 16:48 +0100, Alexander Aring wrote:
>> The current 6LoWPAN udp compression/uncompression is completely broken.
>> This patch series fix a lot of udp compression/uncompression issues and
>> add support parsing with lowpan_fetch_skb function.
>
> If its broken, why targeting net-next tree (which is closed BTW ATM) ?
In any event, if you do want it to go into net-next, please resubmit
this series when the net-next tree opens back up after the merge
window.
Thanks!
^ permalink raw reply
* Re: [PATCH net] ip6tnl: fix use after free of fb_tnl_dev
From: David Miller @ 2013-11-14 22:05 UTC (permalink / raw)
To: nicolas.dichtel
Cc: rostedt, linux-kernel, stable, gregkh, williams, linux-rt-users,
lclaudio, netdev, willemb
In-Reply-To: <1384440423-4275-1-git-send-email-nicolas.dichtel@6wind.com>
From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date: Thu, 14 Nov 2013 15:47:03 +0100
> Bug has been introduced by commit bb8140947a24 ("ip6tnl: allow to use rtnl ops
> on fb tunnel").
>
> When ip6_tunnel.ko is unloaded, FB device is delete by rtnl_link_unregister()
> and then we try to use the pointer in ip6_tnl_destroy_tunnels().
>
> Let's add an handler for dellink, which will never remove the FB tunnel. With
> this patch it will no more be possible to remove it via 'ip link del ip6tnl0',
> but it's safer.
>
> The same fix was already proposed by Willem de Bruijn <willemb@google.com> for
> sit interfaces.
>
> CC: Willem de Bruijn <willemb@google.com>
> Reported-by: Steven Rostedt <rostedt@goodmis.org>
> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Applied and queued up for -stable, thanks for being so proactive about this
Nicolas.
^ permalink raw reply
* [PATCH linux-next] SELinux: security_load_policy: Silence frame-larger-than warning
From: Tim Gardner @ 2013-11-14 22:04 UTC (permalink / raw)
To: linux-security-module, linux-kernel
Cc: Tim Gardner, Stephen Smalley, James Morris, Eric Paris
Dynamically allocate a couple of the larger stack variables in order to
reduce the stack footprint below 1024. gcc-4.8
security/selinux/ss/services.c: In function 'security_load_policy':
security/selinux/ss/services.c:1964:1: warning: the frame size of 1104 bytes is larger than 1024 bytes [-Wframe-larger-than=]
}
Also silence a couple of checkpatch warnings at the same time.
WARNING: sizeof policydb should be sizeof(policydb)
+ memcpy(oldpolicydb, &policydb, sizeof policydb);
WARNING: sizeof policydb should be sizeof(policydb)
+ memcpy(&policydb, newpolicydb, sizeof policydb);
Cc: Stephen Smalley <sds@tycho.nsa.gov>
Cc: James Morris <james.l.morris@oracle.com>
Cc: Eric Paris <eparis@parisplace.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
---
security/selinux/ss/services.c | 54 ++++++++++++++++++++++++----------------
1 file changed, 32 insertions(+), 22 deletions(-)
diff --git a/security/selinux/ss/services.c b/security/selinux/ss/services.c
index b4feecc..c8317c8 100644
--- a/security/selinux/ss/services.c
+++ b/security/selinux/ss/services.c
@@ -1828,7 +1828,7 @@ static int security_preserve_bools(struct policydb *p);
*/
int security_load_policy(void *data, size_t len)
{
- struct policydb oldpolicydb, newpolicydb;
+ struct policydb *oldpolicydb, *newpolicydb;
struct sidtab oldsidtab, newsidtab;
struct selinux_mapping *oldmap, *map = NULL;
struct convert_context_args args;
@@ -1837,12 +1837,19 @@ int security_load_policy(void *data, size_t len)
int rc = 0;
struct policy_file file = { data, len }, *fp = &file;
+ oldpolicydb = kzalloc(2 * sizeof(*oldpolicydb), GFP_KERNEL);
+ if (!oldpolicydb) {
+ rc = -ENOMEM;
+ goto out;
+ }
+ newpolicydb = oldpolicydb + 1;
+
if (!ss_initialized) {
avtab_cache_init();
rc = policydb_read(&policydb, fp);
if (rc) {
avtab_cache_destroy();
- return rc;
+ goto out;
}
policydb.len = len;
@@ -1852,14 +1859,14 @@ int security_load_policy(void *data, size_t len)
if (rc) {
policydb_destroy(&policydb);
avtab_cache_destroy();
- return rc;
+ goto out;
}
rc = policydb_load_isids(&policydb, &sidtab);
if (rc) {
policydb_destroy(&policydb);
avtab_cache_destroy();
- return rc;
+ goto out;
}
security_load_policycaps();
@@ -1871,36 +1878,36 @@ int security_load_policy(void *data, size_t len)
selinux_status_update_policyload(seqno);
selinux_netlbl_cache_invalidate();
selinux_xfrm_notify_policyload();
- return 0;
+ goto out;
}
#if 0
sidtab_hash_eval(&sidtab, "sids");
#endif
- rc = policydb_read(&newpolicydb, fp);
+ rc = policydb_read(newpolicydb, fp);
if (rc)
- return rc;
+ goto out;
- newpolicydb.len = len;
+ newpolicydb->len = len;
/* If switching between different policy types, log MLS status */
- if (policydb.mls_enabled && !newpolicydb.mls_enabled)
+ if (policydb.mls_enabled && !newpolicydb->mls_enabled)
printk(KERN_INFO "SELinux: Disabling MLS support...\n");
- else if (!policydb.mls_enabled && newpolicydb.mls_enabled)
+ else if (!policydb.mls_enabled && newpolicydb->mls_enabled)
printk(KERN_INFO "SELinux: Enabling MLS support...\n");
- rc = policydb_load_isids(&newpolicydb, &newsidtab);
+ rc = policydb_load_isids(newpolicydb, &newsidtab);
if (rc) {
printk(KERN_ERR "SELinux: unable to load the initial SIDs\n");
- policydb_destroy(&newpolicydb);
- return rc;
+ policydb_destroy(newpolicydb);
+ goto out;
}
- rc = selinux_set_mapping(&newpolicydb, secclass_map, &map, &map_size);
+ rc = selinux_set_mapping(newpolicydb, secclass_map, &map, &map_size);
if (rc)
goto err;
- rc = security_preserve_bools(&newpolicydb);
+ rc = security_preserve_bools(newpolicydb);
if (rc) {
printk(KERN_ERR "SELinux: unable to preserve booleans\n");
goto err;
@@ -1918,7 +1925,7 @@ int security_load_policy(void *data, size_t len)
* in the new SID table.
*/
args.oldp = &policydb;
- args.newp = &newpolicydb;
+ args.newp = newpolicydb;
rc = sidtab_map(&newsidtab, convert_context, &args);
if (rc) {
printk(KERN_ERR "SELinux: unable to convert the internal"
@@ -1928,12 +1935,12 @@ int security_load_policy(void *data, size_t len)
}
/* Save the old policydb and SID table to free later. */
- memcpy(&oldpolicydb, &policydb, sizeof policydb);
+ memcpy(oldpolicydb, &policydb, sizeof(policydb));
sidtab_set(&oldsidtab, &sidtab);
/* Install the new policydb and SID table. */
write_lock_irq(&policy_rwlock);
- memcpy(&policydb, &newpolicydb, sizeof policydb);
+ memcpy(&policydb, newpolicydb, sizeof(policydb));
sidtab_set(&sidtab, &newsidtab);
security_load_policycaps();
oldmap = current_mapping;
@@ -1943,7 +1950,7 @@ int security_load_policy(void *data, size_t len)
write_unlock_irq(&policy_rwlock);
/* Free the old policydb and SID table. */
- policydb_destroy(&oldpolicydb);
+ policydb_destroy(oldpolicydb);
sidtab_destroy(&oldsidtab);
kfree(oldmap);
@@ -1953,14 +1960,17 @@ int security_load_policy(void *data, size_t len)
selinux_netlbl_cache_invalidate();
selinux_xfrm_notify_policyload();
- return 0;
+ rc = 0;
+ goto out;
err:
kfree(map);
sidtab_destroy(&newsidtab);
- policydb_destroy(&newpolicydb);
- return rc;
+ policydb_destroy(newpolicydb);
+out:
+ kfree(oldpolicydb);
+ return rc;
}
size_t security_policydb_len(void)
--
1.7.9.5
^ permalink raw reply related
* Re: [lm-sensors] [PATCHv5 05/20] cpufreq: cpufreq-cpu0: add dt node parsing for cooling device prope
From: Rafael J. Wysocki @ 2013-11-14 22:04 UTC (permalink / raw)
To: Eduardo Valentin
Cc: swarren, pawel.moll, mark.rutland, ian.campbell, rob.herring,
linux, rui.zhang, wni, grant.likely, durgadoss.r, linux-pm,
devicetree, lm-sensors, linux-kernel, Viresh Kumar, cpufreq,
devicetree-discuss
In-Reply-To: <5284CD61.3000302@ti.com>
On Thursday, November 14, 2013 09:17:21 AM Eduardo Valentin wrote:
> On 12-11-2013 15:46, Eduardo Valentin wrote:
> > This patch changes the cpufreq-cpu0 driver to consider if
> > a cpu needs cooling (with cpufreq). In case the cooling is needed,
> > the cpu0 device tree node needs to be properly configured
> > with cooling device properties.
> >
> > In case these properties are present,, the driver will
> > load a cpufreq cooling device in the system. The cpufreq-cpu0
> > driver is not interested in determining how the system should
> > be using the cooling device. The driver is responsible
> > only of loading the cooling device.
> >
> > Describing how the cooling device will be used can be
> > accomplished by setting up a thermal zone that references
> > and is composed by the cpufreq cooling device.
> >
> > Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
>
> Rafael, Can I still assume you are OK with this patch and add your
> acked-by [1]?
> http://www.spinics.net/lists/lm-sensors/msg39136.html
>
> It has changed a few bits from V1 to here. The idea is still same though.
Well, this is fine by me, personally, but I'd like someone from the ARM camp to
ACK this to be honest.
Thanks!
> > Cc: Viresh Kumar <viresh.kumar@linaro.org>
> > Cc: Grant Likely <grant.likely@linaro.org>
> > Cc: Rob Herring <rob.herring@calxeda.com>
> > Cc: cpufreq@vger.kernel.org
> > Cc: linux-pm@vger.kernel.org
> > Cc: linux-kernel@vger.kernel.org
> > Cc: devicetree-discuss@lists.ozlabs.org
> > Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
> > ---
> > .../devicetree/bindings/cpufreq/cpufreq-cpu0.txt | 7 +++++++
> > drivers/cpufreq/Kconfig | 2 +-
> > drivers/cpufreq/cpufreq-cpu0.c | 16 ++++++++++++++++
> > 3 files changed, 24 insertions(+), 1 deletion(-)
> >
> > diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt b/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
> > index 051f764..f055515 100644
> > --- a/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
> > +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
> > @@ -15,6 +15,10 @@ Optional properties:
> > - clock-latency: Specify the possible maximum transition latency for clock,
> > in unit of nanoseconds.
> > - voltage-tolerance: Specify the CPU voltage tolerance in percentage.
> > +- #cooling-cells:
> > +- cooling-min-level:
> > +- cooling-max-level:
> > + Please refer to Documentation/devicetree/bindings/thermal/thermal.txt.
> >
> > Examples:
> >
> > @@ -33,6 +37,9 @@ cpus {
> > 198000 850000
> > >;
> > clock-latency = <61036>; /* two CLK32 periods */
> > + #cooling-cells = <2>;
> > + cooling-min-level = <0>;
> > + cooling-max-level = <2>;
> > };
> >
> > cpu@1 {
> > diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig
> > index 534fcb8..fc1e9a5 100644
> > --- a/drivers/cpufreq/Kconfig
> > +++ b/drivers/cpufreq/Kconfig
> > @@ -186,7 +186,7 @@ config CPU_FREQ_GOV_CONSERVATIVE
> >
> > config GENERIC_CPUFREQ_CPU0
> > tristate "Generic CPU0 cpufreq driver"
> > - depends on HAVE_CLK && REGULATOR && PM_OPP && OF
> > + depends on HAVE_CLK && REGULATOR && PM_OPP && OF && THERMAL && CPU_THERMAL
> > select CPU_FREQ_TABLE
> > help
> > This adds a generic cpufreq driver for CPU0 frequency management.
> > diff --git a/drivers/cpufreq/cpufreq-cpu0.c b/drivers/cpufreq/cpufreq-cpu0.c
> > index c522a95..568aaf3 100644
> > --- a/drivers/cpufreq/cpufreq-cpu0.c
> > +++ b/drivers/cpufreq/cpufreq-cpu0.c
> > @@ -13,7 +13,9 @@
> >
> > #include <linux/clk.h>
> > #include <linux/cpu.h>
> > +#include <linux/cpu_cooling.h>
> > #include <linux/cpufreq.h>
> > +#include <linux/cpumask.h>
> > #include <linux/err.h>
> > #include <linux/module.h>
> > #include <linux/of.h>
> > @@ -21,6 +23,7 @@
> > #include <linux/platform_device.h>
> > #include <linux/regulator/consumer.h>
> > #include <linux/slab.h>
> > +#include <linux/thermal.h>
> >
> > static unsigned int transition_latency;
> > static unsigned int voltage_tolerance; /* in percentage */
> > @@ -29,6 +32,7 @@ static struct device *cpu_dev;
> > static struct clk *cpu_clk;
> > static struct regulator *cpu_reg;
> > static struct cpufreq_frequency_table *freq_table;
> > +static struct thermal_cooling_device *cdev;
> >
> > static int cpu0_verify_speed(struct cpufreq_policy *policy)
> > {
> > @@ -260,6 +264,17 @@ static int cpu0_cpufreq_probe(struct platform_device *pdev)
> > goto out_free_table;
> > }
> >
> > + /*
> > + * For now, just loading the cooling device;
> > + * thermal DT code takes care of matching them.
> > + */
> > + if (of_find_property(np, "#cooling-cells", NULL)) {
> > + cdev = of_cpufreq_cooling_register(np, cpu_present_mask);
> > + if (IS_ERR(cdev))
> > + pr_err("running cpufreq without cooling device: %ld\n",
> > + PTR_ERR(cdev));
> > + }
> > +
> > of_node_put(np);
> > return 0;
> >
> > @@ -272,6 +287,7 @@ out_put_node:
> >
> > static int cpu0_cpufreq_remove(struct platform_device *pdev)
> > {
> > + cpufreq_cooling_unregister(cdev);
> > cpufreq_unregister_driver(&cpu0_cpufreq_driver);
> > opp_free_cpufreq_table(cpu_dev, &freq_table);
> >
> >
>
>
>
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply
* Re: [PATCHv5 05/20] cpufreq: cpufreq-cpu0: add dt node parsing for cooling device properties
From: Rafael J. Wysocki @ 2013-11-14 22:04 UTC (permalink / raw)
To: Eduardo Valentin
Cc: swarren, pawel.moll, mark.rutland, ian.campbell, rob.herring,
linux, rui.zhang, wni, grant.likely, durgadoss.r, linux-pm,
devicetree, lm-sensors, linux-kernel, Viresh Kumar, cpufreq,
devicetree-discuss
In-Reply-To: <5284CD61.3000302@ti.com>
On Thursday, November 14, 2013 09:17:21 AM Eduardo Valentin wrote:
> On 12-11-2013 15:46, Eduardo Valentin wrote:
> > This patch changes the cpufreq-cpu0 driver to consider if
> > a cpu needs cooling (with cpufreq). In case the cooling is needed,
> > the cpu0 device tree node needs to be properly configured
> > with cooling device properties.
> >
> > In case these properties are present,, the driver will
> > load a cpufreq cooling device in the system. The cpufreq-cpu0
> > driver is not interested in determining how the system should
> > be using the cooling device. The driver is responsible
> > only of loading the cooling device.
> >
> > Describing how the cooling device will be used can be
> > accomplished by setting up a thermal zone that references
> > and is composed by the cpufreq cooling device.
> >
> > Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
>
> Rafael, Can I still assume you are OK with this patch and add your
> acked-by [1]?
> http://www.spinics.net/lists/lm-sensors/msg39136.html
>
> It has changed a few bits from V1 to here. The idea is still same though.
Well, this is fine by me, personally, but I'd like someone from the ARM camp to
ACK this to be honest.
Thanks!
> > Cc: Viresh Kumar <viresh.kumar@linaro.org>
> > Cc: Grant Likely <grant.likely@linaro.org>
> > Cc: Rob Herring <rob.herring@calxeda.com>
> > Cc: cpufreq@vger.kernel.org
> > Cc: linux-pm@vger.kernel.org
> > Cc: linux-kernel@vger.kernel.org
> > Cc: devicetree-discuss@lists.ozlabs.org
> > Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
> > ---
> > .../devicetree/bindings/cpufreq/cpufreq-cpu0.txt | 7 +++++++
> > drivers/cpufreq/Kconfig | 2 +-
> > drivers/cpufreq/cpufreq-cpu0.c | 16 ++++++++++++++++
> > 3 files changed, 24 insertions(+), 1 deletion(-)
> >
> > diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt b/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
> > index 051f764..f055515 100644
> > --- a/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
> > +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
> > @@ -15,6 +15,10 @@ Optional properties:
> > - clock-latency: Specify the possible maximum transition latency for clock,
> > in unit of nanoseconds.
> > - voltage-tolerance: Specify the CPU voltage tolerance in percentage.
> > +- #cooling-cells:
> > +- cooling-min-level:
> > +- cooling-max-level:
> > + Please refer to Documentation/devicetree/bindings/thermal/thermal.txt.
> >
> > Examples:
> >
> > @@ -33,6 +37,9 @@ cpus {
> > 198000 850000
> > >;
> > clock-latency = <61036>; /* two CLK32 periods */
> > + #cooling-cells = <2>;
> > + cooling-min-level = <0>;
> > + cooling-max-level = <2>;
> > };
> >
> > cpu@1 {
> > diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig
> > index 534fcb8..fc1e9a5 100644
> > --- a/drivers/cpufreq/Kconfig
> > +++ b/drivers/cpufreq/Kconfig
> > @@ -186,7 +186,7 @@ config CPU_FREQ_GOV_CONSERVATIVE
> >
> > config GENERIC_CPUFREQ_CPU0
> > tristate "Generic CPU0 cpufreq driver"
> > - depends on HAVE_CLK && REGULATOR && PM_OPP && OF
> > + depends on HAVE_CLK && REGULATOR && PM_OPP && OF && THERMAL && CPU_THERMAL
> > select CPU_FREQ_TABLE
> > help
> > This adds a generic cpufreq driver for CPU0 frequency management.
> > diff --git a/drivers/cpufreq/cpufreq-cpu0.c b/drivers/cpufreq/cpufreq-cpu0.c
> > index c522a95..568aaf3 100644
> > --- a/drivers/cpufreq/cpufreq-cpu0.c
> > +++ b/drivers/cpufreq/cpufreq-cpu0.c
> > @@ -13,7 +13,9 @@
> >
> > #include <linux/clk.h>
> > #include <linux/cpu.h>
> > +#include <linux/cpu_cooling.h>
> > #include <linux/cpufreq.h>
> > +#include <linux/cpumask.h>
> > #include <linux/err.h>
> > #include <linux/module.h>
> > #include <linux/of.h>
> > @@ -21,6 +23,7 @@
> > #include <linux/platform_device.h>
> > #include <linux/regulator/consumer.h>
> > #include <linux/slab.h>
> > +#include <linux/thermal.h>
> >
> > static unsigned int transition_latency;
> > static unsigned int voltage_tolerance; /* in percentage */
> > @@ -29,6 +32,7 @@ static struct device *cpu_dev;
> > static struct clk *cpu_clk;
> > static struct regulator *cpu_reg;
> > static struct cpufreq_frequency_table *freq_table;
> > +static struct thermal_cooling_device *cdev;
> >
> > static int cpu0_verify_speed(struct cpufreq_policy *policy)
> > {
> > @@ -260,6 +264,17 @@ static int cpu0_cpufreq_probe(struct platform_device *pdev)
> > goto out_free_table;
> > }
> >
> > + /*
> > + * For now, just loading the cooling device;
> > + * thermal DT code takes care of matching them.
> > + */
> > + if (of_find_property(np, "#cooling-cells", NULL)) {
> > + cdev = of_cpufreq_cooling_register(np, cpu_present_mask);
> > + if (IS_ERR(cdev))
> > + pr_err("running cpufreq without cooling device: %ld\n",
> > + PTR_ERR(cdev));
> > + }
> > +
> > of_node_put(np);
> > return 0;
> >
> > @@ -272,6 +287,7 @@ out_put_node:
> >
> > static int cpu0_cpufreq_remove(struct platform_device *pdev)
> > {
> > + cpufreq_cooling_unregister(cdev);
> > cpufreq_unregister_driver(&cpu0_cpufreq_driver);
> > opp_free_cpufreq_table(cpu_dev, &freq_table);
> >
> >
>
>
>
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
^ permalink raw reply
* Re: [PATCH net v2 1/2] macvlan: introduce macvlan_dev_real_dev() helper function
From: David Miller @ 2013-11-14 22:03 UTC (permalink / raw)
To: mkubecek; +Cc: vyasevich, netdev, kaber, john.r.fastabend
In-Reply-To: <20131114155756.GA4161@lion.mk-sys.cz>
From: Michal Kubecek <mkubecek@suse.cz>
Date: Thu, 14 Nov 2013 16:57:57 +0100
> On Thu, Nov 14, 2013 at 10:03:19AM -0500, Vlad Yasevich wrote:
>> On 11/14/2013 09:00 AM, Michal Kubecek wrote:
>> >+#if IS_ENABLED(CONFIG_MACVLAN)
>> >+static inline struct net_device *
>> >+macvlan_dev_real_dev(const struct net_device *dev)
>> >+{
>> >+ struct macvlan_dev *macvlan = netdev_priv(dev);
>> >+
>> >+ return macvlan->lowerdev;
>> >+}
>> >+#else
>> >+static inline struct net_device *
>> >+macvlan_dev_real_dev(const struct net_device *dev)
>> >+{
>> >+ return NULL;
>> >+}
>> >+#endif
>> >+
>>
>> You may want to do the same here as was done for
>> vlan_dev_real_dev(). This function is not intended to be called
>> blindly and should always
>> be called after netif_is_macvlan().
>
> I'm not sure. It makes sense from the developer point of view: if we
> find an inconsistency which must be caused by a bug in kernel code, do
> panic so that the bug is found and fixed as soon as possible. However,
> I remember a discussion where the point was that BUG() and BUG_ON()
> should only be used if there is no way to recover. From this point of
> view, WARN or WARN_ONCE might be better choice - but I'm not strictly
> opposed to BUG().
At least for the time being use BUG(), to be consistent with the same
way how VLAN handles this situation.
Thanks.
^ permalink raw reply
* Re: [RFC PATCH] cpufreq: cpufreq-cpu0: do not allow transitions with regulators suspended
From: Rafael J. Wysocki @ 2013-11-14 22:00 UTC (permalink / raw)
To: viresh kumar
Cc: Nishanth Menon, cpufreq@vger.kernel.org, linux-pm@vger.kernel.org,
Linux Kernel Mailing List, Shawn Guo
In-Reply-To: <52842671.40703@linaro.org>
On Thursday, November 14, 2013 06:55:05 AM viresh kumar wrote:
> On Wednesday 13 November 2013 08:46 PM, Nishanth Menon wrote:
> > arrgh, my bad.. Apologies for the bad one.. I missed it :( Does the following
> > look equivalent?
>
> yes.
>
> > With this, I now see:
>
> > [ 43.212714] cpufreq: cpufreq_add_policy_cpu: Failed to stop governor
> > ^^^ ??
>
> Ahh, I missed this part. I thought it will fail at some other place where there
> is no error checking :), but that's not true.
>
> Following should fix it for you and looks to be the right way as well.
>
>
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index dc67fa0..30b09d3 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -1530,6 +1530,14 @@ static void cpufreq_bp_resume(void)
> }
> }
>
> + if (has_target()) {
> + if ((ret = __cpufreq_governor(policy, CPUFREQ_GOV_START)) ||
> + (ret = __cpufreq_governor(policy, CPUFREQ_GOV_LIMITS))) {
I'm not going to apply anything like this. If I have already, that's been a mistake.
Do not mix assignments with logical operators in such outrageous ways, please.
That's completely unreadable and confusing.
What about:
ret = __cpufreq_governor(policy, CPUFREQ_GOV_START);
if (!ret) {
ret = __cpufreq_governor(policy, CPUFREQ_GOV_LIMITS);
if (ret) {
> + pr_err("%s: Failed to start governor\n", __func__);
> + goto fail;
> + }
> + }
> +
> schedule_work(&policy->update);
>
> fail:
Thanks!
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
^ permalink raw reply
* Re: passing through SMBus
From: Andrew Cooper @ 2013-11-14 21:59 UTC (permalink / raw)
To: Shailesh Kumar, xen-devel@lists.xen.org
In-Reply-To: <CACY1rB41NHNGVVLQJytpcZZ6XTYZEhjo5D3P6sj6O-o=kC6ekA@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 1431 bytes --]
On 14/11/2013 19:30, Shailesh Kumar wrote:
> I am looking for passingthrough the SMBus to the guest.
>
>
Please do not drop xen-devel from the CC line, and please do not top-post.
Passing though the host SMBus to a VM is almost certainly going to cause
issues. dom0 will likely be using bits and pieces on the SMBus itself.
How are you trying to connect to your windows VM ?
~Andrew
> On Thu, Nov 14, 2013 at 2:55 AM, Andrew Cooper
> <andrew.cooper3@citrix.com <mailto:andrew.cooper3@citrix.com>> wrote:
>
> On 14/11/13 03:03, Shailesh Kumar wrote:
>> Hi All,
>>
>> I have a windows 7 as my domU and some windows based drivers are
>> not fully functional (like: touchpad-driver etc ) because they
>> are SMBus based. I was looking at a way to passthrough the SMBus
>> at 00:1f.03 on south bridge ( 00:1f.0), I was debugging at
>> pt-graphics.c and understand that it is detecting the south
>> bridge and passing it through but the other functions for the
>> same dev-id are not getting passed through. Seeking help if
>> someone can help me to get the function '3' also pass through.
>>
>> I am using Xen-4.2.0 and dom-0 linux kernel is 3.9.4. My dom-0 is
>> Fedora-17-64bit based.
>>
>> thanks
>> tsk
>
> Do you mean that you are looking to pass through the host SMBus to
> a guest, or that you are looking for qemu to emulate an SMBus?
>
> ~Andrew
>
>
[-- Attachment #1.2: Type: text/html, Size: 3611 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply
* Re: [PATCH net 3/3] sit/gre6: don't try to add the same route two times
From: David Miller @ 2013-11-14 21:59 UTC (permalink / raw)
To: nicolas.dichtel; +Cc: netdev
In-Reply-To: <1384433467-4780-3-git-send-email-nicolas.dichtel@6wind.com>
From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date: Thu, 14 Nov 2013 13:51:07 +0100
> addrconf_add_linklocal() already adds the link local route, so there is no
> reason to add it before calling this function.
>
> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Applied.
^ permalink raw reply
* Re: [PATCH net 2/3] sit: link local routes are missing
From: David Miller @ 2013-11-14 21:59 UTC (permalink / raw)
To: nicolas.dichtel; +Cc: netdev
In-Reply-To: <1384433467-4780-2-git-send-email-nicolas.dichtel@6wind.com>
From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date: Thu, 14 Nov 2013 13:51:06 +0100
> When a link local address was added to a sit interface, the corresponding route
> was not configured. This breaks routing protocols that use the link local
> address, like OSPFv3.
>
> To ease the code reading, I remove sit_route_add(), which only adds v4 mapped
> routes, and add this kind of route directly in sit_add_v4_addrs(). Thus link
> local and v4 mapped routes are configured in the same place.
>
> Reported-by: Li Hongjun <hongjun.li@6wind.com>
> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Applied.
^ permalink raw reply
* Re: [PATCH net 1/3] sit: fix prefix length of ll and v4mapped addresses
From: David Miller @ 2013-11-14 21:59 UTC (permalink / raw)
To: nicolas.dichtel; +Cc: netdev
In-Reply-To: <1384433467-4780-1-git-send-email-nicolas.dichtel@6wind.com>
From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date: Thu, 14 Nov 2013 13:51:05 +0100
> When the local IPv4 endpoint is wilcard (0.0.0.0), the prefix length is
> correctly set, ie 64 if the address is a link local one or 96 if the address is
> a v4 mapped one.
> But when the local endpoint is specified, the prefix length is set to 128 for
> both kind of address. This patch fix this wrong prefix length.
>
> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Applied.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.