Re: [RFC 07/24] x86/thinkpad_acpi: Use arch_nvram_ops methods instead of nvram_read_byte() and nvram_write_byte()
On Sun, 31 May 2015, Finn Thain wrote: On Sun, 31 May 2015, Henrique de Moraes Holschuh wrote: On Sun, 31 May 2015, Finn Thain wrote: Make use of arch_nvram_ops in the thinkpad_acpi driver so that the nvram_* function exports can be removed. This patch series was tested on a ThinkPad T43. Can you describe how you did the testing? A specific procedure is required to test the hotkey NVRAM polling codepaths (which will read several NVRAM bytes @10Hz by default) in a T43... Signed-off-by: Finn Thain fth...@telegraphics.com.au The patch looks correct, so I don't expect any problems. Provided that your test procedure did enable hotkey NVRAM polling in the T43 and your hotkeys all still worked fine, you have my Acked-by. The procedure I used was this, 1. $ xev 2. # rmmod thinkpad_acpi 3. Press Access IBM key and confirm that xev does not report any events. 4. # modprobe thinkpad_acpi 5. Press Access IBM key and confirm that xev now reports the key press events. Is this sufficient? No. Please try: modprobe thinkpad_acpi echo 0xfb88c0 /sys/devices/platform/thinkpad_acpi/hotkey_source_mask test the hotkeys. Please test several of them, as not all of them are available through NVRAM polling... at least Fn+SPACE, Fn+F1..FN+F12 Please test the brightness keys. In the T43 we use direct EC mode, which depends on the NVRAM to sync with the SMBIOS firmware. to reset the driver to normal mode, it is enough to do this: echo 0 /sys/devices/platform/thinkpad_acpi/hotkey_source_mask -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 06/11] powerpc: don't use module_init for non-modular core hugetlb code
The hugetlbpage.o is obj-y (always built in). It will never
be modular, so using module_init as an alias for __initcall is
somewhat misleading.
Fix this up now, so that we can relocate module_init from
init.h into module.h in the future. If we don't do this, we'd
have to add module.h to obviously non-modular code, and that
would be a worse thing.
Note that direct use of __initcall is discouraged, vs. one
of the priority categorized subgroups. As __initcall gets
mapped onto device_initcall, our use of arch_initcall (which
makes sense for arch code) will thus change this registration
from level 6-device to level 3-arch (i.e. slightly earlier).
However no observable impact of that small difference has
been observed during testing, or is expected.
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Cc: Paul Mackerras pau...@samba.org
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Paul Gortmaker paul.gortma...@windriver.com
---
arch/powerpc/mm/hugetlbpage.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/mm/hugetlbpage.c b/arch/powerpc/mm/hugetlbpage.c
index 3385e3d0506e..f1e00ac9283c 100644
--- a/arch/powerpc/mm/hugetlbpage.c
+++ b/arch/powerpc/mm/hugetlbpage.c
@@ -933,7 +933,7 @@ static int __init hugetlbpage_init(void)
return 0;
}
#endif
-module_init(hugetlbpage_init);
+arch_initcall(hugetlbpage_init);
void flush_dcache_icache_hugepage(struct page *page)
{
--
2.2.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 05/11] powerpc: use subsys_initcall for Freescale Local Bus
The FSL_SOC option is bool, and hence this code is either
present or absent. It will never be modular, so using
module_init as an alias for __initcall is rather misleading.
Fix this up now, so that we can relocate module_init from
init.h into module.h in the future. If we don't do this, we'd
have to add module.h to obviously non-modular code, and that
would be a worse thing.
Note that direct use of __initcall is discouraged, vs. one
of the priority categorized subgroups. As __initcall gets
mapped onto device_initcall, our use of subsys_initcall (which
makes sense for bus code) will thus change this registration
from level 6-device to level 4-subsys (i.e. slightly earlier).
However no observable impact of that small difference has
been observed during testing, or is expected.
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Cc: Paul Mackerras pau...@samba.org
Cc: Scott Wood scottw...@freescale.com
Acked-by: Scott Wood scottw...@freescale.com
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Paul Gortmaker paul.gortma...@windriver.com
---
arch/powerpc/sysdev/fsl_lbc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/sysdev/fsl_lbc.c b/arch/powerpc/sysdev/fsl_lbc.c
index d631022ffb4b..38138cf8d33e 100644
--- a/arch/powerpc/sysdev/fsl_lbc.c
+++ b/arch/powerpc/sysdev/fsl_lbc.c
@@ -407,4 +407,4 @@ static int __init fsl_lbc_init(void)
{
return platform_driver_register(fsl_lbc_ctrl_driver);
}
-module_init(fsl_lbc_init);
+subsys_initcall(fsl_lbc_init);
--
2.2.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH kernel v11 02/34] powerpc/iommu/powernv: Get rid of set_iommu_table_base_and_group
On Fri, May 29, 2015 at 06:44:26PM +1000, Alexey Kardashevskiy wrote: The set_iommu_table_base_and_group() name suggests that the function sets table base and add a device to an IOMMU group. The actual purpose for table base setting is to put some reference into a device so later iommu_add_device() can get the IOMMU group reference and the device to the group. At the moment a group cannot be explicitly passed to iommu_add_device() as we want it to work from the bus notifier, we can fix it later and remove confusing calls of set_iommu_table_base(). This replaces set_iommu_table_base_and_group() with a couple of set_iommu_table_base() + iommu_add_device() which makes reading the code easier. This adds few comments why set_iommu_table_base() and iommu_add_device() are called where they are called. For IODA1/2, this essentially removes iommu_add_device() call from the pnv_pci_ioda_dma_dev_setup() as it will always fail at this particular place: - for physical PE, the device is already attached by iommu_add_device() in pnv_pci_ioda_setup_dma_pe(); - for virtual PE, the sysfs entries are not ready to create all symlinks so actual adding is happening in tce_iommu_bus_notifier. Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru Reviewed-by: Gavin Shan gws...@linux.vnet.ibm.com Reviewed-by: David Gibson da...@gibson.dropbear.id.au -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson pgps9RGRWA3C4.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH kernel v11 01/34] powerpc/eeh/ioda2: Use device::iommu_group to check IOMMU group
On Fri, May 29, 2015 at 06:44:25PM +1000, Alexey Kardashevskiy wrote: This relies on the fact that a PCI device always has an IOMMU table which may not be the case when we get dynamic DMA windows so let's use more reliable check for IOMMU group here. As we do not rely on the table presence here, remove the workaround from pnv_pci_ioda2_set_bypass(); also remove the @add_to_iommu_group parameter from pnv_ioda_setup_bus_dma(). Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru Acked-by: Gavin Shan gws...@linux.vnet.ibm.com Reviewed-by: David Gibson da...@gibson.dropbear.id.au -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson pgpcuTwqUQt_T.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 00/11] Replace module_init with an alternate initcall in non modules
This series of commits converts non-modular code that is using the module_init() call to hook itself into the system to instead use one of the alternate priority initcalls. Unlike the earlier series[1] that used device_initcall and hence was a runtime no-op, these commits change to one of the alternate initcalls, because (a) we have them and (b) it seems like the right thing to do. For example, it would seem logical to use arch_initcall for arch specific setup code and fs_initcall for filesystem setup code. This does mean however, that changes in the init ordering will be taking place, and so there is a small risk that some kind of implicit init ordering issue may lie uncovered. But I think it is still better to give these ones sensible priorities than to just assign them all to device_initcall in order to exactly preserve the old ordering. Thad said, we have already made similar changes in core kernel code in commit c96d6660dc65b0a90aea9834bfd8be1d5656da18 (kernel: audit/fix non-modular users of module_init in core code) without any regressions reported, so this type of change isn't without precedent. This work is factored out from what was a previously larger series[2] so that there is a common theme and lower patch count to ease review. Paul. [1] https://lkml.org/lkml/2015/5/28/809 [2] https://marc.info/?l=linux-kernelm=139033951228828 --- Cc: Andrew Morton a...@linux-foundation.org Cc: Arnaldo Carvalho de Melo a...@kernel.org Cc: Benjamin Herrenschmidt b...@kernel.crashing.org Cc: David S. Miller da...@davemloft.net Cc: Eric Paris epa...@parisplace.org Cc: H. Peter Anvin h...@zytor.com Cc: Ingo Molnar mi...@redhat.com Cc: John McCutchan j...@johnmccutchan.com Cc: Jozsef Kadlecsik kad...@blackhole.kfki.hu Cc: Pablo Neira Ayuso pa...@netfilter.org Cc: Patrick McHardy ka...@trash.net Cc: Paul Mackerras pau...@samba.org Cc: Peter Zijlstra a.p.zijls...@chello.nl Cc: Robert Love rl...@rlove.org Cc: Russell King li...@arm.linux.org.uk Cc: Scott Wood scottw...@freescale.com Cc: Thomas Gleixner t...@linutronix.de Cc: linux-arm-ker...@lists.infradead.org Cc: linux...@kvack.org Cc: linuxppc-dev@lists.ozlabs.org Cc: net...@vger.kernel.org Cc: netfilter-de...@vger.kernel.org Cc: x...@kernel.org Paul Gortmaker (11): mm: replace module_init usages with subsys_initcall in nommu.c fs/notify: don't use module_init for non-modular inotify_user code netfilter: don't use module_init/exit in core IPV4 code x86: don't use module_init for non-modular core bootflag code powerpc: use subsys_initcall for Freescale Local Bus powerpc: don't use module_init for non-modular core hugetlb code arm: use subsys_initcall in non-modular pl320 IPC code lib/list_sort: use late_initcall to hook in self tests mm/page_owner.c: use late_initcall to hook in enabling x86: perf_event_intel_bts.c: use arch_initcall to hook in enabling x86: perf_event_intel_pt.c: use arch_initcall to hook in enabling arch/powerpc/mm/hugetlbpage.c | 2 +- arch/powerpc/sysdev/fsl_lbc.c | 2 +- arch/x86/kernel/bootflag.c | 2 +- arch/x86/kernel/cpu/perf_event_intel_bts.c | 3 +-- arch/x86/kernel/cpu/perf_event_intel_pt.c | 3 +-- drivers/mailbox/pl320-ipc.c| 2 +- fs/notify/inotify/inotify_user.c | 4 ++-- lib/list_sort.c| 2 +- mm/nommu.c | 4 ++-- mm/page_owner.c| 2 +- net/ipv4/netfilter.c | 9 + 11 files changed, 13 insertions(+), 22 deletions(-) -- 2.2.1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [alsa-devel] [RFC] sound: ppc: keywest: check if DEQ was already instantiated
On Fri, May 29, 2015 at 01:44:38PM +0200, Takashi Iwai wrote: At Fri, 29 May 2015 20:06:09 +0900, Wolfram Sang wrote: Do you think from which stable kernel version can this be applied? The offending commit is 3a3dd0186f619b74e61e6f29dddcaf59af7d3cac (i2c/powermac: Improve detection of devices from device-tree) which came in with v3.6 if I read correctly. OK, thanks! Just to make sure: Keep in mind that it depends on sound: ppc: keywest: drop using attach adapter which needs to go to stable, then, too. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V3] drivers/mtd: add powernv flash MTD abstraction driver
On Fri, 2015-05-29 at 14:52 +0530, Neelesh Gupta wrote:
[...]
+/**
+ * @mtd: the device
+ * @erase: the erase info
+ * Returns 0 if erase successful or -ERRNO if an error occurred
+ */
+static int powernv_flash_erase(struct mtd_info *mtd, struct erase_info
*erase)
+{
+ int rc;
+
+ erase-state = MTD_ERASING;
+
+ /* todo: register our own notifier to do a true async implementation */
+ rc = powernv_flash_async_op(mtd, FLASH_OP_ERASE, erase-addr,
+ erase-len, NULL, NULL);
+
+ if (rc) {
+ erase-fail_addr = erase-addr;
+ erase-state = MTD_ERASE_FAILED;
+ } else {
+ erase-state = MTD_ERASE_DONE;
+ }
+ mtd_erase_callback(erase);
return rc ? You also document the same ' or -ERRNO if an error
occurred'
Good catch, I'll amend.
+ return 0;
+}
+
+/**
+ * powernv_flash_set_driver_info - Fill the mtd_info structure and docg3
+ * structure @pdev: The platform device
+ * @mtd: The structure to fill
+ */
+static int powernv_flash_set_driver_info(struct device *dev,
+ struct mtd_info *mtd)
+{
+ u64 size;
+ u32 erase_size;
+ int rc;
+
+ rc = of_property_read_u32(dev-of_node, ibm,flash-block-size,
+ erase_size);
+ if (rc) {
+ dev_err(dev, couldn't get resource block size information\n);
+ return rc;
+ }
+
+ rc = of_property_read_u64(dev-of_node, reg, size);
+ if (rc) {
+ dev_err(dev, couldn't get resource size information\n);
+ return rc;
+ }
+
+ /*
+* Going to have to check what details I need to set and how to
+* get them
+*/
+ mtd-name = of_get_property(dev-of_node, name, NULL);
+ mtd-type = MTD_NORFLASH;
+ mtd-flags = MTD_WRITEABLE;
+ mtd-size = size;
+ mtd-erasesize = erase_size;
+ mtd-writebufsize = mtd-writesize = 1;
+ mtd-owner = THIS_MODULE;
+ mtd-_erase = powernv_flash_erase;
+ mtd-_read = powernv_flash_read;
+ mtd-_write = powernv_flash_write;
+ mtd-dev.parent = dev;
+ return 0;
+}
+
+/**
+ * powernv_flash_probe
+ * @pdev: platform device
+ *
+ * Returns 0 on success, -ENOMEM, -ENXIO on error
+ */
+static int powernv_flash_probe(struct platform_device *pdev)
+{
+ struct device *dev = pdev-dev;
+ struct powernv_flash *data;
+ int ret;
+
+ data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
+ if (!data) {
+ ret = -ENOMEM;
+ goto out;
+ }
+ data-mtd.priv = data;
'mtd' is contained within the 'data' so you can cast 'mtd' to get the
'data'
anywhere you want using container_of() macro.. 'priv' can be used to
pass
an unrelated structure just a thought, you may ignore it.. :)
Yeah, I think I couldn't agree with myself when I wrote and I figured
there might be something I'd want to use priv for. There never was, that
stayed. I realised it got quite circular and there are now many ways of
getting back to data, I can't see any harm in leaving it like that,
except the strangeness of it.
Thanks,
Cyril
Rest looks ok.
Neelesh.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH V3] drivers/mtd: add powernv flash MTD abstraction driver
Powerpc powernv platforms allow access to certain system flash devices
through a firmwarwe interface. This change adds an mtd driver for these
flash devices.
Minor updates from Jeremy Kerr and Joel Stanley.
Signed-off-by: Cyril Bur cyril...@gmail.com
Signed-off-by: Joel Stanley j...@jms.id.au
Signed-off-by: Jeremy Kerr j...@ozlabs.org
---
V2: Address Brian Norris' review
Fix typos
Change from NAND flash type to NOR flash type
Correctness tweaks
V3: Address Neelesh Gupta's review
Minor corrections
Release the opal token on error
Unregister mtd device on module remove
---
drivers/mtd/devices/Kconfig | 8 +
drivers/mtd/devices/Makefile| 1 +
drivers/mtd/devices/powernv_flash.c | 286
3 files changed, 295 insertions(+)
create mode 100644 drivers/mtd/devices/powernv_flash.c
diff --git a/drivers/mtd/devices/Kconfig b/drivers/mtd/devices/Kconfig
index c49d0b1..f73c416 100644
--- a/drivers/mtd/devices/Kconfig
+++ b/drivers/mtd/devices/Kconfig
@@ -195,6 +195,14 @@ config MTD_BLOCK2MTD
Testing MTD users (eg JFFS2) on large media and media that might
be removed during a write (using the floppy drive).
+config MTD_POWERNV_FLASH
+ tristate powernv flash MTD driver
+ depends on PPC_POWERNV
+ help
+ This provides an MTD device to access flash on powernv OPAL
+ platforms from Linux. This device abstracts away the
+ firmware interface for flash access.
+
comment Disk-On-Chip Device Drivers
config MTD_DOCG3
diff --git a/drivers/mtd/devices/Makefile b/drivers/mtd/devices/Makefile
index f0b0e61..7912d3a 100644
--- a/drivers/mtd/devices/Makefile
+++ b/drivers/mtd/devices/Makefile
@@ -16,6 +16,7 @@ obj-$(CONFIG_MTD_SPEAR_SMI) += spear_smi.o
obj-$(CONFIG_MTD_SST25L) += sst25l.o
obj-$(CONFIG_MTD_BCM47XXSFLASH)+= bcm47xxsflash.o
obj-$(CONFIG_MTD_ST_SPI_FSM)+= st_spi_fsm.o
+obj-$(CONFIG_MTD_POWERNV_FLASH)+= powernv_flash.o
CFLAGS_docg3.o += -I$(src)
diff --git a/drivers/mtd/devices/powernv_flash.c
b/drivers/mtd/devices/powernv_flash.c
new file mode 100644
index 000..777e09f
--- /dev/null
+++ b/drivers/mtd/devices/powernv_flash.c
@@ -0,0 +1,286 @@
+/*
+ * OPAL PNOR flash MTD abstraction
+ *
+ * IBM 2015
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/errno.h
+#include linux/of.h
+#include linux/of_address.h
+#include linux/platform_device.h
+#include linux/string.h
+#include linux/slab.h
+#include linux/mtd/mtd.h
+#include linux/mtd/partitions.h
+
+#include linux/debugfs.h
+#include linux/seq_file.h
+
+#include asm/opal.h
+
+
+/*
+ * This driver creates the a Linux MTD abstraction for platform PNOR flash
+ * backed by OPAL calls
+ */
+
+struct powernv_flash {
+ struct mtd_info mtd;
+ u32 id;
+};
+
+enum flash_op {
+ FLASH_OP_READ,
+ FLASH_OP_WRITE,
+ FLASH_OP_ERASE,
+};
+
+static int powernv_flash_async_op(struct mtd_info *mtd, enum flash_op op,
+ loff_t offset, size_t len, size_t *retlen, u_char *buf)
+{
+ struct powernv_flash *info = (struct powernv_flash *)mtd-priv;
+ struct device *dev = mtd-dev;
+ int token;
+ struct opal_msg msg;
+ int rc;
+
+ dev_dbg(dev, %s(op=%d, offset=0x%llx, len=%zu)\n,
+ __func__, op, offset, len);
+
+ token = opal_async_get_token_interruptible();
+ if (token 0) {
+ if (token != -ERESTARTSYS)
+ dev_err(dev, Failed to get an async token\n);
+
+ return token;
+ }
+
+ switch (op) {
+ case FLASH_OP_READ:
+ rc = opal_flash_read(info-id, offset, __pa(buf), len, token);
+ break;
+ case FLASH_OP_WRITE:
+ rc = opal_flash_write(info-id, offset, __pa(buf), len, token);
+ break;
+ case FLASH_OP_ERASE:
+ rc = opal_flash_erase(info-id, offset, len, token);
+ break;
+ default:
+ BUG_ON(1);
+ }
+
+ if (rc != OPAL_ASYNC_COMPLETION) {
+ dev_err(dev, opal_flash_async_op(op=%d) failed (rc %d)\n,
+ op, rc);
+ opal_async_release_token(token);
+ return -EIO;
+ }
+
+ rc = opal_async_wait_response(token, msg);
+ opal_async_release_token(token);
+ if (rc) {
+ dev_err(dev,
RE: [v4] QE: Move QE from arch/powerpc to drivers/soc
On Fri, Jan 30, 2015 at 1:22PM +0800, Wood Scott wrote: -Original Message- From: Wood Scott-B07421 Sent: Friday, January 30, 2015 1:22 PM To: Zhao Qiang-B45475 Cc: linux-ker...@vger.kernel.org; net...@vger.kernel.org; linuxppc- d...@lists.ozlabs.org; Wood Scott-B07421; Xie Xiaobo-R63061 Subject: Re: [v4] QE: Move QE from arch/powerpc to drivers/soc On Wed, Nov 12, 2014 at 11:40:13AM +0800, Zhao Qiang wrote: ls1 has qe and ls1 has arm cpu. move qe from arch/powerpc to drivers/soc/fsl to adapt to powerpc and arm Signed-off-by: Zhao Qiang b45...@freescale.com --- Changes for v2: - move code to driver/soc Changes for v3: - change drivers/soc/qe to drivers/soc/fsl-qe Changes for v4: - move drivers/soc/fsl-qe to drivers/soc/fsl/qe - move head files for qe from include/linux/fsl to include/soc/fsl - move qe_ic.c to drivers/irqchip/ Need MAINTAINERS update for drivers/soc/fsl/qe, as previously discussed. You mean, I need to finish the following work before move qe to public directory? 1. gpio.c - needs to be converted to GPIO framework and placed in drivers/gpio 2. qe_ic* should probably move into drivers/irqchip 3. qe_io.c should be converted over to pinmux and put in drivers/pinctrl 4. Some of the clock could should be looked to be converted to use the clk framework -Scott Best Regards Zhao Qiang ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH v3] powerpc/defconfig: new way of writing defconfig
-Original Message- From: Wood Scott-B07421 Sent: Wednesday, May 13, 2015 5:18 PM To: Pan Lijun-B44306 Cc: linuxppc-...@ozlabs.org Subject: Re: [PATCH v3] powerpc/defconfig: new way of writing defconfig On Mon, 2015-05-11 at 23:39 -0500, Lijun Pan wrote: It is always a headache dealing with different defconfigs though they only differ in a few places. Hence we are proposing a new way of writing the defconfig: 1. Define a basic defconfig say mpc85xx_basic_defconfig 2. Spin off as much features as possible from the current mpc85xx_defconfig and create a separate config file, say, smp.config, kvm_500.config Every time we add a new feature, we don't need to change several defconfigs, we just add a new *.config And you could merge any fragments you want into .config with the current kconfig in Kernel. Say you want to build mpc85xx_smp_defconfig, you do 7 steps: make mpc85xx_basic_defconfig make 32bit.config make smp.config make cpu8.config make kvm_e500.config make uart2.config make i2c.config With the new rules added into arch/powerpc/Makefile, you can do it in one step: make mpc85xx_smp_defconfig We currently do it in one step. The 7 step version exists only in previous versions of this patch, and won't be in the git history, so such comments should go beneath the --- line. Sure, I will put them beneath --- line in the next patch. directory scottwood has my patch, directory scottwood does not have my patch You shouldn't be working off of my repository unless it has patches (that you need or that would conflict) that haven't yet been merged upstream. I am working off an old commit. See the result from $git log 17a0f33 powerpc/defconfig: new way of writing defconfig d41444d powerpc/corenet: enable CONFIG_I2C_MUX and CONFIG_I2C_MUX_PCA954x 7f9af0a powerpc/t2080qds: fix rtc interrupt 56302c5 powerpc/mpic: Remove WHOAMI readback after EOI [b44306@b44306-12 scottwood]$ ./scripts/diffconfig ../scottwood2/.config .config EPAPR_PARAVIRT n - y KVM_GUEST n - y PPC_QEMU_E500 n - y // these changes are expected since mpc85xx_smp_defconfig has enabled kvm_e500.config in freescale's internal git repo. What does our internal git repo have to do with anything? I will take off kvm_e500.config if upstream defconfig does have these. I will add kvm_e500.config later. diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile index fc502e0..7c80298 100644 --- a/arch/powerpc/Makefile +++ b/arch/powerpc/Makefile @@ -269,6 +269,52 @@ bootwrapper_install: %.dtb: scripts $(Q)$(MAKE) ARCH=ppc64 $(build)=$(boot) $(patsubst %,$(boot)/%,$@) +configfiles=$(wildcard $(srctree)/kernel/configs/$(1).config +$(srctree)/arch/$(SRCARCH)/configs/$(1).config) + +define mergeconfig +$(Q)$(CONFIG_SHELL) $(srctree)/scripts/kconfig/merge_config.sh -m -O +$(objtree)/arch/$(SRCARCH)/configs +$(objtree)/arch/$(SRCARCH)/configs/.config $(call configfiles,$(1)) +endef Why not invoke make with the whatever.config target instead? I first merge (no any make) all the config fragments into one, then make it. This is a way to make sure the .config after this patch the same as .config before this patch. + +mpc85xx_defconfig: + $(Q)cp $(srctree)/arch/$(SRCARCH)/configs/mpc85xx_basic_defconfig +$(srctree)/arch/$(SRCARCH)/configs/.config Don't modify $(srctree), ever. Why not just depend on the mpc85xx_basic_defconfig target? + $(call mergeconfig,32-bit) + $(call mergeconfig,uart6) + $(call mergeconfig,mpc85xx_misc) + $(Q)mv $(objtree)/arch/$(SRCARCH)/configs/.config $(objtree)/arch/$(SRCARCH)/configs/mpc85xx_tmp_defconfig + $(Q)$(MAKE) -f $(srctree)/Makefile mpc85xx_tmp_defconfig + +mpc85xx_smp_defconfig: + $(Q)cp $(srctree)/arch/$(SRCARCH)/configs/mpc85xx_basic_defconfig $(srctree)/arch/$(SRCARCH)/configs/.config + $(call mergeconfig,32-bit) + $(call mergeconfig,smp) + $(call mergeconfig,cpu8) + $(call mergeconfig,kvm_e500) + $(call mergeconfig,uart2) + $(call mergeconfig,i2c) + $(Q)mv $(objtree)/arch/$(SRCARCH)/configs/.config $(objtree)/arch/$(SRCARCH)/configs/mpc85xx_smp_tmp_defconfig + $(Q)$(MAKE) -f $(srctree)/Makefile mpc85xx_smp_tmp_defconfig There shouldn't be any difference besides SMP for mpc85xx_defconfig versus mpc85xx_smp_defconfig. I know someone previously asked you to ensure this didn't change the results, but I think this is a good opportunity to get rid of gratuitous differences, as long as you show what the diff is between old and new so we can verify that the changes are beneficial. There are quite a lot difference between mcp85xx_defconfig and mpc85xx_smp_config. Can you tell me which configs could be removed or neglected? +corenet32_smp_defconfig: + $(Q)cp $(srctree)/arch/$(SRCARCH)/configs/corenet_defconfig $(srctree)/arch/$(SRCARCH)/configs/.config + $(call mergeconfig,32-bit)
Re: [PATCH kernel v11 09/34] vfio: powerpc/spapr: Move locked_vm accounting to helpers
On Fri, May 29, 2015 at 06:44:33PM +1000, Alexey Kardashevskiy wrote:
There moves locked pages accounting to helpers.
Later they will be reused for Dynamic DMA windows (DDW).
This reworks debug messages to show the current value and the limit.
This stores the locked pages number in the container so when unlocking
the iommu table pointer won't be needed. This does not have an effect
now but it will with the multiple tables per container as then we will
allow attaching/detaching groups on fly and we may end up having
a container with no group attached but with the counter incremented.
While we are here, update the comment explaining why RLIMIT_MEMLOCK
might be required to be bigger than the guest RAM. This also prints
pid of the current process in pr_warn/pr_debug.
Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
[aw: for the vfio related changes]
Acked-by: Alex Williamson alex.william...@redhat.com
Reviewed-by: David Gibson da...@gibson.dropbear.id.au
Reviewed-by: Gavin Shan gws...@linux.vnet.ibm.com
---
Changes:
v4:
* new helpers do nothing if @npages == 0
* tce_iommu_disable() now can decrement the counter if the group was
detached (not possible now but will be in the future)
---
drivers/vfio/vfio_iommu_spapr_tce.c | 82
-
1 file changed, 63 insertions(+), 19 deletions(-)
diff --git a/drivers/vfio/vfio_iommu_spapr_tce.c
b/drivers/vfio/vfio_iommu_spapr_tce.c
index 64300cc..40583f9 100644
--- a/drivers/vfio/vfio_iommu_spapr_tce.c
+++ b/drivers/vfio/vfio_iommu_spapr_tce.c
@@ -29,6 +29,51 @@
static void tce_iommu_detach_group(void *iommu_data,
struct iommu_group *iommu_group);
+static long try_increment_locked_vm(long npages)
+{
+ long ret = 0, locked, lock_limit;
+
+ if (!current || !current-mm)
+ return -ESRCH; /* process exited */
+
+ if (!npages)
+ return 0;
+
+ down_write(current-mm-mmap_sem);
+ locked = current-mm-locked_vm + npages;
Is there a possibility of userspace triggering an integer overflow
here, if npages is really huge?
+ lock_limit = rlimit(RLIMIT_MEMLOCK) PAGE_SHIFT;
+ if (locked lock_limit !capable(CAP_IPC_LOCK))
+ ret = -ENOMEM;
+ else
+ current-mm-locked_vm += npages;
+
+ pr_debug([%d] RLIMIT_MEMLOCK +%ld %ld/%ld%s\n, current-pid,
+ npages PAGE_SHIFT,
+ current-mm-locked_vm PAGE_SHIFT,
+ rlimit(RLIMIT_MEMLOCK),
+ ret ? - exceeded : );
+
+ up_write(current-mm-mmap_sem);
+
+ return ret;
+}
+
+static void decrement_locked_vm(long npages)
+{
+ if (!current || !current-mm || !npages)
+ return; /* process exited */
+
+ down_write(current-mm-mmap_sem);
+ if (npages current-mm-locked_vm)
+ npages = current-mm-locked_vm;
Can this case ever occur (without there being a leak bug somewhere
else in the code)?
+ current-mm-locked_vm -= npages;
+ pr_debug([%d] RLIMIT_MEMLOCK -%ld %ld/%ld\n, current-pid,
+ npages PAGE_SHIFT,
+ current-mm-locked_vm PAGE_SHIFT,
+ rlimit(RLIMIT_MEMLOCK));
+ up_write(current-mm-mmap_sem);
+}
+
/*
* VFIO IOMMU fd for SPAPR_TCE IOMMU implementation
*
@@ -45,6 +90,7 @@ struct tce_container {
struct mutex lock;
struct iommu_table *tbl;
bool enabled;
+ unsigned long locked_pages;
};
static bool tce_page_is_contained(struct page *page, unsigned page_shift)
@@ -60,7 +106,7 @@ static bool tce_page_is_contained(struct page *page,
unsigned page_shift)
static int tce_iommu_enable(struct tce_container *container)
{
int ret = 0;
- unsigned long locked, lock_limit, npages;
+ unsigned long locked;
struct iommu_table *tbl = container-tbl;
if (!container-tbl)
@@ -89,21 +135,22 @@ static int tce_iommu_enable(struct tce_container
*container)
* Also we don't have a nice way to fail on H_PUT_TCE due to ulimits,
* that would effectively kill the guest at random points, much better
* enforcing the limit based on the max that the guest can map.
+ *
+ * Unfortunately at the moment it counts whole tables, no matter how
+ * much memory the guest has. I.e. for 4GB guest and 4 IOMMU groups
+ * each with 2GB DMA window, 8GB will be counted here. The reason for
+ * this is that we cannot tell here the amount of RAM used by the guest
+ * as this information is only available from KVM and VFIO is
+ * KVM agnostic.
*/
- down_write(current-mm-mmap_sem);
- npages = (tbl-it_size tbl-it_page_shift) PAGE_SHIFT;
- locked = current-mm-locked_vm + npages;
- lock_limit = rlimit(RLIMIT_MEMLOCK) PAGE_SHIFT;
- if (locked lock_limit !capable(CAP_IPC_LOCK)) {
- pr_warn(RLIMIT_MEMLOCK
Re: [PATCH kernel v11 16/34] powerpc/spapr: vfio: Replace iommu_table with iommu_table_group
On Fri, May 29, 2015 at 06:44:40PM +1000, Alexey Kardashevskiy wrote: Modern IBM POWERPC systems support multiple (currently two) TCE tables per IOMMU group (a.k.a. PE). This adds a iommu_table_group container for TCE tables. Right now just one table is supported. This defines iommu_table_group struct which stores pointers to iommu_group and iommu_table(s). This replaces iommu_table with iommu_table_group where iommu_table was used to identify a group: - iommu_register_group(); - iommudata of generic iommu_group; This removes @data from iommu_table as it_table_group provides same access to pnv_ioda_pe. For IODA, instead of embedding iommu_table, the new iommu_table_group keeps pointers to those. The iommu_table structs are allocated dynamically. For P5IOC2, both iommu_table_group and iommu_table are embedded into PE struct. As there is no EEH and SRIOV support for P5IOC2, iommu_free_table() should not be called on iommu_table struct pointers so we can keep it embedded in pnv_phb::p5ioc2. For pSeries, this replaces multiple calls of kzalloc_node() with a new iommu_pseries_alloc_group() helper and stores the table group struct pointer into the pci_dn struct. For release, a iommu_table_free_group() helper is added. This moves iommu_table struct allocation from SR-IOV code to the generic DMA initialization code in pnv_pci_ioda_setup_dma_pe and pnv_pci_ioda2_setup_dma_pe as this is where DMA is actually initialized. This change is here because those lines had to be changed anyway. This should cause no behavioural change. Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru [aw: for the vfio related changes] Acked-by: Alex Williamson alex.william...@redhat.com Reviewed-by: David Gibson da...@gibson.dropbear.id.au -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson pgpjn4d4h633a.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/4] perf: jevents: Program to convert JSON file to C style file
Ok I did some scripting to add these topics you requested to the Intel JSON files, and changed perf list to group events by them. I'll redirect any questions on their value to you. And I certainly hope this is the last of your improvements for now. The updated event lists are available in git://git.kernel.org/pub/scm/linux/kernel/git/ak/linux-misc perf/intel-json-files-3 The updated patches are available in git://git.kernel.org/pub/scm/linux/kernel/git/ak/linux-misc perf/builtin-json-6 Also posted separately. The output looks like this % perf list ... Cache: l1d.replacement [L1D data line replacements] l1d_pend_miss.pending [L1D miss oustandings duration in cycles] l1d_pend_miss.pending_cycles [Cycles with L1D load Misses outstanding] ... Floating point: fp_assist.any [Cycles with any input/output SSE or FP assist] fp_assist.simd_input [Number of SIMD FP assists due to input values] fp_assist.simd_output [Number of SIMD FP assists due to Output values] ... Memory: machine_clears.memory_ordering [Counts the number of machine clears due to memory order conflicts] mem_trans_retired.load_latency_gt_128 [Loads with latency value being above 128 (Must be precise)] mem_trans_retired.load_latency_gt_16 [Loads with latency value being above 16 (Must be precise)] ... Pipeline: arith.fpu_div [Divide operations executed] arith.fpu_div_active [Cycles when divider is busy executing divide operations] baclears.any [Counts the total number when the front end is resteered, mainly when the BPU cannot provide a correct prediction and this is corrected by other branch handling mechanisms at the front end] -Andi P.S.: You may want to look up the definition of logical fallacy in wikipedia. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH kernel v11 05/34] powerpc/iommu: Always release iommu_table in iommu_free_table()
On Fri, May 29, 2015 at 06:44:29PM +1000, Alexey Kardashevskiy wrote: At the moment iommu_free_table() only releases memory if the table was initialized for the platform code use, i.e. it had it_map initialized (which purpose is to track DMA memory space use). With dynamic DMA windows, we will need to be able to release iommu_table even if it was used for VFIO in which case it_map is NULL so does the patch. Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru Reviewed-by: David Gibson da...@gibson.dropbear.id.au -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson pgpgszxEk4Kau.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH kernel v11 03/34] powerpc/powernv/ioda: Clean up IOMMU group registration
On Fri, May 29, 2015 at 06:44:27PM +1000, Alexey Kardashevskiy wrote: The existing code has 3 calls to iommu_register_group() and all 3 branches actually cover all possible cases. This replaces 3 calls with one and moves the registration earlier; the latter will make more sense when we add TCE table sharing. Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru Reviewed-by: Gavin Shan gws...@linux.vnet.ibm.com Reviewed-by: David Gibson da...@gibson.dropbear.id.au -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson pgp9hDdd2aU0T.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH kernel v11 04/34] powerpc/iommu: Put IOMMU group explicitly
On Fri, May 29, 2015 at 06:44:28PM +1000, Alexey Kardashevskiy wrote: So far an iommu_table lifetime was the same as PE. Dynamic DMA windows will change this and iommu_free_table() will not always require the group to be released. This moves iommu_group_put() out of iommu_free_table(). This adds a iommu_pseries_free_table() helper which does iommu_group_put() and iommu_free_table(). Later it will be changed to receive a table_group and we will have to change less lines then. This should cause no behavioural change. Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru Reviewed-by: Gavin Shan gws...@linux.vnet.ibm.com Reviewed-by: David Gibson da...@gibson.dropbear.id.au -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson pgpCE8mxzSPwk.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC 07/24] x86/thinkpad_acpi: Use arch_nvram_ops methods instead of nvram_read_byte() and nvram_write_byte()
On Sun, 31 May 2015, Henrique de Moraes Holschuh wrote:
On Sun, 31 May 2015, Finn Thain wrote:
Make use of arch_nvram_ops in the thinkpad_acpi driver so that the
nvram_* function exports can be removed.
This patch series was tested on a ThinkPad T43.
Can you describe how you did the testing? A specific procedure is
required to test the hotkey NVRAM polling codepaths (which will read
several NVRAM bytes @10Hz by default) in a T43...
Signed-off-by: Finn Thain fth...@telegraphics.com.au
The patch looks correct, so I don't expect any problems.
Provided that your test procedure did enable hotkey NVRAM polling in the
T43 and your hotkeys all still worked fine, you have my Acked-by.
The procedure I used was this,
1. $ xev
2. # rmmod thinkpad_acpi
3. Press Access IBM key and confirm that xev does not report any
events.
4. # modprobe thinkpad_acpi
5. Press Access IBM key and confirm that xev now reports the key press
events.
Is this sufficient?
Regards,
Finn
---
drivers/platform/x86/thinkpad_acpi.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
Index: linux/drivers/platform/x86/thinkpad_acpi.c
===
--- linux.orig/drivers/platform/x86/thinkpad_acpi.c 2015-05-31
11:00:59.0 +1000
+++ linux/drivers/platform/x86/thinkpad_acpi.c 2015-05-31
11:01:07.0 +1000
@@ -2311,30 +2311,30 @@ static void hotkey_read_nvram(struct tp_
u8 d;
if (m TP_NVRAM_HKEY_GROUP_HK2) {
- d = nvram_read_byte(TP_NVRAM_ADDR_HK2);
+ d = arch_nvram_ops.read_byte(TP_NVRAM_ADDR_HK2);
n-thinkpad_toggle = !!(d TP_NVRAM_MASK_HKT_THINKPAD);
n-zoom_toggle = !!(d TP_NVRAM_MASK_HKT_ZOOM);
n-display_toggle = !!(d TP_NVRAM_MASK_HKT_DISPLAY);
n-hibernate_toggle = !!(d TP_NVRAM_MASK_HKT_HIBERNATE);
}
if (m TP_ACPI_HKEY_THNKLGHT_MASK) {
- d = nvram_read_byte(TP_NVRAM_ADDR_THINKLIGHT);
+ d = arch_nvram_ops.read_byte(TP_NVRAM_ADDR_THINKLIGHT);
n-thinklight_toggle = !!(d TP_NVRAM_MASK_THINKLIGHT);
}
if (m TP_ACPI_HKEY_DISPXPAND_MASK) {
- d = nvram_read_byte(TP_NVRAM_ADDR_VIDEO);
+ d = arch_nvram_ops.read_byte(TP_NVRAM_ADDR_VIDEO);
n-displayexp_toggle =
!!(d TP_NVRAM_MASK_HKT_DISPEXPND);
}
if (m TP_NVRAM_HKEY_GROUP_BRIGHTNESS) {
- d = nvram_read_byte(TP_NVRAM_ADDR_BRIGHTNESS);
+ d = arch_nvram_ops.read_byte(TP_NVRAM_ADDR_BRIGHTNESS);
n-brightness_level = (d TP_NVRAM_MASK_LEVEL_BRIGHTNESS)
TP_NVRAM_POS_LEVEL_BRIGHTNESS;
n-brightness_toggle =
!!(d TP_NVRAM_MASK_HKT_BRIGHTNESS);
}
if (m TP_NVRAM_HKEY_GROUP_VOLUME) {
- d = nvram_read_byte(TP_NVRAM_ADDR_MIXER);
+ d = arch_nvram_ops.read_byte(TP_NVRAM_ADDR_MIXER);
n-volume_level = (d TP_NVRAM_MASK_LEVEL_VOLUME)
TP_NVRAM_POS_LEVEL_VOLUME;
n-mute = !!(d TP_NVRAM_MASK_MUTE);
@@ -6153,7 +6153,7 @@ static unsigned int tpacpi_brightness_nv
{
u8 lnvram;
- lnvram = (nvram_read_byte(TP_NVRAM_ADDR_BRIGHTNESS)
+ lnvram = (arch_nvram_ops.read_byte(TP_NVRAM_ADDR_BRIGHTNESS)
TP_NVRAM_MASK_LEVEL_BRIGHTNESS)
TP_NVRAM_POS_LEVEL_BRIGHTNESS;
lnvram = bright_maxlvl;
@@ -6178,7 +6178,7 @@ static void tpacpi_brightness_checkpoint
if (unlikely(!acpi_ec_read(TP_EC_BACKLIGHT, lec)))
goto unlock;
lec = TP_EC_BACKLIGHT_LVLMSK;
- b_nvram = nvram_read_byte(TP_NVRAM_ADDR_BRIGHTNESS);
+ b_nvram = arch_nvram_ops.read_byte(TP_NVRAM_ADDR_BRIGHTNESS);
if (lec != ((b_nvram TP_NVRAM_MASK_LEVEL_BRIGHTNESS)
TP_NVRAM_POS_LEVEL_BRIGHTNESS)) {
@@ -6186,7 +6186,7 @@ static void tpacpi_brightness_checkpoint
b_nvram = ~(TP_NVRAM_MASK_LEVEL_BRIGHTNESS
TP_NVRAM_POS_LEVEL_BRIGHTNESS);
b_nvram |= lec;
- nvram_write_byte(b_nvram, TP_NVRAM_ADDR_BRIGHTNESS);
+ arch_nvram_ops.write_byte(b_nvram, TP_NVRAM_ADDR_BRIGHTNESS);
dbg_printk(TPACPI_DBG_BRGHT,
updated NVRAM backlight level to %u (0x%02x)\n,
(unsigned int) lec, (unsigned int) b_nvram);
@@ -6794,13 +6794,13 @@ static void tpacpi_volume_checkpoint_nvr
if (unlikely(!acpi_ec_read(TP_EC_AUDIO, lec)))
goto unlock;
lec = ec_mask;
- b_nvram = nvram_read_byte(TP_NVRAM_ADDR_MIXER);
+ b_nvram = arch_nvram_ops.read_byte(TP_NVRAM_ADDR_MIXER);
if (lec != (b_nvram ec_mask)) {
/* NVRAM needs update */
b_nvram = ~ec_mask;
b_nvram |=
Re: [RFC 07/24] x86/thinkpad_acpi: Use arch_nvram_ops methods instead of nvram_read_byte() and nvram_write_byte()
On Sun, 31 May 2015, Finn Thain wrote:
Make use of arch_nvram_ops in the thinkpad_acpi driver so that the
nvram_* function exports can be removed.
This patch series was tested on a ThinkPad T43.
Can you describe how you did the testing? A specific procedure is required
to test the hotkey NVRAM polling codepaths (which will read several NVRAM
bytes @10Hz by default) in a T43...
Signed-off-by: Finn Thain fth...@telegraphics.com.au
The patch looks correct, so I don't expect any problems.
Provided that your test procedure did enable hotkey NVRAM polling in the T43
and your hotkeys all still worked fine, you have my Acked-by.
---
drivers/platform/x86/thinkpad_acpi.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
Index: linux/drivers/platform/x86/thinkpad_acpi.c
===
--- linux.orig/drivers/platform/x86/thinkpad_acpi.c 2015-05-31
11:00:59.0 +1000
+++ linux/drivers/platform/x86/thinkpad_acpi.c2015-05-31
11:01:07.0 +1000
@@ -2311,30 +2311,30 @@ static void hotkey_read_nvram(struct tp_
u8 d;
if (m TP_NVRAM_HKEY_GROUP_HK2) {
- d = nvram_read_byte(TP_NVRAM_ADDR_HK2);
+ d = arch_nvram_ops.read_byte(TP_NVRAM_ADDR_HK2);
n-thinkpad_toggle = !!(d TP_NVRAM_MASK_HKT_THINKPAD);
n-zoom_toggle = !!(d TP_NVRAM_MASK_HKT_ZOOM);
n-display_toggle = !!(d TP_NVRAM_MASK_HKT_DISPLAY);
n-hibernate_toggle = !!(d TP_NVRAM_MASK_HKT_HIBERNATE);
}
if (m TP_ACPI_HKEY_THNKLGHT_MASK) {
- d = nvram_read_byte(TP_NVRAM_ADDR_THINKLIGHT);
+ d = arch_nvram_ops.read_byte(TP_NVRAM_ADDR_THINKLIGHT);
n-thinklight_toggle = !!(d TP_NVRAM_MASK_THINKLIGHT);
}
if (m TP_ACPI_HKEY_DISPXPAND_MASK) {
- d = nvram_read_byte(TP_NVRAM_ADDR_VIDEO);
+ d = arch_nvram_ops.read_byte(TP_NVRAM_ADDR_VIDEO);
n-displayexp_toggle =
!!(d TP_NVRAM_MASK_HKT_DISPEXPND);
}
if (m TP_NVRAM_HKEY_GROUP_BRIGHTNESS) {
- d = nvram_read_byte(TP_NVRAM_ADDR_BRIGHTNESS);
+ d = arch_nvram_ops.read_byte(TP_NVRAM_ADDR_BRIGHTNESS);
n-brightness_level = (d TP_NVRAM_MASK_LEVEL_BRIGHTNESS)
TP_NVRAM_POS_LEVEL_BRIGHTNESS;
n-brightness_toggle =
!!(d TP_NVRAM_MASK_HKT_BRIGHTNESS);
}
if (m TP_NVRAM_HKEY_GROUP_VOLUME) {
- d = nvram_read_byte(TP_NVRAM_ADDR_MIXER);
+ d = arch_nvram_ops.read_byte(TP_NVRAM_ADDR_MIXER);
n-volume_level = (d TP_NVRAM_MASK_LEVEL_VOLUME)
TP_NVRAM_POS_LEVEL_VOLUME;
n-mute = !!(d TP_NVRAM_MASK_MUTE);
@@ -6153,7 +6153,7 @@ static unsigned int tpacpi_brightness_nv
{
u8 lnvram;
- lnvram = (nvram_read_byte(TP_NVRAM_ADDR_BRIGHTNESS)
+ lnvram = (arch_nvram_ops.read_byte(TP_NVRAM_ADDR_BRIGHTNESS)
TP_NVRAM_MASK_LEVEL_BRIGHTNESS)
TP_NVRAM_POS_LEVEL_BRIGHTNESS;
lnvram = bright_maxlvl;
@@ -6178,7 +6178,7 @@ static void tpacpi_brightness_checkpoint
if (unlikely(!acpi_ec_read(TP_EC_BACKLIGHT, lec)))
goto unlock;
lec = TP_EC_BACKLIGHT_LVLMSK;
- b_nvram = nvram_read_byte(TP_NVRAM_ADDR_BRIGHTNESS);
+ b_nvram = arch_nvram_ops.read_byte(TP_NVRAM_ADDR_BRIGHTNESS);
if (lec != ((b_nvram TP_NVRAM_MASK_LEVEL_BRIGHTNESS)
TP_NVRAM_POS_LEVEL_BRIGHTNESS)) {
@@ -6186,7 +6186,7 @@ static void tpacpi_brightness_checkpoint
b_nvram = ~(TP_NVRAM_MASK_LEVEL_BRIGHTNESS
TP_NVRAM_POS_LEVEL_BRIGHTNESS);
b_nvram |= lec;
- nvram_write_byte(b_nvram, TP_NVRAM_ADDR_BRIGHTNESS);
+ arch_nvram_ops.write_byte(b_nvram, TP_NVRAM_ADDR_BRIGHTNESS);
dbg_printk(TPACPI_DBG_BRGHT,
updated NVRAM backlight level to %u (0x%02x)\n,
(unsigned int) lec, (unsigned int) b_nvram);
@@ -6794,13 +6794,13 @@ static void tpacpi_volume_checkpoint_nvr
if (unlikely(!acpi_ec_read(TP_EC_AUDIO, lec)))
goto unlock;
lec = ec_mask;
- b_nvram = nvram_read_byte(TP_NVRAM_ADDR_MIXER);
+ b_nvram = arch_nvram_ops.read_byte(TP_NVRAM_ADDR_MIXER);
if (lec != (b_nvram ec_mask)) {
/* NVRAM needs update */
b_nvram = ~ec_mask;
b_nvram |= lec;
- nvram_write_byte(b_nvram, TP_NVRAM_ADDR_MIXER);
+ arch_nvram_ops.write_byte(b_nvram, TP_NVRAM_ADDR_MIXER);
dbg_printk(TPACPI_DBG_MIXER,
updated NVRAM mixer status to 0x%02x (0x%02x)\n,
(unsigned int) lec, (unsigned int)
