Re: ACPI vs Device Tree - moving forward
On 08/23/2013 09:51 PM, Matthew Garrett wrote: On Fri, Aug 23, 2013 at 09:45:10PM -0700, Guenter Roeck wrote: "What happens when you have an ACPI device that contains an interrupt in _CRS and contains a different interrupt in an embedded FDT block?" Does the situation occur today, ie does it ever happen that one interrupt for a device is specified (if that is the correct term) in _CRS and another by some other means ? The only case I can think of is PCI, where we ignored the ACPI-provided resources until fairly recently. That was a somewhat reasonable thing to do, since the hardware still had to support pre-ACPI operating systems and so the non-ACPI information sources were typically correct. Other than that, I think we always trust the ACPI data. Seems to me you answered your question. It should be possible to do the same if you replace (ACPI, BIOS) with (ACPI, FDT). Plus, hopefully there should be no reason to specify data in FDT that is already provided through ACPI. If it is specified anyway, its handling is a matter of policy. Guenter -- 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] i2c-designware: make *CNT values configurable
On 8/21/13 11:39 PM, Christian Ruppert wrote: On Fri, Aug 16, 2013 at 11:15:12AM +0900, Shinya Kuribayashi wrote: On 8/5/13 6:31 PM, Christian Ruppert wrote: On Wed, Jul 24, 2013 at 11:31:44PM +0900, Shinya Kuribayashi wrote: As said before, all t_SCL things should go away. Please forget about 100kbps, 400kbps, and so on. Bus/clock speed is totally pointless concept for the I2C bus systems. For example, as long as tr/tf, tHIGH/tLOW, tHD;STA, etc. are met by _all_ devices in a certain I2C bus, it doesn't matter that the resulting clock speed is, say 120 kbps with Standard-mode, or even 800 kbps for Fast-mode. Nobody in the I2C bus doesn't care about actual bus/clock speed. We don't have to care about the resulting bus speed, or rather we should/must not check to see if it's within the proper range. Actually, the I2C specification clearly defines f_SCL;max (and thus implies t_SCL;min), both in the tables and the timing diagrams. Why can we ignore this constraint while having to meet all the others? If we meet t_r, t_f, t_HIGH, t_LOW (and t_HIGH in this DW case), f_SCL;max will be met by itself. I'm not sure if I agree with this: Standard mode: t_r;min 0ns t_f;min +0ns t_HIGH;min + 4000ns t_LOW;min + 4700ns 1/f_SCL = 8700ns ==> f_SCL = 115kHz==>violation of f_SCL;max=100kHz Fast mode (let's assume V_DD = 5.5V): t_r;min 20ns t_f;min + 20ns t_HIGH;min + 600ns t_LIW;min + 1300ns 1/f_SCL = 1940ns ==> f_SCL = 515kHz==>violation of f_SCL;max=400kHz It's more realistic to calculate with say 50ns < tr,tf < 300ns, than with tt = tf = 0ns or <20ns. Even if with such real tf/tr times, there is cases where f_SCL can be greater than 100/400Hz. I understand what you mean, but that was not my point. See below. And again, all I2C master and slave devices in the bus don't care about f_SCL; what they do care are t_f, t_r, t_HIGH, t_LOW, and so on. That's why I'm saying f_SCL is pointless and has no value for HCNT/LCNT calculations. I partially agree: If I2C devices don't care about f_SCL but only about t_r, t_f, t_HIGH and t_LOW there's no need to respect the f_SCL;max constraint. If this is the case, I'm wondering why it is part of the specification, though. With t_r;max and t_f;max, Standard mode: t_r;max 1000ns (max time applied) t_f;max + 300ns (max time applied) t_HIGH;min + 4000ns t_LOW;min + 4700ns 1/f_SCL =1ns ==> f_SCL = 100kHz==> f_SCL;max for Standard-mode Fast mode: t_r;max300ns (max time applied) t_f;max + 300ns (max time applied) t_HIGH;min + 600ns t_LIW;min + 1300ns 1/f_SCL = 2500ns ==> f_SCL = 400kHz==> f_SCL;max for Fast-mode f_SCL;max is defined as a resulting clock frequency with the combination of: (1) the max. conditions of t_r and t_f (2) the min. conditions of t_HIGH and t_LOW We can try to meet t_HIGH;min and t_LOW;min, but we can't meet t_r;min nor t_f;min in the actual systems. The t_r and t_f are _minimum requisites_ for the I/O buffer characteristic of the master and the board designs, hence necessarily contain some time margin. f_SCL is anything more than the resulting speed of (1) + (2), so I don't think we need to adjust HCNT/LCNT values at all. If with t_r < t_r;max and t_f < t_f;max, and you've got a faster clock speed than f_SCL;max, then it's a bonus and we can accept it gratefully. I'd make a compromise proposal; it's fine to make sure whether the resulting f_SCL is within a supported range, but should not make a correction of HCNT/LCNT values. Just report warning messages that some parameters/calculations might be mis-configured an/or wrong. Not sure if this is a good idea: If f_SCL is met by design I'm perfectly happy with dropping the t_HIGH/t_LOW adjustment code, no need to bloat the kernel with confusing warnings. If f_SCL is not automatically met we must either make sure t_HIGH/t_LOW are adjusted or we must take the decision to ignore that constraint and document the reasons behind that decision accordingly. I tried to write my thought down, not sure well-explained, though. Notes: * As long as tHD;SDA issue remains in the DW I2C core, we need to have t_HIGH with a relatively lager value than necessary. In such a case, the resulting f_SCL can never exceed f_SCL;max. * I also wonder which values do you think should be adjusted to meet f_SCL;max, HCNT or LCNT, and why is that? I think it's hard to explain, isn't it? Shinya -- 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: ACPI vs Device Tree - moving forward
On Fri, Aug 23, 2013 at 09:45:10PM -0700, Guenter Roeck wrote: > "What happens when you have an ACPI device that contains an interrupt in > _CRS and contains a different interrupt in an embedded FDT block?" > > Does the situation occur today, ie does it ever happen that one interrupt > for a device is specified (if that is the correct term) in _CRS and > another by some other means ? The only case I can think of is PCI, where we ignored the ACPI-provided resources until fairly recently. That was a somewhat reasonable thing to do, since the hardware still had to support pre-ACPI operating systems and so the non-ACPI information sources were typically correct. Other than that, I think we always trust the ACPI data. -- Matthew Garrett | mj...@srcf.ucam.org -- 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: ACPI vs Device Tree - moving forward
On 08/23/2013 08:06 PM, Matthew Garrett wrote: On Fri, Aug 23, 2013 at 07:55:31PM -0700, Guenter Roeck wrote: Question is: Does this work _today_ with any existing driver, where one interrupt is served through ACPI and another as 'standard' Linux interrupt ? If yes, it must be working, and using fdt to describe the interrupt mapping for the non-ACPI interrupt should not make a difference. If no, the problem does not really have anything to do with fdt. There's no such thing as an ACPI interrupt, it's just a data source in the same way that PnP used to be. _CRS refers to platform interrupts. Ah, you are catching my lack of ACPI knowledge. Rephrasing the question: "What happens when you have an ACPI device that contains an interrupt in _CRS and contains a different interrupt in an embedded FDT block?" Does the situation occur today, ie does it ever happen that one interrupt for a device is specified (if that is the correct term) in _CRS and another by some other means ? Guenter -- 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 00/16] cpufreq: create & use cpufreq_generic_get() routine
On 24 August 2013 01:10, Rafael J. Wysocki wrote: > On Friday, August 23, 2013 09:20:35 PM Viresh Kumar wrote: >> CPUFreq drivers that use clock frameworks interface,i.e. clk_get_rate(), to >> get >> CPUs clk rate, has similar sort of code used for most of them. >> >> This patchset adds a generic ->get() which will do the same thing for them. >> All >> those drivers are required to now is to set .get to cpufreq_generic_get() and >> set their clk pointer in policy->clk during ->init(). >> >> Later part of this patchset fixes 17 drivers with this change. >> >> That's part 7 of my generic cleanups for CPUFreq core, first six are here: > > And that's the last one for 3.13, right? 3.13 is too far, can't promise that really :) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] pinctrl: mvebu: add missing iounmap
Hi Linus and Ezequiel, On Fri, 23 Aug 2013 13:19:26 -0700 Ezequiel Garcia wrote: > On Fri, Aug 23, 2013 at 08:06:02PM +0200, Linus Walleij wrote: > > On Thu, Aug 22, 2013 at 3:22 PM, Ezequiel Garcia > > wrote: > > > On Thu, Aug 22, 2013 at 08:46:51PM +0800, Jisheng Zhang wrote: > > >> Add missing iounmap to prove error path and remove path > > >> > > >> Signed-off-by: Jisheng Zhang > > >> --- > > >> drivers/pinctrl/mvebu/pinctrl-mvebu.c | 24 +--- > > >> 1 file changed, 17 insertions(+), 7 deletions(-) > > > > > > How about using devm_ioremap_resource() instead? > > > > Yeah that's the right solution, Jisheng can you fix this? > > > > I think he already did that, there's a v2 floating around > with such change. I plan to give it a test, maybe tomorrow, > if I can find some spare time. > Yep. Here is the V2 http://lists.infradead.org/pipermail/linux-arm-kernel/2013-August/194072.html Thank you for your help, Jisheng -- 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 3/4] clk: mvebu: add missing iounmap
Hi Mike, On Fri, 23 Aug 2013 14:29:50 -0700 Mike Turquette wrote: > Quoting Jisheng Zhang (2013-08-22 19:34:01) > > Add missing iounmap to setup error path. > > > > Change-Id: I4371569d14d7026aa9f90d7cd53f669d365fe26a > > Please remove Change-Id's from the commit message for upstream patch > submissions in the future. I can remove this one, this time. > > I've taken the patch into clk-next. > Thanks for kindly reminding. I'll take care of this in the future. Best Regards, Jisheng -- 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: ACPI vs Device Tree - moving forward
On Fri, Aug 23, 2013 at 07:55:31PM -0700, Guenter Roeck wrote: > Question is: Does this work _today_ with any existing driver, where > one interrupt is served through ACPI and another as 'standard' Linux > interrupt ? If yes, it must be working, and using fdt to describe > the interrupt mapping for the non-ACPI interrupt should not make > a difference. If no, the problem does not really have anything > to do with fdt. There's no such thing as an ACPI interrupt, it's just a data source in the same way that PnP used to be. _CRS refers to platform interrupts. -- Matthew Garrett | mj...@srcf.ucam.org -- 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: ACPI vs Device Tree - moving forward
On 08/23/2013 07:38 PM, Matthew Garrett wrote: On Fri, Aug 23, 2013 at 06:47:23PM -0700, Guenter Roeck wrote: On Sat, Aug 24, 2013 at 02:10:36AM +0100, Matthew Garrett wrote: On Fri, Aug 23, 2013 at 05:13:45PM -0700, Guenter Roeck wrote: Did the group conclude that the idea of FDT augmenting ACPI is not feasible ? I think expressing FDT in ACPI is feasible, I'm just not sure it's desirable. We'd still end up with duplicate information and no mechanism for drivers to handle both. Not sure I understand what you are saying. My understanding of "augment" would be that there is ACPI information, and there is a separate FDT (or an FDT overlay) providing additional information. There should be no duplicate information in this model. What happens when you have an ACPI device that contains an interrupt in _CRS and contains a different interrupt in an embedded FDT block? Question is: Does this work _today_ with any existing driver, where one interrupt is served through ACPI and another as 'standard' Linux interrupt ? If yes, it must be working, and using fdt to describe the interrupt mapping for the non-ACPI interrupt should not make a difference. If no, the problem does not really have anything to do with fdt. Guenter -- 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 0/8] x86, acpi: Move acpi_initrd_override() earlier.
On Fri, Aug 23, 2013 at 01:08:56PM -0700, Yinghai Lu wrote: > On Fri, Aug 23, 2013 at 11:25 AM, H. Peter Anvin wrote: > > > > BRK makes sense as long as you can set a sane O(1) size limit. > > > >> > >>put the acpi override table in BRK, we still need ok from HPA. > >>I have impression that he did not like it, so want to confirm from him. > > on 8 sockets system: > -rw-r--r-- 1 root root 3532 Aug 22 10:26 APIC.dat > -rw-r--r-- 1 root root 48 Aug 22 10:26 BDAT.dat > -rw-r--r-- 1 root root824 Aug 22 10:26 DMAR.dat > -rw-r--r-- 1 root root 83509 Aug 22 10:26 DSDT.dat > -rw-r--r-- 1 root root244 Aug 22 10:26 FACP.dat > -rw-r--r-- 1 root root 64 Aug 22 10:26 FACS.dat > -rw-r--r-- 1 root root 68 Aug 22 10:26 FPDT.dat > -rw-r--r-- 1 root root 56 Aug 22 10:26 HPET.dat > -rw-r--r-- 1 root root304 Aug 22 10:26 MCEJ.dat > -rw-r--r-- 1 root root 60 Aug 22 10:26 MCFG.dat > -rw-r--r-- 1 root root 6712 Aug 22 10:26 MPST.dat > -rw-r--r-- 1 root root232 Aug 22 10:26 MSCT.dat > -rw-r--r-- 1 root root172 Aug 22 10:26 PCCT.dat > -rw-r--r-- 1 root root 96 Aug 22 10:26 PMCT.dat > -rw-r--r-- 1 root root 48 Aug 22 10:26 RASF.dat > -rw-r--r-- 1 root root108 Aug 22 10:26 SLIT.dat > -rw-r--r-- 1 root root 80 Aug 22 10:26 SPCR.dat > -rw-r--r-- 1 root root 65 Aug 22 10:26 SPMI.dat > -rw-r--r-- 1 root root 6448 Aug 22 10:26 SRAT.dat > -rw-r--r-- 1 root root100 Aug 22 10:26 SSDT1.dat > -rw-r--r-- 1 root root 283527 Aug 22 10:26 SSDT2.dat > -rw-r--r-- 1 root root 66 Aug 22 10:26 UEFI.dat > -rw-r--r-- 1 root root 64 Aug 22 10:26 WDDT.dat > > assume for 32sockets will have four times bigger with DSDT and SSDT. > (with more pci and cpus) > > So we can not have O(1) the size. > > Russ, What is ACPI table size on your big machine? This is from a 255 socket, 4080 cpu, 15TB system. --- -rw-r--r-- 1 root root 65392 Aug 23 21:23 apic.dat -rw-r--r-- 1 root root 316 Aug 23 21:23 dmar.dat -rw-r--r-- 1 root root 8309249 Aug 23 21:23 dsdt.dat -rw-r--r-- 1 root root 244 Aug 23 21:23 facp.dat -rw-r--r-- 1 root root 64 Aug 23 21:23 facs.dat -rw-r--r-- 1 root root 56 Aug 23 21:23 hpet.dat -rw-r--r-- 1 root root4172 Aug 23 21:23 mcfg.dat -rw-r--r-- 1 root root 36 Aug 23 21:23 rsdp.dat -rw-r--r-- 1 root root 80 Aug 23 21:23 rsdt.dat -rw-r--r-- 1 root root 65069 Aug 23 21:23 slit.dat -rw-r--r-- 1 root root 80 Aug 23 21:23 spcr.dat -rw-r--r-- 1 root root 108168 Aug 23 21:23 srat.dat -rw-r--r-- 1 root root 21330 Aug 23 21:23 ssdt.dat -rw-r--r-- 1 root root 92 Aug 23 21:23 uefi1.dat -rw-r--r-- 1 root root 298 Aug 23 21:23 uefi.dat -rw-r--r-- 1 root root 124 Aug 23 21:23 xsdt.dat --- -- Russ Anderson, OS RAS/Partitioning Project Lead SGI - Silicon Graphics Inc r...@sgi.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: ACPI vs Device Tree - moving forward
On Fri, Aug 23, 2013 at 06:47:23PM -0700, Guenter Roeck wrote: > On Sat, Aug 24, 2013 at 02:10:36AM +0100, Matthew Garrett wrote: > > On Fri, Aug 23, 2013 at 05:13:45PM -0700, Guenter Roeck wrote: > > > > > Did the group conclude that the idea of FDT augmenting ACPI is not > > > feasible ? > > > > I think expressing FDT in ACPI is feasible, I'm just not sure it's > > desirable. We'd still end up with duplicate information and no mechanism > > for drivers to handle both. > > > Not sure I understand what you are saying. My understanding of "augment" > would be that there is ACPI information, and there is a separate FDT > (or an FDT overlay) providing additional information. There should be > no duplicate information in this model. What happens when you have an ACPI device that contains an interrupt in _CRS and contains a different interrupt in an embedded FDT block? -- Matthew Garrett | mj...@srcf.ucam.org -- 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] bq24190_charger: Add support for TI BQ24190 Battery Charger
Add driver support for the Texas Instruments BQ24190 battery charger. Some of the information provided by the device is about the charger and other information is about the battery so create two power_supply objects (one for each) and provide the appropriate information for each one. The device has many fields that go beyond what is reasonable to report or modify using the existing 'POWER_SUPPLY_PROP_*' properties so the driver exports the register fields via sysfs. They are prefixed by 'f_' (for 'field') to make it easier to distinguish between a register field and a "normal" sysfs file exported by the power_supply infrastructure. Signed-off-by: Mark A. Greer --- - Tested on an ARM 3703-based platform which hasn't been submitted to the community yet. - Patch tested on k.o 89b53e5 (Merge branch 'for-3.11-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata) plus patches for platform mentioned above. - Information on the device is available here: http://www.ti.com/product/bq24190?DCMP=hpa-pmp-battery-bq2419x-en=bq24190-pr - Change from v1: - 'first_time' is now per-device - The OF irq code changed to use irq_of_parse_and_map() - Unnecessary goto's removed - Now builds and works when CONFIG_SYSFS is not defined - When removing driver, the registers are reset instead of just turning default mode back on drivers/power/Kconfig |6 + drivers/power/Makefile|1 + drivers/power/bq24190_charger.c | 1548 + include/linux/power/bq24190_charger.h | 16 + 4 files changed, 1571 insertions(+) create mode 100644 drivers/power/bq24190_charger.c create mode 100644 include/linux/power/bq24190_charger.h diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig index 7b8979c..c31ec0a 100644 --- a/drivers/power/Kconfig +++ b/drivers/power/Kconfig @@ -334,6 +334,12 @@ config CHARGER_BQ2415X You'll need this driver to charge batteries on e.g. Nokia RX-51/N900. +config CHARGER_BQ24190 + tristate "TI BQ24190 battery charger driver" + depends on I2C && GPIOLIB + help + Say Y to enable support for the TI BQ24190 battery charger. + config CHARGER_SMB347 tristate "Summit Microelectronics SMB347 Battery Charger" depends on I2C diff --git a/drivers/power/Makefile b/drivers/power/Makefile index 653bf6c..4ae4533 100644 --- a/drivers/power/Makefile +++ b/drivers/power/Makefile @@ -50,6 +50,7 @@ obj-$(CONFIG_CHARGER_MANAGER) += charger-manager.o obj-$(CONFIG_CHARGER_MAX8997) += max8997_charger.o obj-$(CONFIG_CHARGER_MAX8998) += max8998_charger.o obj-$(CONFIG_CHARGER_BQ2415X) += bq2415x_charger.o +obj-$(CONFIG_CHARGER_BQ24190) += bq24190_charger.o obj-$(CONFIG_POWER_AVS)+= avs/ obj-$(CONFIG_CHARGER_SMB347) += smb347-charger.o obj-$(CONFIG_CHARGER_TPS65090) += tps65090-charger.o diff --git a/drivers/power/bq24190_charger.c b/drivers/power/bq24190_charger.c new file mode 100644 index 000..5619786 --- /dev/null +++ b/drivers/power/bq24190_charger.c @@ -0,0 +1,1548 @@ +/* + * Driver for the TI bq24190 battery charger. + * + * Author: Mark A. Greer + * + * 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 +#include +#include +#include +#include +#include +#include +#include +#include + +#include + + +#defineBQ24190_MANUFACTURER"Texas Instruments" + +#define BQ24190_REG_ISC0x00 /* Input Source Control */ +#define BQ24190_REG_ISC_EN_HIZ_MASKBIT(7) +#define BQ24190_REG_ISC_EN_HIZ_SHIFT 7 +#define BQ24190_REG_ISC_VINDPM_MASK(BIT(6) | BIT(5) | BIT(4) | \ +BIT(3)) +#define BQ24190_REG_ISC_VINDPM_SHIFT 3 +#define BQ24190_REG_ISC_IINLIM_MASK(BIT(2) | BIT(1) | BIT(0)) +#define BQ24190_REG_ISC_IINLIM_SHIFT 0 + +#define BQ24190_REG_POC0x01 /* Power-On Configuration */ +#define BQ24190_REG_POC_RESET_MASK BIT(7) +#define BQ24190_REG_POC_RESET_SHIFT7 +#define BQ24190_REG_POC_WDT_RESET_MASK BIT(6) +#define BQ24190_REG_POC_WDT_RESET_SHIFT6 +#define BQ24190_REG_POC_CHG_CONFIG_MASK(BIT(5) | BIT(4)) +#define BQ24190_REG_POC_CHG_CONFIG_SHIFT 4 +#define BQ24190_REG_POC_SYS_MIN_MASK (BIT(3) | BIT(2) | BIT(1)) +#define BQ24190_REG_POC_SYS_MIN_SHIFT 1 +#define BQ24190_REG_POC_BOOST_LIM_MASK BIT(0) +#define BQ24190_REG_POC_BOOST_LIM_SHIFT0 + +#define BQ24190_REG_CCC0x02 /* Charge Current Control */ +#define BQ24190_REG_CCC_ICHG_MASK (BIT(7) | BIT(6) | BIT(5) | \ +BIT(4) | BIT(3) | BIT(2)) +#define BQ24190_REG_CCC_ICHG_SHIFT 2
Re: [PATCH] ACPI: Fix osc flag setup ordering to allow pcie hotplug use when available
On Fri, Aug 23, 2013 at 04:04:59PM -0600, Bjorn Helgaas wrote: > On Fri, Aug 23, 2013 at 3:40 PM, Rafael J. Wysocki wrote: > > On Friday, August 23, 2013 02:46:23 PM Bjorn Helgaas wrote: > >> On Fri, Aug 23, 2013 at 2:53 PM, Rafael J. Wysocki wrote: > >> > On Friday, August 23, 2013 04:05:11 PM Neil Horman wrote: > >> >> On Fri, Aug 23, 2013 at 09:38:18PM +0200, Rafael J. Wysocki wrote: > >> >> > [CCs added] > >> >> > > >> >> > Please always send PCI-related material to linux-pci in the first > >> >> > place. > >> >> > > >> >> Sorry, I ran get_maintainers and it seemed to think linux-acpi was > >> >> sufficient. > >> >> > >> >> > The change that broke things for you was actually intentional: > >> >> > > >> >> > commit b8178f130e25c1bdac1c33e0996f1ff6e20ec08e > >> >> > Author: Bjorn Helgaas > >> >> > Date: Mon Apr 1 15:47:39 2013 -0600 > >> >> > > >> >> > Revert "PCI/ACPI: Request _OSC control before scanning PCI root > >> >> > bus" > >> >> > > >> >> > This reverts commit 8c33f51df406e1a1f7fa4e9b244845b7ebd61fa6. > >> >> > > >> >> > so I think we'll need to clean up the ASMP initialization after all. > >> >> > > >> >> Crud. Reading over the revert commit, it seems like the problem boils > >> >> down to > >> >> the odering of checking aspm_disabled. It seems to me that the simple > >> >> fix is to > >> >> track the desire for acpi to disable aspm separately from the users > >> >> desire to > >> >> disable aspm (aspm_disabled). Then we just turn the points where we > >> >> check the > >> >> aspm_disabled into the appropriate or of two variables, except for > >> >> pcie_asmp_sanity_check, which remains sensitive to just the user > >> >> disable option. > >> >> > >> >> Or is there more to this? > >> > > >> > No, I think you're right. > >> > > >> > Bjorn, what do you think? > >> > >> My opinion is that the _OSC/ASPM state management is ridiculously > >> complicated already, and this would make it slightly more complicated. > >> That's why my preference would be to attempt a more radical cleanup > >> and simplification instead of adding another wart. > > > > Well, do you have anything specific in mind? > > If I had a specific fix in mind, I would just post it, but I've never > had time to work through it all. What I mean by complicated is that > every time I have to look at ASPM, I have to start by trying to figure > out the relationships between these variables: > > aspm_policy # default 0 (POLICY_DEFAULT) > or POLICY_PERFORMANCE > or POLICY_POWERSAVE depending on config > aspm_disabled # default 0 > aspm_force # default 0 > aspm_support_enabled# default true > > plus the _OSC-related code in acpi_pci_root_add(), which honestly is a > rat's nest. > I agree, I've only looked at it for an hour, and it looks pretty hairy. > It sounds like Neil's fix (while probably correct) would tangle that > nest a little more. But I guess it would make sense to see the actual No argument, it would add complexity to something thats already very complex. That said, I think this needs to be fixed. Currently there are several systems that are reporting conflicts between ACPI and PCIE hotplug. While that means theres lots of griping, theres several people willing to test, so I think we have an opportunity to fix this. > patch and the justification (a regression fix, I suppose, but the > details weren't clear to me) before deciding. > Agreed. A larger cleanup would be preferable at this point, but I'm not sufficiently versed in the code to do that right now, so I'll try write an appropriate for this particular bug, and see what you think on monday. Regards Neil -- 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: ACPI vs Device Tree - moving forward
On Sat, Aug 24, 2013 at 02:10:36AM +0100, Matthew Garrett wrote: > On Fri, Aug 23, 2013 at 05:13:45PM -0700, Guenter Roeck wrote: > > > Did the group conclude that the idea of FDT augmenting ACPI is not feasible > > ? > > I think expressing FDT in ACPI is feasible, I'm just not sure it's > desirable. We'd still end up with duplicate information and no mechanism > for drivers to handle both. > Not sure I understand what you are saying. My understanding of "augment" would be that there is ACPI information, and there is a separate FDT (or an FDT overlay) providing additional information. There should be no duplicate information in this model. Guenter -- 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: ACPI vs Device Tree - moving forward
On Fri, Aug 23, 2013 at 05:13:45PM -0700, Guenter Roeck wrote: > Did the group conclude that the idea of FDT augmenting ACPI is not feasible ? I think expressing FDT in ACPI is feasible, I'm just not sure it's desirable. We'd still end up with duplicate information and no mechanism for drivers to handle both. -- Matthew Garrett | mj...@srcf.ucam.org -- 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 3/3] gpio: pcf857x: Add OF support
Hi Tomasz,
Thank you for the review.
On Saturday 24 August 2013 02:41:59 Tomasz Figa wrote:
> On Tuesday 20 of August 2013 01:04:54 Laurent Pinchart wrote:
> > Add DT bindings for the pcf857x-compatible chips and parse the device
> > tree node in the driver.
> >
> > Signed-off-by: Laurent Pinchart
> > ---
> >
> > .../devicetree/bindings/gpio/gpio-pcf857x.txt | 71 +
> > drivers/gpio/gpio-pcf857x.c| 57 ++---
> > 2 files changed, 119 insertions(+), 9 deletions(-)
> >
> > create mode 100644
> >
> > Documentation/devicetree/bindings/gpio/gpio-pcf857x.txt
> >
> > diff --git a/Documentation/devicetree/bindings/gpio/gpio-pcf857x.txt
> > b/Documentation/devicetree/bindings/gpio/gpio-pcf857x.txt new file mode
> > 100644
> > index 000..df94462
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/gpio/gpio-pcf857x.txt
> > @@ -0,0 +1,71 @@
[snip]
> > + - pins-initial-state: Bitmask that specifies the initial state of
> > +each pin. When a bit is set to zero, the corresponding pin will be
> > +initialized to the input (pulled-up) state. When the bit is set to
> > +one, the pin will be initialized the the low-level output state. If
> > +the property is not specified all pins will be initialized to the
> > +input state.
>
> Hmm, do you actually need to know whether those pins are outputs or inputs
> before they get used for first time? I believe any driver using GPIO will
> call gpio_direction_{in,out}put() before it starts using the pin, which
> will initialize the pin to a known state.
>
> What I'd suggest is making the driver handle this by having a bit mask
> that marks states of pins as defined and flagging all pins as undefined by
> default. Then any call to gpio_direction_output() or _input() would mark
> it as defined and direction of the pin could be stored in internal driver
> structures.
The problem is that all pins are controlled through a single I2C write.
Setting the direction of a pin will set the direction of all other pins. I
thus need to know what the initial settings are to avoid glitches.
> > + The I/O expander can detect input state changes, and thus optionally
> > + act as an interrupt controller. When interrupts support is desired
>
> I don't like this statement. Device tree should represent what the device
> allows you to do, not what you want the device to do.
>
> My opinion on this is that if the chip supports interrupts then it should
> always be an interrupt-controller (unless its interrupt pin is not wired
> on the board, but this still conforms to what I wrote above).
I agree. What about the following text then ?
The I/O expander can detect input state changes, and thus optionally act as an
interrupt controller. When the expander interrupt pin is connected all the
following properties must be set. For more information please see the
interrupt controller device tree bindings documentation available at
Documentation/devicetree/bindings/interrupt-controller/interrupts.txt.
> > diff --git a/drivers/gpio/gpio-pcf857x.c b/drivers/gpio/gpio-pcf857x.c
> > index 070e81f..50a90f1 100644
> > --- a/drivers/gpio/gpio-pcf857x.c
> > +++ b/drivers/gpio/gpio-pcf857x.c
[snip]
> > @@ -50,6 +52,27 @@ static const struct i2c_device_id pcf857x_id[] = {
> > };
> > MODULE_DEVICE_TABLE(i2c, pcf857x_id);
> >
> > +#ifdef CONFIG_OF
> > +static const struct of_device_id pcf857x_of_table[] = {
> > + { .compatible = "nxp,pcf8574", .data = (void *)8 },
> > + { .compatible = "nxp,pcf8574a", .data = (void *)8 },
> > + { .compatible = "nxp,pca8574", .data = (void *)8 },
> > + { .compatible = "nxp,pca9670", .data = (void *)8 },
> > + { .compatible = "nxp,pca9672", .data = (void *)8 },
> > + { .compatible = "nxp,pca9674", .data = (void *)8 },
> > + { .compatible = "nxp,pcf8575", .data = (void *)16 },
> > + { .compatible = "nxp,pca8575", .data = (void *)16 },
> > + { .compatible = "nxp,pca9671", .data = (void *)16 },
> > + { .compatible = "nxp,pca9673", .data = (void *)16 },
> > + { .compatible = "nxp,pca9675", .data = (void *)16 },
> > + { .compatible = "maxim,max7328", .data = (void *)8 },
> > + { .compatible = "maxim,max7329", .data = (void *)8 },
> > + { .compatible = "ti,tca9554", .data = (void *)8 },
> > + { }
> > +};
> > +MODULE_DEVICE_TABLE(of, pcf857x_of_table);
> > +#endif
> > +
> > /*
> > * The pcf857x, pca857x, and pca967x chips only expose one read and one
> > * write register. Writing a "one" bit (to match the reset state) lets
> > @@ -257,14 +280,29 @@ fail:
> > static int pcf857x_probe(struct i2c_client *client,
> > const struct i2c_device_id *id)
> > {
> > - struct pcf857x_platform_data*pdata;
> > + struct pcf857x_platform_data*pdata = client->dev.platform_data;
> > + struct device_node *np = client->dev.of_node;
> > struct pcf857x *gpio;
> > + unsigned int
Re: [PATCH v4 26/28] PCI, x86, ACPI: Link acpi ioapic register to ioapic
On 8/11/13, Yinghai Lu wrote:
> During ioapic hotplug, acpi_register_ioapic will be called.
> Now for x86, that function is blank.
> Fill that will update __mp_register_ioapic to use those ioapic.
>
> Signed-off-by: Yinghai Lu
> ---
> arch/x86/kernel/acpi/boot.c | 10 ++
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
> index 5be15d1..4a5336d 100644
> --- a/arch/x86/kernel/acpi/boot.c
> +++ b/arch/x86/kernel/acpi/boot.c
> @@ -707,16 +707,18 @@ EXPORT_SYMBOL(acpi_unmap_lsapic);
>
> int acpi_register_ioapic(acpi_handle handle, u64 phys_addr, u32 gsi_base)
> {
> - /* TBD */
> - return -EINVAL;
> + unsigned long long id = 0;
> +
> + acpi_evaluate_integer(handle, "_UID", NULL, );
We cannot assume that "_UID" is an integer. "_UID" can be either an
integer or a string. Need to consider the case when it is a string.
Thanks
Rui
> +
> + return __mp_register_ioapic(id, phys_addr, gsi_base, true);
> }
>
> EXPORT_SYMBOL(acpi_register_ioapic);
>
> int acpi_unregister_ioapic(acpi_handle handle, u32 gsi_base)
> {
> - /* TBD */
> - return -EINVAL;
> + return mp_unregister_ioapic(gsi_base);
> }
>
> EXPORT_SYMBOL(acpi_unregister_ioapic);
> --
> 1.8.1.4
>
> --
> 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/
>
--
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 3/3] gpio: pcf857x: Add OF support
Hi Laurent,
On Tuesday 20 of August 2013 01:04:54 Laurent Pinchart wrote:
> Add DT bindings for the pcf857x-compatible chips and parse the device
> tree node in the driver.
>
> Signed-off-by: Laurent Pinchart
> ---
> .../devicetree/bindings/gpio/gpio-pcf857x.txt | 71
> ++ drivers/gpio/gpio-pcf857x.c
> | 57 ++--- 2 files changed, 119 insertions(+), 9
> deletions(-)
> create mode 100644
> Documentation/devicetree/bindings/gpio/gpio-pcf857x.txt
>
> diff --git a/Documentation/devicetree/bindings/gpio/gpio-pcf857x.txt
> b/Documentation/devicetree/bindings/gpio/gpio-pcf857x.txt new file mode
> 100644
> index 000..df94462
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpio/gpio-pcf857x.txt
> @@ -0,0 +1,71 @@
> +* PCF857x-compatible I/O expanders
> +
> +The PCF857x-compatible chips have "quasi-bidirectional" I/O pins that
> can be +driven high by a pull-up current source or driven low to
> ground. This combines +the direction and output level into a single bit
> per pin, which can't be read +back. We can't actually know at
> initialization time whether a pin is configured +(a) as output and
> driving the signal low/high, or (b) as input and reporting a +low/high
> value, without knowing the last value written since the chip came out
> +of reset (if any). The only reliable solution for setting up pin
> direction is +thus to do it explicitly.
> +
> +Required Properties:
> +
> + - compatible: should be one of the following.
> +- "maxim,max7328": For the Maxim MAX7378
> +- "maxim,max7329": For the Maxim MAX7329
> +- "nxp,pca8574": For the NXP PCA8574
> +- "nxp,pca8575": For the NXP PCA8575
> +- "nxp,pca9670": For the NXP PCA9670
> +- "nxp,pca9671": For the NXP PCA9671
> +- "nxp,pca9672": For the NXP PCA9672
> +- "nxp,pca9673": For the NXP PCA9673
> +- "nxp,pca9674": For the NXP PCA9674
> +- "nxp,pca9675": For the NXP PCA9675
> +- "nxp,pcf8574": For the NXP PCF8574
> +- "nxp,pcf8574a": For the NXP PCF8574A
> +- "nxp,pcf8575": For the NXP PCF8575
> +- "ti,tca9554": For the TI TCA9554
> +
> + - reg: I2C slave address.
> +
> + - gpio-controller: Marks the device node as a gpio controller.
> + - #gpio-cells: Should be 2. The first cell is the GPIO number and the
> second +cell specifies GPIO flags, as defined in
> . Only the +GPIO_ACTIVE_HIGH and
> GPIO_ACTIVE_LOW flags are supported. +
> +Optional Properties:
> +
> + - pins-initial-state: Bitmask that specifies the initial state of
> each pin. + When a bit is set to zero, the corresponding pin will be
> initialized to the + input (pulled-up) state. When the bit is set to
> one, the pin will be + initialized the the low-level output state. If
> the property is not specified + all pins will be initialized to the
> input state.
Hmm, do you actually need to know whether those pins are outputs or inputs
before they get used for first time? I believe any driver using GPIO will
call gpio_direction_{in,out}put() before it starts using the pin, which
will initialize the pin to a known state.
What I'd suggest is making the driver handle this by having a bit mask
that marks states of pins as defined and flagging all pins as undefined by
default. Then any call to gpio_direction_output() or _input() would mark
it as defined and direction of the pin could be stored in internal driver
structures.
> + The I/O expander can detect input state changes, and thus optionally
> act as + an interrupt controller. When interrupts support is desired
I don't like this statement. Device tree should represent what the device
allows you to do, not what you want the device to do.
My opinion on this is that if the chip supports interrupts then it should
always be an interrupt-controller (unless its interrupt pin is not wired
on the board, but this still conforms to what I wrote above).
> all the following + properties must be set. For more information
> please see the interrupt + controller device tree bindings
> documentation available at
> +
> Documentation/devicetree/bindings/interrupt-controller/interrupts.txt.
> +
> + - interrupt-controller: Identifies the node as an interrupt
> controller. + - #interrupt-cells: Number of cells to encode an
> interrupt source, shall be 2. + - interrupt-parent: phandle of the
> parent interrupt controller. + - interrupts: Interrupt specifier for
> the controllers interrupt. +
> +
> +Please refer to gpio.txt in this directory for details of the common
> GPIO +bindings used by client devices.
> +
> +Example: PCF8575 I/O expander node
> +
> + pcf8575: gpio@20 {
> + compatible = "nxp,pcf8575";
> + reg = <0x20>;
> + interrupt-parent = <>;
> + interrupts = <3 0>;
> + gpio-controller;
> + #gpio-cells = <2>;
> + interrupt-controller;
> + #interrupt-cells = <2>;
> + };
> diff --git
[PATCH] workqueue: remove unnecessary goto statement
Using return NULL to replace goto statement and avoiding a redundant function call for free_workqueue_attrs(). If kzalloc for attrs of struct workqueue_attrs is failed, alloc_workqueue_attrs return NULL directedly. With no functional changs. Signed-off-by: Libin --- kernel/workqueue.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/workqueue.c b/kernel/workqueue.c index 7f5d4be..dabeb88 100644 --- a/kernel/workqueue.c +++ b/kernel/workqueue.c @@ -3400,7 +3400,7 @@ struct workqueue_attrs *alloc_workqueue_attrs(gfp_t gfp_mask) attrs = kzalloc(sizeof(*attrs), gfp_mask); if (!attrs) - goto fail; + return NULL; if (!alloc_cpumask_var(>cpumask, gfp_mask)) goto fail; -- 1.8.2.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] Documentation/kmemcheck: update kmemcheck documentation
Kmemcheck configuration menu location correction in Documentation/ kmemcheck.txt Signed-off-by: Libin --- Documentation/kmemcheck.txt | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Documentation/kmemcheck.txt b/Documentation/kmemcheck.txt index c28f828..9398a50 100644 --- a/Documentation/kmemcheck.txt +++ b/Documentation/kmemcheck.txt @@ -91,9 +91,9 @@ information from the kmemcheck warnings, which is extremely valuable in debugging a problem. This option is not mandatory, however, because it slows down the compilation process and produces a much bigger kernel image. -Now the kmemcheck menu should be visible (under "Kernel hacking" / "kmemcheck: -trap use of uninitialized memory"). Here follows a description of the -kmemcheck configuration variables: +Now the kmemcheck menu should be visible (under "Kernel hacking" / "Memory +Debugging" / "kmemcheck: trap use of uninitialized memory"). Here follows +a description of the kmemcheck configuration variables: o CONFIG_KMEMCHECK -- 1.8.2.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/3] cpuidle: coupled: disable interrupts after entering safe state
On Fri, Aug 23, 2013 at 4:09 PM, Stephen Warren wrote: > On 08/23/2013 01:45 PM, Colin Cross wrote: >> Calling cpuidle_enter_state is expected to return with interrupts >> enabled, but interrupts must be disabled before starting the >> ready loop synchronization stage. Call local_irq_disable after >> each call to cpuidle_enter_state for the safe state. > > Tested-by: Stephen Warren > > Note: I tested the current Tegra cpuidle code that's in next-20130819. > IIRC, Joseph reported the issue when trying to enable some additional > feature in Tegra30 cpuidle. I didn't actually try to enable whatever > that was; I just briefly tested for regressions in the existing code > configuration. Is that for the series or just this patch? -- 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: Unusually high system CPU usage with recent kernels
On Fri, Aug 23, 2013 at 03:20:25PM +0200, Tibor Billes wrote:
> > From: Paul E. McKenney Sent: 08/22/13 12:09 AM
> > On Wed, Aug 21, 2013 at 11:05:51PM +0200, Tibor Billes wrote:
> > > > From: Paul E. McKenney Sent: 08/21/13 09:12 PM
> > > > On Wed, Aug 21, 2013 at 08:14:46PM +0200, Tibor Billes wrote:
> > > > > > From: Paul E. McKenney Sent: 08/20/13 11:43 PM
> > > > > > On Tue, Aug 20, 2013 at 10:52:26PM +0200, Tibor Billes wrote:
> > > > > > > > From: Paul E. McKenney Sent: 08/20/13 04:53 PM
> > > > > > > > On Tue, Aug 20, 2013 at 08:01:28AM +0200, Tibor Billes wrote:
> > > > > > > > > Hi,
> > > > > > > > >
> > > > > > > > > I was using the 3.9.7 stable release and tried to upgrade to
> > > > > > > > > the 3.10.x series.
> > > > > > > > > The 3.10.x series was showing unusually high (>75%) system
> > > > > > > > > CPU usage in some
> > > > > > > > > situations, making things really slow. The latest stable I
> > > > > > > > > tried is 3.10.7.
> > > > > > > > > I also tried 3.11-rc5, they both show this behaviour. This
> > > > > > > > > behaviour doesn't
> > > > > > > > > show up when the system is idling, only when doing some CPU
> > > > > > > > > intensive work,
> > > > > > > > > like compiling with multiple threads. Compiling with only one
> > > > > > > > > thread seems not
> > > > > > > > > to trigger this behaviour.
> > > > > > > > >
> > > > > > > > > To be more precise I did a `perf record -a` while compiling a
> > > > > > > > > large C++ program
> > > > > > > > > with scons using 4 threads, the result is appended at the end
> > > > > > > > > of this email.
> > > > > > > >
> > > > > > > > New one on me! You are running a mainstream system (x86_64), so
> > > > > > > > I am
> > > > > > > > surprised no one else noticed.
> > > > > > > >
> > > > > > > > Could you please send along your .config file?
> > > > > > >
> > > > > > > Here it is
> > > > > >
> > > > > > Interesting. I don't see RCU stuff all that high on the list, but
> > > > > > the items I do see lead me to suspect RCU_FAST_NO_HZ, which has some
> > > > > > relevance to the otherwise inexplicable group of commits you located
> > > > > > with your bisection. Could you please rerun with
> > > > > > CONFIG_RCU_FAST_NO_HZ=n?
> > > > > >
> > > > > > If that helps, there are some things I could try.
> > > > >
> > > > > It did help. I didn't notice anything unusual when running with
> > > > > CONFIG_RCU_FAST_NO_HZ=n.
> > > >
> > > > Interesting. Thank you for trying this -- and we at least have a
> > > > short-term workaround for this problem. I will put a patch together
> > > > for further investigation.
> > >
> > > I don't specifically need this config option so I'm fine without it in
> > > the long term, but I guess it's not supposed to behave like that.
> >
> > OK, good, we have a long-term workload for your specific case,
> > even better. ;-)
> >
> > But yes, there are situations where RCU_FAST_NO_HZ needs to work
> > a bit better. I hope you will bear with me with a bit more
> > testing...
>
> Don't worry, I will :) Unfortunately I didn't have time yesterday and I
> won't have time today either. But I'll do what you asked tomorrow and I'll
> send you the results.
Not a problem! I did find one issue that -might- help, please see
the patch below. (Run with CONFIG_RCU_FAST_NO_HZ=y.)
Please let me know how it goes!
Thanx, Paul
rcu: Remove redundant code from rcu_cleanup_after_idle()
The rcu_try_advance_all_cbs() function returns a bool saying whether or
not there are callbacks ready to invoke, but rcu_cleanup_after_idle()
rechecks this regardless. This commit therefore uses the value returned
by rcu_try_advance_all_cbs() instead of making rcu_cleanup_after_idle()
do this recheck.
Signed-off-by: Paul E. McKenney
diff --git a/kernel/rcutree_plugin.h b/kernel/rcutree_plugin.h
index 01676b7..a538e73 100644
--- a/kernel/rcutree_plugin.h
+++ b/kernel/rcutree_plugin.h
@@ -1768,17 +1768,11 @@ static void rcu_prepare_for_idle(int cpu)
*/
static void rcu_cleanup_after_idle(int cpu)
{
- struct rcu_data *rdp;
- struct rcu_state *rsp;
if (rcu_is_nocb_cpu(cpu))
return;
- rcu_try_advance_all_cbs();
- for_each_rcu_flavor(rsp) {
- rdp = per_cpu_ptr(rsp->rda, cpu);
- if (cpu_has_callbacks_ready_to_invoke(rdp))
- invoke_rcu_core();
- }
+ if (rcu_try_advance_all_cbs())
+ invoke_rcu_core();
}
/*
--
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 12/18] ARM: s3c64xx: Add support for DMA using generic amba-pl08x driver
This patch adds all required platform-specific data and initialization
code to support the generic amba-pl08x driver on S3C64xx SoCs.
Also some compatibility definitions are added to make the transition
from legacy API to DMA engine easier. The biggest hack here is passing
const char * pointers through DMA resource, casted to unsigned long,
but this is how Samsung DMA wrappers (used to support both s3c-dma and
DMA engine in drivers) are designed.
Signed-off-by: Tomasz Figa
---
arch/arm/Kconfig | 1 +
arch/arm/mach-s3c64xx/Kconfig| 8 +-
arch/arm/mach-s3c64xx/Makefile | 1 +
arch/arm/mach-s3c64xx/common.h | 5 +
arch/arm/mach-s3c64xx/include/mach/dma.h | 63
arch/arm/mach-s3c64xx/pl080.c| 244 +++
arch/arm/plat-samsung/devs.c | 12 +-
arch/arm/plat-samsung/dma-ops.c | 8 +-
8 files changed, 337 insertions(+), 5 deletions(-)
create mode 100644 arch/arm/mach-s3c64xx/pl080.c
Changes since v1:
- Stopped hijacking pl330_filter() symbol to plug pl08_filter_id()
as channel filtering callback on S3C64xx.
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 43594d5..7e0e1b6 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -721,6 +721,7 @@ config ARCH_S3C64XX
bool "Samsung S3C64XX"
select ARCH_HAS_CPUFREQ
select ARCH_REQUIRE_GPIOLIB
+ select ARM_AMBA
select ARM_VIC
select CLKDEV_LOOKUP
select CLKSRC_MMIO
diff --git a/arch/arm/mach-s3c64xx/Kconfig b/arch/arm/mach-s3c64xx/Kconfig
index 2057853..704c5e4 100644
--- a/arch/arm/mach-s3c64xx/Kconfig
+++ b/arch/arm/mach-s3c64xx/Kconfig
@@ -28,9 +28,15 @@ config CPU_S3C6410
help
Enable S3C6410 CPU support
+config S3C64XX_PL080
+ bool "S3C64XX DMA using generic PL08x driver"
+ select AMBA_PL08X
+ select SAMSUNG_DMADEV
+
config S3C64XX_DMA
- bool "S3C64XX DMA"
+ bool "S3C64XX DMA using legacy S3C DMA API"
select S3C_DMA
+ depends on !S3C64XX_PL080
config S3C64XX_SETUP_SDHCI
bool
diff --git a/arch/arm/mach-s3c64xx/Makefile b/arch/arm/mach-s3c64xx/Makefile
index 31d0c91..4e3326a 100644
--- a/arch/arm/mach-s3c64xx/Makefile
+++ b/arch/arm/mach-s3c64xx/Makefile
@@ -27,6 +27,7 @@ obj-$(CONFIG_CPU_IDLE)+= cpuidle.o
# DMA support
obj-$(CONFIG_S3C64XX_DMA) += dma.o
+obj-$(CONFIG_S3C64XX_PL080)+= pl080.o
# Device support
diff --git a/arch/arm/mach-s3c64xx/common.h b/arch/arm/mach-s3c64xx/common.h
index e8f990b..4e84617 100644
--- a/arch/arm/mach-s3c64xx/common.h
+++ b/arch/arm/mach-s3c64xx/common.h
@@ -60,4 +60,9 @@ int __init s3c64xx_pm_late_initcall(void);
static inline int s3c64xx_pm_late_initcall(void) { return 0; }
#endif
+#ifdef CONFIG_S3C64XX_PL080
+extern struct pl08x_platform_data s3c64xx_dma0_plat_data;
+extern struct pl08x_platform_data s3c64xx_dma1_plat_data;
+#endif
+
#endif /* __ARCH_ARM_MACH_S3C64XX_COMMON_H */
diff --git a/arch/arm/mach-s3c64xx/include/mach/dma.h
b/arch/arm/mach-s3c64xx/include/mach/dma.h
index fe1a98c..26a6bc3 100644
--- a/arch/arm/mach-s3c64xx/include/mach/dma.h
+++ b/arch/arm/mach-s3c64xx/include/mach/dma.h
@@ -11,6 +11,8 @@
#ifndef __ASM_ARCH_DMA_H
#define __ASM_ARCH_DMA_H __FILE__
+#ifdef CONFIG_S3C64XX_DMA
+
#define S3C_DMA_CHANNELS (16)
/* see mach-s3c2410/dma.h for notes on dma channel numbers */
@@ -128,4 +130,65 @@ struct s3c2410_dma_chan {
#include
+#else
+
+#define S3C64XX_DMA_CHAN(name) ((unsigned long)(name))
+
+/* DMA0/SDMA0 */
+#define DMACH_UART0S3C64XX_DMA_CHAN("uart0_tx")
+#define DMACH_UART0_SRC2 S3C64XX_DMA_CHAN("uart0_rx")
+#define DMACH_UART1S3C64XX_DMA_CHAN("uart1_tx")
+#define DMACH_UART1_SRC2 S3C64XX_DMA_CHAN("uart1_rx")
+#define DMACH_UART2S3C64XX_DMA_CHAN("uart2_tx")
+#define DMACH_UART2_SRC2 S3C64XX_DMA_CHAN("uart2_rx")
+#define DMACH_UART3S3C64XX_DMA_CHAN("uart3_tx")
+#define DMACH_UART3_SRC2 S3C64XX_DMA_CHAN("uart3_rx")
+#define DMACH_PCM0_TX S3C64XX_DMA_CHAN("pcm0_tx")
+#define DMACH_PCM0_RX S3C64XX_DMA_CHAN("pcm0_rx")
+#define DMACH_I2S0_OUT S3C64XX_DMA_CHAN("i2s0_tx")
+#define DMACH_I2S0_IN S3C64XX_DMA_CHAN("i2s0_rx")
+#define DMACH_SPI0_TX S3C64XX_DMA_CHAN("spi0_tx")
+#define DMACH_SPI0_RX S3C64XX_DMA_CHAN("spi0_rx")
+#define DMACH_HSI_I2SV40_TXS3C64XX_DMA_CHAN("i2s2_tx")
+#define DMACH_HSI_I2SV40_RXS3C64XX_DMA_CHAN("i2s2_rx")
+
+/* DMA1/SDMA1 */
+#define DMACH_PCM1_TX S3C64XX_DMA_CHAN("pcm1_tx")
+#define DMACH_PCM1_RX S3C64XX_DMA_CHAN("pcm1_rx")
+#define DMACH_I2S1_OUT S3C64XX_DMA_CHAN("i2s1_tx")
+#define DMACH_I2S1_IN S3C64XX_DMA_CHAN("i2s1_rx")
+#define DMACH_SPI1_TX S3C64XX_DMA_CHAN("spi1_tx")
+#define DMACH_SPI1_RX S3C64XX_DMA_CHAN("spi1_rx")
+#define DMACH_AC97_PCMOUT
Re: ACPI vs Device Tree - moving forward
On Fri, Aug 23, 2013 at 04:45:48PM -0700, Darren Hart wrote: > On Sat, 2013-08-24 at 00:38 +0100, Matthew Garrett wrote: > > On Fri, Aug 23, 2013 at 04:25:43PM -0700, Darren Hart wrote: > > > > > It had been my hope at the start of this project to open the creation of > > > SSDTs up to inventors and hackers who want to create Lures for the > > > MinnowBoard in such a way that they could write these SSDTs and load > > > them from a file at boot time, modify, rebuild, iterate, etc. When/if > > > the Lure goes to production, the SSDT could either be stored on an > > > EEPROM, or for very low volume boards, possibly just shipped as a binary > > > to be loaded (with source available of course). > > > > There's no fundamental problem with doing this, especially on UEFI > > systems. As long as you know the host ACPI code, it's trivial to merge > > an SSDT in from a UEFI option ROM. > > > > > It appears that Matthew, at least, would prefer this latter scenario > > > just used DT instead. However, that seems to leave a gap in the > > > transition to incorporating the table into the board firmware should a > > > derivative product be made. e.g. no good way to prototype with ACPI. It > > > also seems to have all the same problems raised regarding mixing ACPI > > > and DT on the same system. > > > > I've no problem with additional hardware shipping with ACPI support - my > > position was more that if a vendor ships a system with ACPI that fails > > to describe the integrated hardware (or does so incorrectly), it's > > probably easier to replace it with DT than a fixed ACPI table. Still, if > > people *do* want to replace shipped ACPI tables, it's probably > > preferable to do that at the bootloader level than the kernel level. > > > > OK. Thanks for elaborating. > > It seems to me that in order to fully support this, we are back to the > problem of how do we provide arbitrary configuration data via ACPI (the > DSM being the only current means, but there is no standard there). Is > that still the hard problem we are looking to solve as a group? > Did the group conclude that the idea of FDT augmenting ACPI is not feasible ? If not, the key question for me is how to implement it, and how to handle all its little problems. If yes, the key question for me is how to handle all the drivers which assume fdt-style properties, and how to express all that information in ACPI in a way which does not require a substantial driver rewrite (and, as you point out, how that data would be described in ACPI consistently across multiple vendors). Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 03/14] hwmon: lm75: expose to thermal fw via DT nodes
On Fri, Aug 23, 2013 at 07:15:44PM -0400, Eduardo Valentin wrote:
> This patch adds to lm75 temperature sensor the possibility
> to expose itself as thermal zone device, registered on the
> thermal framework.
>
> The thermal zone is built only if a device tree node
> describing a thermal zone for this sensor is present
> inside the lm75 DT node. Otherwise, the driver behavior
> will be the same.
>
> Cc: Jean Delvare
> Cc: Guenter Roeck
> Cc: lm-sens...@lm-sensors.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Eduardo Valentin
> ---
> drivers/hwmon/lm75.c | 31 +++
> 1 file changed, 31 insertions(+)
>
> diff --git a/drivers/hwmon/lm75.c b/drivers/hwmon/lm75.c
> index c03b490..dc55908 100644
> --- a/drivers/hwmon/lm75.c
> +++ b/drivers/hwmon/lm75.c
> @@ -27,6 +27,8 @@
> #include
> #include
> #include
> +#include
> +#include
> #include "lm75.h"
>
>
> @@ -70,6 +72,7 @@ static const u8 LM75_REG_TEMP[3] = {
> /* Each client has this additional data */
> struct lm75_data {
> struct device *hwmon_dev;
> + struct thermal_zone_device *tz;
> struct mutexupdate_lock;
> u8 orig_conf;
> u8 resolution; /* In bits, between 9 and 12 */
> @@ -92,6 +95,19 @@ static struct lm75_data *lm75_update_device(struct device
> *dev);
>
> /* sysfs attributes for hwmon */
>
> +static int lm75_read_temp(void *dev, unsigned long *temp)
> +{
> + struct lm75_data *data = lm75_update_device(dev);
> +
> + if (IS_ERR(data))
> + return PTR_ERR(data);
> +
> + *temp = ((data->temp[0] >> (16 - data->resolution)) * 1000) >>
> + (data->resolution - 8);
> +
The reported temperature can be negative, which would result in reporting a very
high temperature (note this applies to the tmp102 driver patch as well).
The computation is quite complex and matches the computation done in
show_temp().
Given that, it would make sense to declare an inline function to convert the
register value to the temperature. This function can take the register value
and the resolution as argument.
Guenter
> + return 0;
> +}
> +
> static ssize_t show_temp(struct device *dev, struct device_attribute *da,
>char *buf)
> {
> @@ -271,11 +287,25 @@ lm75_probe(struct i2c_client *client, const struct
> i2c_device_id *id)
> goto exit_remove;
> }
>
> + if (of_find_property(client->dev.of_node, "monitored-zones", NULL)) {
> + data->tz = thermal_zone_of_device_register(>dev,
> +0,
> +false, /* -hwmon */
> +>dev,
> +lm75_read_temp);
> + if (IS_ERR(data->tz)) {
> + status = PTR_ERR(data->tz);
> + goto exit_hwmon;
> + }
> + }
> +
> dev_info(>dev, "%s: sensor '%s'\n",
>dev_name(data->hwmon_dev), client->name);
>
> return 0;
>
> +exit_hwmon:
> + hwmon_device_unregister(data->hwmon_dev);
> exit_remove:
> sysfs_remove_group(>dev.kobj, _group);
> return status;
> @@ -285,6 +315,7 @@ static int lm75_remove(struct i2c_client *client)
> {
> struct lm75_data *data = i2c_get_clientdata(client);
>
> + thermal_zone_device_unregister(data->tz);
> hwmon_device_unregister(data->hwmon_dev);
> sysfs_remove_group(>dev.kobj, _group);
> lm75_write_value(client, LM75_REG_CONF, data->orig_conf);
> --
> 1.8.2.1.342.gfa7285d
>
>
--
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: ACPI vs Device Tree - moving forward
On Sat, 2013-08-24 at 00:38 +0100, Matthew Garrett wrote: > On Fri, Aug 23, 2013 at 04:25:43PM -0700, Darren Hart wrote: > > > It had been my hope at the start of this project to open the creation of > > SSDTs up to inventors and hackers who want to create Lures for the > > MinnowBoard in such a way that they could write these SSDTs and load > > them from a file at boot time, modify, rebuild, iterate, etc. When/if > > the Lure goes to production, the SSDT could either be stored on an > > EEPROM, or for very low volume boards, possibly just shipped as a binary > > to be loaded (with source available of course). > > There's no fundamental problem with doing this, especially on UEFI > systems. As long as you know the host ACPI code, it's trivial to merge > an SSDT in from a UEFI option ROM. > > > It appears that Matthew, at least, would prefer this latter scenario > > just used DT instead. However, that seems to leave a gap in the > > transition to incorporating the table into the board firmware should a > > derivative product be made. e.g. no good way to prototype with ACPI. It > > also seems to have all the same problems raised regarding mixing ACPI > > and DT on the same system. > > I've no problem with additional hardware shipping with ACPI support - my > position was more that if a vendor ships a system with ACPI that fails > to describe the integrated hardware (or does so incorrectly), it's > probably easier to replace it with DT than a fixed ACPI table. Still, if > people *do* want to replace shipped ACPI tables, it's probably > preferable to do that at the bootloader level than the kernel level. > OK. Thanks for elaborating. It seems to me that in order to fully support this, we are back to the problem of how do we provide arbitrary configuration data via ACPI (the DSM being the only current means, but there is no standard there). Is that still the hard problem we are looking to solve as a group? -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel -- 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 17/17] clk: zynq: remove call to of_clk_init
On Fri, Aug 23, 2013 at 09:00:23AM -0700, Sören Brinkmann wrote:
> Hi Steffen,
>
> On Fri, Aug 23, 2013 at 09:32:50AM +0200, Steffen Trumtrar wrote:
> > Hi!
> >
> > On Thu, Aug 22, 2013 at 05:59:36PM -0700, Sören Brinkmann wrote:
> > > On Thu, Aug 22, 2013 at 05:26:47PM -0700, Sören Brinkmann wrote:
> [ ... ]
> > I propose getting rid of the whole global pointer and let the clkc map the
> > address itself instead.
> >
> > Then there is no need to shuffle stuff around in the initcalls.
> > I have some WIP patches (not rebased on next and not even tested with it,
> > but with v3.11-rc4)
> >
> > The dtsi would be something like:
> >
> >control-register@f800 {
> >compatible = "simple-bus";
> >#address-cells = <1>;
> >#size-cells = <1>;
> >reg = <0xf800 0x1000>;
> >ranges;
> >
> >slcr: slcr@f800 {
> >compatible = "xlnx,zynq-slcr", "syscon";
> >reg = <0xf800 0x10>;
> >};
> >
> >clkc: clkc@f8000100 {
> >#clock-cells = <1>;
> >compatible = "xlnx,ps7-clkc";
> >reg = <0xf8000100 0x100>;
>
> This is splitting the SLCR into multiple regions. I just heard about the
> syscon the first time, but wouldn't it be more correct to leave the SLCR
> region in one piece in the slcr node and then pass the slcr phandle to
> the clkc and later also pinmux etc. nodes? This way the SLCR is in
> charge of the lock and all registers protected by the lock.
> That wouldn't get rid of the dependency that SLCR has to be initialized
> before any of its users, but seems to reflect actual HW better since the
> whole region is protected by the same SLCR lock which makes them kinda
> inseparable.
>
Actually I agree. What I was struggeling with, was the correct mapping of the
ranges. But maybe I have to take another look at the "ranges = <..>" property.
> Anyway, after all we more or less agree, that syscon/slcr has to be
> initialized before any SLCR user. So, no matter whether we do this
> through current code and a global pointer or DT phandles, the effect
> stays the same, IIUC.
> So, in order to not mix stuff around too much, I'd rather make sure that
> zynq_slcr_init() is called early enough (put it in init_irq() or some
> init_call() whatever works best), and keep the global pointer for now.
> That way most code can stay as is and we don't have to change the DT
> bindings.
> And then you can finish your work on this and we can revisit the topic
> of migrating to use the slcr through a phandle later?
>
Agreed.
Steffen
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 03/14] hwmon: lm75: expose to thermal fw via DT nodes
On Fri, Aug 23, 2013 at 07:15:44PM -0400, Eduardo Valentin wrote:
> This patch adds to lm75 temperature sensor the possibility
> to expose itself as thermal zone device, registered on the
> thermal framework.
>
> The thermal zone is built only if a device tree node
> describing a thermal zone for this sensor is present
> inside the lm75 DT node. Otherwise, the driver behavior
> will be the same.
>
> Cc: Jean Delvare
> Cc: Guenter Roeck
> Cc: lm-sens...@lm-sensors.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Eduardo Valentin
> ---
> drivers/hwmon/lm75.c | 31 +++
> 1 file changed, 31 insertions(+)
>
> diff --git a/drivers/hwmon/lm75.c b/drivers/hwmon/lm75.c
> index c03b490..dc55908 100644
> --- a/drivers/hwmon/lm75.c
> +++ b/drivers/hwmon/lm75.c
> @@ -27,6 +27,8 @@
> #include
> #include
> #include
> +#include
> +#include
> #include "lm75.h"
>
>
> @@ -70,6 +72,7 @@ static const u8 LM75_REG_TEMP[3] = {
> /* Each client has this additional data */
> struct lm75_data {
> struct device *hwmon_dev;
> + struct thermal_zone_device *tz;
> struct mutexupdate_lock;
> u8 orig_conf;
> u8 resolution; /* In bits, between 9 and 12 */
> @@ -92,6 +95,19 @@ static struct lm75_data *lm75_update_device(struct device
> *dev);
>
> /* sysfs attributes for hwmon */
>
> +static int lm75_read_temp(void *dev, unsigned long *temp)
> +{
> + struct lm75_data *data = lm75_update_device(dev);
> +
> + if (IS_ERR(data))
> + return PTR_ERR(data);
> +
> + *temp = ((data->temp[0] >> (16 - data->resolution)) * 1000) >>
> + (data->resolution - 8);
> +
> + return 0;
> +}
> +
> static ssize_t show_temp(struct device *dev, struct device_attribute *da,
>char *buf)
> {
> @@ -271,11 +287,25 @@ lm75_probe(struct i2c_client *client, const struct
> i2c_device_id *id)
> goto exit_remove;
> }
>
> + if (of_find_property(client->dev.of_node, "monitored-zones", NULL)) {
> + data->tz = thermal_zone_of_device_register(>dev,
> +0,
> +false, /* -hwmon */
> +>dev,
> +lm75_read_temp);
> + if (IS_ERR(data->tz)) {
> + status = PTR_ERR(data->tz);
> + goto exit_hwmon;
> + }
> + }
> +
I don't think it should be fatal if thermal_zone_of_device_register fails.
hwmon itself still works fine, and should not be penaltized for a thermal
subsystem failure. Better display a warning if that happens and don't bail out.
The same comment applies to all patches affecting the hwmon subsystem.
> dev_info(>dev, "%s: sensor '%s'\n",
>dev_name(data->hwmon_dev), client->name);
>
> return 0;
>
> +exit_hwmon:
> + hwmon_device_unregister(data->hwmon_dev);
> exit_remove:
> sysfs_remove_group(>dev.kobj, _group);
> return status;
> @@ -285,6 +315,7 @@ static int lm75_remove(struct i2c_client *client)
> {
> struct lm75_data *data = i2c_get_clientdata(client);
>
> + thermal_zone_device_unregister(data->tz);
> hwmon_device_unregister(data->hwmon_dev);
> sysfs_remove_group(>dev.kobj, _group);
> lm75_write_value(client, LM75_REG_CONF, data->orig_conf);
> --
> 1.8.2.1.342.gfa7285d
>
>
--
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 3/3] gpio: pcf857x: Add OF support
Hi Linus, On Friday 23 August 2013 19:54:03 Linus Walleij wrote: > On Tue, Aug 20, 2013 at 1:04 AM, Laurent Pinchart wrote: > > Add DT bindings for the pcf857x-compatible chips and parse the device > > tree node in the driver. > > > > Signed-off-by: Laurent Pinchart > > > > I'm holding this until I get some reaction from the device tree reviewers, > or until I get unpatient, whichever comes first. Will you get unpatient before the end of the v3.12 merge window ? ;-) > It looks good to me. Thanks. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ACPI vs Device Tree - moving forward
On Fri, Aug 23, 2013 at 04:25:43PM -0700, Darren Hart wrote: > It had been my hope at the start of this project to open the creation of > SSDTs up to inventors and hackers who want to create Lures for the > MinnowBoard in such a way that they could write these SSDTs and load > them from a file at boot time, modify, rebuild, iterate, etc. When/if > the Lure goes to production, the SSDT could either be stored on an > EEPROM, or for very low volume boards, possibly just shipped as a binary > to be loaded (with source available of course). There's no fundamental problem with doing this, especially on UEFI systems. As long as you know the host ACPI code, it's trivial to merge an SSDT in from a UEFI option ROM. > It appears that Matthew, at least, would prefer this latter scenario > just used DT instead. However, that seems to leave a gap in the > transition to incorporating the table into the board firmware should a > derivative product be made. e.g. no good way to prototype with ACPI. It > also seems to have all the same problems raised regarding mixing ACPI > and DT on the same system. I've no problem with additional hardware shipping with ACPI support - my position was more that if a vendor ships a system with ACPI that fails to describe the integrated hardware (or does so incorrectly), it's probably easier to replace it with DT than a fixed ACPI table. Still, if people *do* want to replace shipped ACPI tables, it's probably preferable to do that at the bootloader level than the kernel level. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] usb: acm gadget: Null termintate strings table
On Fri, Aug 23, 2013 at 11:19:55PM +, Graham Williams wrote: > I couldn't get the whitespace formatting correctly from Windows Office (work > email) so I attached the patch file. I ran it on it applies correctly. I can't take attachments, and especially not base64 ones :( Take a look at the file I pointed you at in the Documentation directory for how to set up other email clients to work. Lots of other Broadcom developers have this working properly for their work emails, so perhaps you should contact them and ask what the magic incantantation is. 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: ACPI vs Device Tree - moving forward
On Thu, 2013-08-22 at 01:03 +0100, Matthew Garrett wrote: > On Thu, Aug 22, 2013 at 02:02:29AM +0200, Rafael J. Wysocki wrote: > > > And now the practice appears to be that vendors actually ship some ACPI > > tables with their systems, but those ACPI tables do not contain information > > needed to enumerate all devices. On the other hand, it is known what the > > DT bindings for the missing part should be. How can we address this? > > On ARM? I know that this is true on x86, but that's because x86 vendors > have never intended i2c hardware monitoring devices be driven by a > general purpoes OS - they're there for the benefit of the firmware, not > anything above that. > > > Next, say we have a driver written with DT bindings in mind and there's > > an ACPI-based system with identical hardware, although wired up slightly > > differently. Say that all of the information needed by that driver is > > there in the ACPI tables (Q: How the vendor is supposed to know what > > information the driver expects?). Who is supposed to take care of updating > > the driver to be able to use ACPI in addition to DTs? > > Ideally we have a consistent in-kernel representation of this > information and drivers don't need to care about whether it came from DT > or ACPI, but like I said, that's going to be tricky. > > > I don't honestly think that the "ask vendors to ship their systems with > > correct > > ACPI tables" approach will take us anywhere. > > It's worked well enough on x86. If hardware vendors don't actually test > that their hardware is able to boot the OS it's intended to run then > there's very little we can do about that - and the worst case outcome is > that people just ignore the shipped ACPI and use FDT. > It appears both Matthew and Rafael are supporting a statement to the effect that we should not expect anyone but BIOS/firmware vendors to be writing ACPI code (such as SSDTs which they compile, store on the boot media, and pass into the kernel at boot time). This is certainly the case know (with a few rare exceptions where people are trying to work around broken BIOS ACPI tables. It had been my hope at the start of this project to open the creation of SSDTs up to inventors and hackers who want to create Lures for the MinnowBoard in such a way that they could write these SSDTs and load them from a file at boot time, modify, rebuild, iterate, etc. When/if the Lure goes to production, the SSDT could either be stored on an EEPROM, or for very low volume boards, possibly just shipped as a binary to be loaded (with source available of course). It appears that Matthew, at least, would prefer this latter scenario just used DT instead. However, that seems to leave a gap in the transition to incorporating the table into the board firmware should a derivative product be made. e.g. no good way to prototype with ACPI. It also seems to have all the same problems raised regarding mixing ACPI and DT on the same system. -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 06/14] arm: dts: add omap4 CPU thermal data
This patch changes a dtsi file to contain the thermal data
for MPU domain on OMAP4 and later SoCs. This data will
enable the passive cooling with CPUfreq cooling device
at 100C and the system will do a thermal shutdown at 125C.
This thermal data can be reused across TI SoC devices.
Cc: "Benoît Cousson"
Cc: Tony Lindgren
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Stephen Warren
Cc: Ian Campbell
Cc: Russell King
Cc: linux-o...@vger.kernel.org
Cc: devicet...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin
---
arch/arm/boot/dts/omap4-cpu-thermal.dtsi | 40
1 file changed, 40 insertions(+)
create mode 100644 arch/arm/boot/dts/omap4-cpu-thermal.dtsi
diff --git a/arch/arm/boot/dts/omap4-cpu-thermal.dtsi
b/arch/arm/boot/dts/omap4-cpu-thermal.dtsi
new file mode 100644
index 000..d74c565
--- /dev/null
+++ b/arch/arm/boot/dts/omap4-cpu-thermal.dtsi
@@ -0,0 +1,40 @@
+
+/*
+ * Device Tree Source for OMAP4/5 SoC CPU thermal
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ * Contact: Eduardo Valentin
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include
+
+cpu_thermal: cpu_thermal {
+ #thermal-cells = <1>;
+ mask = <0x03>; /* trips writability */
+ passive_delay = <250>; /* milliseconds */
+ polling_delay = <1000>; /* milliseconds */
+ trips {
+ alert@10{
+ temperature = <10>; /* milliCelsius */
+ hysteresis = <2000>; /* milliCelsius */
+ type = ;
+ };
+ crit@125000{
+ temperature = <125000>; /* milliCelsius */
+ hysteresis = <2000>; /* milliCelsius */
+ type = ;
+ };
+ };
+ bind_params {
+ action@0{
+ cooling_device = "thermal-cpufreq";
+ weight = <100>; /* percentage */
+ mask = <0x01>;
+ /* no limits, using defaults */
+ };
+ };
+};
--
1.8.2.1.342.gfa7285d
--
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 17/17] clk: zynq: remove call to of_clk_init
On Fri, Aug 23, 2013 at 07:44:03PM +0200, Sebastian Hesselbarth wrote: > On 08/23/13 19:19, Sören Brinkmann wrote: > >On Fri, Aug 23, 2013 at 11:30:18AM +0200, Sebastian Hesselbarth wrote: > >>On 08/23/13 02:59, Sören Brinkmann wrote: > >>>On Thu, Aug 22, 2013 at 05:26:47PM -0700, Sören Brinkmann wrote: > On Tue, Aug 20, 2013 at 04:04:31AM +0200, Sebastian Hesselbarth wrote: > >With arch/arm calling of_clk_init(NULL) from time_init(), we can now > >remove it from corresponding drivers/clk code. > > I think that would break Zynq. > If I see this correctly you call of_clk_init() from common code, > _before_ the SOC specific time init function is called. > The problem is, that we have code setting up a global pointer which is > required by zynq_clk_setup() which is triggered when of_clk_init() is > called. > >[ ... ] > >>thanks for looking into this. I also had a look at the files in > >>question. Based on Steffen's proposal, I prepared a diff that should do > >>the trick. It moves zynq_slcr_init() to early_init, instead of reusing > >>another hook that has magic cow powers (it calls irqchip_init that zynq > >>also wants sooner or later). > >> > >>Also, it removes zynq_clock_init() and let zynq_clk_setup() map the > >>register itself by finding the node and use of_iomap(). I realized that > >>clock registers are quite separated within slcr, so you can consider > >>to have your own node for the clk-provider. As Steffen is proposing > >>this but mentioned incompatible DT changes, I chose that intermediate > >>step above. > >> > >>It would be great, if you test the diff and prepare a patch out of > >>it, that I pick-up in the patch set. That way, we also have your > >>Signed-off on it. > > > >I looked into this. Looks like init_early() happens to early. I suspect > >slab is missing to make zynq_slcr_init() work. So, I moved it into > >init_irq(). Is there any init_call() type which is called at the correct > >time? > > Sören, > > I mistakenly assumed init_early is after mm, so of course my proposal > does not work as it should. I am fine with moving it to init_irq() until > you find the best solution (or until we have the same "mess" with > default init_irq hook). > > >I looked briefly into syscon and regmap, and that does actually look > >promising and to really fix this mess, I guess we have to wait a little > >until Steffen finishes his work on it. > > IIRC, both syscon and regmap will require you to have devices ready. > I haven't followed all recent discussions about early device > registration. Anyway, it will not help much in the current approach > to get rid of custom .init_timer and maybe .init_irq later. > Yes. The syscon driver can not be used that early. It only makes sense for later stages. Therefore the slcr has to be mapped early to unlock and than remapped later. But with the current drivers, it is not essential to have the slcr as a seperate driver. > >To facilitate Sebastian's series I came up with the patch below. > >The problem I have is, I do not really want the clkc to map the > >registers. They are in the SLCR and the SLCR driver is doing it, hence > >we should work with what that driver provides - which ideally would be > >based on regmap and syscon, but we're not there yet. Hence I somehow > >need to pass the SLCR pointer to the clkc. To avoid accessing the global > >pointer directly I kept the zynq_clock_init() routine which is called > >from zynq_slcr_init(). > > For this patch set I'd be fine with the proposal below. For the short > run, you could consider to hide register accesses to slcr by providing > zynq_slcr_readl/writel instead of passing just the base address. > > But again, that will require either custom .init_time or .init_irq > to set up slcr before clocks. > > >That is the best I could come up with quickly and w/o investing a lot of > >time to figure out the regmap and syscon stuff, which seems to be handled > >by Steffen already, anyway. > >It is essentially a stripped down version of Sebastian's proposal. > > If there are no general objections, I take that one for the real patch > set. I haven't tested this, but I hope Sören did. For the time being, I am okay with it. Regards, Steffen -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 11/14] arm: dts: add omap5 GPU thermal data
This patch changes a dtsi file to contain the thermal data
for GPU domain on OMAP5 and later SoCs. This data will
enable a thermal shutdown at 125C.
This thermal data can be reused across TI SoC devices.
Cc: "Benoît Cousson"
Cc: Tony Lindgren
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Stephen Warren
Cc: Ian Campbell
Cc: Russell King
Cc: linux-o...@vger.kernel.org
Cc: devicet...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin
---
arch/arm/boot/dts/omap5-gpu-thermal.dtsi | 27 +++
1 file changed, 27 insertions(+)
create mode 100644 arch/arm/boot/dts/omap5-gpu-thermal.dtsi
diff --git a/arch/arm/boot/dts/omap5-gpu-thermal.dtsi
b/arch/arm/boot/dts/omap5-gpu-thermal.dtsi
new file mode 100644
index 000..f421492
--- /dev/null
+++ b/arch/arm/boot/dts/omap5-gpu-thermal.dtsi
@@ -0,0 +1,27 @@
+
+/*
+ * Device Tree Source for OMAP543x SoC GPU thermal
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ * Contact: Eduardo Valentin
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include
+
+gpu_thermal: gpu_thermal {
+ #thermal-cells = <1>;
+ mask = <0x01>; /* trips writability */
+ passive_delay = <250>; /* milliseconds */
+ polling_delay = <1000>; /* milliseconds */
+ trips {
+ crit@125000{
+ temperature = <125000>; /* milliCelsius */
+ hysteresis = <2000>; /* milliCelsius */
+ type = ;
+ };
+ };
+};
--
1.8.2.1.342.gfa7285d
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 13/14] arm: dts: add omap5 thermal data
This patch changes the dtsi entry on omap5 to contain
the thermal data. This data will enable the passive
cooling with CPUfreq cooling device at 100C. The
system will do a thermal shutdown at 125C whenever
any of its sensors sees this level.
Cc: "Benoît Cousson"
Cc: Tony Lindgren
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Stephen Warren
Cc: Ian Campbell
Cc: Russell King
Cc: linux-o...@vger.kernel.org
Cc: devicet...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin
---
arch/arm/boot/dts/omap5.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index e643620..4a33fe0 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -45,6 +45,12 @@
};
};
+ thermal_zones {
+ #include "omap4-cpu-thermal.dtsi"
+ #include "omap5-gpu-thermal.dtsi"
+ #include "omap5-core-thermal.dtsi"
+ };
+
timer {
compatible = "arm,armv7-timer";
/* PPI secure/nonsecure IRQ */
@@ -711,6 +717,9 @@
0x4a0023C0 0x3c>;
interrupts = ;
compatible = "ti,omap5430-bandgap";
+ monitored-zones = <_thermal 0>,
+ <_thermal 1>,
+ <_thermal 2>;
};
};
};
--
1.8.2.1.342.gfa7285d
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 12/14] arm: dts: add omap5 CORE thermal data
This patch changes a dtsi file to contain the thermal data
for CORE domain on OMAP5 and later SoCs. This data will
enable a thermal shutdown at 125C.
This thermal data can be reused across TI SoC devices.
Cc: "Benoît Cousson"
Cc: Tony Lindgren
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Stephen Warren
Cc: Ian Campbell
Cc: Russell King
Cc: linux-o...@vger.kernel.org
Cc: devicet...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin
---
arch/arm/boot/dts/omap5-core-thermal.dtsi | 27 +++
1 file changed, 27 insertions(+)
create mode 100644 arch/arm/boot/dts/omap5-core-thermal.dtsi
diff --git a/arch/arm/boot/dts/omap5-core-thermal.dtsi
b/arch/arm/boot/dts/omap5-core-thermal.dtsi
new file mode 100644
index 000..3d9fa09
--- /dev/null
+++ b/arch/arm/boot/dts/omap5-core-thermal.dtsi
@@ -0,0 +1,27 @@
+
+/*
+ * Device Tree Source for OMAP543x SoC CORE thermal
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ * Contact: Eduardo Valentin
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include
+
+core_thermal: core_thermal {
+ #thermal-cells = <1>;
+ mask = <0x01>; /* trips writability */
+ passive_delay = <250>; /* milliseconds */
+ polling_delay = <1000>; /* milliseconds */
+ trips {
+ crit@125000{
+ temperature = <125000>; /* milliCelsius */
+ hysteresis = <2000>; /* milliCelsius */
+ type = ;
+ };
+ };
+};
--
1.8.2.1.342.gfa7285d
--
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] usb: acm gadget: Null termintate strings table
I couldn't get the whitespace formatting correctly from Windows Office (work email) so I attached the patch file. I ran it on it applies correctly. 0001-usb-acm-gadget-Null-termintate-strings-table.patch Description: 0001-usb-acm-gadget-Null-termintate-strings-table.patch
Re: [PATCH v3 3/5] clk: Add common __clk_get(), __clk_put() implementations
On Fri, Aug 23, 2013 at 05:03:45PM +0200, Sylwester Nawrocki wrote:
> This patch adds common __clk_get(), __clk_put() clkdev helpers which
> replace their platform specific counterparts when the common clock
> API is enabled.
>
> The owner module pointer field is added to struct clk so a reference
> to the clock supplier module can be taken by the clock consumers.
>
> Signed-off-by: Sylwester Nawrocki
> Signed-off-by: Kyungmin Park
I'm mostly happy with this now.
> +int __clk_get(struct clk *clk)
> +{
> + if (clk && !try_module_get(clk->owner))
> + return 0;
> +
> + return 1;
> +}
> +EXPORT_SYMBOL(__clk_get);
> +
> +void __clk_put(struct clk *clk)
> +{
> + if (WARN_ON_ONCE(IS_ERR(clk)))
> + return;
> +
> + if (clk)
> + module_put(clk->owner);
> +}
> +EXPORT_SYMBOL(__clk_put);
Why are these exported? clkdev can only be built into the kernel, as can
the common clk framework - they can't be modular. So why would a module
wish to access these directly?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 14/14] arm: dts: point to cooling-zones on omap5 cpu node
OMAP5 devices can reach high temperatures and thus
needs to have cpufreq-cooling on systems running on it.
This patch links the cpu node to its thermal-zone
so that cpufreq-cpu0 driver loads the cooling device.
Cc: "Benoît Cousson"
Cc: Tony Lindgren
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Stephen Warren
Cc: Ian Campbell
Cc: Russell King
Cc: linux-o...@vger.kernel.org
Cc: devicet...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin
---
arch/arm/boot/dts/omap5.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 4a33fe0..335fcea 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -37,6 +37,7 @@
device_type = "cpu";
compatible = "arm,cortex-a15";
reg = <0x0>;
+ cooling-zones = <_thermal>;
};
cpu@1 {
device_type = "cpu";
--
1.8.2.1.342.gfa7285d
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 07/14] arm: dts: add omap4430 thermal data
This patch changes the dtsi entry on omap4430 to contain
the thermal data. This data will enable the passive
cooling with CPUfreq cooling device at 100C and the
system will do a thermal shutdown at 125C.
Cc: "Benoît Cousson"
Cc: Tony Lindgren
Cc: Russell King
Cc: linux-o...@vger.kernel.org
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin
---
arch/arm/boot/dts/omap443x.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/omap443x.dtsi b/arch/arm/boot/dts/omap443x.dtsi
index bcf455e..91a3a5d 100644
--- a/arch/arm/boot/dts/omap443x.dtsi
+++ b/arch/arm/boot/dts/omap443x.dtsi
@@ -25,9 +25,14 @@
};
};
+ thermal_zones{
+ #include "omap4-cpu-thermal.dtsi"
+ };
+
bandgap {
reg = <0x4a002260 0x4
0x4a00232C 0x4>;
compatible = "ti,omap4430-bandgap";
+ monitored-zones = <_thermal 0>;
};
};
--
1.8.2.1.342.gfa7285d
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 05/14] thermal: ti-soc-thermal: use thermal DT infrastructure
This patch improves the ti-soc-thermal driver by adding the
support to build the thermal zones based on DT nodes.
The driver will have two options now to build the thermal
zones. The first option is the zones originally coded
in this driver. So, the driver behavior will be same
if there is no DT node describing the zones. The second
option, when it is found a DT node with thermal data,
will used the common infrastructure to build the thermal
zone and bind its cooling devices.
In case the driver loads thermal data using the legacy
mode, this driver still adds to the system
a cpufreq cooling device. Loading the thermal data from
DT, the driver assumes someone else will add the cpufreq
cooling device, like the cpufreq driver.
Cc: Zhang Rui
Cc: linux...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin
---
drivers/thermal/ti-soc-thermal/ti-thermal-common.c | 52 +-
1 file changed, 41 insertions(+), 11 deletions(-)
diff --git a/drivers/thermal/ti-soc-thermal/ti-thermal-common.c
b/drivers/thermal/ti-soc-thermal/ti-thermal-common.c
index 5ab613a..6aac72c 100644
--- a/drivers/thermal/ti-soc-thermal/ti-thermal-common.c
+++ b/drivers/thermal/ti-soc-thermal/ti-thermal-common.c
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#include "ti-thermal.h"
#include "ti-bandgap.h"
@@ -75,11 +76,10 @@ static inline int ti_thermal_hotspot_temperature(int t, int
s, int c)
/* thermal zone ops */
/* Get temperature callback function for thermal zone*/
-static inline int ti_thermal_get_temp(struct thermal_zone_device *thermal,
- unsigned long *temp)
+static inline int __ti_thermal_get_temp(void *devdata, unsigned long *temp)
{
struct thermal_zone_device *pcb_tz = NULL;
- struct ti_thermal_data *data = thermal->devdata;
+ struct ti_thermal_data *data = devdata;
struct ti_bandgap *bgp;
const struct ti_temp_sensor *s;
int ret, tmp, slope, constant;
@@ -117,6 +117,14 @@ static inline int ti_thermal_get_temp(struct
thermal_zone_device *thermal,
return ret;
}
+static inline int ti_thermal_get_temp(struct thermal_zone_device *thermal,
+ unsigned long *temp)
+{
+ struct ti_thermal_data *data = thermal->devdata;
+
+ return __ti_thermal_get_temp(data, temp);
+}
+
/* Bind callback functions for thermal zone */
static int ti_thermal_bind(struct thermal_zone_device *thermal,
struct thermal_cooling_device *cdev)
@@ -293,6 +301,7 @@ int ti_thermal_expose_sensor(struct ti_bandgap *bgp, int id,
char *domain)
{
struct ti_thermal_data *data;
+ struct device_node *np;
data = ti_bandgap_get_sensor_data(bgp, id);
@@ -302,16 +311,23 @@ int ti_thermal_expose_sensor(struct ti_bandgap *bgp, int
id,
if (!data)
return -EINVAL;
- /* Create thermal zone */
- data->ti_thermal = thermal_zone_device_register(domain,
+ /* in case this is specified by DT */
+ np = bgp->dev->of_node;
+ data->ti_thermal = thermal_zone_of_device_register(bgp->dev, id,
+ true, /* +hwmon */
+ data, __ti_thermal_get_temp);
+ if (IS_ERR(data->ti_thermal)) {
+ /* Create thermal zone */
+ data->ti_thermal = thermal_zone_device_register(domain,
OMAP_TRIP_NUMBER, 0, data, _thermal_ops,
NULL, FAST_TEMP_MONITORING_RATE,
FAST_TEMP_MONITORING_RATE, true);
- if (IS_ERR(data->ti_thermal)) {
- dev_err(bgp->dev, "thermal zone device is NULL\n");
- return PTR_ERR(data->ti_thermal);
+ if (IS_ERR(data->ti_thermal)) {
+ dev_err(bgp->dev, "thermal zone device is NULL\n");
+ return PTR_ERR(data->ti_thermal);
+ }
+ data->ti_thermal->polling_delay = FAST_TEMP_MONITORING_RATE;
}
- data->ti_thermal->polling_delay = FAST_TEMP_MONITORING_RATE;
ti_bandgap_set_sensor_data(bgp, id, data);
return 0;
@@ -323,7 +339,8 @@ int ti_thermal_remove_sensor(struct ti_bandgap *bgp, int id)
data = ti_bandgap_get_sensor_data(bgp, id);
- thermal_zone_device_unregister(data->ti_thermal);
+ if (data && data->ti_thermal)
+ thermal_zone_device_unregister(data->ti_thermal);
return 0;
}
@@ -342,6 +359,17 @@ int ti_thermal_report_sensor_temperature(struct ti_bandgap
*bgp, int id)
int ti_thermal_register_cpu_cooling(struct ti_bandgap *bgp, int id)
{
struct ti_thermal_data *data;
+ struct device_node *np = bgp->dev->of_node;
+
+ /*
+* We are assuming here that if one deploys the zone
+* using DT, then it must be aware that the cooling device
+
[RFC PATCH 09/14] arm: dts: point to cooling-zones on omap4430 cpu node
OMAP4430 devices can reach high temperatures and thus needs to have cpufreq-cooling on systems running on it. This patch links the cpu node to its thermal-zone so that cpufreq-cpu0 driver loads the cooling device. Cc: "Benoît Cousson" Cc: Tony Lindgren Cc: Russell King Cc: linux-o...@vger.kernel.org Cc: devicetree-disc...@lists.ozlabs.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Eduardo Valentin --- arch/arm/boot/dts/omap443x.dtsi | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/boot/dts/omap443x.dtsi b/arch/arm/boot/dts/omap443x.dtsi index 91a3a5d..e4eea43 100644 --- a/arch/arm/boot/dts/omap443x.dtsi +++ b/arch/arm/boot/dts/omap443x.dtsi @@ -22,6 +22,7 @@ 1008000 1375000 >; clock-latency = <30>; /* From legacy driver */ + cooling-zones = <_thermal>; }; }; -- 1.8.2.1.342.gfa7285d -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 08/14] arm: dts: add omap4460 thermal data
This patch changes the dtsi entry on omap4460 to contain
the thermal data. This data will enable the passive
cooling with CPUfreq cooling device at 100C and the
system will do a thermal shutdown at 125C.
Cc: "Benoît Cousson"
Cc: Tony Lindgren
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Stephen Warren
Cc: Ian Campbell
Cc: Russell King
Cc: linux-o...@vger.kernel.org
Cc: devicet...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin
---
arch/arm/boot/dts/omap4460.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/omap4460.dtsi b/arch/arm/boot/dts/omap4460.dtsi
index c2f0f39..9855f29 100644
--- a/arch/arm/boot/dts/omap4460.dtsi
+++ b/arch/arm/boot/dts/omap4460.dtsi
@@ -30,6 +30,10 @@
ti,hwmods = "debugss";
};
+ thermal_zones{
+ #include "omap4-cpu-thermal.dtsi"
+ };
+
bandgap {
reg = <0x4a002260 0x4
0x4a00232C 0x4
@@ -37,5 +41,6 @@
compatible = "ti,omap4460-bandgap";
interrupts = <0 126 IRQ_TYPE_LEVEL_HIGH>; /* talert */
gpios = < 22 0>; /* tshut */
+ monitored-zones = <_thermal 0>;
};
};
--
1.8.2.1.342.gfa7285d
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 10/14] arm: dts: point to cooling-zones on omap4460 cpu node
OMAP4460 devices can reach high temperatures and thus needs to have cpufreq-cooling on systems running on it. This patch links the cpu node to its thermal-zone so that cpufreq-cpu0 driver loads the cooling device. Cc: "Benoît Cousson" Cc: Tony Lindgren Cc: Rob Herring Cc: Pawel Moll Cc: Mark Rutland Cc: Stephen Warren Cc: Ian Campbell Cc: Russell King Cc: linux-o...@vger.kernel.org Cc: devicet...@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Eduardo Valentin --- arch/arm/boot/dts/omap4460.dtsi | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/boot/dts/omap4460.dtsi b/arch/arm/boot/dts/omap4460.dtsi index 9855f29..991bd1b 100644 --- a/arch/arm/boot/dts/omap4460.dtsi +++ b/arch/arm/boot/dts/omap4460.dtsi @@ -20,6 +20,7 @@ 92 1313000 >; clock-latency = <30>; /* From legacy driver */ + cooling-zones = <_thermal>; }; }; -- 1.8.2.1.342.gfa7285d -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 04/14] hwmon: tmp102: expose to thermal fw via DT nodes
This patch adds to tmp102 temperature sensor the possibility
to expose itself as thermal zone device, registered on the
thermal framework.
The thermal zone is built only if a device tree node
describing a thermal zone for this sensor is present
inside the tmp102 DT node. Otherwise, the driver behavior
will be the same.
Cc: Jean Delvare
Cc: Guenter Roeck
Cc: lm-sens...@lm-sensors.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin
---
drivers/hwmon/tmp102.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/drivers/hwmon/tmp102.c b/drivers/hwmon/tmp102.c
index d7b47ab..0f1e44a 100644
--- a/drivers/hwmon/tmp102.c
+++ b/drivers/hwmon/tmp102.c
@@ -27,6 +27,8 @@
#include
#include
#include
+#include
+#include
#defineDRIVER_NAME "tmp102"
@@ -50,6 +52,7 @@
struct tmp102 {
struct device *hwmon_dev;
+ struct thermal_zone_device *tz;
struct mutex lock;
u16 config_orig;
unsigned long last_update;
@@ -93,6 +96,15 @@ static struct tmp102 *tmp102_update_device(struct i2c_client
*client)
return tmp102;
}
+static int tmp102_read_temp(void *dev, unsigned long *temp)
+{
+ struct tmp102 *tmp102 = tmp102_update_device(to_i2c_client(dev));
+
+ *temp = tmp102->temp[0];
+
+ return 0;
+}
+
static ssize_t tmp102_show_temp(struct device *dev,
struct device_attribute *attr,
char *buf)
@@ -204,10 +216,23 @@ static int tmp102_probe(struct i2c_client *client,
goto fail_remove_sysfs;
}
+ if (of_find_property(client->dev.of_node, "monitored-zones", NULL)) {
+ tmp102->tz = thermal_zone_of_device_register(>dev, 0,
+false, /* -hwmon */
+>dev,
+tmp102_read_temp);
+ if (IS_ERR(tmp102->tz)) {
+ status = PTR_ERR(tmp102->tz);
+ goto exit_hwmon;
+ }
+ }
+
dev_info(>dev, "initialized\n");
return 0;
+exit_hwmon:
+ hwmon_device_unregister(tmp102->hwmon_dev);
fail_remove_sysfs:
sysfs_remove_group(>dev.kobj, _attr_group);
fail_restore_config:
@@ -220,6 +245,7 @@ static int tmp102_remove(struct i2c_client *client)
{
struct tmp102 *tmp102 = i2c_get_clientdata(client);
+ thermal_zone_device_unregister(tmp102->tz);
hwmon_device_unregister(tmp102->hwmon_dev);
sysfs_remove_group(>dev.kobj, _attr_group);
--
1.8.2.1.342.gfa7285d
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 00/14] RFCv2: device thermal limits represented in device tree nodes
Hello all, First of all, apologize for the very late answer. But I am resuming this work. This RFC is about describing hardware thermal limits using device tree. Based on the discussion on the first RFC: http://lkml.org/lkml/2013/7/22/319 I have changed the code and the device tree bindings as follows: 1. Now bindings may have several thermal zones per device (req. by Wei Ni) 2. The constants used are now using C preprocessor macros (as per Stephen suggestion) 3. Improved the bindings to have a better representation of links between involved entities (thermal zone, cooling devices, sensors), as suggested by Pawel and Mark. 4. Couple of changes in code, as per previous reviews. 5. Removed policies from DT bindings. In summary, based on the discussion of the first RFC, now the idea is to have thermal zones nodes describing the thermal zones and the hardware limits. Then sensor devices nodes will point to thermal zones via phandles and cooling device will also point to thermal zone via phandles. So, I am also posting the patch series to dt mailing list as requested. Please refer to patch 02/14 to a documentation of what I am proposing. This patch series includes: a. Required changes in cpufreq-cpu0 driver so that it loads cooling device when requested. b. The thermal zone builder based on thermal bindings c. Changes in sensor drivers (as examples) d. Changes in device tree DTS files (as examples) This patch series depends on the fixes I sent to linux-pm: http://lkml.org/lkml/2013/8/23/572 In the above link you will find also the request to have a flag to determine if virtual hwmon device will be created, based on thermal device. All best, Eduardo Valentin (14): cpufreq: cpufreq-cpu0: add dt node parsing for 'cooling-zones' drivers: thermal: introduce device tree parser hwmon: lm75: expose to thermal fw via DT nodes hwmon: tmp102: expose to thermal fw via DT nodes thermal: ti-soc-thermal: use thermal DT infrastructure arm: dts: add omap4 CPU thermal data arm: dts: add omap4430 thermal data arm: dts: add omap4460 thermal data arm: dts: point to cooling-zones on omap4430 cpu node arm: dts: point to cooling-zones on omap4460 cpu node arm: dts: add omap5 GPU thermal data arm: dts: add omap5 CORE thermal data arm: dts: add omap5 thermal data arm: dts: point to cooling-zones on omap5 cpu node .../devicetree/bindings/cpufreq/cpufreq-cpu0.txt | 4 + .../devicetree/bindings/thermal/thermal.txt| 160 +++ arch/arm/boot/dts/omap4-cpu-thermal.dtsi | 40 ++ arch/arm/boot/dts/omap443x.dtsi| 6 + arch/arm/boot/dts/omap4460.dtsi| 6 + arch/arm/boot/dts/omap5-core-thermal.dtsi | 27 ++ arch/arm/boot/dts/omap5-gpu-thermal.dtsi | 27 ++ arch/arm/boot/dts/omap5.dtsi | 10 + drivers/cpufreq/cpufreq-cpu0.c | 12 + drivers/hwmon/lm75.c | 31 ++ drivers/hwmon/tmp102.c | 26 ++ drivers/thermal/Kconfig| 13 + drivers/thermal/Makefile | 1 + drivers/thermal/thermal_dt.c | 473 + drivers/thermal/ti-soc-thermal/ti-thermal-common.c | 52 ++- include/dt-bindings/thermal/thermal.h | 27 ++ include/linux/thermal.h| 3 + 17 files changed, 907 insertions(+), 11 deletions(-) create mode 100644 Documentation/devicetree/bindings/thermal/thermal.txt create mode 100644 arch/arm/boot/dts/omap4-cpu-thermal.dtsi create mode 100644 arch/arm/boot/dts/omap5-core-thermal.dtsi create mode 100644 arch/arm/boot/dts/omap5-gpu-thermal.dtsi create mode 100644 drivers/thermal/thermal_dt.c create mode 100644 include/dt-bindings/thermal/thermal.h -- 1.8.2.1.342.gfa7285d -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 02/14] drivers: thermal: introduce device tree parser
In order to be able to build thermal policies
based on generic sensors, like I2C device, that
can be places in different points on different boards,
there is a need to have a way to feed board dependent
data into the thermal framework.
This patch introduces a thermal data parser for device
tree. The parsed data is used to build thermal zones
and thermal binding parameters. The output data
can then be used to deploy thermal policies.
This patch adds also documentation regarding this
API and how to define tree nodes to use
this infrastructure.
Cc: Zhang Rui
Cc: linux...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin
---
.../devicetree/bindings/thermal/thermal.txt| 160 +++
drivers/thermal/Kconfig| 13 +
drivers/thermal/Makefile | 1 +
drivers/thermal/thermal_dt.c | 473 +
include/dt-bindings/thermal/thermal.h | 27 ++
include/linux/thermal.h| 3 +
6 files changed, 677 insertions(+)
create mode 100644 Documentation/devicetree/bindings/thermal/thermal.txt
create mode 100644 drivers/thermal/thermal_dt.c
create mode 100644 include/dt-bindings/thermal/thermal.h
diff --git a/Documentation/devicetree/bindings/thermal/thermal.txt
b/Documentation/devicetree/bindings/thermal/thermal.txt
new file mode 100644
index 000..af20ab0
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/thermal.txt
@@ -0,0 +1,160 @@
+
+Thermal Framework Device Tree descriptor
+
+
+This file describes how to define a thermal structure using device tree.
+A thermal structure includes thermal zones and their components, such
+as name, trip points, polling intervals and cooling devices binding
+descriptors. A binding descriptor may contain information on how to
+react, with a cooling stepped action or a weight on a fair share.
+The target of device tree thermal descriptors is to describe only
+the hardware thermal aspects, not how the system must control or which
+algorithm or policy must take place. It follows a description of each
+type of device tree node.
+
+
+trip
+
+
+The trip node is a node to describe a point in the temperature domain
+in which the system takes an action. This node describes just the point,
+not the action.
+
+A node describing a trip must contain:
+- temperature: the trip temperature level, in milliCelsius.
+- hysteresis: a (low) hysteresis value on 'temperature'. This is a relative
+value, in milliCelsius.
+- type: the trip type. Here is the type mapping:
+ THERMAL_TRIP_ACTIVE
+ THERMAL_TRIP_PASSIVE
+ THERMAL_TRIP_HOT
+ THERMAL_TRIP_CRITICAL
+
+**
+bind_param
+**
+
+The bind_param node is a node to describe how cooling devices get assigned
+to trip points of the zone. The cooling devices are expected to be loaded
+in the target system.
+
+A node describing a bind_param must contain:
+- cooling_device: A string with the cooling device name.
+- weight: The 'influence' of a particular cooling device on this zone.
+ This is on a percentage scale. The sum of all these weights
+ (for a particular zone) cannot exceed 100.
+- trip_mask: This is a bit mask that gives the binding relation between
+ this thermal zone and cdev, for a particular trip point.
+ If nth bit is set, then the cdev and thermal zone are bound
+ for trip point n.
+- limits: An array integers consisting of 2-tuples items, and each item means
+ lower and upper state limits, like .
+
+**
+temperature sensor devices
+**
+
+Temperature sensor devices have to be linked to a specific thermal zone.
+This is done by means of the 'monitored-zones' list.
+- monitored-zones: A list of thermal zones phandles, identifying which
+thermal zones the temperature sensor device is used to monitor.
+
+
+thermal_zone
+
+
+The thermal_zone node is the node containing all the required info
+for describing a thermal zone, including its cdev bindings. The thermal_zone
+node must contain, apart from its own properties, one node containing
+trip nodes and one node containing all the zone bind parameters.
+
+Required properties:
+- mask: Bit string: If 'n'th bit is set, then trip point 'n' is writeable.
+
+- passive_delay: number of milliseconds to wait between polls when
+ performing passive cooling.
+
+- polling_delay: number of milliseconds to wait between polls when checking.
+
+- #thermal-cells: An integer that is used to specify how many cells compose
+ sensor ids.
+
+Below is an example:
+cpu_thermal: thermal_zone {
+#thermal-cells = <1>;
+mask = <0x03>; /* trips writability */
+passive_delay = <250>; /* milliseconds */
+polling_delay = <1000>; /* milliseconds
[RFC PATCH 03/14] hwmon: lm75: expose to thermal fw via DT nodes
This patch adds to lm75 temperature sensor the possibility
to expose itself as thermal zone device, registered on the
thermal framework.
The thermal zone is built only if a device tree node
describing a thermal zone for this sensor is present
inside the lm75 DT node. Otherwise, the driver behavior
will be the same.
Cc: Jean Delvare
Cc: Guenter Roeck
Cc: lm-sens...@lm-sensors.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin
---
drivers/hwmon/lm75.c | 31 +++
1 file changed, 31 insertions(+)
diff --git a/drivers/hwmon/lm75.c b/drivers/hwmon/lm75.c
index c03b490..dc55908 100644
--- a/drivers/hwmon/lm75.c
+++ b/drivers/hwmon/lm75.c
@@ -27,6 +27,8 @@
#include
#include
#include
+#include
+#include
#include "lm75.h"
@@ -70,6 +72,7 @@ static const u8 LM75_REG_TEMP[3] = {
/* Each client has this additional data */
struct lm75_data {
struct device *hwmon_dev;
+ struct thermal_zone_device *tz;
struct mutexupdate_lock;
u8 orig_conf;
u8 resolution; /* In bits, between 9 and 12 */
@@ -92,6 +95,19 @@ static struct lm75_data *lm75_update_device(struct device
*dev);
/* sysfs attributes for hwmon */
+static int lm75_read_temp(void *dev, unsigned long *temp)
+{
+ struct lm75_data *data = lm75_update_device(dev);
+
+ if (IS_ERR(data))
+ return PTR_ERR(data);
+
+ *temp = ((data->temp[0] >> (16 - data->resolution)) * 1000) >>
+ (data->resolution - 8);
+
+ return 0;
+}
+
static ssize_t show_temp(struct device *dev, struct device_attribute *da,
char *buf)
{
@@ -271,11 +287,25 @@ lm75_probe(struct i2c_client *client, const struct
i2c_device_id *id)
goto exit_remove;
}
+ if (of_find_property(client->dev.of_node, "monitored-zones", NULL)) {
+ data->tz = thermal_zone_of_device_register(>dev,
+ 0,
+ false, /* -hwmon */
+ >dev,
+ lm75_read_temp);
+ if (IS_ERR(data->tz)) {
+ status = PTR_ERR(data->tz);
+ goto exit_hwmon;
+ }
+ }
+
dev_info(>dev, "%s: sensor '%s'\n",
dev_name(data->hwmon_dev), client->name);
return 0;
+exit_hwmon:
+ hwmon_device_unregister(data->hwmon_dev);
exit_remove:
sysfs_remove_group(>dev.kobj, _group);
return status;
@@ -285,6 +315,7 @@ static int lm75_remove(struct i2c_client *client)
{
struct lm75_data *data = i2c_get_clientdata(client);
+ thermal_zone_device_unregister(data->tz);
hwmon_device_unregister(data->hwmon_dev);
sysfs_remove_group(>dev.kobj, _group);
lm75_write_value(client, LM75_REG_CONF, data->orig_conf);
--
1.8.2.1.342.gfa7285d
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 01/14] cpufreq: cpufreq-cpu0: add dt node parsing for 'cooling-zones'
This patch changes the cpufreq-cpu0 driver to consider if
a cpu needs cooling (with cpufreq). In case the cooling is needed,
it can be flagged at the cpu0 device tree node, with the list
of zones property 'cooling-zones'.
In case this list of zones is 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"
Cc: Viresh Kumar
Cc: Grant Likely
Cc: Rob Herring
Cc: cpuf...@vger.kernel.org
Cc: linux...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: devicetree-disc...@lists.ozlabs.org
Signed-off-by: Eduardo Valentin
---
Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt | 4
drivers/cpufreq/cpufreq-cpu0.c | 12
2 files changed, 16 insertions(+)
diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
b/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
index 051f764..add50f7 100644
--- a/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
+++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
@@ -15,6 +15,9 @@ 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-zones: A list of thermal zones phandles. The generic cpu
+ cooling (freq clipping) is loaded by the generic cpufreq-cpu0 driver
+ in case the device tree node has this list.
Examples:
@@ -33,6 +36,7 @@ cpus {
198000 85
>;
clock-latency = <61036>; /* two CLK32 periods */
+ cooling-zones = <_thermal>;
};
cpu@1 {
diff --git a/drivers/cpufreq/cpufreq-cpu0.c b/drivers/cpufreq/cpufreq-cpu0.c
index ad1fde2..ede6487 100644
--- a/drivers/cpufreq/cpufreq-cpu0.c
+++ b/drivers/cpufreq/cpufreq-cpu0.c
@@ -20,6 +20,9 @@
#include
#include
#include
+#include
+#include
+#include
static unsigned int transition_latency;
static unsigned int voltage_tolerance; /* in percentage */
@@ -28,6 +31,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)
{
@@ -268,6 +272,13 @@ 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-zones", NULL))
+ cdev = cpufreq_cooling_register(cpu_present_mask);
+
of_node_put(np);
of_node_put(parent);
return 0;
@@ -283,6 +294,7 @@ out_put_parent:
static int cpu0_cpufreq_remove(struct platform_device *pdev)
{
+ cpufreq_cooling_unregister(cdev);
cpufreq_unregister_driver(_cpufreq_driver);
opp_free_cpufreq_table(cpu_dev, _table);
--
1.8.2.1.342.gfa7285d
--
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/3] cpuidle: coupled: disable interrupts after entering safe state
On 08/23/2013 01:45 PM, Colin Cross wrote: > Calling cpuidle_enter_state is expected to return with interrupts > enabled, but interrupts must be disabled before starting the > ready loop synchronization stage. Call local_irq_disable after > each call to cpuidle_enter_state for the safe state. Tested-by: Stephen Warren Note: I tested the current Tegra cpuidle code that's in next-20130819. IIRC, Joseph reported the issue when trying to enable some additional feature in Tegra30 cpuidle. I didn't actually try to enable whatever that was; I just briefly tested for regressions in the existing code configuration. -- 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/1] AMD64_EDAC: Fix incorrect wrap arounds due to left shift beyond 32 bits.
On 8/23/2013 4:37 PM, Borislav Petkov wrote: On Mon, Aug 19, 2013 at 07:27:52PM -0500, Aravind Gopalakrishnan wrote: Link to the bug report: http://marc.info/?l=linux-edac=137692201732220=2 dct_base and dct_limit obtain 32 bit register values when they read their respective pci config space registers. A left shift beyond 32 bits will cause them to wrap around. Similar case for chan_addr as can be seen from the bug report. In the patch, we rectify this by casting chan_addr to u64 and by comparing dct_base and dct_limit against (sys_addr >> 27) Tested on F15h, M30h with ECC turned on and works fine. Signed-off-by: Aravind Gopalakrishnan diff --git a/drivers/edac/amd64_edac.c b/drivers/edac/amd64_edac.c index b86228c..eb4793e 100644 --- a/drivers/edac/amd64_edac.c +++ b/drivers/edac/amd64_edac.c @@ -1558,11 +1558,12 @@ static int f15_m30h_match_to_this_node(struct amd64_pvt *pvt, unsigned range, } /* Verify sys_addr is within DCT Range. */ - dct_base = (dct_sel_baseaddr(pvt) << 27); - dct_limit = (((dct_cont_limit_reg >> 11) & 0x1FFF) << 27) | 0x7FF; + dct_base = dct_sel_baseaddr(pvt); This can't be correct. So the original patch takes the shifted dct_base while your change doesn't anymore... + dct_limit = (dct_cont_limit_reg >> 11) & 0x1FFF; if (!(dct_cont_base_reg & BIT(0)) && - !(dct_base <= sys_addr && dct_limit >= sys_addr)) + !(dct_base <= (sys_addr >> 27) && + dct_limit >= (sys_addr >> 27))) ... and while this comparison shifts sys_addr to use the proper bits, the code does this assignment later: chan_offset = dct_base; Now, chan_offset has the << 27 version of dct_base which makes the following calculation wrong: chan_addr = sys_addr - chan_offset; Oops. my apologies. because sys_addr is the full 64-bit, unshifted value. The right thing to do would be to do: chan_offset = dct_base << 27; Or am I missing something? No, you are right. I am re-sending the patch. Thanks, -Aravind. -- 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 0/8] x86, acpi: Move acpi_initrd_override() earlier.
> So we need to allocate memory. That is why you suggested to use BRK, right ? > And the size seems to be a problem. > > So I suggest to use early_ioremap(). > > 1. After paging is enabled, before direct mapping page tables are > setup, we map the > initrd with early_ioremap(). And we are able to access it with va, > even on 32bit. > Then we can find all tables. > 2. We still use memblock to allocate memory. Maybe it will be > hotpluggable memory, > but this memory can be freed when all the acpi tables are parsed, right ? > > So I want to try early_ioremap(). All these should be done in setup_arch(). no. cpio search need to take whole range virtual address, and early_ioremap has size limitation. you will have to update cpio search to take mapping function. could be too messy. Yinghai -- 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 2/4] clk: implement clk_unregister
On 08/23/2013 11:58 PM, Mike Turquette wrote:
+static void clk_nodrv_disable_unprepare(struct clk_hw *hw)
> +{
> + WARN_ON(1);
Ideally we shouldn't get here, but if we do I guess it could be very
noisy. How about WARN_ONCE?
Yes, I guess that would be much better. I could resend it tomorrow if
needed.
After you address Russell's comments in patch #1 I will be happy to take
this series.
I have posted today v3 addressing Russell's comments. Hopefully patch #3
(the patches got reordered) looks OK now. v3 includes actual assigning
of clk->owner I somehow managed to miss in previous series :/ Please have
a look at it.
--
Regards,
Sylwester
--
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] drivers: thermal: make usage of CONFIG_THERMAL_HWMON optional
On Friday, August 23, 2013 06:03:14 PM Eduardo Valentin wrote:
> When registering a new thermal_device, the thermal framework
> will always add a hwmon sysfs interface.
>
> This patch adds a flag to make this behavior optional. Now
> when registering a new thermal device, the caller needs
> to say if the hwmon interface is required.
>
> In order to keep same behavior as of today, all current
> calls will by default create the hwmon interface.
Well, instead of modifying all of the callers this way, why don't
you add new versions taking the additional argument as, for example,
thermal_zone_device_register_full()
and redefine the old ones as static inline wrappers, for example
static inline struct thermal_zone_device *thermal_zone_device_register(args)
{
return thermal_zone_device_register_full(args, true);
}
?
That'd reduce the size of this patch a bit I suppose (and the number of
subsystems involved at the same time).
Thanks,
Rafael
> Cc: Anton Vorontsov
> Cc: David Woodhouse
> Cc: devicet...@vger.kernel.org
> Cc: Grant Likely
> Cc: Kukjin Kim
> Cc: Len Brown
> Cc: linux-a...@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux...@vger.kernel.org
> Cc: linux-samsung-...@vger.kernel.org
> Cc: Matthew Garrett
> Cc: Peter Feuerer
> Cc: platform-driver-...@vger.kernel.org
> Cc: "Rafael J. Wysocki"
> Cc: Rob Herring
> Cc: Zhang Rui
> Suggested-by: Wei Ni
> Signed-off-by: Eduardo Valentin
> ---
> Documentation/thermal/sysfs-api.txt| 4 +++-
> drivers/acpi/thermal.c | 6 --
> drivers/platform/x86/acerhdf.c | 3 ++-
> drivers/platform/x86/intel_mid_thermal.c | 2 +-
> drivers/power/power_supply_core.c | 2 +-
> drivers/thermal/armada_thermal.c | 2 +-
> drivers/thermal/db8500_thermal.c | 2 +-
> drivers/thermal/dove_thermal.c | 2 +-
> drivers/thermal/exynos_thermal.c | 2 +-
> drivers/thermal/kirkwood_thermal.c | 2 +-
> drivers/thermal/rcar_thermal.c | 2 +-
> drivers/thermal/spear_thermal.c| 2 +-
> drivers/thermal/thermal_core.c | 13 +
> drivers/thermal/ti-soc-thermal/ti-thermal-common.c | 2 +-
> drivers/thermal/x86_pkg_temp_thermal.c | 2 +-
> include/linux/thermal.h| 2 +-
> 16 files changed, 30 insertions(+), 20 deletions(-)
>
> diff --git a/Documentation/thermal/sysfs-api.txt
> b/Documentation/thermal/sysfs-api.txt
> index a71bd5b..4b4a052 100644
> --- a/Documentation/thermal/sysfs-api.txt
> +++ b/Documentation/thermal/sysfs-api.txt
> @@ -64,7 +64,9 @@ temperature) and throttle appropriate devices.
> performing passive cooling.
> polling_delay: number of milliseconds to wait between polls when checking
> whether trip points have been crossed (0 for interrupt driven systems).
> -
> +add_hwmon: a boolean to indicate if the thermal to hwmon sysfs interface
> + is required. When add_hwmon == true, a hwmon sysfs interface
> + will be created. When add_hwmon == false, nothing will be done
>
> 1.1.2 void thermal_zone_device_unregister(struct thermal_zone_device *tz)
>
> diff --git a/drivers/acpi/thermal.c b/drivers/acpi/thermal.c
> index a33821c..4d542b4 100644
> --- a/drivers/acpi/thermal.c
> +++ b/drivers/acpi/thermal.c
> @@ -916,12 +916,14 @@ static int acpi_thermal_register_thermal_zone(struct
> acpi_thermal *tz)
> thermal_zone_device_register("acpitz", trips, 0, tz,
> _thermal_zone_ops, NULL,
>tz->trips.passive.tsp*100,
> - tz->polling_frequency*100);
> + tz->polling_frequency*100,
> + true);
> else
> tz->thermal_zone =
> thermal_zone_device_register("acpitz", trips, 0, tz,
> _thermal_zone_ops, NULL,
> - 0, tz->polling_frequency*100);
> + 0, tz->polling_frequency*100,
> + true);
> if (IS_ERR(tz->thermal_zone))
> return -ENODEV;
>
> diff --git a/drivers/platform/x86/acerhdf.c b/drivers/platform/x86/acerhdf.c
> index f94467c..004d9ba0 100644
> --- a/drivers/platform/x86/acerhdf.c
> +++ b/drivers/platform/x86/acerhdf.c
> @@ -663,7 +663,8 @@ static int acerhdf_register_thermal(void)
>
> thz_dev = thermal_zone_device_register("acerhdf", 1, 0, NULL,
> _dev_ops, NULL, 0,
> - (kernelmode) ?
Re: [PATCH 0/4] seqlock: Add new blocking reader type & use rwlock
On 07/03/2013 09:52 PM, Waiman Long wrote: During some perf-record sessions of the kernel running the high_systime workload of the AIM7 benchmark, it was found that quite a large portion of the spinlock contention was due to the perf_event_mmap_event() function itself. This perf kernel function calls d_path() which, in turn, call path_get() and dput() indirectly. These 3 functions were the hottest functions shown in the perf-report output of the _raw_spin_lock() function in an 8-socket system with 80 cores (hyperthreading off) with a 3.10-rc1 kernel: - 13.91% reaim [kernel.kallsyms] [k] _raw_spin_lock - _raw_spin_lock + 35.54% path_get + 34.85% dput + 19.49% d_path In fact, the output of the "perf record -s -a" (without call-graph) showed: 13.37% reaim [kernel.kallsyms] [k] _raw_spin_lock 7.61% ls [kernel.kallsyms] [k] _raw_spin_lock 3.54%true [kernel.kallsyms] [k] _raw_spin_lock Without using the perf monitoring tool, the actual execution profile will be quite different. In fact, with this patch set and my other lockless reference count update patch applied, the output of the same "perf record -s -a" command became: 2.82% reaim [kernel.kallsyms] [k] _raw_spin_lock 1.11% ls [kernel.kallsyms] [k] _raw_spin_lock 0.26%true [kernel.kallsyms] [k] _raw_spin_lock So the time spent on _raw_spin_lock() function went down from 24.52% to 4.19%. It can be seen that the performance data collected by the perf-record command can be heavily skewed in some cases on a system with a large number of CPUs. This set of patches enables the perf command to give a more accurate and reliable picture of what is really happening in the system. At the same time, they can also improve the general performance of systems especially those with a large number of CPUs. The d_path() function takes the following two locks: 1. dentry->d_lock [spinlock] from dget()/dget_parent()/dput() 2. rename_lock[seqlock] from d_path() This set of patches address the rename_lock bottleneck by changing the way seqlock is implemented so that we can optionally use a read/write lock as the underlying implementation instead of the default spinlock. Incidentally, this patch also provides slight 5% performance boost over just the the lockless reference count update patch in the short workload of the AIM7 benchmark running on a 8-socket 80-core DL980 machine on a 3.10-based kernel. There were still a few percentage points of contention in d_path() and getcwd syscall left due to their use of the rename_lock. Signed-off-by: Waiman Long Waiman Long (4): seqlock: Add a new blocking reader type dcache: Use blocking reader seqlock when protected data are not changed seqlock: Allow the use of rwlock in seqlock dcache: Use rwlock as the underlying lock in rename_lock fs/dcache.c | 28 include/linux/seqlock.h | 167 --- 2 files changed, 158 insertions(+), 37 deletions(-) I haven't received any feedback on this patchset. Would you mind letting me know if any further change will be needed to make it acceptable to be merged? Thank, Longman -- 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 0/8] x86, acpi: Move acpi_initrd_override() earlier.
Hi Yinghai, 2013/8/24 Yinghai Lu : > On Fri, Aug 23, 2013 at 2:50 PM, chen tang wrote: >>> >>> so the DSDT is 7F493E, and total is more than 8M. >>> >>> that will need BRK to be extended 16M? >>> >> >> Then how about use early_ioremap(), and don't do it that early in >> head_32 and head64 ? > > why could early_ioremap() help? > > when to use early_ioremap()? what for? > In my understanding, acpica framework needs users to copy the override tables somewhere in the memory. And acpica will get these user specified tables when installing firmware tables. This is the acpica logic, which cannot be changed, I think. So we need to allocate memory. That is why you suggested to use BRK, right ? And the size seems to be a problem. So I suggest to use early_ioremap(). 1. After paging is enabled, before direct mapping page tables are setup, we map the initrd with early_ioremap(). And we are able to access it with va, even on 32bit. Then we can find all tables. 2. We still use memblock to allocate memory. Maybe it will be hotpluggable memory, but this memory can be freed when all the acpi tables are parsed, right ? So I want to try early_ioremap(). All these should be done in setup_arch(). 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/
Re: [PATCH V3 RFC 00/16] EFI stub for ARM
On Fri, Aug 16, 2013 at 5:16 PM, Roy Franz wrote: > On Tue, Aug 13, 2013 at 10:58 AM, Roy Franz wrote: >> On Fri, Aug 9, 2013 at 4:26 PM, Roy Franz wrote: >>> >>> This patch series adds EFI stub support for the ARM architecture. >>> Some code that was previously only used by x86/x86_64 is now shared >>> and has been made more general. The stub for ARM is implemented in >>> a similar manner to x86 in that it is a shim layer between EFI and >>> the normal zImage/bzImage boot process, and that an image with the >>> stub configured is bootable as both a zImage and EFI application. >>> >>> This patch now (new for v3) series depends on the >>> "arm: Add [U]EFI runtime services support" patches by >>> leif.lindh...@linaro.org. >>> The Kconfig option now depends on the "CONFIG_EFI" option that his series >>> adds, and this option will ensure a little endian configuration. Also, the >>> EFI support is used to handle the EFI memory map the stub passes to the >>> kernel. >>> There are some minor changes to be coordinated with the EFI runtime services >>> patch series, so I have put this back to RFC status. These changes should >>> be >>> minor and relate to final device tree bindings. >>> >>> Changes since v2: >>> * EFI bugfix "correct call to free_pages" that patch series >>> depends on now in mainline >>> * remove "-fno-stack-protector" from decompressor Makefile. The current >>> code doesn't >>> trigger the stack protection, so the decompressor now compiles with it >>> still >>> on. Note that there has never been any stack protection in the >>> decompressor >>> since the stack usage doesn't trigger the heuristic in GCC, so right now >>> the "-fno-stack-protector" is a noop. >>> * Changed EFI command line handling to not have a fixed limit. >>> * Change FDT memory allocation to retry with a larger allocation if >>> first educated guess is inadequate. >>> * Correctly set 'SizeOfCode' in PE/COFF header. >>> * Reviewed ".setup" section that is in x86 PE/COFF header. This is used >>> for x86 >>> to account for code that is not in the .text section. We don't need this >>> for ARM, as all of our code is in the .text section, or in the PE/COFF >>> header >>> itself. >>> * Moved EFI_STUB_ERROR #define to header file to share between stub C and >>> ASM. >>> * Variety of cleanups and fixes in head.S. >>> * Changed update_fdt_and_exit_boot() to just update the device tree, and >>> renamed appropriately. Memory allocations moved out of this function as >>> well, which enables the retries if the initial FDT size is too small. >>> Note that in order to do the retried allocations, the original FDT and >>> command line memory regions are left allocated. This is OK since the >>> kernel >>> has the memory map and will free these allocations along with the initrd >>> and new fdt allocations. >>> * Added prefix to all prints, reduced number of prints, and reviewed all >>> messages. >>> * Change mixed usage of dtb/fdt to all be fdt or "device tree" in efi-stub.c >>> * remove unnecessary zimage_size variable from relocate_kernel() >>> * correct return types on EFI functions - should be efi_status_t, not int. >>> >>> >>> >>> Changes since V1: >>> * Updated head.S based on feedback from Dave Martin. ARM/THUMB >>> switches now much cleaner. >>> * Broke up changes to x86 and common code into more patches. >>> 10 more patches in this series. >>> >>> Roy Franz (16): >>> Move common EFI stub code from x86 arch code to common location >>> Add system pointer argument to shared EFI stub related functions >>> so they no longer use global system table pointer as they did >>> when part of eboot.c. This code is now shared, so using a >>> global variable as part of the interface is not that nice. >>> Also, by avoiding any global variables in the ARM EFI stub, >>> this allows the code to be position independent without >>> requiring GOT fixups. >>> Rename memory allocation/free functions >>> Add minimum address parameter to efi_low_alloc() >>> rename __get_map() to efi_get_memory_map(), add parameter to >>> optionally return mmap key. The mmap key is required to exit >>> EFI boot services, and allows efi_get_memory_map() to be used >>> for getting final memory map. >>> Enforce minimum alignment of 1 page on allocations. The >>> efi_high_alloc() and efi_low_alloc() functions use the >>> EFI_ALLOCATE_ADDRESS option to the EFI function >>> allocate_pages(), which requires a minimum of page alignment, >>> and rejects all other requests. >>> Allow efi_free() to be called with size of 0, and do nothing in that >>> case. >>> Generalize handle_ramdisks() and rename to handle_cmdline_files(). >>> Renames in handle_cmdline_files() to complete generalization. >>> Move EFI_READ_CHUNK_SIZE define to shared location. >>> Add proper definitions for some EFI function pointers. >>>
Re: [PATCH 0/8] x86, acpi: Move acpi_initrd_override() earlier.
On Fri, Aug 23, 2013 at 2:50 PM, chen tang wrote: >> >> so the DSDT is 7F493E, and total is more than 8M. >> >> that will need BRK to be extended 16M? >> > > Then how about use early_ioremap(), and don't do it that early in > head_32 and head64 ? why could early_ioremap() help? when to use early_ioremap()? what for? Yinghai -- 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 0/8] x86, acpi: Move acpi_initrd_override() earlier.
On Fri, Aug 23, 2013 at 2:52 PM, Moore, Robert wrote: > While we're at it: > > Can someone send me the acpidump for this machine? We very much would like to > test all of ACPICA with such a large DSDT. That is Russ. -- 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/5] drivers: thermal: make usage of CONFIG_THERMAL_HWMON optional
When registering a new thermal_device, the thermal framework
will always add a hwmon sysfs interface.
This patch adds a flag to make this behavior optional. Now
when registering a new thermal device, the caller needs
to say if the hwmon interface is required.
In order to keep same behavior as of today, all current
calls will by default create the hwmon interface.
Cc: Anton Vorontsov
Cc: David Woodhouse
Cc: devicet...@vger.kernel.org
Cc: Grant Likely
Cc: Kukjin Kim
Cc: Len Brown
Cc: linux-a...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Cc: linux...@vger.kernel.org
Cc: linux-samsung-...@vger.kernel.org
Cc: Matthew Garrett
Cc: Peter Feuerer
Cc: platform-driver-...@vger.kernel.org
Cc: "Rafael J. Wysocki"
Cc: Rob Herring
Cc: Zhang Rui
Suggested-by: Wei Ni
Signed-off-by: Eduardo Valentin
---
Documentation/thermal/sysfs-api.txt| 4 +++-
drivers/acpi/thermal.c | 6 --
drivers/platform/x86/acerhdf.c | 3 ++-
drivers/platform/x86/intel_mid_thermal.c | 2 +-
drivers/power/power_supply_core.c | 2 +-
drivers/thermal/armada_thermal.c | 2 +-
drivers/thermal/db8500_thermal.c | 2 +-
drivers/thermal/dove_thermal.c | 2 +-
drivers/thermal/exynos_thermal.c | 2 +-
drivers/thermal/kirkwood_thermal.c | 2 +-
drivers/thermal/rcar_thermal.c | 2 +-
drivers/thermal/spear_thermal.c| 2 +-
drivers/thermal/thermal_core.c | 13 +
drivers/thermal/ti-soc-thermal/ti-thermal-common.c | 2 +-
drivers/thermal/x86_pkg_temp_thermal.c | 2 +-
include/linux/thermal.h| 2 +-
16 files changed, 30 insertions(+), 20 deletions(-)
diff --git a/Documentation/thermal/sysfs-api.txt
b/Documentation/thermal/sysfs-api.txt
index a71bd5b..4b4a052 100644
--- a/Documentation/thermal/sysfs-api.txt
+++ b/Documentation/thermal/sysfs-api.txt
@@ -64,7 +64,9 @@ temperature) and throttle appropriate devices.
performing passive cooling.
polling_delay: number of milliseconds to wait between polls when checking
whether trip points have been crossed (0 for interrupt driven systems).
-
+add_hwmon: a boolean to indicate if the thermal to hwmon sysfs interface
+ is required. When add_hwmon == true, a hwmon sysfs interface
+ will be created. When add_hwmon == false, nothing will be done
1.1.2 void thermal_zone_device_unregister(struct thermal_zone_device *tz)
diff --git a/drivers/acpi/thermal.c b/drivers/acpi/thermal.c
index a33821c..4d542b4 100644
--- a/drivers/acpi/thermal.c
+++ b/drivers/acpi/thermal.c
@@ -916,12 +916,14 @@ static int acpi_thermal_register_thermal_zone(struct
acpi_thermal *tz)
thermal_zone_device_register("acpitz", trips, 0, tz,
_thermal_zone_ops, NULL,
tz->trips.passive.tsp*100,
-tz->polling_frequency*100);
+tz->polling_frequency*100,
+true);
else
tz->thermal_zone =
thermal_zone_device_register("acpitz", trips, 0, tz,
_thermal_zone_ops, NULL,
- 0, tz->polling_frequency*100);
+ 0, tz->polling_frequency*100,
+ true);
if (IS_ERR(tz->thermal_zone))
return -ENODEV;
diff --git a/drivers/platform/x86/acerhdf.c b/drivers/platform/x86/acerhdf.c
index f94467c..004d9ba0 100644
--- a/drivers/platform/x86/acerhdf.c
+++ b/drivers/platform/x86/acerhdf.c
@@ -663,7 +663,8 @@ static int acerhdf_register_thermal(void)
thz_dev = thermal_zone_device_register("acerhdf", 1, 0, NULL,
_dev_ops, NULL, 0,
- (kernelmode) ? interval*1000 : 0);
+ (kernelmode) ? interval*1000 : 0,
+ true);
if (IS_ERR(thz_dev))
return -EINVAL;
diff --git a/drivers/platform/x86/intel_mid_thermal.c
b/drivers/platform/x86/intel_mid_thermal.c
index 81c491e..efea0bf 100644
--- a/drivers/platform/x86/intel_mid_thermal.c
+++ b/drivers/platform/x86/intel_mid_thermal.c
@@ -502,7 +502,7 @@ static int mid_thermal_probe(struct platform_device *pdev)
goto err;
}
pinfo->tzd[i] = thermal_zone_device_register(name[i],
- 0, 0, td_info, _ops, NULL, 0, 0);
+
Re: [PATCH] ACPI: Fix osc flag setup ordering to allow pcie hotplug use when available
On Fri, Aug 23, 2013 at 3:40 PM, Rafael J. Wysocki wrote: > On Friday, August 23, 2013 02:46:23 PM Bjorn Helgaas wrote: >> On Fri, Aug 23, 2013 at 2:53 PM, Rafael J. Wysocki wrote: >> > On Friday, August 23, 2013 04:05:11 PM Neil Horman wrote: >> >> On Fri, Aug 23, 2013 at 09:38:18PM +0200, Rafael J. Wysocki wrote: >> >> > [CCs added] >> >> > >> >> > Please always send PCI-related material to linux-pci in the first place. >> >> > >> >> Sorry, I ran get_maintainers and it seemed to think linux-acpi was >> >> sufficient. >> >> >> >> > The change that broke things for you was actually intentional: >> >> > >> >> > commit b8178f130e25c1bdac1c33e0996f1ff6e20ec08e >> >> > Author: Bjorn Helgaas >> >> > Date: Mon Apr 1 15:47:39 2013 -0600 >> >> > >> >> > Revert "PCI/ACPI: Request _OSC control before scanning PCI root bus" >> >> > >> >> > This reverts commit 8c33f51df406e1a1f7fa4e9b244845b7ebd61fa6. >> >> > >> >> > so I think we'll need to clean up the ASMP initialization after all. >> >> > >> >> Crud. Reading over the revert commit, it seems like the problem boils >> >> down to >> >> the odering of checking aspm_disabled. It seems to me that the simple >> >> fix is to >> >> track the desire for acpi to disable aspm separately from the users >> >> desire to >> >> disable aspm (aspm_disabled). Then we just turn the points where we >> >> check the >> >> aspm_disabled into the appropriate or of two variables, except for >> >> pcie_asmp_sanity_check, which remains sensitive to just the user disable >> >> option. >> >> >> >> Or is there more to this? >> > >> > No, I think you're right. >> > >> > Bjorn, what do you think? >> >> My opinion is that the _OSC/ASPM state management is ridiculously >> complicated already, and this would make it slightly more complicated. >> That's why my preference would be to attempt a more radical cleanup >> and simplification instead of adding another wart. > > Well, do you have anything specific in mind? If I had a specific fix in mind, I would just post it, but I've never had time to work through it all. What I mean by complicated is that every time I have to look at ASPM, I have to start by trying to figure out the relationships between these variables: aspm_policy # default 0 (POLICY_DEFAULT) or POLICY_PERFORMANCE or POLICY_POWERSAVE depending on config aspm_disabled # default 0 aspm_force # default 0 aspm_support_enabled# default true plus the _OSC-related code in acpi_pci_root_add(), which honestly is a rat's nest. It sounds like Neil's fix (while probably correct) would tangle that nest a little more. But I guess it would make sense to see the actual patch and the justification (a regression fix, I suppose, but the details weren't clear to me) before deciding. >> >> > On Friday, August 23, 2013 01:19:39 PM Neil Horman wrote: >> >> > > Somewhere between 3.9 and 3.10 it seems the order in which pcie and >> >> > > acpi probed >> >> > > slots for hotplug capabilites got reversed. While this isn't a big >> >> > > deal, it did >> >> > > uncover a bug in the ACPI bus setup path. Specifically, >> >> > > acpi_pci_root_add calls >> >> > > pci_acpi_scan_root before setting the osc flags for the device handle. >> >> > > pci_acpi_scan_root, among other things uses >> >> > > device_is_managed_by_native_pciehp() >> >> > > to determine if a given slot has pcie hotplug capabilties, whcih >> >> > > checks the >> >> > > devices OSC_PCI_EXPRESS_NATIVE_HP_CONTROL flag. Since that flag is >> >> > > not set >> >> > > until after pci_acpi_scan_root_completes, the acpi code never sees >> >> > > that pcie >> >> > > slots are hotplug capable and configures them all to use acpi instead. >> >> > > >> >> > > Fix is pretty simple, just defer the scan until after the osc flags >> >> > > have been >> >> > > set on the device. Tested by myself and it seems to work well. >> >> > > >> >> > > Signed-off-by: Neil Horman >> >> > > CC: Len Brown >> >> > > CC: "Rafael J. Wysocki" >> >> > > CC: linux-a...@vger.kernel.org >> >> > > --- >> >> > > drivers/acpi/pci_root.c | 41 >> >> > > - >> >> > > 1 file changed, 20 insertions(+), 21 deletions(-) >> >> > > >> >> > > diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c >> >> > > index 5917839..a2c2661 100644 >> >> > > --- a/drivers/acpi/pci_root.c >> >> > > +++ b/drivers/acpi/pci_root.c >> >> > > @@ -437,27 +437,6 @@ static int acpi_pci_root_add(struct acpi_device >> >> > > *device, >> >> > > flags = base_flags = OSC_PCI_SEGMENT_GROUPS_SUPPORT; >> >> > > acpi_pci_osc_support(root, flags); >> >> > > >> >> > > - /* >> >> > > - * TBD: Need PCI interface for enumeration/configuration of roots. >> >> > > - */ >> >> > > - >> >> > > - /* >> >> > > - * Scan the Root Bridge >> >> > > - * >> >> > > - * Must do this prior to
[PATCH 2/5] drivers: thermal: parent virtual hwmon with thermal zone
When creating virtual hwmon devices based out of thermal
zone devices, the virtual devices won't have parents.
This patch changes the code so that the parent of virtual
hwmon devices is the thermal zone device that they are
based of.
Cc: Zhang Rui
Cc: linux...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin
---
drivers/thermal/thermal_hwmon.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/thermal/thermal_hwmon.c b/drivers/thermal/thermal_hwmon.c
index fdb0719..eeef0e2 100644
--- a/drivers/thermal/thermal_hwmon.c
+++ b/drivers/thermal/thermal_hwmon.c
@@ -159,7 +159,7 @@ int thermal_add_hwmon_sysfs(struct thermal_zone_device *tz)
INIT_LIST_HEAD(>tz_list);
strlcpy(hwmon->type, tz->type, THERMAL_NAME_LENGTH);
- hwmon->device = hwmon_device_register(NULL);
+ hwmon->device = hwmon_device_register(>device);
if (IS_ERR(hwmon->device)) {
result = PTR_ERR(hwmon->device);
goto free_mem;
--
1.8.2.1.342.gfa7285d
--
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 5/5] drivers: thermal: add check when unregistering cpu cooling
This patch avoids NULL pointer accesses while unregistering
cpu cooling devices, in case a NULL pointer is received.
Cc: Zhang Rui
Cc: linux...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin
---
drivers/thermal/cpu_cooling.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c
index 82e15db..429a98c 100644
--- a/drivers/thermal/cpu_cooling.c
+++ b/drivers/thermal/cpu_cooling.c
@@ -496,8 +496,12 @@ EXPORT_SYMBOL_GPL(cpufreq_cooling_register);
*/
void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev)
{
- struct cpufreq_cooling_device *cpufreq_dev = cdev->devdata;
+ struct cpufreq_cooling_device *cpufreq_dev;
+ if (!cdev)
+ return;
+
+ cpufreq_dev = cdev->devdata;
mutex_lock(_cpufreq_lock);
cpufreq_dev_count--;
--
1.8.2.1.342.gfa7285d
--
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/5] thermal: thermal_core: allow binding with limits on bind_params
When registering a thermal zone device using platform information
via bind_params, the thermal framework will always perform the
cdev binding using the lowest and highest limits (THERMAL_NO_LIMIT).
This patch changes the data structures so that it is possible
to inform what are the desired limits for each trip point
inside a bind_param. The way the binding is performed is also
changed so that it uses the new data structure.
Cc: Zhang Rui
Cc: linux...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin
---
Documentation/thermal/sysfs-api.txt | 7 +++
drivers/thermal/thermal_core.c | 19 +++
include/linux/thermal.h | 10 ++
3 files changed, 32 insertions(+), 4 deletions(-)
diff --git a/Documentation/thermal/sysfs-api.txt
b/Documentation/thermal/sysfs-api.txt
index 4b4a052..86e75a6 100644
--- a/Documentation/thermal/sysfs-api.txt
+++ b/Documentation/thermal/sysfs-api.txt
@@ -136,6 +136,13 @@ temperature) and throttle appropriate devices.
this thermal zone and cdev, for a particular trip point.
If nth bit is set, then the cdev and thermal zone are bound
for trip point n.
+.limits: This is an array of cooling state limits. Must have exactly
+ 2 * thermal_zone.number_of_trip_points. It is an array consisting
+ of tuples of state limits. Each trip
+ will be associated with one state limit tuple when binding.
+ A NULL pointer means
+ on all trips. These limits are used when binding a cdev to a
+ trip point.
.match: This call back returns success(0) if the 'tz and cdev' need to
be bound, as per platform data.
1.4.2 struct thermal_zone_params
diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index d949ab0..e9545a7 100644
--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
@@ -202,14 +202,23 @@ static void print_bind_err_msg(struct thermal_zone_device
*tz,
}
static void __bind(struct thermal_zone_device *tz, int mask,
- struct thermal_cooling_device *cdev)
+ struct thermal_cooling_device *cdev,
+ unsigned long *limits)
{
int i, ret;
for (i = 0; i < tz->trips; i++) {
if (mask & (1 << i)) {
+ unsigned long upper, lower;
+
+ upper = THERMAL_NO_LIMIT;
+ lower = THERMAL_NO_LIMIT;
+ if (limits) {
+ lower = limits[i * 2];
+ upper = limits[i * 2 + 1];
+ }
ret = thermal_zone_bind_cooling_device(tz, i, cdev,
- THERMAL_NO_LIMIT, THERMAL_NO_LIMIT);
+ upper, lower);
if (ret)
print_bind_err_msg(tz, cdev, ret);
}
@@ -254,7 +263,8 @@ static void bind_cdev(struct thermal_cooling_device *cdev)
if (tzp->tbp[i].match(pos, cdev))
continue;
tzp->tbp[i].cdev = cdev;
- __bind(pos, tzp->tbp[i].trip_mask, cdev);
+ __bind(pos, tzp->tbp[i].trip_mask, cdev,
+ tzp->tbp[i].binding_limits);
}
}
@@ -292,7 +302,8 @@ static void bind_tz(struct thermal_zone_device *tz)
if (tzp->tbp[i].match(tz, pos))
continue;
tzp->tbp[i].cdev = pos;
- __bind(tz, tzp->tbp[i].trip_mask, pos);
+ __bind(tz, tzp->tbp[i].trip_mask, pos,
+ tzp->tbp[i].binding_limits);
}
}
exit:
diff --git a/include/linux/thermal.h b/include/linux/thermal.h
index 88148b9..7c2769c 100644
--- a/include/linux/thermal.h
+++ b/include/linux/thermal.h
@@ -207,6 +207,16 @@ struct thermal_bind_params {
* See Documentation/thermal/sysfs-api.txt for more information.
*/
int trip_mask;
+
+ /*
+* This is an array of cooling state limits. Must have exactly
+* 2 * thermal_zone.number_of_trip_points. It is an array consisting
+* of tuples of state limits. Each trip
+* will be associated with one state limit tuple when binding.
+* A NULL pointer means
+* on all trips.
+*/
+ unsigned long *binding_limits;
int (*match) (struct thermal_zone_device *tz,
struct thermal_cooling_device *cdev);
};
--
1.8.2.1.342.gfa7285d
--
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
[PATCH 0/5] drivers: thermal: several fixes
Hello all, This is simple patch set with fixes on core thermal framework. These fixes are a set of changes that I find needed that I found during the process of attempting to describe thermal data using device tree. These patches touch several drivers, as there is an API change. I have only compiled tested on other drivers. I have done a runtime test on OMAP and DRA devices though. Please feel free to perform your own test and report issues if you find some. All best, Eduardo Valentin (5): thermal: hwmon: move hwmon support to single file drivers: thermal: parent virtual hwmon with thermal zone drivers: thermal: make usage of CONFIG_THERMAL_HWMON optional thermal: thermal_core: allow binding with limits on bind_params drivers: thermal: add check when unregistering cpu cooling Documentation/thermal/sysfs-api.txt| 11 +- drivers/acpi/thermal.c | 6 +- drivers/platform/x86/acerhdf.c | 3 +- drivers/platform/x86/intel_mid_thermal.c | 2 +- drivers/power/power_supply_core.c | 2 +- drivers/thermal/Kconfig| 9 + drivers/thermal/Makefile | 3 + drivers/thermal/armada_thermal.c | 2 +- drivers/thermal/cpu_cooling.c | 6 +- drivers/thermal/db8500_thermal.c | 2 +- drivers/thermal/dove_thermal.c | 2 +- drivers/thermal/exynos_thermal.c | 2 +- drivers/thermal/kirkwood_thermal.c | 2 +- drivers/thermal/rcar_thermal.c | 2 +- drivers/thermal/spear_thermal.c| 2 +- drivers/thermal/thermal_core.c | 287 ++--- drivers/thermal/thermal_hwmon.c| 269 +++ drivers/thermal/thermal_hwmon.h| 49 drivers/thermal/ti-soc-thermal/ti-thermal-common.c | 2 +- drivers/thermal/x86_pkg_temp_thermal.c | 2 +- include/linux/thermal.h| 12 +- 21 files changed, 398 insertions(+), 279 deletions(-) create mode 100644 drivers/thermal/thermal_hwmon.c create mode 100644 drivers/thermal/thermal_hwmon.h -- 1.8.2.1.342.gfa7285d -- 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/5] thermal: hwmon: move hwmon support to single file
In order to improve code organization, this patch
moves the hwmon sysfs support to a file named
thermal_hwmon. This helps to add extra support
for hwmon without scrambling the code.
In order to do this move, the hwmon list head is now
using its own locking. Before, the list used
the global thermal locking. Also, some minor changes
in the code were required, as recommended by checkpatch.pl.
Cc: Zhang Rui
Cc: linux...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Acked-by: Durgadoss R
Signed-off-by: Eduardo Valentin
---
drivers/thermal/Kconfig | 9 ++
drivers/thermal/Makefile| 3 +
drivers/thermal/thermal_core.c | 255 +
drivers/thermal/thermal_hwmon.c | 269
drivers/thermal/thermal_hwmon.h | 49
5 files changed, 331 insertions(+), 254 deletions(-)
create mode 100644 drivers/thermal/thermal_hwmon.c
create mode 100644 drivers/thermal/thermal_hwmon.h
diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index e988c81..7fb16bc 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -17,8 +17,17 @@ if THERMAL
config THERMAL_HWMON
bool
+ prompt "Expose thermal sensors as hwmon device"
depends on HWMON=y || HWMON=THERMAL
default y
+ help
+ In case a sensor is registered with the thermal
+ framework, this option will also register it
+ as a hwmon. The sensor will then have the common
+ hwmon sysfs interface.
+
+ Say 'Y' here if you want all thermal sensors to
+ have hwmon sysfs interface too.
choice
prompt "Default Thermal governor"
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index 67184a2..24cb894 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -5,6 +5,9 @@
obj-$(CONFIG_THERMAL) += thermal_sys.o
thermal_sys-y += thermal_core.o
+# interface to/from other layers providing sensors
+thermal_sys-$(CONFIG_THERMAL_HWMON)+= thermal_hwmon.o
+
# governors
thermal_sys-$(CONFIG_THERMAL_GOV_FAIR_SHARE) += fair_share.o
thermal_sys-$(CONFIG_THERMAL_GOV_STEP_WISE)+= step_wise.o
diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index 1f02e8e..247528b 100644
--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
@@ -38,6 +38,7 @@
#include
#include "thermal_core.h"
+#include "thermal_hwmon.h"
MODULE_AUTHOR("Zhang Rui");
MODULE_DESCRIPTION("Generic thermal management sysfs support");
@@ -859,260 +860,6 @@ thermal_cooling_device_trip_point_show(struct device *dev,
/* Device management */
-#if defined(CONFIG_THERMAL_HWMON)
-
-/* hwmon sys I/F */
-#include
-
-/* thermal zone devices with the same type share one hwmon device */
-struct thermal_hwmon_device {
- char type[THERMAL_NAME_LENGTH];
- struct device *device;
- int count;
- struct list_head tz_list;
- struct list_head node;
-};
-
-struct thermal_hwmon_attr {
- struct device_attribute attr;
- char name[16];
-};
-
-/* one temperature input for each thermal zone */
-struct thermal_hwmon_temp {
- struct list_head hwmon_node;
- struct thermal_zone_device *tz;
- struct thermal_hwmon_attr temp_input; /* hwmon sys attr */
- struct thermal_hwmon_attr temp_crit;/* hwmon sys attr */
-};
-
-static LIST_HEAD(thermal_hwmon_list);
-
-static ssize_t
-name_show(struct device *dev, struct device_attribute *attr, char *buf)
-{
- struct thermal_hwmon_device *hwmon = dev_get_drvdata(dev);
- return sprintf(buf, "%s\n", hwmon->type);
-}
-static DEVICE_ATTR(name, 0444, name_show, NULL);
-
-static ssize_t
-temp_input_show(struct device *dev, struct device_attribute *attr, char *buf)
-{
- long temperature;
- int ret;
- struct thermal_hwmon_attr *hwmon_attr
- = container_of(attr, struct thermal_hwmon_attr, attr);
- struct thermal_hwmon_temp *temp
- = container_of(hwmon_attr, struct thermal_hwmon_temp,
- temp_input);
- struct thermal_zone_device *tz = temp->tz;
-
- ret = thermal_zone_get_temp(tz, );
-
- if (ret)
- return ret;
-
- return sprintf(buf, "%ld\n", temperature);
-}
-
-static ssize_t
-temp_crit_show(struct device *dev, struct device_attribute *attr,
- char *buf)
-{
- struct thermal_hwmon_attr *hwmon_attr
- = container_of(attr, struct thermal_hwmon_attr, attr);
- struct thermal_hwmon_temp *temp
- = container_of(hwmon_attr, struct thermal_hwmon_temp,
- temp_crit);
- struct thermal_zone_device *tz = temp->tz;
- long temperature;
- int ret;
-
- ret = tz->ops->get_trip_temp(tz, 0, );
- if (ret)
- return ret;
-
- return sprintf(buf,
Re: [PATCH v3 2/5] ARM: dts: add reference voltage property for MXS LRADC
On 08/22/13 17:51, Pawel Moll wrote: > On Thu, 2013-08-22 at 07:17 +0100, Jonathan Cameron wrote: >> I would favour option 2 though some of the discussions going on at the >> moment about >> bindings might result in a generic description of this and any other bits of >> analog front end. > > Any link to this discussion? devicet...@vger.kernel.org doesn't seem to > be involved (of course I may have simply missed the thread ;-) Some cc's dropped off the discussion at some point that should have been there and the topic has 'wandered' somewhat from where it started. https://lkml.org/lkml/2013/8/21/409 and the couple of messages after that are probably the most relevant. Speaking of which the devicetree list on here was the old one, I've just switched to the vger list you suggest above. > > Paweł > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-iio" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- 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 2/4] clk: implement clk_unregister
Quoting Sylwester Nawrocki (2013-08-20 10:34:21)
> clk_unregister() is currently not implemented and it is required when
> a clock provider module needs to be unloaded.
>
> Normally the clock supplier module is prevented to be unloaded by
> taking reference on the module in clk_get().
>
> For cases when the clock supplier module deinitializes despite the
> consumers of its clocks holding a reference on the module, e.g. when
> the driver is unbound through "unbind" sysfs attribute, there are
> empty clock ops added. These ops are assigned temporarily to struct
> clk and used until all consumers release the clock, to avoid invoking
> callbacks from the module which just got removed.
>
> Signed-off-by: Jiada Wang
> Signed-off-by: Sylwester Nawrocki
This change looks good to me. One minor nitpick below.
> ---
> Changes since RFC v1:
> - renamed clk_dummy_* to clk_nodrv_*.
>
> Changes since v3 of the original patch [1]:
> - reparent all children to the orphan list instead of leaving
>the clock unregistered when it has child clocks,
> - removed unnecessary prerequisite checks in clk_debug_unregister(),
> - struct clk is now being freed only when the last clock consumer
>calls clk_put(),
> - empty clock ops are used after clk_unregister() has been called
>until all references to the clock are released and the clock
>object is freed.
>
> [1] http://www.spinics.net/lists/arm-kernel/msg247548.html
> ---
> drivers/clk/clk.c | 123
> +--
> include/linux/clk-private.h |2 +
> 2 files changed, 122 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index 0e0eb31..549fcb7 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -342,6 +342,21 @@ out:
> return ret;
> }
>
> + /**
> + * clk_debug_unregister - remove a clk node from the debugfs clk tree
> + * @clk: the clk being removed from the debugfs clk tree
> + *
> + * Dynamically removes a clk and all it's children clk nodes from the
> + * debugfs clk tree if clk->dentry points to debugfs created by
> + * clk_debug_register in __clk_init.
> + *
> + * Caller must hold prepare_lock.
> + */
> +static void clk_debug_unregister(struct clk *clk)
> +{
> + debugfs_remove_recursive(clk->dentry);
> +}
> +
> /**
> * clk_debug_reparent - reparent clk node in the debugfs clk tree
> * @clk: the clk being reparented
> @@ -432,6 +447,9 @@ static inline int clk_debug_register(struct clk *clk) {
> return 0; }
> static inline void clk_debug_reparent(struct clk *clk, struct clk
> *new_parent)
> {
> }
> +static inline void clk_debug_unregister(struct clk *clk)
> +{
> +}
> #endif
>
> /* caller must hold prepare_lock */
> @@ -1656,6 +1674,7 @@ int __clk_init(struct device *dev, struct clk *clk)
>
> clk_debug_register(clk);
>
> + kref_init(>ref);
> out:
> clk_prepare_unlock();
>
> @@ -1785,13 +1804,106 @@ fail_out:
> }
> EXPORT_SYMBOL_GPL(clk_register);
>
> +/*
> + * Free memory allocated for a clock.
> + * Caller must hold prepare_lock.
> + */
> +static void __clk_release(struct kref *ref)
> +{
> + struct clk *clk = container_of(ref, struct clk, ref);
> + int i = clk->num_parents;
> +
> + kfree(clk->parents);
> + while (--i >= 0)
> + kfree(clk->parent_names[i]);
> +
> + kfree(clk->parent_names);
> + kfree(clk->name);
> + kfree(clk);
> +}
> +
> +/*
> + * Empty clk_ops for unregistered clocks. These are used temporarily
> + * after clk_unregister() was called on a clock and until last clock
> + * consumer calls clk_put() and the struct clk object is freed.
> + */
> +static int clk_nodrv_prepare_enable(struct clk_hw *hw)
> +{
> + return -ENXIO;
> +}
> +
> +static void clk_nodrv_disable_unprepare(struct clk_hw *hw)
> +{
> + WARN_ON(1);
Ideally we shouldn't get here, but if we do I guess it could be very
noisy. How about WARN_ONCE?
After you address Russell's comments in patch #1 I will be happy to take
this series.
Thanks,
Mike
> +}
> +
> +static int clk_nodrv_set_rate(struct clk_hw *hw, unsigned long rate,
> + unsigned long parent_rate)
> +{
> + return -ENXIO;
> +}
> +
> +static int clk_nodrv_set_parent(struct clk_hw *hw, u8 index)
> +{
> + return -ENXIO;
> +}
> +
> +static const struct clk_ops clk_nodrv_ops = {
> + .enable = clk_nodrv_prepare_enable,
> + .disable= clk_nodrv_disable_unprepare,
> + .prepare= clk_nodrv_prepare_enable,
> + .unprepare = clk_nodrv_disable_unprepare,
> + .set_rate = clk_nodrv_set_rate,
> + .set_parent = clk_nodrv_set_parent,
> +};
> +
> /**
> * clk_unregister - unregister a currently registered clock
> * @clk: clock to unregister
> - *
> - * Currently unimplemented.
> */
> -void clk_unregister(struct clk *clk) {}
> +void clk_unregister(struct clk *clk)
> +{
> + unsigned
Re: [PATCH RFC v2 3/5] spmi: add generic SPMI controller binding documentation
On 08/22/2013 01:59 PM, Josh Cartwright wrote: > Signed-off-by: Josh Cartwright > --- > I'm introducing this as an RFC, because there are set of assumptions > made in this binding spec, that currently hold true for the supported > controller/addressing scheme for the Snapdragon 800 series, but don't > necessarily hold true for SPMI in general. > > 1. No use of Group Slave Identifiers (GSIDs) > (SPMI allows for a slave to belong to zero or more groups specified > by GSID, however this feature isn't currently implemented) > > 2. No specification of Master Identifier (MID) > (A "system integrator" allocates to each master a 2-bit MID, this > currently isn't being specified, as it isn't needed by software for > the PMIC Arb; not sure if this is of use to other SPMI controllers) > > 3. Single SPMI master per controller > > Effectively, only a subset of possible SPMI configurations are specified > in this document. > > So, if it's considered necessary to provide a generic SPMI binding > specification, is it acceptable to only define a subset at this time, > expanding only when necessary, or shall I expand the definition to at > least address 1 & 2, even though they are of no use in the current > implementation? It's best to define the whole thing from the start if possible. It's easier to ensure the whole binding is consistent, and nothing has been left out. However, it's probably OK to define a subset binding initially and then expand it later, as long as some thought it put into how it can be expanded in a way that is 100% compatible: old DTs will still operate with new kernels and perhaps even new DTs will still operate with old kernels. That said, if the thought is put in to ensure that's possible, it's probably just as easy to define the whole binding from the start. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC v2 5/5] spmi: document the PMIC arbiter SPMI bindings
On 08/09/2013 02:37 PM, Josh Cartwright wrote:
Patch description?
> diff --git a/Documentation/devicetree/bindings/spmi/qcom,spmi-pmic-arb.txt
> b/Documentation/devicetree/bindings/spmi/qcom,spmi-pmic-arb.txt
> +Required properties:
> +- compatible : should be "qcom,spmi-pmic-arb".
> +- reg-names : should be "core", "intr", "cnfg"
> +- reg : offset and length of the PMIC Arbiter Core register map.
> +- reg : offset and length of the PMIC Arbiter Interrupt controller register
> map.
> +- reg : offset and length of the PMIC Arbiter Configuration register map.
This seems like it's defining the "reg" property 3 times each with a
different meaning. It'd be better to say something like:
reg : register specifier. Must contain 3 entries, in the following
order: core registers, interrupt register, configuration registers.
> + qcom,spmi@fc4c {
...
> + qcom,pm8841@4 {
Node names typically don't include a vendor prefix. For the first
instance above, I think just "spmi@fc4c" or even just "spmi" would
be appropriate here; the latter being best in the case where there's
only 1 SPMI controller and hence no need to include the unit address for
uniqueness.
--
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: [Intel-gfx] [PATCH] i915: Update VGA arbiter support for newer devices
On Fri, 2013-08-23 at 15:18 -0600, Alex Williamson wrote: > On Fri, 2013-08-23 at 21:21 +0300, Ville Syrjälä wrote: > > On Tue, Aug 20, 2013 at 10:46:45PM +0300, Ville Syrjälä wrote: > > > On Fri, Aug 16, 2013 at 12:22:14PM -0600, Alex Williamson wrote: > > > > On Fri, 2013-08-16 at 13:20 +0300, Ville Syrjälä wrote: > > > > > On Thu, Aug 15, 2013 at 04:54:15PM -0600, Alex Williamson wrote: > > > > > > On Fri, 2013-08-16 at 08:49 +1000, Dave Airlie wrote: > > > > > > > On Fri, Aug 16, 2013 at 8:43 AM, Alex Williamson > > > > > > > wrote: > > > > > > > > This is intended to add VGA arbiter support for Intel HD > > > > > > > > graphics on > > > > > > > > Core processors. The old GMCH registers no longer exist, so > > > > > > > > even > > > > > > > > though it appears that i915 participates in VGA arbitration, it > > > > > > > > doesn't > > > > > > > > work. On Intel HD graphics we already attempt to disable VGA > > > > > > > > regions > > > > > > > > of the device. This makes registering as a VGA client > > > > > > > > unnecessary since > > > > > > > > we don't intend to operate differently depending on how many > > > > > > > > VGA devices > > > > > > > > are present. We can disable VGA memory regions by clearing a > > > > > > > > memory > > > > > > > > enable bit in the VGA MSR. That only leaves VGA IO, which we > > > > > > > > update > > > > > > > > the VGA arbiter to know that we don't participate in VGA memory > > > > > > > > arbitration. We also add a hook on unload to re-enable memory > > > > > > > > and > > > > > > > > reinstate VGA memory arbitration. > > > > > > > > > > > > > > I would think there is still a VGA disable bit on the Intel device > > > > > > > somewhere, we'd just need > > > > > > > Intel to look in the docs and find it. A bit that can nuke both > > > > > > > i/o > > > > > > > and cmd regs. > > > > > > > > > > > > The only bit available is in the GGC and is a keyed/locked register > > > > > > that > > > > > > not only disables VGA memory and I/O, but also modifies the class > > > > > > code > > > > > > of the device. Early Core processors didn't lock this, but it's > > > > > > untouchable in newer ones AFAICT. Thanks, > > > > > > > > > > I've not found anything else in the docs. And also we _need_ VGA I/O > > > > > access to make i915_disable_vga() work. It's not 100% clear whether > > > > > we really need to poke at the sequencer register in modern hardware, > > > > > but the docs do still list it as a mandatory step. So even if we were > > > > > to have a global "disable VGA I/O and mem bit" we'd need to make sure > > > > > we already disabled VGA eg. after resume when the BIOS had a chance to > > > > > turn the VGA display back on. I think there were also some BIOSen that > > > > > turned VGA display back on when closing/opening the laptop lid. Not > > > > > sure what would even happen with those if totally disabled VGA I/O > > > > > access. I'm not sure they actually frob with the VGA regs though. > > > > > Could be they just turn on the VGA display bit in the VGA_CONTROL > > > > > register. > > > > > > > > Hmm, it appears the MSR write isn't fully disabling VGA memory space. > > > > When the VBIOS for the PEG graphics is run in the guest, I get some > > > > corruption of the IGD frame buffer. If I manually disable PCI memory in > > > > the command register, this doesn't happen. I also get some strange > > > > artifacts on the PEG display that don't happen when PCI memory is > > > > disabled. Should that MSR bit give us the whole a_-b_ range? > > > > > > Perhaps. It does that on some old graphics cards I've played with, but > > > frankly I have no idea what it does on our hardware. > > > > > > I'm trying to find out though. If and when I get an answer I'll let you > > > know. > > > > So the answer I basically got is that MSR is the only option here when > > the GMCH register can't be used. Supposedly it should work too, but > > I felt that I didn't get a 100% definite answer on that subject. > > I can imagine that the GMCH could be modified if we knew where the bit > was that's locking it. I can't find that in the spec though and I > assume that's intentional. > > > I tried it a bit on an IVB machine and PCI and PCIe Matrox G550 cards, > > and for me it does seem to work. In the G550 PCIe case there's an extra > > PCIe-PCI bridge on the card, and and in the G550 PCI case there's a > > PCI-PCI bridge on the card and a PCIe-PCI bridge on the motherboard. > > I don't have any native PCIe graphics cards on me to test the no > > extra bridges case. > > > > Based on a bit of manual register/memory banging it looks like the IGD > > will decode the access when MSR[1]=1, and won't when MSR[1]=0. Same was > > true for PCI_COMMAND[0] in case of VGA I/O. If those bits are disabled > > for IGD, the accesses get to the external card. If neither claims it, > > I just get 0xff back and writes are ignored. > > > > Curiously I didn't see any problems when
RE: [PATCH 0/8] x86, acpi: Move acpi_initrd_override() earlier.
While we're at it: Can someone send me the acpidump for this machine? We very much would like to test all of ACPICA with such a large DSDT. Thanks, Bob > -Original Message- > From: chen tang [mailto:imtangc...@gmail.com] > Sent: Friday, August 23, 2013 2:51 PM > To: Yinghai Lu > Cc: Russ Anderson; H. Peter Anvin; Zhang Yanfei; Toshi Kani; Tejun Heo; > Tang Chen; Konrad Rzeszutek Wilk; Moore, Robert; Zheng, Lv; Rafael J. > Wysocki; Ingo Molnar; Andrew Morton; Thomas Renninger; Yasuaki Ishimatsu; > Mel Gorman; Linux Kernel Mailing List > Subject: Re: [PATCH 0/8] x86, acpi: Move acpi_initrd_override() earlier. > > Hi Yinghai, > > 2013/8/24 Yinghai Lu : > > On Fri, Aug 23, 2013 at 1:30 PM, Russ Anderson wrote: > >> On Fri, Aug 23, 2013 at 01:08:56PM -0700, Yinghai Lu wrote: > >>> On Fri, Aug 23, 2013 at 11:25 AM, H. Peter Anvin > wrote: > > > >>> Russ, What is ACPI table size on your big machine? > >> > >> This is from a 256 socket 32TB system. > >> > >> Reserving 256MB of memory at 66973408MB for crashkernel (System RAM: > 32501719MB) > >> ACPI: RSDP 7ef3d014 00024 (v02 INTEL ) > >> ACPI: XSDT 7ef3d120 0007C (v01 INTEL TIANO > 0113) > >> ACPI: FACP 7ef3a000 000F4 (v04 INTEL TIANO MSFT > 0113) > >> ACPI: DSDT 7e6c3000 7F493E (v02 SGI2 UVX 0002 MSFT > 0113) > >> ACPI: FACS 7d147000 00040 > >> ACPI: UEFI 7ef3c000 0012A (v01 INTEL RstScuO > ) > >> ACPI: UEFI 7ef3b000 0005C (v01 INTEL RstScuV > ) > >> ACPI: HPET 7ef39000 00038 (v01 INTEL TIANO0001 MSFT > 0113) > >> ACPI: SSDT 7ef33000 05352 (v02 INTEL ROSECITY 0003 INTL > 20070508) > >> ACPI: SLIT 7ef1 1002C (v01 SGI2 UVX 0002 MSFT > 0001) > >> ACPI: APIC 7000 10070 (v03 SGI2 UVX 0002 MSFT > 0001) > >> ACPI: SRAT 7eeb8000 1A830 (v03 SGI2 UVX 0002 MSFT > 0001) > >> ACPI: MCFG 7d6d4000 0105C (v01 SGI2 UVX 0002 MSFT > 0001) > >> ACPI: SPCR 7e6c2000 00050 (v01 > ) > >> ACPI: DMAR 7d6d3000 0013C (v01 INTEL TIANO0001 MSFT > 0113) > >> > > > > so the DSDT is 7F493E, and total is more than 8M. > > > > that will need BRK to be extended 16M? > > > > Then how about use early_ioremap(), and don't do it that early in > head_32 and head64 ? > > 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/
[ANNOUNCE] Git v1.8.4
The latest feature release Git v1.8.4 is now available at the usual places. It contains 870+ changes from ~100 contributors (among which 33 people are new) since v1.8.3. We will have two more releases til the end of this year; the release after that could be Git 2.0. The release tarballs are found at: http://code.google.com/p/git-core/downloads/list and their SHA-1 checksums are: 2a361a2d185b8bc604f7f2ce2f502d0dea9d3279 git-1.8.4.tar.gz f130398eb623c913497ef51a6e61d916fe7e31c8 git-htmldocs-1.8.4.tar.gz 8c67a7bc442d6191bc17633c7f2846c71bda71cf git-manpages-1.8.4.tar.gz The following public repositories all have a copy of the v1.8.4 tag and the master branch that the tag points at: url = https://kernel.googlesource.com/pub/scm/git/git url = git://repo.or.cz/alt-git.git url = https://code.google.com/p/git-core/ url = git://git.sourceforge.jp/gitroot/git-core/git.git url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core url = https://github.com/gitster/git Also, http://www.kernel.org/pub/software/scm/git/ has copies of the release tarballs. Git v1.8.4 Release Notes Backward compatibility notes (for Git 2.0) -- When "git push [$there]" does not say what to push, we have used the traditional "matching" semantics so far (all your branches were sent to the remote as long as there already are branches of the same name over there). In Git 2.0, the default will change to the "simple" semantics that pushes: - only the current branch to the branch with the same name, and only when the current branch is set to integrate with that remote branch, if you are pushing to the same remote as you fetch from; or - only the current branch to the branch with the same name, if you are pushing to a remote that is not where you usually fetch from. Use the user preference configuration variable "push.default" to change this. If you are an old-timer who is used to the "matching" semantics, you can set the variable to "matching" to keep the traditional behaviour. If you want to live in the future early, you can set it to "simple" today without waiting for Git 2.0. When "git add -u" (and "git add -A") is run inside a subdirectory and does not specify which paths to add on the command line, it will operate on the entire tree in Git 2.0 for consistency with "git commit -a" and other commands. There will be no mechanism to make plain "git add -u" behave like "git add -u .". Current users of "git add -u" (without a pathspec) should start training their fingers to explicitly say "git add -u ." before Git 2.0 comes. A warning is issued when these commands are run without a pathspec and when you have local changes outside the current directory, because the behaviour in Git 2.0 will be different from today's version in such a situation. In Git 2.0, "git add " will behave as "git add -A ", so that "git add dir/" will notice paths you removed from the directory and record the removal. Versions before Git 2.0, including this release, will keep ignoring removals, but the users who rely on this behaviour are encouraged to start using "git add --ignore-removal " now before 2.0 is released. Updates since v1.8.3 Foreign interfaces, subsystems and ports. * Cygwin port has been updated for more recent Cygwin 1.7. * "git rebase -i" now honors --strategy and -X options. * Git-gui has been updated to its 0.18.0 version. * MediaWiki remote helper (in contrib/) has been updated to use the credential helper interface from Git.pm. * Update build for Cygwin 1.[57]. Torsten Bögershausen reports that this is fine with Cygwin 1.7 ($gmane/225824) so let's try moving it ahead. * The credential helper to talk to keychain on OS X (in contrib/) has been updated to kick in not just when talking http/https but also imap(s) and smtp. * Remote transport helper has been updated to report errors and maintain ref hierarchy used to keep track of its own state better. * With "export" remote-helper protocol, (1) a push that tries to update a remote ref whose name is different from the pushing side does not work yet, and (2) the helper may not know how to do --dry-run; these problematic cases are disabled for now. * git-remote-hg/bzr (in contrib/) updates. * git-remote-mw (in contrib/) hints users to check the certificate, when https:// connection failed. * git-remote-mw (in contrib/) adds a command to allow previewing the contents locally before pushing it out, when working with a MediaWiki remote. UI, Workflows & Features * Sample "post-receive-email" hook script got an enhanced replacement "multimail" (in contrib/). * Also in contrib/ is a new "contacts" script that runs "git blame" to find out the people who may be interested in a set of changes. * "git clean" command learned an interactive mode. * The "--head" option to "git show-ref" was only to add
Re: [PATCH 0/8] x86, acpi: Move acpi_initrd_override() earlier.
Hi Yinghai, 2013/8/24 Yinghai Lu : > On Fri, Aug 23, 2013 at 1:30 PM, Russ Anderson wrote: >> On Fri, Aug 23, 2013 at 01:08:56PM -0700, Yinghai Lu wrote: >>> On Fri, Aug 23, 2013 at 11:25 AM, H. Peter Anvin wrote: > >>> Russ, What is ACPI table size on your big machine? >> >> This is from a 256 socket 32TB system. >> >> Reserving 256MB of memory at 66973408MB for crashkernel (System RAM: >> 32501719MB) >> ACPI: RSDP 7ef3d014 00024 (v02 INTEL ) >> ACPI: XSDT 7ef3d120 0007C (v01 INTEL TIANO >> 0113) >> ACPI: FACP 7ef3a000 000F4 (v04 INTEL TIANO MSFT >> 0113) >> ACPI: DSDT 7e6c3000 7F493E (v02 SGI2 UVX 0002 MSFT >> 0113) >> ACPI: FACS 7d147000 00040 >> ACPI: UEFI 7ef3c000 0012A (v01 INTEL RstScuO >> ) >> ACPI: UEFI 7ef3b000 0005C (v01 INTEL RstScuV >> ) >> ACPI: HPET 7ef39000 00038 (v01 INTEL TIANO0001 MSFT >> 0113) >> ACPI: SSDT 7ef33000 05352 (v02 INTEL ROSECITY 0003 INTL >> 20070508) >> ACPI: SLIT 7ef1 1002C (v01 SGI2 UVX 0002 MSFT >> 0001) >> ACPI: APIC 7000 10070 (v03 SGI2 UVX 0002 MSFT >> 0001) >> ACPI: SRAT 7eeb8000 1A830 (v03 SGI2 UVX 0002 MSFT >> 0001) >> ACPI: MCFG 7d6d4000 0105C (v01 SGI2 UVX 0002 MSFT >> 0001) >> ACPI: SPCR 7e6c2000 00050 (v01 >> ) >> ACPI: DMAR 7d6d3000 0013C (v01 INTEL TIANO0001 MSFT >> 0113) >> > > so the DSDT is 7F493E, and total is more than 8M. > > that will need BRK to be extended 16M? > Then how about use early_ioremap(), and don't do it that early in head_32 and head64 ? 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/
Re: [PATCH] PCI: avoid NULL deref in alloc_pcie_link_state
[+cc Shaohua]
On Thu, Aug 22, 2013 at 6:02 PM, Bjorn Helgaas wrote:
> On Thu, Aug 08, 2013 at 03:57:07PM +0200, Radim Krčmář wrote:
>> PCIe switch can be connected directly to the PCIe root complex in QEMU;
>> ASPM does not expect this topology and dereferences NULL pointer when
>> initializing.
>>
>> Downstream port can be also connected to the root complex without
>> upstream one, so code checks for both, otherwise they dereference NULL
>> on line drivers/pci/pcie/aspm.c:530 (alloc_pcie_link_state+13):
>> parent = pdev->bus->parent->self->link_state;
>> "pdev->bus->parent->self == NULL" if upstream port is connected directly
>> to the root bus and "pdev->bus->parent == NULL" in the second case.
>>
>> v1 -> v2: (https://lkml.org/lkml/2013/6/19/753)
>> - Initialization is aborted in pcie_aspm_init_link_state, where other
>>special cases are being handled
>> - pci_is_root_bus is used
>> - Warning is printed
>>
>> Reproducer for "downstream -- root" and "downstream -- upstream -- root"
>> (used qemu-kvm 1.5, q35 machine type might be missing on older ones)
>>
>> for parent in pcie.0 upstream; do
>>qemu-kvm -m 128 -M q35 -nographic -no-reboot \
>> -device x3130-upstream,bus=pcie.0,id=upstream \
>> -device xio3130-downstream,bus=$parent,id=downstream,chassis=1 \
>> -device virtio-blk-pci,bus=downstream,id=virtio-zero,drive=zero \
>> -drive file=/dev/zero,id=zero,format=raw \
>> -kernel bzImage -append "console=ttyS0 panic=3" # pcie_aspm=off
>> done
>>
>> ASPM in QEMU works if we connect upstream through root port
>> -device ioh3420,bus=pcie.0,id=root.0 \
>> -device x3130-upstream,bus=root.0,id=upstream
>>
>> Signed-off-by: Radim Krčmář
>> ---
>> drivers/pci/pcie/aspm.c | 9 +
>> 1 file changed, 9 insertions(+)
>>
>> diff --git a/drivers/pci/pcie/aspm.c b/drivers/pci/pcie/aspm.c
>> index 403a443..209cd7f 100644
>> --- a/drivers/pci/pcie/aspm.c
>> +++ b/drivers/pci/pcie/aspm.c
>> @@ -570,6 +570,15 @@ void pcie_aspm_init_link_state(struct pci_dev *pdev)
>> pdev->bus->self)
>> return;
>>
>> + /* We require at least two ports between downstream and root bus */
>> + if (pci_pcie_type(pdev) == PCI_EXP_TYPE_DOWNSTREAM &&
>> + (pci_is_root_bus(pdev->bus) ||
>> + pci_is_root_bus(pdev->bus->parent))) {
>> + dev_warn(>dev, "ASPM disabled"
>> + " (connected directly to root bus)\n");
>> + return;
>> + }
>
> I don't really want to detect invalid topologies piecemeal -- we will
> likely find other areas (MPS, AER, link speed management, etc.) that
> have similar dependencies. I'd rather do it generically, maybe with
> something like the following patch.
>
> I tried this with the following qemu invocation:
>
> $ /usr/local/bin/qemu-system-x86_64 -M q35 -enable-kvm -m 512 -device
> x3130-upstream,bus=pcie.0,id=upstream -device
> xio3130-downstream,bus=upstream,id=downstream,chassis=1 -drive
> file=ubuntu.img,if=none,id=mydisk -device ide-drive,drive=mydisk,bus=ide.0
> -drive file=scratch.img,id=disk1 -device
> virtio-blk-pci,bus=downstream,id=virtio-disk1,drive=disk1 -nographic -kernel
> ~/linux/arch/x86/boot/bzImage -append "console=ttyS0,115200n8
> root=/dev/sda1 ignore_loglevel"
>
> With unmodified v3.11-rc2, I see the NULL pointer dereference, but with
> the patch below applied, we just ignore the 00:03.0 device and the kernel
> boots fine.
Thinking about this some more, I'm inclined to do nothing. The patch
below *would* avoid the issue, but it's a fair bit of code and
comments that future code readers would have to wade through, and the
only benefit is for topologies that are completely invalid and will
never be seen in real hardware.
I think that we could also avoid this issue by reworking our ASPM
support, and if we were to do anything, that's what I would prefer.
For example, consider the following (legal and common) topology:
00:1c.0 Root Port (bridge leading to [bus 01-03])
01:00.0 Upstream Port (bridge leading to [bus 02-03])
02:00.0 Downstream Port (bridge leading to [bus 03])
When we initialize ASPM link state for 02:00.0, we look all the way up
to the link state for 00:1c.0 (the
"pdev->bus->parent->self->link_state" in alloc_pcie_link_state()). I
think that's crazy. ASPM is fundamentally a feature of a *link*, and
the only link directly related to 02:00.0 is the one leading
*downstream* to device 03:00.0.
I know there are latency questions where we do care about upstream
links, and there's commit 46bbdfa44c, which is what originally added
this "pdev->bus->parent->self->link_state" expression. It suggests
that we need to check the whole hierarchy up to the root port. But
there's not enough information in the changelog to really explain it.
So I strongly support rework that would simplify ASPM management
overall. I just don't want to add point fixes that only handle
special cases,
RE: [E1000-devel] 3.11-rc4 ixgbevf: endless "Last Request of type 00 to PF Nacked" messages
> -Original Message- > From: Bjorn Helgaas [mailto:bhelg...@google.com] > Sent: Friday, August 23, 2013 1:43 PM > To: Skidmore, Donald C > Cc: e1000-de...@lists.sourceforge.net; linux-...@vger.kernel.org; linux- > ker...@vger.kernel.org; Don Dutile > Subject: Re: [E1000-devel] 3.11-rc4 ixgbevf: endless "Last Request of type 00 > to PF Nacked" messages > > On Fri, Aug 23, 2013 at 2:37 PM, Skidmore, Donald C > wrote: > >> -Original Message- > >> From: Bjorn Helgaas [mailto:bhelg...@google.com] > >> Sent: Friday, August 23, 2013 11:53 AM > >> To: Skidmore, Donald C > >> Cc: e1000-de...@lists.sourceforge.net; linux-...@vger.kernel.org; > >> linux- ker...@vger.kernel.org; Don Dutile > >> Subject: Re: [E1000-devel] 3.11-rc4 ixgbevf: endless "Last Request of > >> type 00 to PF Nacked" messages > >> > >> On Fri, Aug 23, 2013 at 06:25:06PM +, Skidmore, Donald C wrote: > >> > > -Original Message- > >> > > From: Bjorn Helgaas [mailto:bhelg...@google.com] > >> > > Sent: Friday, August 23, 2013 9:53 AM > >> > > To: Skidmore, Donald C > >> > > Cc: e1000-de...@lists.sourceforge.net; linux-...@vger.kernel.org; > >> > > linux- ker...@vger.kernel.org; Don Dutile > >> > > Subject: Re: [E1000-devel] 3.11-rc4 ixgbevf: endless "Last > >> > > Request of type 00 to PF Nacked" messages > >> > > > >> > > On Tue, Aug 20, 2013 at 5:37 PM, Bjorn Helgaas > >> > > > >> > > wrote: > >> > > > On Tue, Aug 20, 2013 at 5:08 PM, Bjorn Helgaas > >> > > > > >> > > wrote: > >> > > >> On Tue, Aug 13, 2013 at 8:23 PM, Bjorn Helgaas > >> > > >> > >> > > wrote: > >> > > > > >> > > >>> I played with this a little more and found this: > >> > > >>> > >> > > >>> 1) Magma card in z420, connected to chassis containing X540: > >> > > >>> fails (original report) > >> > > >>> 2) X540 in z420, Magma card in z420, connected to empty chassis: > >> > > >>> fails > >> > > >>> 3) X540 in z420, Magma card in z420 but no cable to chassis: > >> > > >>> works > >> > > > > >> > > > For what it's worth, I tried config 3 again with v3.11-rc6, and > >> > > > it failed the same way. I haven't bothered with config 2. > >> > > > It's not 100% reproducible, but at least it doesn't seem > >> > > > related to the expansion chassis. > >> > > > > >> > > > I attached the logs from config 3 to > >> > > > https://bugzilla.kernel.org/show_bug.cgi?id=60776 > >> > > > >> > > Is there anything I can do to help debug this? Add > >> > > instrumentation, etc.? It seems like I'm doing the simplest > >> > > possible thing -- just writing to the sysfs sriov_num_vfs file to > >> > > enable > VFs. > >> > > > >> > > I almost think it must be related to my config somehow if nobody > >> > > else is seeing this, but at the same time, my config also seems > >> > > the simplest possible, so I don't know what I could be doing that's > unusual. > >> > > > >> > > Bjorn > >> > > >> > Hey Bjorn, > >> > > >> > I'm may be little confused so bear with me. > >> > > >> > Option 1 = (your normal set up), Magma card plugged to chasis, X540 > >> > in > >> chasis. > >> > Option 2 = Magma card plugged to chasis, X540 in z420 system. > >> > Option 3 = Magma card UNplugged from chasis, x540 in z420 system. > >> > > >> > Options 1 & 2 - always fail > >> > Option 3 - sometimes fails (unsure at what rate failure occurs) > >> > > >> > Please correct me if I messed any of that up. :) > >> > >> Generally correct. I've seen failures in all three configs, so I'm > >> only concerned with the simplest for now (config 3, no expansion chassis). > >> > >> > Another question I have relates to the lspci output you supplied in > >> > the > >> bugzilla. I'm not seeing the VF devices (i.e. 08:10.0) did you run > >> lspci before you created the VF's? If so could we see one while the > >> failure > was occurring? > >> > >> That's correct, I collected the lspci output before reproducing the > >> problem. I can't easily collect lspci afterwards because the machine > >> isn't responsive after the problem starts. > >> > >> > Also could you download the latest ixgbevf from source forge? > >> > > >> > https://sourceforge.net/projects/e1000/files/ixgbevf%20stable/ > >> > > >> > If we add debugging messages it will be easier to patch this driver > >> > and it > >> contains our latest validated code base. > >> > >> I can do that if it turns out to be necessary. But John Haller gave > >> me a good clue off-list: > >> > >> John wrote: > >> > I assume you want the VFs to be instantiated in a VM. To do this, > >> > you need to blacklist the ixgbevf driver in the host (or not > >> > compile it into the host), or it will try to associate the driver > >> > in the host, rather than in the VM where you want it. Then, the VM > >> > needs the ixgbevf driver, which will hopefully do a better job of > >> > talking to the mailbox in the host. There is some work to assign > >> > the VF(s) to the VM, but I don't remember that offhand. > >> > >> I don't have any VMs (I started this whole thing because I was > >>
Re: [PATCH 1/1] AMD64_EDAC: Fix incorrect wrap arounds due to left shift beyond 32 bits.
On Mon, Aug 19, 2013 at 07:27:52PM -0500, Aravind Gopalakrishnan wrote: > Link to the bug report: > http://marc.info/?l=linux-edac=137692201732220=2 > > dct_base and dct_limit obtain 32 bit register values when they read their > respective pci config space registers. A left shift beyond 32 bits will > cause them to wrap around. Similar case for chan_addr as can be seen from > the bug report. In the patch, we rectify this by casting chan_addr to u64 > and by comparing dct_base and dct_limit against (sys_addr >> 27) > > Tested on F15h, M30h with ECC turned on and works fine. > > Signed-off-by: Aravind Gopalakrishnan > > diff --git a/drivers/edac/amd64_edac.c b/drivers/edac/amd64_edac.c > index b86228c..eb4793e 100644 > --- a/drivers/edac/amd64_edac.c > +++ b/drivers/edac/amd64_edac.c > @@ -1558,11 +1558,12 @@ static int f15_m30h_match_to_this_node(struct > amd64_pvt *pvt, unsigned range, > } > > /* Verify sys_addr is within DCT Range. */ > - dct_base = (dct_sel_baseaddr(pvt) << 27); > - dct_limit = (((dct_cont_limit_reg >> 11) & 0x1FFF) << 27) | 0x7FF; > + dct_base = dct_sel_baseaddr(pvt); This can't be correct. So the original patch takes the shifted dct_base while your change doesn't anymore... > + dct_limit = (dct_cont_limit_reg >> 11) & 0x1FFF; > > if (!(dct_cont_base_reg & BIT(0)) && > - !(dct_base <= sys_addr && dct_limit >= sys_addr)) > + !(dct_base <= (sys_addr >> 27) && > + dct_limit >= (sys_addr >> 27))) ... and while this comparison shifts sys_addr to use the proper bits, the code does this assignment later: chan_offset = dct_base; Now, chan_offset has the << 27 version of dct_base which makes the following calculation wrong: chan_addr = sys_addr - chan_offset; because sys_addr is the full 64-bit, unshifted value. The right thing to do would be to do: chan_offset = dct_base << 27; Or am I missing something? -- 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: [PATCH 15/15] workqueue: convert bus code to use dev_groups
On Fri, Aug 23, 2013 at 05:28:32PM -0400, Tejun Heo wrote: > On Fri, Aug 23, 2013 at 02:24:41PM -0700, Greg Kroah-Hartman wrote: > > The dev_attrs field of struct bus_type is going away soon, dev_groups > > should be used instead. This converts the workqueue bus code to use > > the correct field. > > > > Cc: Tejun Heo > > Signed-off-by: Greg Kroah-Hartman > > Acked-by: Tejun Heo > > If you want the patch to be routed through the wq tree, please let me > know. No worries, I can take this through my driver-core tree, thanks for the ack. 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] ACPI: Fix osc flag setup ordering to allow pcie hotplug use when available
On Friday, August 23, 2013 02:46:23 PM Bjorn Helgaas wrote:
> On Fri, Aug 23, 2013 at 2:53 PM, Rafael J. Wysocki wrote:
> > On Friday, August 23, 2013 04:05:11 PM Neil Horman wrote:
> >> On Fri, Aug 23, 2013 at 09:38:18PM +0200, Rafael J. Wysocki wrote:
> >> > [CCs added]
> >> >
> >> > Please always send PCI-related material to linux-pci in the first place.
> >> >
> >> Sorry, I ran get_maintainers and it seemed to think linux-acpi was
> >> sufficient.
> >>
> >> > The change that broke things for you was actually intentional:
> >> >
> >> > commit b8178f130e25c1bdac1c33e0996f1ff6e20ec08e
> >> > Author: Bjorn Helgaas
> >> > Date: Mon Apr 1 15:47:39 2013 -0600
> >> >
> >> > Revert "PCI/ACPI: Request _OSC control before scanning PCI root bus"
> >> >
> >> > This reverts commit 8c33f51df406e1a1f7fa4e9b244845b7ebd61fa6.
> >> >
> >> > so I think we'll need to clean up the ASMP initialization after all.
> >> >
> >> Crud. Reading over the revert commit, it seems like the problem boils
> >> down to
> >> the odering of checking aspm_disabled. It seems to me that the simple fix
> >> is to
> >> track the desire for acpi to disable aspm separately from the users desire
> >> to
> >> disable aspm (aspm_disabled). Then we just turn the points where we check
> >> the
> >> aspm_disabled into the appropriate or of two variables, except for
> >> pcie_asmp_sanity_check, which remains sensitive to just the user disable
> >> option.
> >>
> >> Or is there more to this?
> >
> > No, I think you're right.
> >
> > Bjorn, what do you think?
>
> My opinion is that the _OSC/ASPM state management is ridiculously
> complicated already, and this would make it slightly more complicated.
> That's why my preference would be to attempt a more radical cleanup
> and simplification instead of adding another wart.
Well, do you have anything specific in mind?
> But if you want to merge a patch along the lines of what Neil
> proposes, I won't object.
I'm not sure what to do really, so I'm asking. :-)
Rafael
> >> > On Friday, August 23, 2013 01:19:39 PM Neil Horman wrote:
> >> > > Somewhere between 3.9 and 3.10 it seems the order in which pcie and
> >> > > acpi probed
> >> > > slots for hotplug capabilites got reversed. While this isn't a big
> >> > > deal, it did
> >> > > uncover a bug in the ACPI bus setup path. Specifically,
> >> > > acpi_pci_root_add calls
> >> > > pci_acpi_scan_root before setting the osc flags for the device handle.
> >> > > pci_acpi_scan_root, among other things uses
> >> > > device_is_managed_by_native_pciehp()
> >> > > to determine if a given slot has pcie hotplug capabilties, whcih
> >> > > checks the
> >> > > devices OSC_PCI_EXPRESS_NATIVE_HP_CONTROL flag. Since that flag is
> >> > > not set
> >> > > until after pci_acpi_scan_root_completes, the acpi code never sees
> >> > > that pcie
> >> > > slots are hotplug capable and configures them all to use acpi instead.
> >> > >
> >> > > Fix is pretty simple, just defer the scan until after the osc flags
> >> > > have been
> >> > > set on the device. Tested by myself and it seems to work well.
> >> > >
> >> > > Signed-off-by: Neil Horman
> >> > > CC: Len Brown
> >> > > CC: "Rafael J. Wysocki"
> >> > > CC: linux-a...@vger.kernel.org
> >> > > ---
> >> > > drivers/acpi/pci_root.c | 41 -
> >> > > 1 file changed, 20 insertions(+), 21 deletions(-)
> >> > >
> >> > > diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
> >> > > index 5917839..a2c2661 100644
> >> > > --- a/drivers/acpi/pci_root.c
> >> > > +++ b/drivers/acpi/pci_root.c
> >> > > @@ -437,27 +437,6 @@ static int acpi_pci_root_add(struct acpi_device
> >> > > *device,
> >> > > flags = base_flags = OSC_PCI_SEGMENT_GROUPS_SUPPORT;
> >> > > acpi_pci_osc_support(root, flags);
> >> > >
> >> > > - /*
> >> > > - * TBD: Need PCI interface for enumeration/configuration of roots.
> >> > > - */
> >> > > -
> >> > > - /*
> >> > > - * Scan the Root Bridge
> >> > > - *
> >> > > - * Must do this prior to any attempt to bind the root device, as the
> >> > > - * PCI namespace does not get created until this call is made (and
> >> > > - * thus the root bridge's pci_dev does not exist).
> >> > > - */
> >> > > - root->bus = pci_acpi_scan_root(root);
> >> > > - if (!root->bus) {
> >> > > - dev_err(>dev,
> >> > > - "Bus %04x:%02x not present in PCI namespace\n",
> >> > > - root->segment, (unsigned int)root->secondary.start);
> >> > > - result = -ENODEV;
> >> > > - goto end;
> >> > > - }
> >> > > -
> >> > > - /* Indicate support for various _OSC capabilities. */
> >> > > if (pci_ext_cfg_avail())
> >> > > flags |= OSC_EXT_PCI_CONFIG_SUPPORT;
> >> > > if (pcie_aspm_support_enabled()) {
> >> > > @@ -520,6 +499,26 @@ static int acpi_pci_root_add(struct acpi_device
> >> > > *device,
> >> > >"(_OSC support mask: 0x%02x)\n", flags);
> >> > >
Re: [PATCH v2 3/4] clk: mvebu: add missing iounmap
Quoting Jisheng Zhang (2013-08-22 19:34:01)
> Add missing iounmap to setup error path.
>
> Change-Id: I4371569d14d7026aa9f90d7cd53f669d365fe26a
Please remove Change-Id's from the commit message for upstream patch
submissions in the future. I can remove this one, this time.
I've taken the patch into clk-next.
Regards,
Mike
> Signed-off-by: Jisheng Zhang
> ---
> drivers/clk/mvebu/clk-cpu.c | 4 +++-
> drivers/clk/mvebu/common.c | 18 --
> 2 files changed, 15 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/clk/mvebu/clk-cpu.c b/drivers/clk/mvebu/clk-cpu.c
> index b0fbc07..1466865 100644
> --- a/drivers/clk/mvebu/clk-cpu.c
> +++ b/drivers/clk/mvebu/clk-cpu.c
> @@ -119,7 +119,7 @@ void __init of_cpu_clk_setup(struct device_node *node)
>
> cpuclk = kzalloc(ncpus * sizeof(*cpuclk), GFP_KERNEL);
> if (WARN_ON(!cpuclk))
> - return;
> + goto cpuclk_out;
>
> clks = kzalloc(ncpus * sizeof(*clks), GFP_KERNEL);
> if (WARN_ON(!clks))
> @@ -170,6 +170,8 @@ bail_out:
> kfree(cpuclk[ncpus].clk_name);
> clks_out:
> kfree(cpuclk);
> +cpuclk_out:
> + iounmap(clock_complex_base);
> }
>
> CLK_OF_DECLARE(armada_xp_cpu_clock, "marvell,armada-xp-cpu-clock",
> diff --git a/drivers/clk/mvebu/common.c b/drivers/clk/mvebu/common.c
> index adaa4a1..25ceccf 100644
> --- a/drivers/clk/mvebu/common.c
> +++ b/drivers/clk/mvebu/common.c
> @@ -45,8 +45,10 @@ void __init mvebu_coreclk_setup(struct device_node *np,
> clk_data.clk_num = 2 + desc->num_ratios;
> clk_data.clks = kzalloc(clk_data.clk_num * sizeof(struct clk *),
> GFP_KERNEL);
> - if (WARN_ON(!clk_data.clks))
> + if (WARN_ON(!clk_data.clks)) {
> + iounmap(base);
> return;
> + }
>
> /* Register TCLK */
> of_property_read_string_index(np, "clock-output-names", 0,
> @@ -134,7 +136,7 @@ void __init mvebu_clk_gating_setup(struct device_node *np,
>
> ctrl = kzalloc(sizeof(*ctrl), GFP_KERNEL);
> if (WARN_ON(!ctrl))
> - return;
> + goto ctrl_out;
>
> spin_lock_init(>lock);
>
> @@ -145,10 +147,8 @@ void __init mvebu_clk_gating_setup(struct device_node
> *np,
> ctrl->num_gates = n;
> ctrl->gates = kzalloc(ctrl->num_gates * sizeof(struct clk *),
> GFP_KERNEL);
> - if (WARN_ON(!ctrl->gates)) {
> - kfree(ctrl);
> - return;
> - }
> + if (WARN_ON(!ctrl->gates))
> + goto gates_out;
>
> for (n = 0; n < ctrl->num_gates; n++) {
> const char *parent =
> @@ -160,4 +160,10 @@ void __init mvebu_clk_gating_setup(struct device_node
> *np,
> }
>
> of_clk_add_provider(np, clk_gating_get_src, ctrl);
> +
> + return;
> +gates_out:
> + kfree(ctrl);
> +ctrl_out:
> + iounmap(base);
> }
> --
> 1.8.4.rc3
--
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 02/15] rbd: convert bus code to use bus_groups
The bus_attrs field of struct bus_type is going away soon, dev_groups
should be used instead. This converts the RBD bus code to use the
correct field.
Cc: Yehuda Sadeh
Cc: Sage Weil
Cc: Alex Elder
Cc:
Signed-off-by: Greg Kroah-Hartman
---
drivers/block/rbd.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/block/rbd.c b/drivers/block/rbd.c
index 4ad2ad9a..191cd177 100644
--- a/drivers/block/rbd.c
+++ b/drivers/block/rbd.c
@@ -397,15 +397,19 @@ static ssize_t rbd_remove(struct bus_type *bus, const
char *buf,
static int rbd_dev_image_probe(struct rbd_device *rbd_dev, bool mapping);
static void rbd_spec_put(struct rbd_spec *spec);
-static struct bus_attribute rbd_bus_attrs[] = {
- __ATTR(add, S_IWUSR, NULL, rbd_add),
- __ATTR(remove, S_IWUSR, NULL, rbd_remove),
- __ATTR_NULL
+static BUS_ATTR(add, S_IWUSR, NULL, rbd_add);
+static BUS_ATTR(remove, S_IWUSR, NULL, rbd_remove);
+
+static struct attribute *rbd_bus_attrs[] = {
+ _attr_add.attr,
+ _attr_remove.attr,
+ NULL,
};
+ATTRIBUTE_GROUPS(rbd_bus);
static struct bus_type rbd_bus_type = {
.name = "rbd",
- .bus_attrs = rbd_bus_attrs,
+ .bus_groups = rbd_bus_groups,
};
static void rbd_root_dev_release(struct device *dev)
--
1.8.3.rc0.20.gb99dd2e
--
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 15/15] workqueue: convert bus code to use dev_groups
On Fri, Aug 23, 2013 at 02:24:41PM -0700, Greg Kroah-Hartman wrote: > The dev_attrs field of struct bus_type is going away soon, dev_groups > should be used instead. This converts the workqueue bus code to use > the correct field. > > Cc: Tejun Heo > Signed-off-by: Greg Kroah-Hartman Acked-by: Tejun Heo If you want the patch to be routed through the wq tree, please let me know. Thanks. -- tejun -- 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 01/15] PCI: convert bus code to use bus_groups
The bus_attrs field of struct bus_type is going away soon, dev_groups
should be used instead. This converts the PCI bus code to use the
correct field.
Cc: Bjorn Helgaas
Signed-off-by: Greg Kroah-Hartman
---
drivers/pci/pci-driver.c | 2 +-
drivers/pci/pci-sysfs.c | 16 +---
drivers/pci/pci.h| 2 +-
3 files changed, 15 insertions(+), 5 deletions(-)
diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c
index e6515e21..09db761e 100644
--- a/drivers/pci/pci-driver.c
+++ b/drivers/pci/pci-driver.c
@@ -1274,7 +1274,7 @@ struct bus_type pci_bus_type = {
.remove = pci_device_remove,
.shutdown = pci_device_shutdown,
.dev_attrs = pci_dev_attrs,
- .bus_attrs = pci_bus_attrs,
+ .bus_groups = pci_bus_groups,
.drv_attrs = pci_drv_attrs,
.pm = PCI_PM_OPS_PTR,
};
diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
index c0dbe1f6..f0195946 100644
--- a/drivers/pci/pci-sysfs.c
+++ b/drivers/pci/pci-sysfs.c
@@ -302,10 +302,20 @@ static ssize_t bus_rescan_store(struct bus_type *bus,
const char *buf,
}
return count;
}
+static BUS_ATTR(rescan, (S_IWUSR|S_IWGRP), NULL, bus_rescan_store);
-struct bus_attribute pci_bus_attrs[] = {
- __ATTR(rescan, (S_IWUSR|S_IWGRP), NULL, bus_rescan_store),
- __ATTR_NULL
+struct attribute *pci_bus_attrs[] = {
+ _attr_rescan.attr,
+ NULL,
+};
+
+static const struct attribute_group pci_bus_group = {
+ .attrs = pci_bus_attrs,
+};
+
+const struct attribute_group *pci_bus_groups[] = {
+ _bus_group,
+ NULL,
};
static ssize_t
diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index d1182c4a..62bcf2bd 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -153,7 +153,7 @@ static inline int pci_no_d1d2(struct pci_dev *dev)
extern struct device_attribute pci_dev_attrs[];
extern struct device_attribute pcibus_dev_attrs[];
extern struct device_type pci_dev_type;
-extern struct bus_attribute pci_bus_attrs[];
+extern const struct attribute_group *pci_bus_groups[];
/**
--
1.8.3.rc0.20.gb99dd2e
--
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 04/15] PPC: ibmebus: convert bus code to use bus_groups
The bus_attrs field of struct bus_type is going away soon, dev_groups
should be used instead. This converts the ibmebus bus code to use the
correct field.
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Signed-off-by: Greg Kroah-Hartman
---
arch/powerpc/kernel/ibmebus.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/kernel/ibmebus.c b/arch/powerpc/kernel/ibmebus.c
index 16a7c232..1114d13a 100644
--- a/arch/powerpc/kernel/ibmebus.c
+++ b/arch/powerpc/kernel/ibmebus.c
@@ -292,6 +292,7 @@ out:
return rc;
return count;
}
+static BUS_ATTR(probe, S_IWUSR, NULL, ibmebus_store_probe);
static ssize_t ibmebus_store_remove(struct bus_type *bus,
const char *buf, size_t count)
@@ -317,13 +318,14 @@ static ssize_t ibmebus_store_remove(struct bus_type *bus,
return -ENODEV;
}
}
+static BUS_ATTR(remove, S_IWUSR, NULL, ibmebus_store_remove);
-
-static struct bus_attribute ibmebus_bus_attrs[] = {
- __ATTR(probe, S_IWUSR, NULL, ibmebus_store_probe),
- __ATTR(remove, S_IWUSR, NULL, ibmebus_store_remove),
- __ATTR_NULL
+static struct attribute *ibmbus_bus_attrs[] = {
+ _attr_probe.attr,
+ _attr_remove.attr,
+ NULL,
};
+ATTRIBUTE_GROUPS(ibmbus_bus);
static int ibmebus_bus_bus_match(struct device *dev, struct device_driver *drv)
{
@@ -713,7 +715,7 @@ static struct dev_pm_ops ibmebus_bus_dev_pm_ops = {
struct bus_type ibmebus_bus_type = {
.name = "ibmebus",
.uevent= of_device_uevent_modalias,
- .bus_attrs = ibmebus_bus_attrs,
+ .bus_groups = ibmbus_bus_groups,
.match = ibmebus_bus_bus_match,
.probe = ibmebus_bus_device_probe,
.remove= ibmebus_bus_device_remove,
--
1.8.3.rc0.20.gb99dd2e
--
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 03/15] rapidio: convert bus code to use bus_groups
The bus_attrs field of struct bus_type is going away soon, dev_groups
should be used instead. This converts the rapidio bus code to use the
correct field.
Cc: Matt Porter
Cc: Alexandre Bounine
Signed-off-by: Greg Kroah-Hartman
---
drivers/rapidio/rio-driver.c | 2 +-
drivers/rapidio/rio-sysfs.c | 16 +---
drivers/rapidio/rio.h| 2 +-
3 files changed, 15 insertions(+), 5 deletions(-)
diff --git a/drivers/rapidio/rio-driver.c b/drivers/rapidio/rio-driver.c
index 3e9b6a78..2be2d24d 100644
--- a/drivers/rapidio/rio-driver.c
+++ b/drivers/rapidio/rio-driver.c
@@ -224,7 +224,7 @@ struct bus_type rio_bus_type = {
.name = "rapidio",
.match = rio_match_bus,
.dev_attrs = rio_dev_attrs,
- .bus_attrs = rio_bus_attrs,
+ .bus_groups = rio_bus_groups,
.probe = rio_device_probe,
.remove = rio_device_remove,
.uevent = rio_uevent,
diff --git a/drivers/rapidio/rio-sysfs.c b/drivers/rapidio/rio-sysfs.c
index 9331be64..795a4776 100644
--- a/drivers/rapidio/rio-sysfs.c
+++ b/drivers/rapidio/rio-sysfs.c
@@ -316,8 +316,18 @@ exit:
return rc;
}
+static BUS_ATTR(scan, (S_IWUSR|S_IWGRP), NULL, bus_scan_store);
-struct bus_attribute rio_bus_attrs[] = {
- __ATTR(scan, (S_IWUSR|S_IWGRP), NULL, bus_scan_store),
- __ATTR_NULL
+static struct attribute *rio_bus_attrs[] = {
+ _attr_scan.attr,
+ NULL,
+};
+
+static const struct attribute_group rio_bus_group = {
+ .attrs = rio_bus_attrs,
+};
+
+const struct attribute_group *rio_bus_groups[] = {
+ _bus_group,
+ NULL,
};
diff --git a/drivers/rapidio/rio.h b/drivers/rapidio/rio.h
index 085215cd..57d2ad06 100644
--- a/drivers/rapidio/rio.h
+++ b/drivers/rapidio/rio.h
@@ -49,7 +49,7 @@ extern int rio_mport_scan(int mport_id);
/* Structures internal to the RIO core code */
extern struct device_attribute rio_dev_attrs[];
-extern struct bus_attribute rio_bus_attrs[];
+extern const struct attribute_group *rio_bus_groups[];
#define RIO_GET_DID(size, x) (size ? (x & 0x) : ((x & 0x00ff) >> 16))
#define RIO_SET_DID(size, x) (size ? (x & 0x) : ((x & 0x00ff) << 16))
--
1.8.3.rc0.20.gb99dd2e
--
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 08/15] Input: serio: convert bus code to use drv_groups
The drv_attrs field of struct bus_type is going away soon, drv_groups
should be used instead. This converts the serio bus code to use the
correct field.
Cc: Dmitry Torokhov
Signed-off-by: Greg Kroah-Hartman
---
drivers/input/serio/serio.c | 21 +++--
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/drivers/input/serio/serio.c b/drivers/input/serio/serio.c
index 25fc5971..2b56855c 100644
--- a/drivers/input/serio/serio.c
+++ b/drivers/input/serio/serio.c
@@ -732,19 +732,20 @@ EXPORT_SYMBOL(serio_unregister_child_port);
* Serio driver operations
*/
-static ssize_t serio_driver_show_description(struct device_driver *drv, char
*buf)
+static ssize_t description_show(struct device_driver *drv, char *buf)
{
struct serio_driver *driver = to_serio_driver(drv);
return sprintf(buf, "%s\n", driver->description ? driver->description :
"(none)");
}
+static DRIVER_ATTR_RO(description);
-static ssize_t serio_driver_show_bind_mode(struct device_driver *drv, char
*buf)
+static ssize_t bind_mode_show(struct device_driver *drv, char *buf)
{
struct serio_driver *serio_drv = to_serio_driver(drv);
return sprintf(buf, "%s\n", serio_drv->manual_bind ? "manual" : "auto");
}
-static ssize_t serio_driver_set_bind_mode(struct device_driver *drv, const
char *buf, size_t count)
+static ssize_t bind_mode_store(struct device_driver *drv, const char *buf,
size_t count)
{
struct serio_driver *serio_drv = to_serio_driver(drv);
int retval;
@@ -760,14 +761,14 @@ static ssize_t serio_driver_set_bind_mode(struct
device_driver *drv, const char
return retval;
}
+static DRIVER_ATTR_RW(bind_mode);
-
-static struct driver_attribute serio_driver_attrs[] = {
- __ATTR(description, S_IRUGO, serio_driver_show_description, NULL),
- __ATTR(bind_mode, S_IWUSR | S_IRUGO,
- serio_driver_show_bind_mode, serio_driver_set_bind_mode),
- __ATTR_NULL
+static struct attribute *serio_driver_attrs[] = {
+ _attr_description.attr,
+ _attr_bind_mode.attr,
+ NULL,
};
+ATTRIBUTE_GROUPS(serio_driver);
static int serio_driver_probe(struct device *dev)
{
@@ -996,7 +997,7 @@ EXPORT_SYMBOL(serio_interrupt);
static struct bus_type serio_bus = {
.name = "serio",
.dev_attrs = serio_device_attrs,
- .drv_attrs = serio_driver_attrs,
+ .drv_groups = serio_driver_groups,
.match = serio_bus_match,
.uevent = serio_uevent,
.probe = serio_driver_probe,
--
1.8.3.rc0.20.gb99dd2e
--
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 07/15] Input: gameport: convert bus code to use drv_groups
The drv_attrs field of struct bus_type is going away soon, drv_groups
should be used instead. This converts the gameport bus code to use the
correct field.
Cc: Dmitry Torokhov
Signed-off-by: Greg Kroah-Hartman
---
drivers/input/gameport/gameport.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/input/gameport/gameport.c
b/drivers/input/gameport/gameport.c
index da739d9d..922a7fea 100644
--- a/drivers/input/gameport/gameport.c
+++ b/drivers/input/gameport/gameport.c
@@ -639,16 +639,18 @@ EXPORT_SYMBOL(gameport_unregister_port);
* Gameport driver operations
*/
-static ssize_t gameport_driver_show_description(struct device_driver *drv,
char *buf)
+static ssize_t description_show(struct device_driver *drv, char *buf)
{
struct gameport_driver *driver = to_gameport_driver(drv);
return sprintf(buf, "%s\n", driver->description ? driver->description :
"(none)");
}
+static DRIVER_ATTR_RO(description);
-static struct driver_attribute gameport_driver_attrs[] = {
- __ATTR(description, S_IRUGO, gameport_driver_show_description, NULL),
- __ATTR_NULL
+static struct attribute *gameport_driver_attrs[] = {
+ _attr_description.attr,
+ NULL
};
+ATTRIBUTE_GROUPS(gameport_driver);
static int gameport_driver_probe(struct device *dev)
{
@@ -749,7 +751,7 @@ static int gameport_bus_match(struct device *dev, struct
device_driver *drv)
static struct bus_type gameport_bus = {
.name = "gameport",
.dev_attrs = gameport_device_attrs,
- .drv_attrs = gameport_driver_attrs,
+ .drv_groups = gameport_driver_groups,
.match = gameport_bus_match,
.probe = gameport_driver_probe,
.remove = gameport_driver_remove,
--
1.8.3.rc0.20.gb99dd2e
--
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 13/15] MEI: convert bus code to use dev_groups
> > The dev_attrs field of struct bus_type is going away soon, dev_groups should > be used instead. This converts the MEI bus code to use the correct field. > > Cc: Tomas Winkler > Signed-off-by: Greg Kroah-Hartman ACK + CC: Samuel. Thanks Tomas -- 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 05/15] PPC: VIO: convert bus code to use bus_groups
The bus_attrs field of struct bus_type is going away soon, dev_groups
should be used instead. This converts the VIO bus code to use the
correct field.
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Signed-off-by: Greg Kroah-Hartman
---
arch/powerpc/kernel/vio.c | 66 ++-
1 file changed, 36 insertions(+), 30 deletions(-)
diff --git a/arch/powerpc/kernel/vio.c b/arch/powerpc/kernel/vio.c
index 536016d7..5e34f20b 100644
--- a/arch/powerpc/kernel/vio.c
+++ b/arch/powerpc/kernel/vio.c
@@ -997,21 +997,36 @@ static struct device_attribute vio_cmo_dev_attrs[] = {
/* sysfs bus functions and data structures for CMO */
#define viobus_cmo_rd_attr(name)\
-static ssize_t \
-viobus_cmo_##name##_show(struct bus_type *bt, char *buf)\
+static ssize_t cmo_##name##_show(struct bus_type *bt, char *buf)\
{ \
return sprintf(buf, "%lu\n", vio_cmo.name); \
-}
+} \
+static BUS_ATTR_RO(cmo_##name)
#define viobus_cmo_pool_rd_attr(name, var) \
static ssize_t \
-viobus_cmo_##name##_pool_show_##var(struct bus_type *bt, char *buf) \
+cmo_##name##_##var##_show(struct bus_type *bt, char *buf) \
{ \
return sprintf(buf, "%lu\n", vio_cmo.name.var); \
+} \
+static BUS_ATTR_RO(cmo_##name##_##var)
+
+viobus_cmo_rd_attr(entitled);
+viobus_cmo_rd_attr(spare);
+viobus_cmo_rd_attr(min);
+viobus_cmo_rd_attr(desired);
+viobus_cmo_rd_attr(curr);
+viobus_cmo_pool_rd_attr(reserve, size);
+viobus_cmo_pool_rd_attr(excess, size);
+viobus_cmo_pool_rd_attr(excess, free);
+
+static ssize_t cmo_high_show(struct bus_type *bt, char *buf)
+{
+ return sprintf(buf, "%lu\n", vio_cmo.high);
}
-static ssize_t viobus_cmo_high_reset(struct bus_type *bt, const char *buf,
- size_t count)
+static ssize_t cmo_high_store(struct bus_type *bt, const char *buf,
+ size_t count)
{
unsigned long flags;
@@ -1021,35 +1036,26 @@ static ssize_t viobus_cmo_high_reset(struct bus_type
*bt, const char *buf,
return count;
}
-
-viobus_cmo_rd_attr(entitled);
-viobus_cmo_pool_rd_attr(reserve, size);
-viobus_cmo_pool_rd_attr(excess, size);
-viobus_cmo_pool_rd_attr(excess, free);
-viobus_cmo_rd_attr(spare);
-viobus_cmo_rd_attr(min);
-viobus_cmo_rd_attr(desired);
-viobus_cmo_rd_attr(curr);
-viobus_cmo_rd_attr(high);
-
-static struct bus_attribute vio_cmo_bus_attrs[] = {
- __ATTR(cmo_entitled, S_IRUGO, viobus_cmo_entitled_show, NULL),
- __ATTR(cmo_reserve_size, S_IRUGO, viobus_cmo_reserve_pool_show_size,
NULL),
- __ATTR(cmo_excess_size, S_IRUGO, viobus_cmo_excess_pool_show_size,
NULL),
- __ATTR(cmo_excess_free, S_IRUGO, viobus_cmo_excess_pool_show_free,
NULL),
- __ATTR(cmo_spare, S_IRUGO, viobus_cmo_spare_show, NULL),
- __ATTR(cmo_min, S_IRUGO, viobus_cmo_min_show, NULL),
- __ATTR(cmo_desired, S_IRUGO, viobus_cmo_desired_show, NULL),
- __ATTR(cmo_curr,S_IRUGO, viobus_cmo_curr_show,NULL),
- __ATTR(cmo_high,S_IWUSR|S_IRUSR|S_IWGRP|S_IRGRP|S_IROTH,
- viobus_cmo_high_show, viobus_cmo_high_reset),
- __ATTR_NULL
+static BUS_ATTR_RW(cmo_high);
+
+static struct attribute *vio_bus_attrs[] = {
+ _attr_cmo_entitled.attr,
+ _attr_cmo_spare.attr,
+ _attr_cmo_min.attr,
+ _attr_cmo_desired.attr,
+ _attr_cmo_curr.attr,
+ _attr_cmo_high.attr,
+ _attr_cmo_reserve_size.attr,
+ _attr_cmo_excess_size.attr,
+ _attr_cmo_excess_free.attr,
+ NULL,
};
+ATTRIBUTE_GROUPS(vio_bus);
static void vio_cmo_sysfs_init(void)
{
vio_bus_type.dev_attrs = vio_cmo_dev_attrs;
- vio_bus_type.bus_attrs = vio_cmo_bus_attrs;
+ vio_bus_type.bus_groups = vio_bus_groups;
}
#else /* CONFIG_PPC_SMLPAR */
int vio_cmo_entitlement_update(size_t new_entitlement) { return 0; }
--
1.8.3.rc0.20.gb99dd2e
--
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 15/15] workqueue: convert bus code to use dev_groups
The dev_attrs field of struct bus_type is going away soon, dev_groups
should be used instead. This converts the workqueue bus code to use
the correct field.
Cc: Tejun Heo
Signed-off-by: Greg Kroah-Hartman
---
kernel/workqueue.c | 27 +++
1 file changed, 15 insertions(+), 12 deletions(-)
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index 7f5d4be2..0d6063d8 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -3086,25 +3086,26 @@ static struct workqueue_struct *dev_to_wq(struct device
*dev)
return wq_dev->wq;
}
-static ssize_t wq_per_cpu_show(struct device *dev,
- struct device_attribute *attr, char *buf)
+static ssize_t per_cpu_show(struct device *dev, struct device_attribute *attr,
+ char *buf)
{
struct workqueue_struct *wq = dev_to_wq(dev);
return scnprintf(buf, PAGE_SIZE, "%d\n", (bool)!(wq->flags &
WQ_UNBOUND));
}
+static DEVICE_ATTR_RO(per_cpu);
-static ssize_t wq_max_active_show(struct device *dev,
- struct device_attribute *attr, char *buf)
+static ssize_t max_active_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
{
struct workqueue_struct *wq = dev_to_wq(dev);
return scnprintf(buf, PAGE_SIZE, "%d\n", wq->saved_max_active);
}
-static ssize_t wq_max_active_store(struct device *dev,
- struct device_attribute *attr,
- const char *buf, size_t count)
+static ssize_t max_active_store(struct device *dev,
+ struct device_attribute *attr, const char *buf,
+ size_t count)
{
struct workqueue_struct *wq = dev_to_wq(dev);
int val;
@@ -3115,12 +3116,14 @@ static ssize_t wq_max_active_store(struct device *dev,
workqueue_set_max_active(wq, val);
return count;
}
+static DEVICE_ATTR_RW(max_active);
-static struct device_attribute wq_sysfs_attrs[] = {
- __ATTR(per_cpu, 0444, wq_per_cpu_show, NULL),
- __ATTR(max_active, 0644, wq_max_active_show, wq_max_active_store),
- __ATTR_NULL,
+static struct attribute *wq_sysfs_attrs[] = {
+ _attr_per_cpu.attr,
+ _attr_max_active.attr,
+ NULL,
};
+ATTRIBUTE_GROUPS(wq_sysfs);
static ssize_t wq_pool_ids_show(struct device *dev,
struct device_attribute *attr, char *buf)
@@ -3270,7 +3273,7 @@ static struct device_attribute wq_sysfs_unbound_attrs[] =
{
static struct bus_type wq_subsys = {
.name = "workqueue",
- .dev_attrs = wq_sysfs_attrs,
+ .dev_groups = wq_sysfs_groups,
};
static int __init wq_sysfs_init(void)
--
1.8.3.rc0.20.gb99dd2e
--
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 11/15] driver-core: platform: convert bus code to use dev_groups
The dev_attrs field of struct bus_type is going away soon, dev_groups
should be used instead. This converts the platform bus code to use
the correct field.
Signed-off-by: Greg Kroah-Hartman
---
drivers/base/platform.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index 3c3197a8..5343f24e 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -672,11 +672,13 @@ static ssize_t modalias_show(struct device *dev, struct
device_attribute *a,
return (len >= PAGE_SIZE) ? (PAGE_SIZE - 1) : len;
}
+static DEVICE_ATTR_RO(modalias);
-static struct device_attribute platform_dev_attrs[] = {
- __ATTR_RO(modalias),
- __ATTR_NULL,
+static struct attribute *platform_dev_attrs[] = {
+ _attr_modalias.attr,
+ NULL,
};
+ATTRIBUTE_GROUPS(platform_dev);
static int platform_uevent(struct device *dev, struct kobj_uevent_env *env)
{
@@ -893,7 +895,7 @@ static const struct dev_pm_ops platform_dev_pm_ops = {
struct bus_type platform_bus_type = {
.name = "platform",
- .dev_attrs = platform_dev_attrs,
+ .dev_groups = platform_dev_groups,
.match = platform_match,
.uevent = platform_uevent,
.pm = _dev_pm_ops,
--
1.8.3.rc0.20.gb99dd2e
--
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 12/15] HID: convert bus code to use dev_groups
The dev_attrs field of struct bus_type is going away soon, dev_groups
should be used instead. This converts the HID bus code to use
the correct field.
Cc: Jiri Kosina
Signed-off-by: Greg Kroah-Hartman
---
drivers/hid/hid-core.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 36668d1a..b8f1c77f 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -1917,11 +1917,13 @@ static ssize_t modalias_show(struct device *dev, struct
device_attribute *a,
return (len >= PAGE_SIZE) ? (PAGE_SIZE - 1) : len;
}
+static DEVICE_ATTR_RO(modalias);
-static struct device_attribute hid_dev_attrs[] = {
- __ATTR_RO(modalias),
- __ATTR_NULL,
+static struct attribute *hid_dev_attrs[] = {
+ _attr_modalias.attr,
+ NULL,
};
+ATTRIBUTE_GROUPS(hid_dev);
static int hid_uevent(struct device *dev, struct kobj_uevent_env *env)
{
@@ -1949,7 +1951,7 @@ static int hid_uevent(struct device *dev, struct
kobj_uevent_env *env)
static struct bus_type hid_bus_type = {
.name = "hid",
- .dev_attrs = hid_dev_attrs,
+ .dev_groups = hid_dev_groups,
.match = hid_bus_match,
.probe = hid_device_probe,
.remove = hid_device_remove,
--
1.8.3.rc0.20.gb99dd2e
--
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 09/15] PCI: convert bus code to use drv_groups
The drv_attrs field of struct bus_type is going away soon, drv_groups
should be used instead. This converts the PCI bus code to use the
correct field.
Cc: Bjorn Helgaas
Signed-off-by: Greg Kroah-Hartman
---
drivers/pci/pci-driver.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c
index 09db761e..a9c53f03 100644
--- a/drivers/pci/pci-driver.c
+++ b/drivers/pci/pci-driver.c
@@ -135,6 +135,7 @@ store_new_id(struct device_driver *driver, const char *buf,
size_t count)
return retval;
return count;
}
+static DRIVER_ATTR(new_id, S_IWUSR, NULL, store_new_id);
/**
* store_remove_id - remove a PCI device ID from this driver
@@ -180,12 +181,14 @@ store_remove_id(struct device_driver *driver, const char
*buf, size_t count)
return retval;
return count;
}
+static DRIVER_ATTR(remove_id, S_IWUSR, NULL, store_remove_id);
-static struct driver_attribute pci_drv_attrs[] = {
- __ATTR(new_id, S_IWUSR, NULL, store_new_id),
- __ATTR(remove_id, S_IWUSR, NULL, store_remove_id),
- __ATTR_NULL,
+static struct attribute *pci_drv_attrs[] = {
+ _attr_new_id.attr,
+ _attr_remove_id.attr,
+ NULL,
};
+ATTRIBUTE_GROUPS(pci_drv);
/**
* pci_match_id - See if a pci device matches a given pci_id table
@@ -1275,7 +1278,7 @@ struct bus_type pci_bus_type = {
.shutdown = pci_device_shutdown,
.dev_attrs = pci_dev_attrs,
.bus_groups = pci_bus_groups,
- .drv_attrs = pci_drv_attrs,
+ .drv_groups = pci_drv_groups,
.pm = PCI_PM_OPS_PTR,
};
--
1.8.3.rc0.20.gb99dd2e
--
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 10/15] USB: serial: convert bus code to use drv_groups
The drv_attrs field of struct bus_type is going away soon, drv_groups
should be used instead. This converts the USB serial bus code to use
the correct field.
Signed-off-by: Greg Kroah-Hartman
---
drivers/usb/serial/bus.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/serial/bus.c b/drivers/usb/serial/bus.c
index f053b302..24624339 100644
--- a/drivers/usb/serial/bus.c
+++ b/drivers/usb/serial/bus.c
@@ -122,7 +122,7 @@ static int usb_serial_device_remove(struct device *dev)
return retval;
}
-static ssize_t store_new_id(struct device_driver *driver,
+static ssize_t new_id_store(struct device_driver *driver,
const char *buf, size_t count)
{
struct usb_serial_driver *usb_drv = to_usb_serial_driver(driver);
@@ -135,17 +135,19 @@ static ssize_t store_new_id(struct device_driver *driver,
return retval;
}
-static ssize_t show_dynids(struct device_driver *driver, char *buf)
+static ssize_t new_id_show(struct device_driver *driver, char *buf)
{
struct usb_serial_driver *usb_drv = to_usb_serial_driver(driver);
return usb_show_dynids(_drv->dynids, buf);
}
+static DRIVER_ATTR_RW(new_id);
-static struct driver_attribute drv_attrs[] = {
- __ATTR(new_id, S_IRUGO | S_IWUSR, show_dynids, store_new_id),
- __ATTR_NULL,
+static struct attribute *usb_serial_drv_attrs[] = {
+ _attr_new_id.attr,
+ NULL,
};
+ATTRIBUTE_GROUPS(usb_serial_drv);
static void free_dynids(struct usb_serial_driver *drv)
{
@@ -164,7 +166,7 @@ struct bus_type usb_serial_bus_type = {
.match =usb_serial_device_match,
.probe =usb_serial_device_probe,
.remove = usb_serial_device_remove,
- .drv_attrs =drv_attrs,
+ .drv_groups = usb_serial_drv_groups,
};
int usb_serial_bus_register(struct usb_serial_driver *driver)
--
1.8.3.rc0.20.gb99dd2e
--
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 14/15] pmu_bus: convert bus code to use dev_groups
The dev_attrs field of struct bus_type is going away soon, dev_groups
should be used instead. This converts the pmu bus code to use
the correct field.
Cc: Peter Zijlstra
Cc: Paul Mackerras
Cc: Ingo Molnar
Cc: Arnaldo Carvalho de Melo
Signed-off-by: Greg Kroah-Hartman
---
kernel/events/core.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/kernel/events/core.c b/kernel/events/core.c
index f86599e8..0417ccae 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -6189,6 +6189,7 @@ type_show(struct device *dev, struct device_attribute
*attr, char *page)
return snprintf(page, PAGE_SIZE-1, "%d\n", pmu->type);
}
+static DEVICE_ATTR_RO(type);
static ssize_t
perf_event_mux_interval_ms_show(struct device *dev,
@@ -6233,17 +6234,19 @@ perf_event_mux_interval_ms_store(struct device *dev,
return count;
}
+static DEVICE_ATTR_RW(perf_event_mux_interval_ms);
-static struct device_attribute pmu_dev_attrs[] = {
- __ATTR_RO(type),
- __ATTR_RW(perf_event_mux_interval_ms),
- __ATTR_NULL,
+static struct attribute *pmu_dev_attrs[] = {
+ _attr_type.attr,
+ _attr_perf_event_mux_interval_ms.attr,
+ NULL,
};
+ATTRIBUTE_GROUPS(pmu_dev);
static int pmu_bus_running;
static struct bus_type pmu_bus = {
.name = "event_source",
- .dev_attrs = pmu_dev_attrs,
+ .dev_groups = pmu_dev_groups,
};
static void pmu_dev_release(struct device *dev)
--
1.8.3.rc0.20.gb99dd2e
--
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 13/15] MEI: convert bus code to use dev_groups
The dev_attrs field of struct bus_type is going away soon, dev_groups
should be used instead. This converts the MEI bus code to use
the correct field.
Cc: Tomas Winkler
Signed-off-by: Greg Kroah-Hartman
---
drivers/misc/mei/bus.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/misc/mei/bus.c b/drivers/misc/mei/bus.c
index 9ecd49a7..2ce92a6a 100644
--- a/drivers/misc/mei/bus.c
+++ b/drivers/misc/mei/bus.c
@@ -108,11 +108,13 @@ static ssize_t modalias_show(struct device *dev, struct
device_attribute *a,
return (len >= PAGE_SIZE) ? (PAGE_SIZE - 1) : len;
}
+static DEVICE_ATTR_RO(modalias);
-static struct device_attribute mei_cl_dev_attrs[] = {
- __ATTR_RO(modalias),
- __ATTR_NULL,
+static struct attribute *mei_cl_dev_attrs[] = {
+ _attr_modalias.attr,
+ NULL,
};
+ATTRIBUTE_GROUPS(mei_cl_dev);
static int mei_cl_uevent(struct device *dev, struct kobj_uevent_env *env)
{
@@ -124,7 +126,7 @@ static int mei_cl_uevent(struct device *dev, struct
kobj_uevent_env *env)
static struct bus_type mei_cl_bus_type = {
.name = "mei",
- .dev_attrs = mei_cl_dev_attrs,
+ .dev_groups = mei_cl_dev_groups,
.match = mei_cl_device_match,
.probe = mei_cl_device_probe,
.remove = mei_cl_device_remove,
--
1.8.3.rc0.20.gb99dd2e
--
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 06/15] SCSI: fcoe: convert bus code to use bus_groups
The bus_attrs field of struct bus_type is going away soon, dev_groups
should be used instead. This converts the fcoe bus code to use the
correct field.
Cc: Robert Love
Cc: "James E.J. Bottomley"
Signed-off-by: Greg Kroah-Hartman
---
drivers/scsi/fcoe/fcoe_sysfs.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/scsi/fcoe/fcoe_sysfs.c b/drivers/scsi/fcoe/fcoe_sysfs.c
index c9382d6e..8189b96e 100644
--- a/drivers/scsi/fcoe/fcoe_sysfs.c
+++ b/drivers/scsi/fcoe/fcoe_sysfs.c
@@ -553,16 +553,20 @@ static struct device_type fcoe_fcf_device_type = {
.release = fcoe_fcf_device_release,
};
-static struct bus_attribute fcoe_bus_attr_group[] = {
- __ATTR(ctlr_create, S_IWUSR, NULL, fcoe_ctlr_create_store),
- __ATTR(ctlr_destroy, S_IWUSR, NULL, fcoe_ctlr_destroy_store),
- __ATTR_NULL
+static BUS_ATTR(ctlr_create, S_IWUSR, NULL, fcoe_ctlr_create_store);
+static BUS_ATTR(ctlr_destroy, S_IWUSR, NULL, fcoe_ctlr_destroy_store);
+
+static struct attribute *fcoe_bus_attrs[] = {
+ _attr_ctlr_create.attr,
+ _attr_ctrl_destroy.attr,
+ NULL,
};
+ATTRIBUTE_GROUPS(fcoe_bus);
static struct bus_type fcoe_bus_type = {
.name = "fcoe",
.match = _bus_match,
- .bus_attrs = fcoe_bus_attr_group,
+ .bus_groups = fcoe_bus_groups,
};
/**
--
1.8.3.rc0.20.gb99dd2e
--
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] LMK: Optimize lowmem_shrink
On (08/23/13 09:48), Greg KH wrote: > Subject: Re: [PATCH] LMK: Optimize lowmem_shrink > User-Agent: Mutt/1.5.21 (2010-09-15) > > On Wed, Aug 21, 2013 at 09:41:05AM +0800, Leon Ma wrote: > > From: Leon Ma > > Date: Mon, 19 Aug 2013 14:22:38 +0800 > > Subject: [PATCH] LMK: Optimize lowmem_shrink. > > Why is all of this in the patch body? > > And what does "LMK:" stand for? > > > By comparing with selected_oom_score_adj instead of min_score_adj, > > we may do less calculation. > > What does this change? Does it fix a problem? Hello, linux-next since c95dd63d4cc3647643ff502d70c4c1b52947c770 Author: Dave Chinner Date: Fri Aug 16 09:39:54 2013 +1000 drivers: convert shrinkers to new count/scan API does not contain lowmem_shrink(), but lowmem_scan() instead. plus at lest one more patch on top of it (e2bfaf75e763396b7baa7c1effa4053d7f19e6d3): [..] -static int lowmem_shrink(struct shrinker *s, struct shrink_control *sc) +static long lowmem_scan(struct shrinker *s, struct shrink_control *sc) [..] wouldn't it be better to have the patch against -next in this case (in case it fixes anything)? thanks, -ss > thanks, > > greg k-h > ___ > devel mailing list > de...@linuxdriverproject.org > http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel > -- 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: [Intel-gfx] [PATCH] i915: Update VGA arbiter support for newer devices
On Fri, 2013-08-23 at 21:21 +0300, Ville Syrjälä wrote: > On Tue, Aug 20, 2013 at 10:46:45PM +0300, Ville Syrjälä wrote: > > On Fri, Aug 16, 2013 at 12:22:14PM -0600, Alex Williamson wrote: > > > On Fri, 2013-08-16 at 13:20 +0300, Ville Syrjälä wrote: > > > > On Thu, Aug 15, 2013 at 04:54:15PM -0600, Alex Williamson wrote: > > > > > On Fri, 2013-08-16 at 08:49 +1000, Dave Airlie wrote: > > > > > > On Fri, Aug 16, 2013 at 8:43 AM, Alex Williamson > > > > > > wrote: > > > > > > > This is intended to add VGA arbiter support for Intel HD graphics > > > > > > > on > > > > > > > Core processors. The old GMCH registers no longer exist, so even > > > > > > > though it appears that i915 participates in VGA arbitration, it > > > > > > > doesn't > > > > > > > work. On Intel HD graphics we already attempt to disable VGA > > > > > > > regions > > > > > > > of the device. This makes registering as a VGA client > > > > > > > unnecessary since > > > > > > > we don't intend to operate differently depending on how many VGA > > > > > > > devices > > > > > > > are present. We can disable VGA memory regions by clearing a > > > > > > > memory > > > > > > > enable bit in the VGA MSR. That only leaves VGA IO, which we > > > > > > > update > > > > > > > the VGA arbiter to know that we don't participate in VGA memory > > > > > > > arbitration. We also add a hook on unload to re-enable memory and > > > > > > > reinstate VGA memory arbitration. > > > > > > > > > > > > I would think there is still a VGA disable bit on the Intel device > > > > > > somewhere, we'd just need > > > > > > Intel to look in the docs and find it. A bit that can nuke both i/o > > > > > > and cmd regs. > > > > > > > > > > The only bit available is in the GGC and is a keyed/locked register > > > > > that > > > > > not only disables VGA memory and I/O, but also modifies the class code > > > > > of the device. Early Core processors didn't lock this, but it's > > > > > untouchable in newer ones AFAICT. Thanks, > > > > > > > > I've not found anything else in the docs. And also we _need_ VGA I/O > > > > access to make i915_disable_vga() work. It's not 100% clear whether > > > > we really need to poke at the sequencer register in modern hardware, > > > > but the docs do still list it as a mandatory step. So even if we were > > > > to have a global "disable VGA I/O and mem bit" we'd need to make sure > > > > we already disabled VGA eg. after resume when the BIOS had a chance to > > > > turn the VGA display back on. I think there were also some BIOSen that > > > > turned VGA display back on when closing/opening the laptop lid. Not > > > > sure what would even happen with those if totally disabled VGA I/O > > > > access. I'm not sure they actually frob with the VGA regs though. > > > > Could be they just turn on the VGA display bit in the VGA_CONTROL > > > > register. > > > > > > Hmm, it appears the MSR write isn't fully disabling VGA memory space. > > > When the VBIOS for the PEG graphics is run in the guest, I get some > > > corruption of the IGD frame buffer. If I manually disable PCI memory in > > > the command register, this doesn't happen. I also get some strange > > > artifacts on the PEG display that don't happen when PCI memory is > > > disabled. Should that MSR bit give us the whole a_-b_ range? > > > > Perhaps. It does that on some old graphics cards I've played with, but > > frankly I have no idea what it does on our hardware. > > > > I'm trying to find out though. If and when I get an answer I'll let you > > know. > > So the answer I basically got is that MSR is the only option here when > the GMCH register can't be used. Supposedly it should work too, but > I felt that I didn't get a 100% definite answer on that subject. I can imagine that the GMCH could be modified if we knew where the bit was that's locking it. I can't find that in the spec though and I assume that's intentional. > I tried it a bit on an IVB machine and PCI and PCIe Matrox G550 cards, > and for me it does seem to work. In the G550 PCIe case there's an extra > PCIe-PCI bridge on the card, and and in the G550 PCI case there's a > PCI-PCI bridge on the card and a PCIe-PCI bridge on the motherboard. > I don't have any native PCIe graphics cards on me to test the no > extra bridges case. > > Based on a bit of manual register/memory banging it looks like the IGD > will decode the access when MSR[1]=1, and won't when MSR[1]=0. Same was > true for PCI_COMMAND[0] in case of VGA I/O. If those bits are disabled > for IGD, the accesses get to the external card. If neither claims it, > I just get 0xff back and writes are ignored. > > Curiously I didn't see any problems when I configured both graphics > devices and bridges to decode/forward VGA resources. The IGD was > always the one to answer and the data didn't seem corrupted. Not sure > why that is. Maybe I just got lucky or something. > > My tests weren't very thorough however, so I may have missed
