Re: [PATCH 1/3] x86: Move msr accesses out of line
Still, I wondered, so I ran me a little test. Note that I used a serializing instruction (LOCK XCHG) because WRMSR is too. WRMSR has a lot of uops internally unlike LOCK XCHG, so I expect it will mostly overlap with what it does. I'll run some benchmarks on this today. Also we do quite a few RDMSRs, which are not necessarily serializing. I see a ~14 cycle difference between the inline and noinline version. If I substitute the LOCK XCHG with XADD, I get to 1,5 cycles in difference, so clearly there is some magic happening, but serializing instructions wreck it. Anybody can explain how such RSP deps get magiced away? On Intel Core (since Yonah), the CPU frontend has a special stack tracker that avoids these dependencies. See 2.3.2.5 in the optimization manual Also BTW just from tracing MSRs there is a lot of optimization potential. Will send some patches later. -Andi -- 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: [SUSPECT SPAM] Re: [PATCH] Add a quirk for the Dell XPS 13 (2015) when in PS/2 mode.
On 02/23/2015 06:01 PM, Pali Rohár wrote: On Tuesday 24 February 2015 00:31:52 Mario Limonciello wrote: For older dell models (some old inspirions and maybe also latitude) it was possible to use undocumented DELLDIAG interface (which enter into SMM mode and call some functions) to enable that RAW mode. Now when you are discussing with us, do you have some information or can you comment (if it is not secret) that DELLDIAG SMM interface? In linux kernel we have for it driver (provides info about temperature, fan speed, power management, hotkeys, ...), but it use undocumented interface (and sometimes it has problems): https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/char/i8k.c I don't have any more information I can share on this interface other than I wouldn't recommend to rely on it. It's generally not supposed to be used by the OS but only for diagnostic purposes from BIOS level diagnostic tools. Nothing new. It is that problem with repeating keys which is fixed by last version of BIOS. I saw one E6440 model with preinstalled Ubuntu 12.04.2 and distributed with A08 BIOS (which had that problem). And this was very very annoying! You could imagine it, you buy new Latitude (business class pro notebook), you started it and on preinstalled OS, keyboard is not usable. Updating to A10 fixed it. I'm sorry that this had actually made it out the door with a pre-installed machine, but I'm glad we were able to get it fixed in the field. In this forum thread people reported that repeating keys problem for more models: http://en.community.dell.com/support-forums/laptop/f/3518/t/19593360?pi239031352=19 Yes, there is a support agent in that thread relaying those models to the BIOS team. And it looks like (from what I'm reading) last version A10 of E6440 BIOS broke USB3.0 support. -- 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 2/2] hwrng: iproc-rng200 - Add Broadcom IPROC RNG driver
This adds a driver for random number generator present on Broadcom
IPROC devices.
Reviewed-by: Ray Jui r...@broadcom.com
Signed-off-by: Scott Branden sbran...@broadcom.com
---
drivers/char/hw_random/Kconfig| 13 ++
drivers/char/hw_random/Makefile | 1 +
drivers/char/hw_random/iproc-rng200.c | 239 ++
3 files changed, 253 insertions(+)
create mode 100644 drivers/char/hw_random/iproc-rng200.c
diff --git a/drivers/char/hw_random/Kconfig b/drivers/char/hw_random/Kconfig
index de57b38..f48cf11 100644
--- a/drivers/char/hw_random/Kconfig
+++ b/drivers/char/hw_random/Kconfig
@@ -101,6 +101,19 @@ config HW_RANDOM_BCM2835
If unsure, say Y.
+config HW_RANDOM_IPROC_RNG200
+ tristate Broadcom iProc RNG200 support
+ depends on ARCH_BCM_IPROC
+ default HW_RANDOM
+ ---help---
+ This driver provides kernel-side support for the RNG200
+ hardware found on the Broadcom iProc SoCs.
+
+ To compile this driver as a module, choose M here: the
+ module will be called iproc-rng200
+
+ If unsure, say Y.
+
config HW_RANDOM_GEODE
tristate AMD Geode HW Random Number Generator support
depends on X86_32 PCI
diff --git a/drivers/char/hw_random/Makefile b/drivers/char/hw_random/Makefile
index 0b4cd57..055bb01 100644
--- a/drivers/char/hw_random/Makefile
+++ b/drivers/char/hw_random/Makefile
@@ -28,5 +28,6 @@ obj-$(CONFIG_HW_RANDOM_POWERNV) += powernv-rng.o
obj-$(CONFIG_HW_RANDOM_EXYNOS) += exynos-rng.o
obj-$(CONFIG_HW_RANDOM_TPM) += tpm-rng.o
obj-$(CONFIG_HW_RANDOM_BCM2835) += bcm2835-rng.o
+obj-$(CONFIG_HW_RANDOM_IPROC_RNG200) += iproc-rng200.o
obj-$(CONFIG_HW_RANDOM_MSM) += msm-rng.o
obj-$(CONFIG_HW_RANDOM_XGENE) += xgene-rng.o
diff --git a/drivers/char/hw_random/iproc-rng200.c
b/drivers/char/hw_random/iproc-rng200.c
new file mode 100644
index 000..4643aa9
--- /dev/null
+++ b/drivers/char/hw_random/iproc-rng200.c
@@ -0,0 +1,239 @@
+/*
+* Copyright (C) 2014 Broadcom Corporation
+*
+* 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 version 2.
+*
+* This program is distributed as is WITHOUT ANY WARRANTY of any
+* kind, whether express or implied; without even the implied warranty
+* of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+* GNU General Public License for more details.
+*/
+/*
+ * DESCRIPTION: The Broadcom iProc RNG200 Driver
+ */
+
+#include linux/hw_random.h
+#include linux/init.h
+#include linux/io.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/of_address.h
+#include linux/of_platform.h
+#include linux/platform_device.h
+#include linux/delay.h
+
+
+/* Registers */
+#define RNG_CTRL_OFFSET0x00
+#define RNG_CTRL_RNG_RBGEN_MASK0x1FFF
+#define RNG_CTRL_RNG_RBGEN_ENABLE 0x0001
+#define RNG_CTRL_RNG_RBGEN_DISABLE 0x
+
+#define RNG_SOFT_RESET_OFFSET 0x04
+#define RNG_SOFT_RESET_RNG_SOFT_RESET_MASK 0x0001
+#define RNG_SOFT_RESET_RNG_SOFT_RESET_ACTIVE 0x0001
+#define RNG_SOFT_RESET_RNG_SOFT_RESET_CLEAR0x
+
+#define RBG_SOFT_RESET_OFFSET 0x08
+#define RBG_SOFT_RESET_RNG_SOFT_RESET_MASK 0x0001
+#define RBG_SOFT_RESET_RNG_SOFT_RESET_ACTIVE 0x0001
+#define RBG_SOFT_RESET_RNG_SOFT_RESET_CLEAR0x
+
+#define RNG_INT_STATUS_OFFSET 0x18
+#define RNG_INT_STATUS_MASTER_FAIL_LOCKOUT_IRQ_MASK0x8000
+#define RNG_INT_STATUS_STARTUP_TRANSITIONS_MET_IRQ_MASK0x0002
+#define RNG_INT_STATUS_NIST_FAIL_IRQ_MASK 0x0020
+#define RNG_INT_STATUS_TOTAL_BITS_COUNT_IRQ_MASK 0x0001
+
+#define RNG_FIFO_DATA_OFFSET 0x20
+
+#define RNG_FIFO_COUNT_OFFSET 0x24
+#define RNG_FIFO_COUNT_RNG_FIFO_COUNT_MASK 0x00FF
+
+static void iproc_rng200_restart(void __iomem *rng_base)
+{
+ uint32_t val;
+
+ /* Disable RBG */
+ val = ioread32(rng_base + RNG_CTRL_OFFSET);
+ val = ~RNG_CTRL_RNG_RBGEN_MASK;
+ val |= RNG_CTRL_RNG_RBGEN_DISABLE;
+ iowrite32(val, rng_base + RNG_CTRL_OFFSET);
+
+ /* Clear all interrupt status */
+ iowrite32(0xUL, rng_base + RNG_INT_STATUS_OFFSET);
+
+ /* Reset RNG and RBG */
+ val = ioread32(rng_base + RBG_SOFT_RESET_OFFSET);
+ val = ~RBG_SOFT_RESET_RNG_SOFT_RESET_MASK;
+ val |= RBG_SOFT_RESET_RNG_SOFT_RESET_ACTIVE;
+ iowrite32(val, rng_base + RBG_SOFT_RESET_OFFSET);
+
+ val = ioread32(rng_base + RNG_SOFT_RESET_OFFSET);
+ val = ~RNG_SOFT_RESET_RNG_SOFT_RESET_MASK;
+ val |= RNG_SOFT_RESET_RNG_SOFT_RESET_ACTIVE;
+ iowrite32(val,
Re: Video option for a big endian machine?
On Thu, 12 Feb 2015 07:08:10 +1000 Dave Airlie airl...@gmail.com wrote: On 12 February 2015 at 00:44, Alex Deucher alexdeuc...@gmail.com wrote: On Wed, Feb 11, 2015 at 3:53 AM, lausg...@gmail.com wrote: Hello. I'm looking for a PCI or AGP video card that would work on a Linux port for a big endian architecture (HP PA-RISC). Unfortunately the stock video options (ATI FireGL X1 and X3) give an incredibly slow unaccelerated 2D due to failure to kickstart the command processor (radeon open source driver). Neither folks from linux-parisc@ nor from dri-devel@ camps know how to fix this. The X1 and X3 are really old asics and the risc specific versions tended to have special firmware for that platform that the open driver does not handle properly. You might have better luck using a more modern GPU (e.g., an R5xx or newer based asic) with an x86 vbios. If memory serves PA-RISC had some restrictions on PCI BAR windows, it wasn't just endianness problems. PCI isn't really the root bus so it's a bit odd. If you can live with 1024x768 then the ancient PCI Voodoo2 graphics cards in 2D mode don't even report as video cards, have minimal setup requirements and work on just about anything with a PCI bus. They are also usually available in the junk box under the table at computer shows. 3D is a bit trickier but the 2D acceleration is quite nice and can even do alpha blending (as it was in part designed to work with the 3D). Actually doing 3D is a different kettle of fish. Alan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] mmc: dw_mmc: Give a good reset after we give power
Hello Doug, On 02/20/2015 07:57 PM, Doug Anderson wrote: We should give dw_mmc a good reset after we apply power. On some boards vqmmc may actually be connected to the IP block in the SoC so it's good to reset after power comes in. Without this we sometimes see failures enumerating cards on rk3288. Signed-off-by: Doug Anderson diand...@chromium.org On an Exynos5250 Snow, Exynos5420 Peach Pit and Exynos5800 Peach Pi: Tested-by: Javier Martinez Canillas javier.marti...@collabora.co.uk Best regards, Javier -- 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] f2fs: fix recover orphan inodes
Hi Wanpeng,
On Wed, Feb 25, 2015 at 12:53:37PM +0800, Wanpeng Li wrote:
recover_orphan_inodes is used to recover orphan inodes, the meta pages
which readahead should be orphan_blkaddr - start_blk instead of
orphan_blkaddr.
This patch fix it.
Signed-off-by: Wanpeng Li wanpeng...@linux.intel.com
---
fs/f2fs/checkpoint.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c
index e6c271f..0f42ff3 100644
--- a/fs/f2fs/checkpoint.c
+++ b/fs/f2fs/checkpoint.c
@@ -468,9 +468,9 @@ void recover_orphan_inodes(struct f2fs_sb_info *sbi)
le32_to_cpu(F2FS_RAW_SUPER(sbi)-cp_payload);
Actually it seems the name, orphan_blkaddr, was wrong.
That should be orphan_blocks which is no need to fix like this.
Instead, I found there is another bug below.
orphan_blkaddr = __start_sum_addr(sbi) - 1;
orphan_blocks = __start_sum_addr(sbi) - 1 -
le32_to_cpu(F2FS_RAW_SUPER(sbi)-cp_payload);
It may help to define a macro to get cp_payload.
- ra_meta_pages(sbi, start_blk, orphan_blkaddr, META_CP);
+ ra_meta_pages(sbi, start_blk, orphan_blkaddr - start_blk, META_CP);
The orphan_blocks is enough. No need to fix this.
- for (i = 0; i orphan_blkaddr; i++) {
+ for (i = 0; i orphan_blkaddr - start_blk; i++) {
ditto.
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] ARM: dts: am335x-boneblack: enable aes and sham
On Wed, Feb 25, 2015 at 12:36:11PM -0600, Robert Nelson wrote:
On Wed, Feb 25, 2015 at 11:07 AM, Matt Porter mpor...@konsulko.com wrote:
Beaglebone Black doesn't have AES and SHAM enabled like the
original Beaglebone White dts. This breaks applications that
leverage the crypto blocks so fix this by enabling these nodes.
Signed-off-by: Matt Porter mpor...@konsulko.com
---
arch/arm/boot/dts/am335x-boneblack.dts | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-boneblack.dts
b/arch/arm/boot/dts/am335x-boneblack.dts
index 5c42d25..00853ff 100644
--- a/arch/arm/boot/dts/am335x-boneblack.dts
+++ b/arch/arm/boot/dts/am335x-boneblack.dts
@@ -33,6 +33,14 @@
status = okay;
};
+sham {
+ status = okay;
+};
+
+aes {
+ status = okay;
+};
+
am33xx_pinmux {
nxp_hdmi_bonelt_pins: nxp_hdmi_bonelt_pins {
pinctrl-single,pins =
--
1.8.4
Shouldn't we just move these to: am335x-bone-common.dtsi ?
(and then nuke the 6 lines in the am335x-bone.dts )
Good idea, v2 on the way.
-Matt
--
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/AER: Avoid info leak in __print_tlp_header
On Tue, Feb 24, 2015 at 11:50:46PM +0100, Rasmus Villemoes wrote:
Commit fab4c256a58b (PCI/AER: Add a TLP header print helper)
introduced the helper function __print_tlp_header, but contrary to the
intention, the behaviour did change: Since we're taking the address of
Whoops, good catch.
the parameter t, the first 4 or 8 bytes printed will be the value of
the pointer t itself, and the remaining 12 or 8 bytes will be
who-knows-what (something from the stack).
We want to treat the four members of the struct aer_header_log_regs as
little-endian 32 bit numbers and print those. That can be done without
ugly and confusing casts.
Fixes: fab4c256a58b (PCI/AER: Add a TLP header print helper)
Signed-off-by: Rasmus Villemoes li...@rasmusvillemoes.dk
---
drivers/pci/pcie/aer/aerdrv_errprint.c | 13 +++--
1 file changed, 3 insertions(+), 10 deletions(-)
diff --git a/drivers/pci/pcie/aer/aerdrv_errprint.c
b/drivers/pci/pcie/aer/aerdrv_errprint.c
index c6849d9e86ce..e328978038c1 100644
--- a/drivers/pci/pcie/aer/aerdrv_errprint.c
+++ b/drivers/pci/pcie/aer/aerdrv_errprint.c
@@ -132,16 +132,9 @@ static const char *aer_agent_string[] = {
static void __print_tlp_header(struct pci_dev *dev,
struct aer_header_log_regs *t)
{
- unsigned char *tlp = (unsigned char *)t;
-
- dev_err(dev-dev, TLP Header:
- %02x%02x%02x%02x %02x%02x%02x%02x
- %02x%02x%02x%02x %02x%02x%02x%02x\n,
- *(tlp + 3), *(tlp + 2), *(tlp + 1), *tlp,
- *(tlp + 7), *(tlp + 6), *(tlp + 5), *(tlp + 4),
- *(tlp + 11), *(tlp + 10), *(tlp + 9),
- *(tlp + 8), *(tlp + 15), *(tlp + 14),
- *(tlp + 13), *(tlp + 12));
+ dev_err(dev-dev, TLP Header: %08x %08x %08x %08x\n,
+ le32_to_cpu(t-dw0), le32_to_cpu(t-dw1),
+ le32_to_cpu(t-dw2), le32_to_cpu(t-dw3));
I'm not sure about this: I think the original intention was to dump the
dwords MS-bit to LS-bit like this here:
http://www.fpga4fun.com/PCI-Express4.html
Now, if this runs on a big endian machine, converting to CPU order would
be wrong IMHO. You'd rather want do do cpu_to_le32() for consistency.
But I don't know whether big endian machines are even sporting PCIE
AER...
Bjorn?
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
--
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/1] Synopsis 8250 serial port driver fix
Hi, This patchset fixes a bug in the Synopsis 8250 serial driver which causes the driver to hang. The bug occurs on simple 2 wire serial ports when modem control signalling has been enabled. It can be reproduced from user space by enabling modem control signals (stty -clocal), then opening a serial port and polling for data available to read with a timeout. A properly implemented driver will ignore the control signals and the call to poll will return. The current version of the driver hangs forever on the call to poll despite the timeout. Jon Desmond Liu (1): serial: 8250_dw: Fix get_mctrl behaviour .../bindings/serial/snps-dw-apb-uart.txt |7 drivers/tty/serial/8250/8250_dw.c | 41 2 files changed, 48 insertions(+) -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] of/address: Add of_io_release_and_unmap()
New Fumction of_io_release_an_unmap frees resources and io memory
allocated by io_request_and_map()
Signed-off-by: Joshua Clayton stillcompil...@gmail.com
---
drivers/of/address.c | 29 +
include/linux/of_address.h | 2 ++
2 files changed, 31 insertions(+)
diff --git a/drivers/of/address.c b/drivers/of/address.c
index ad29069..d0f3b81 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -872,6 +872,7 @@ EXPORT_SYMBOL(of_iomap);
/*
* of_io_request_and_map - Requests a resource and maps the memory mapped IO
*for a given device_node
+ *Call of_io_release_and_unmap() to free the memory
* @device:the device whose io range will be mapped
* @index: index of the io range
* @name: name of the resource
@@ -882,6 +883,10 @@ EXPORT_SYMBOL(of_iomap);
* base = of_io_request_and_map(node, 0, foo);
* if (IS_ERR(base))
* return PTR_ERR(base);
+ *
+ * ...
+ *
+ * return of_io_request_and_map(node, 0, base);
*/
void __iomem *of_io_request_and_map(struct device_node *np, int index,
const char *name)
@@ -906,6 +911,30 @@ void __iomem *of_io_request_and_map(struct device_node
*np, int index,
EXPORT_SYMBOL(of_io_request_and_map);
/**
+ * of_io_release_and_unmap - Unmap memory and release resource
+ *associated with a device node
+ * Use this function to free memory requested by of_io_request_and_map()
+ * See the Usage example for of_io_request_and_map
+ *
+ */
+int of_io_release_and_unmap(struct device_node *np, int index,
+ void __iomem *addr)
+{
+ struct resource res;
+ int ret = 0;
+
+ ret = of_address_to_resource(np, index, res);
+ if (ret)
+ return ret;
+
+ iounmap(addr);
+ release_mem_region(res.start, resource_size(res));
+
+ return ret;
+}
+EXPORT_SYMBOL(of_io_release_and_unmap);
+
+/**
* of_dma_get_range - Get DMA range info
* @np:device node to get DMA range info
* @dma_addr: pointer to store initial DMA address of DMA range
diff --git a/include/linux/of_address.h b/include/linux/of_address.h
index d88e81b..f62eb9e 100644
--- a/include/linux/of_address.h
+++ b/include/linux/of_address.h
@@ -107,6 +107,8 @@ extern int of_address_to_resource(struct device_node *dev,
int index,
void __iomem *of_iomap(struct device_node *node, int index);
void __iomem *of_io_request_and_map(struct device_node *device,
int index, const char *name);
+int of_io_release_and_unmap(struct device_node *np, int index,
+ void __iomem *addr);
#else
#include linux/io.h
--
2.1.0
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v9 0/4] Add gpio/pinconf support to Broadcom Cygnus SoC
On Tue, Feb 10, 2015 at 02:16:20PM -0800, Ray Jui wrote: This patchset contains the initial GPIO/PINCONF support for the Broadcom Cygnus SoC. Cygnus has 3 GPIO controllers: 1) the ASIU GPIO; 2) the chipCommonG GPIO; and 3) the ALWAYS-ON GPIO. All 3 types of GPIO controllers are supported by the this driver. All 3 Cygnus GPIO controllers support basic PINCONF functions such as bias pull up, pull down, and drive strength configurations, when these pins are muxed to GPIO. Pins from the ASIU GPIO can be individually muxed to GPIO function, through interaction with the Cygnus IOMUX controller. Note this patchset has a dependency on the other patchset Add pinctrl support to Broadcom Cygnus SoC that is also under review Changes from v8: - Add code in function 'cygnus_gpio_pinmux_add_range' to free pinmux node resource by calling of_node_put - Drop .suppress_bind_attrs = true, since this is already done in platform_driver_probe Changes from v7: - Use 'bool' instead of 'int' for flag that indicates pinmux support in the driver - Call put_device to drop reference to the pinmux dev after call to of_find_device_by_node - Replace kasprintf with devm_kasprintf and remove memory deallocation logic in the driver - Set suppress_bind_attrs to true for the driver Changes from v6: - Move the driver from drivers/gpio/* to drivers/pinctrl/* since this driver supports both GPIO and some basic PINCONF features - Support PINCONF features through standard DT subnodes properties including bias-disable, bias-pull-up, bias-pull-down, and drive-strength, by creating local PINCONF controller - Add support to allow individual ASIU GPIO pins to be muxed as GPIO, through interactions with the Cygnus IOMUX driver - Convert the driver to use standard GPIOCHIP_IRQ APIs. This helps to reduce customized code in the driver - Other miscellaneous imrpovements in the driver - Enable GPIO based phone hook detection support for BCM911360 phone factor board Changes from v5: - Get rid of DT property linux,gpio-base. Use dynamic allocation for GPIO base number Changes from v4: - Use DT property linux,gpio-base to define GPIO base number - factorize common code to improve code readability and reduce code size - remove bcm_ prefix on function and struct names - improve debugging prints - default GPIO_BCM_CYGNUS to y in Kconfig (it still depends on ARCH_BCM_CYGNUS). This way we do not need to select it from the arch/arm/mach-bcm/Kconfig - Get rid of redundant MAINTAINER entry for this driver. It will be maintained by Broadcom iProc/Cygnus maintainers - Update device tree document based on driver changes Changes from v3: - Fix dt property tpyo - Fix incorrect GPIO compatible ID in device tree binding document example Changes from v2: - Consolidate different compatible IDs into brcm,cygnus-gpio - Get rid of redundant no-interrupt property Changes from v1: - Get rid of inline qualifier - Get rid of redundant check in the ISR - Other minor fixes to imrove code readability FWIW I tested this series on BCM958305K SVK. Tested-by: Dmitry Torokhov d...@chromium.org Thanks. -- Dmitry -- 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/
SYMTAB_SHNDX has bad sh_link build error
Hi. With Linux 4.0-rc1, I get this allyesconfig build error on CentOS 5. This build error occurs starting with Linux 3.15-rc1. + modpost_link vmlinux.o + ld -m elf_x86_64 -r -o vmlinux.o arch/x86/kernel/head_64.o arch/x86/kernel/he$ + make -f ./scripts/Makefile.modpost vmlinux.o scripts/mod/modpost -m -a -o ./Module.symvers vmlinux.o FATAL: vmlinux.o: SYMTAB_SHNDX has bad sh_link: 71288!=71032 Cheers, Vinson -- 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] KVM: SVM: fix interrupt injection (apic-isr_count always 0)
2015-02-25 17:00+0100, Borislav Petkov:
Hi,
commit in $Subject breaks my kvm guest on AMD host, causing it to do the
following below. Mouse doesn't work anymore in the guest, network is
gone too.
Reverting it fixes the issue.
Thanks,
this patch should fix it.
---8---
In commit b4eef9b36db4, we started to use hwapic_isr_update() != NULL
instead of kvm_apic_vid_enabled(vcpu-kvm). This didn't work because
SVM had it defined and apicv path in apic_{set,clear}_isr() does not
change apic-isr_count, because it should always be 1. The initial
value of apic-isr_count was based on kvm_apic_vid_enabled(vcpu-kvm),
which is always 0 for SVM, so KVM could have injected interrupts when it
shouldn't.
Fix it by setting SVM's hwapic_isr_update to NULL and make the initial
isr_count depend on hwapic_isr_update() for good measure.
Fixes: b4eef9b36db4 (kvm: x86: vmx: NULL out hwapic_isr_update() in case of
!enable_apicv)
Reported-by: Borislav Petkov b...@alien8.de
Signed-off-by: Radim Krčmář rkrc...@redhat.com
---
arch/x86/kvm/lapic.c | 4 ++--
arch/x86/kvm/svm.c | 7 +--
2 files changed, 3 insertions(+), 8 deletions(-)
diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index e55b5fc344eb..bd4e34de24c7 100644
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
@@ -1572,7 +1572,7 @@ void kvm_lapic_reset(struct kvm_vcpu *vcpu)
apic_set_reg(apic, APIC_TMR + 0x10 * i, 0);
}
apic-irr_pending = kvm_apic_vid_enabled(vcpu-kvm);
- apic-isr_count = kvm_apic_vid_enabled(vcpu-kvm);
+ apic-isr_count = kvm_x86_ops-hwapic_isr_update ? 1 : 0;
apic-highest_isr_cache = -1;
update_divide_count(apic);
atomic_set(apic-lapic_timer.pending, 0);
@@ -1782,7 +1782,7 @@ void kvm_apic_post_state_restore(struct kvm_vcpu *vcpu,
update_divide_count(apic);
start_apic_timer(apic);
apic-irr_pending = true;
- apic-isr_count = kvm_apic_vid_enabled(vcpu-kvm) ?
+ apic-isr_count = kvm_x86_ops-hwapic_isr_update ?
1 : count_vectors(apic-regs + APIC_ISR);
apic-highest_isr_cache = -1;
if (kvm_x86_ops-hwapic_irr_update)
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index d319e0c24758..54c7b36ad12d 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -3649,11 +3649,6 @@ static void svm_load_eoi_exitmap(struct kvm_vcpu *vcpu,
u64 *eoi_exit_bitmap)
return;
}
-static void svm_hwapic_isr_update(struct kvm *kvm, int isr)
-{
- return;
-}
-
static void svm_sync_pir_to_irr(struct kvm_vcpu *vcpu)
{
return;
@@ -4403,7 +4398,7 @@ static struct kvm_x86_ops svm_x86_ops = {
.set_virtual_x2apic_mode = svm_set_virtual_x2apic_mode,
.vm_has_apicv = svm_vm_has_apicv,
.load_eoi_exitmap = svm_load_eoi_exitmap,
- .hwapic_isr_update = svm_hwapic_isr_update,
+ .hwapic_isr_update = NULL,
.sync_pir_to_irr = svm_sync_pir_to_irr,
.set_tss_addr = svm_set_tss_addr,
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] clk: Use lockdep asserts to find missing hold of prepare_lock
Quoting Krzysztof Kozlowski (2015-01-09 00:28:10)
Add lockdep asserts for holding the prepare_lock to all functions
marking this as a requirement in description. Add this to private and
exported functions so all locking misuse could be detected during
debugging.
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
Applied.
Thanks,
Mike
---
drivers/clk/clk.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index f4963b7d4e17..cdbfaa34ace4 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -432,6 +432,8 @@ static void clk_unprepare_unused_subtree(struct clk *clk)
{
struct clk *child;
+ lockdep_assert_held(prepare_lock);
+
if (!clk)
return;
@@ -458,6 +460,8 @@ static void clk_disable_unused_subtree(struct clk *clk)
struct clk *child;
unsigned long flags;
+ lockdep_assert_held(prepare_lock);
+
if (!clk)
goto out;
@@ -947,6 +951,8 @@ unsigned long __clk_round_rate(struct clk *clk, unsigned
long rate)
struct clk *parent;
struct clk_hw *parent_hw;
+ lockdep_assert_held(prepare_lock);
+
if (!clk)
return 0;
@@ -1040,6 +1046,8 @@ static void __clk_recalc_accuracies(struct clk *clk)
unsigned long parent_accuracy = 0;
struct clk *child;
+ lockdep_assert_held(prepare_lock);
+
if (clk-parent)
parent_accuracy = clk-parent-accuracy;
@@ -1104,6 +1112,8 @@ static void __clk_recalc_rates(struct clk *clk,
unsigned long msg)
unsigned long parent_rate = 0;
struct clk *child;
+ lockdep_assert_held(prepare_lock);
+
old_rate = clk-rate;
if (clk-parent)
@@ -1297,6 +1307,8 @@ static int __clk_speculate_rates(struct clk *clk,
unsigned long parent_rate)
unsigned long new_rate;
int ret = NOTIFY_DONE;
+ lockdep_assert_held(prepare_lock);
+
new_rate = clk_recalc(clk, parent_rate);
/* abort rate change if a driver returns NOTIFY_BAD or NOTIFY_STOP */
@@ -2110,6 +2122,8 @@ static void __clk_release(struct kref *ref)
struct clk *clk = container_of(ref, struct clk, ref);
int i = clk-num_parents;
+ lockdep_assert_held(prepare_lock);
+
kfree(clk-parents);
while (--i = 0)
kfree(clk-parent_names[i]);
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] perf: Fix sigbus with perf-top
Em Wed, Feb 18, 2015 at 07:03:18PM -0500, David Ahern escreveu:
perf-top is terminating due to SIGBUS on sparc64. git bisect points to:
commit 82396986032915c1572bfb74b224fcc2e4e8ba7c
Author: Arnaldo Carvalho de Melo a...@redhat.com
Date: Mon Sep 8 13:26:35 2014 -0300
perf evlist: Refcount mmaps
We need to know how many fds are using a perf mmap via
PERF_EVENT_IOC_SET_OUTPUT, so that we can know when to ditch an mmap,
refcount it.
This commit added 'int refcnt' to struct perf_mmap and the addition makes the
event_copy element no longer 8-byte aligned. Fix by adding a pad.
I am applying this, but please consider doing like the kernel and using
one of those __aligned_on_foo struct member attributes.
I am adding a comment right after that pad...
- Arnaldo
Signed-off-by: David Ahern david.ah...@oracle.com
---
tools/perf/util/evlist.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/perf/util/evlist.h b/tools/perf/util/evlist.h
index c94a9e03ecf1..7a5a77b2b907 100644
--- a/tools/perf/util/evlist.h
+++ b/tools/perf/util/evlist.h
@@ -28,6 +28,7 @@ struct perf_mmap {
int mask;
int refcnt;
unsigned int prev;
+ int pad;
char event_copy[PERF_SAMPLE_MAX_SIZE];
};
--
1.9.3
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] thermal: armada: read stable temp on Armada XP
Hi Gregory, Eduardo,
On Wed, Feb 25, 2015 at 05:10:14PM +0100, Gregory CLEMENT wrote:
By using it by default do you mean removing marvell,armadaxp-thermal
and adding armadaxp-filtered-thermal instead ?
Yes, replacing it in device tree. For me,
/sys/class/thermal/thermal_zone0/temp returns the same temperature but
with less variability between samples. My intent was to switch the
source of the data and not affect user space other than providing a
more stable reading.
Tyler,
In the meantime could you double check your values? The temperature on my
board
seemed broken on my board. If needed I can check on an other board. By the way
on which board/product did you try it?
I'm on a custom board with the 4-core MV78460. In addition to my
patch, this is new device tree entry.
thermal@184c4 {
compatible = marvell,armadaxp-filtered-thermal;
reg = 0x184c4 0x4
0x184d0 0x4;
status = okay;
};
I dumped some raw samples of the temperature fields in each of these
registers. This CSV contains the raw values converted to decimal.
http://pastebin.com/Umc3cy5L
The first column is the current register at 0x182b0 27:19 and the
second is the register at 0x184c4 9:1.
Here's a quick plot of a larger sample size while the temperature was rising.
https://imgur.com/E9HlSBx
The blue value is the current 0x182b0 register which seems to bounce
around the green value from 0x184c4.
I'll try a test of instantiating both at the same time and comparing
the final output of the driver.
On Wed, Feb 25, 2015 at 1:39 PM, Eduardo Valentin edubez...@gmail.com wrote:
Does that new thermal sensors only improve the stability or does it
also modify the value?
In the second case it will more or less break the user space expectation.
Yeah, I agree here. We need to understand if this is:
(1) a fix of which register to use. In that case, the old dtbs are
essentially wrong, and the driver would need to adapt, I would say.
(2) a way to report better temperature extrapolations. then, this is
essentially a new temp sensor, and we should have two separated
compatible. in other words, just keep the patch the way it is.
This *might* be a different physical sensor, or it could be from the
same source with some averaging/filtering applied in hardware. The
conversion formula is the same, however, and I get similar raw values
from both.
Yes. Typically I ask to see the complete series, even if I am not taking
the DTS changes. That is, you send a complete series, with changes in
the kernel code and in the DTS, copying the required audience (from
kernel side and from DT side). Once the changes are accepted, the
patches will be picked by the correct tree maintainer. It is common that
DTS changes go via the platform tree, to avoid conflicts though.
Thanks for the clarification. I'll send both in the next version as I
suspect there will be a v2 of this change.
--
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 1/3] i2c: Enhancement of i2c API to address circular lock dependency problem
Quoting Mark Brown (2015-01-18 05:41:24) On Sun, Jan 18, 2015 at 11:54:56AM +0100, Krzysztof Kozlowski wrote: W dniu 18.01.2015 o 07:30, Tomasz Figa pisze: So, the question is, do we actually have hardware that _really_ requires _actual_ preparation or all the clk_prepare_enable()s in I2C drivers (at least in i2c-s3c2410) are just to simplify the code? I completely forgot that you already thought about this deadlock in 2014. I think we can try the no-prepare way for i2c-s3c2410. However this would be only workaround for specific chip. Other buses (like SPI) would require similar changes. Right, and it's every single driver which would need an update too which is a bit icky and sad. On the other hand a more detailed fix is going to involve trying to make the clock API locking more fine grained which isn't fun. Not fun is right. Please see Stephen's attempt here: http://lkml.kernel.org/r/1409792466-5092-1-git-send-email-sb...@codeaurora.org I'm hoping this approach will be revisited soon. Regards, Mike I wondered why this was not observed (at least not observed by me with lockdep) on Gear 2 (Rinato) board. This is quite similar case: the S2MPS14 PMIC provides regulators and 32kHz clocks. I think it is exactly the same pattern as for max77686... but somehow lockdep never reported that deadlock there. Mostly the clocks on PMICs never get changed at runtime which helps a lot here. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 1/7] mfd: Add support for DA9150 combined charger fuel-gauge device
Hi, On Wed, Feb 18, 2015 at 02:08:24PM +, Adam Thomson wrote: DA9150 is a combined Charger and Fuel-Gauge IC, with additional GPIO and GPADC functionality. Signed-off-by: Adam Thomson adam.thomson.opensou...@diasemi.com Acked-by: Lee Jones lee.jo...@linaro.org This patch is already in 4.0-rc1 making things easier for 4.1 :) -- Sebastian signature.asc Description: Digital signature
Re: [PATCH 0/3] MSM8960 LCC fixes
Quoting Stephen Boyd (2015-01-29 15:38:10) A couple of small fixes found while testing the audio clock control on apq8064. Applied to clk-fixes. Regards, Mike Stephen Boyd (3): clk: qcom: lcc-msm8960: Fix slimbus n and m val offsets clk: qcom: lcc-msm8960: Fix PLL rate detection clk: qcom: Add PLL4 vote clock drivers/clk/qcom/gcc-msm8960.c | 13 + drivers/clk/qcom/lcc-msm8960.c | 6 +++--- 2 files changed, 16 insertions(+), 3 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Question about Old Fix Me comment in mempool.c
On Tue, 16 Dec 2014, nick wrote: Greetings Andrew and other maintainers, I am wondering why the below comment is even in mempool.c and this has not been changed to a call to io_schedule as the kernel version is stupidly old and this should be fixed by now and the issues with DM would have been removed by now. /* * FIXME: this should be io_schedule(). The timeout is there as a * workaround for some DM problems in 2.6.18. */ Sorry for the stupid question but I like to double check with the maintainers before I sent in a patch for things like this to see if I am missing anything:). Thanks for Your Time, Nick There are still some bugs with respect to this (and they will probably never be removed all) - for example this bug which wasn't fixed yet http://www.redhat.com/archives/dm-devel/2014-May/msg00089.html . So, you should not remove it. Mikulas -- 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] mmc: dw_mmc: fix bug that cause mmc_test failture
Hello Addy, On 02/20/2015 03:55 AM, Addy Ke wrote: The STOP command can terminate a data transfer between a memory card and mmc controller. As show in Synopsys DesignWare Cores Mobile Stroage Host Databook: s/Stroage/Storage but maybe Ulf can amend the typo when applying? Data timeout and Data end-bit error will terminate further data transfer by mmc controller. So we should not send abort command to terminate a data transfer again if we got DRTO and EBE interrupt. After this patch, all mmc_test cases can pass on RK3288-Pink2 board. Signed-off-by: Addy Ke addy...@rock-chips.com I did not run all the tests listed in /sys/kernel/debug/mmc*/*/testlist because some of them will overwrite the data in my card but at least the read ones completed successfully and $subject does not cause a regression in the Exynos5250 Snow, Exynos5420 Peach Pit and Exynos5800 Peach Pi Chromebooks where I tested it. Tested-by: Javier Martinez Canillas javier.marti...@collabora.co.uk Best regards, Javier -- 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: Provide an always-on clock domain framework
Quoting Lee Jones (2015-02-25 07:48:08)
On Wed, 25 Feb 2015, Rob Herring wrote:
On Mon, Feb 23, 2015 at 11:23 AM, Mike Turquette mturque...@linaro.org
wrote:
Quoting Lee Jones (2015-02-18 08:15:00)
Much h/w contain clocks which if turned off would prove fatal. The
only way to recover is to restart the board(s). This driver takes
references to clocks which are required to be always-on in order to
prevent the common clk framework from trying to turn them off during
the clk_disabled_unused() procedure.
[...]
+static int ao_clock_domain_probe(struct platform_device *pdev)
+{
+ struct device_node *np = pdev-dev.of_node;
+ int nclks, i;
+
+ nclks = of_count_phandle_with_args(np, clocks, #clock-cells);
Minor nitpick: please use of_clk_get_parent_count. I spent a solid 5
minutes writing that function and I need people to use it so I can get a
return on my investment.
Otherwise the patch looks good. I believe that this method is targeting
always-on clock in a production environment, which is different from the
CLK_IGNORE_UNUSED stuff which typically is helpful while bringing up new
hardware or dealing with a platform that has incomplete driver support.
There is also the usecase of keep clocks on until I load a module that
properly handles my hardware (e.g simplefb). We have a simplefb node
with clocks and the simplefb driver jumps thru some hoops to hand-off
clocks to the real driver. I don't really like it and don't want to
see more examples. And there is the case of I thought I would never
manage this clock, but kernel subsystems evolve and now I want to
manage a clock. This should not require a DT update to do so.
Neither of these may be Lee's usecase, but I want to see them covered
by the binding.
I wonder if there is a clever way for existing clock providers
(expressed in DT) to use this without having to create a separate node
of clocks with the always-on-clk-domain flag. Possibly the common
clock binding could declare some always-on flag that is standardized?
Then the framework core could use this code easily. Not sure if that is
a good idea though...
I would prefer to see the always on clocks just listed within the
clock controller's node rather than creating made up nodes with clock
properties.
This should be always-on until claimed IMO, but that
aspect is the OS's problem, not a DT problem.
I disagree with this point. There are likely to be many unclaimed,
but perfectly gateable clocks in a system, which will consume power
unnecessarily. The clk framework does the right thing by turning all
unclaimed clocks off IMHO. This only leaves a small use-case where we
need to artificially claim some which must not be gated.
I might have misread both of your mails, but I think you two are
actually in agreement. You both support a common property which lists
the always-on clocks inside of the common clock binding, no?
The other way to do is, as you mentioned is list the clocks which must
stay on in the clock source node, but this will still require a
binding. It will also require a much more complicated framework
driver.
clkprovider@ {
always-on-clks = 1, 2, 4, 5, 7;
};
This should pose no burden on the driver. Since always-on-clks is in the
common clock binding it should be handled by the framework core. At
clk_register-time we can check for always-on-clks, walk the list and see
if we have a match. It's ugly O(n^2) but it works.
Thoughts?
Mike
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 6/6] hwmon: pwm-fan: Code for using PWM FAN as a cooling device
Hey Lukasz,
On Wed, Feb 25, 2015 at 04:34:22PM +0100, Lukasz Majewski wrote:
The PWM FAN device can now be used as a thermal cooling device. Necessary
infrastructure has been added in this commit.
Signed-off-by: Lukasz Majewski l.majew...@samsung.com
---
Changes for v2:
- Replace pwm_fan_cooling_states with pwm_fan_cooling_levels
- Update ctx-pwm_fan_state when correct data from device tree is available
- Using therma_cdev_update() when thermal is ready for controlling the fan
Changes for v3:
- Rename patch heading
- pwm_fan_of_get_cooling_data() now returns -EINVAL when no cooling-levels
property defined
- register of cooling device only when proper cooling data is present
Changes for v4:
- None
Changes for v5:
- Check for IS_ENABLED(CONFIG_THERMAL) has been added to prevent from
executing thermal_* specific functions
---
drivers/hwmon/pwm-fan.c | 83
-
1 file changed, 82 insertions(+), 1 deletion(-)
diff --git a/drivers/hwmon/pwm-fan.c b/drivers/hwmon/pwm-fan.c
index e6ed353..2c1a8f0 100644
--- a/drivers/hwmon/pwm-fan.c
+++ b/drivers/hwmon/pwm-fan.c
@@ -24,6 +24,7 @@
#include linux/platform_device.h
#include linux/pwm.h
#include linux/sysfs.h
+#include linux/thermal.h
#define MAX_PWM 255
@@ -68,6 +69,17 @@ exit_set_pwm_err:
return ret;
}
+static void pwm_fan_update_state(struct pwm_fan_ctx *ctx, unsigned long pwm)
+{
+ int i;
+
+ for (i = 0; i ctx-pwm_fan_max_state; ++i)
+ if (pwm ctx-pwm_fan_cooling_levels[i + 1])
+ break;
+
+ ctx-pwm_fan_state = i;
+}
+
static ssize_t set_pwm(struct device *dev, struct device_attribute *attr,
const char *buf, size_t count)
{
@@ -82,6 +94,7 @@ static ssize_t set_pwm(struct device *dev, struct
device_attribute *attr,
if (ret)
return ret;
+ pwm_fan_update_state(ctx, pwm);
return count;
}
@@ -103,6 +116,59 @@ static struct attribute *pwm_fan_attrs[] = {
ATTRIBUTE_GROUPS(pwm_fan);
+/* thermal cooling device callbacks */
+static int pwm_fan_get_max_state(struct thermal_cooling_device *cdev,
+ unsigned long *state)
+{
+ struct pwm_fan_ctx *ctx = cdev-devdata;
+
Why this call back is the only one you didn't add a check for ctx ==
NULL?
+ *state = ctx-pwm_fan_max_state;
+
+ return 0;
+}
+
+static int pwm_fan_get_cur_state(struct thermal_cooling_device *cdev,
+ unsigned long *state)
+{
+ struct pwm_fan_ctx *ctx = cdev-devdata;
+
+ if (!ctx)
+ return -EINVAL;
+
+ *state = ctx-pwm_fan_state;
+
+ return 0;
+}
+
+static int
+pwm_fan_set_cur_state(struct thermal_cooling_device *cdev, unsigned long
state)
+{
+ struct pwm_fan_ctx *ctx = cdev-devdata;
+ int ret;
+
+ if (!ctx || (state ctx-pwm_fan_max_state))
+ return -EINVAL;
+
+ if (state == ctx-pwm_fan_state)
+ return 0;
+
+ ret = __set_pwm(ctx, ctx-pwm_fan_cooling_levels[state]);
+ if (ret) {
+ dev_err(cdev-device, Cannot set pwm!\n);
+ return ret;
+ }
+
+ ctx-pwm_fan_state = state;
+
+ return ret;
+}
+
+static const struct thermal_cooling_device_ops pwm_fan_cooling_ops = {
+ .get_max_state = pwm_fan_get_max_state,
+ .get_cur_state = pwm_fan_get_cur_state,
+ .set_cur_state = pwm_fan_set_cur_state,
+};
+
int pwm_fan_of_get_cooling_data(struct device *dev, struct pwm_fan_ctx *ctx)
{
struct device_node *np = dev-of_node;
@@ -145,8 +211,9 @@ int pwm_fan_of_get_cooling_data(struct device *dev,
struct pwm_fan_ctx *ctx)
static int pwm_fan_probe(struct platform_device *pdev)
{
- struct device *hwmon;
+ struct thermal_cooling_device *cdev;
struct pwm_fan_ctx *ctx;
+ struct device *hwmon;
int duty_cycle;
int ret;
@@ -193,6 +260,20 @@ static int pwm_fan_probe(struct platform_device *pdev)
if (ret)
return ret;
+ ctx-pwm_fan_state = ctx-pwm_fan_max_state;
+ if (IS_ENABLED(CONFIG_THERMAL)) {
+ cdev = thermal_of_cooling_device_register(pdev-dev.of_node,
+ pwm-fan, ctx,
+ pwm_fan_cooling_ops);
I know this is a PITA, but thermal subsystem still does not use devm
based helpers. That means, you need to be old school and unregister the
device yourself.
Please add the cdev to ctx structure:
+ ctx-cdev = cdev;
and add a call for:
thermal_cooling_device_unregister(ctx-cdev);
in static int pwm_fan_remove(struct platform_device *pdev)
despite the above two minor issues, you may add my
Acked-by: Eduardo Valentin edubez...@gmail.com
+ if (IS_ERR(cdev)) {
+ dev_err(pdev-dev,
+
Re: [PATCH] Add a quirk for the Dell XPS 13 (2015) when in PS/2 mode.
On 02/23/2015 06:51 PM, Dmitry Torokhov wrote: On Sun, Feb 22, 2015 at 05:55:05PM +0100, Pali Rohár wrote: I am not sure what exactly the issue is... We do need to have the break code to know when the key is released. We can't go and say that we will release old key when we detect another key press as that would mess up key combination handling (like control, meta, etc). What does Windows driver do? Thanks. To me it sounds like the Windows driver understands a situation that there are a bunch of key down events without a keyup event until you lift your finger rather than expecting a pair every time. https://msdn.microsoft.com/en-us/library/windows/desktop/ms646267(v=vs.85).aspx -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 5/8] ARM: dts: Add properties to use pwm-fan device as a cooling device in Odroid U3
On Wed, Feb 25, 2015 at 02:28:15PM +0100, Lukasz Majewski wrote:
Hi Eduardo,
On Wed, Feb 18, 2015 at 11:07:33AM +0100, Lukasz Majewski wrote:
With those bindings it is possible to use pwm-fan device available
in Odroid U3 as a cooling device.
Signed-off-by: Lukasz Majewski l.majew...@samsung.com
---
Changes for v2:
- Rename cooling-pwm-values property to cooling-levels
Changes for v3:
- Change patch's topic to ARM dts
- Reduce maximal cooling-level to 230 from 255
Changes for v4:
- None
---
arch/arm/boot/dts/exynos4412-odroidu3.dts | 33
++- 1 file changed, 32 insertions(+), 1
deletion(-)
diff --git a/arch/arm/boot/dts/exynos4412-odroidu3.dts
b/arch/arm/boot/dts/exynos4412-odroidu3.dts index 60bd1e4..3e5df3e
100644 --- a/arch/arm/boot/dts/exynos4412-odroidu3.dts
+++ b/arch/arm/boot/dts/exynos4412-odroidu3.dts
@@ -32,11 +32,42 @@
};
};
- pwm-fan {
+ fan0: pwm-fan {
compatible = pwm-fan;
pwms = pwm 0 1 0;
+ cooling-min-state = 0;
+ cooling-max-state = 3;
+ #cooling-cells = 2;
+ cooling-levels = 0 102 170 230;
status = okay;
};
+
+ thermal-zones {
+ cpu_thermal: cpu-thermal {
This thermal zone misses the mandatory properties as per
Documentation/devicetree/bindings/thermal/thermal.txt
Following mandatory properties:
thermal-sensors = tmu 0;
polling-delay-passive = 0;
polling-delay = 0;
trips {
}
are defined in exynos4-cpu-thermal.dtsi included by this file.
In this patch only device dependent changes are stated.
OK. I missed that.
+ cooling-maps {
+ map0 {
+ trip = cpu_alert1;
+ cooling-device = cpu0 7 7;
+ };
+ map1 {
+ trip = cpu_alert2;
+ cooling-device = cpu0 13
13;
+ };
+ map2 {
+ trip = cpu_alert0;
+ cooling-device = fan0 0 1;
+ };
+ map3 {
+ trip = cpu_alert1;
+ cooling-device = fan0 1 2;
+ };
+ map4 {
+ trip = cpu_alert2;
+ cooling-device = fan0 2 3;
+ };
+ };
+ };
+ };
};
pwm {
--
2.0.0.rc2
--
Best regards,
Lukasz Majewski
Samsung RD Institute Poland (SRPOL) | Linux Platform Group
signature.asc
Description: Digital signature
Re: [PATCH] ARM: dts: am335x-boneblack: enable aes and sham
On Wed, Feb 25, 2015 at 11:07 AM, Matt Porter mpor...@konsulko.com wrote:
Beaglebone Black doesn't have AES and SHAM enabled like the
original Beaglebone White dts. This breaks applications that
leverage the crypto blocks so fix this by enabling these nodes.
Signed-off-by: Matt Porter mpor...@konsulko.com
---
arch/arm/boot/dts/am335x-boneblack.dts | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-boneblack.dts
b/arch/arm/boot/dts/am335x-boneblack.dts
index 5c42d25..00853ff 100644
--- a/arch/arm/boot/dts/am335x-boneblack.dts
+++ b/arch/arm/boot/dts/am335x-boneblack.dts
@@ -33,6 +33,14 @@
status = okay;
};
+sham {
+ status = okay;
+};
+
+aes {
+ status = okay;
+};
+
am33xx_pinmux {
nxp_hdmi_bonelt_pins: nxp_hdmi_bonelt_pins {
pinctrl-single,pins =
--
1.8.4
Shouldn't we just move these to: am335x-bone-common.dtsi ?
(and then nuke the 6 lines in the am335x-bone.dts )
Regards,
--
Robert Nelson
http://www.rcn-ee.com/
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/2] hwrng: iproc-rng200 - Add Broadcom IPROC RNG driver
Hi Scott,
On Wed, Feb 25, 2015 at 10:16:24AM -0800, Scott Branden wrote:
This adds a driver for random number generator present on Broadcom
IPROC devices.
Reviewed-by: Ray Jui r...@broadcom.com
Signed-off-by: Scott Branden sbran...@broadcom.com
---
drivers/char/hw_random/Kconfig| 13 ++
drivers/char/hw_random/Makefile | 1 +
drivers/char/hw_random/iproc-rng200.c | 239
++
3 files changed, 253 insertions(+)
create mode 100644 drivers/char/hw_random/iproc-rng200.c
diff --git a/drivers/char/hw_random/Kconfig b/drivers/char/hw_random/Kconfig
index de57b38..f48cf11 100644
--- a/drivers/char/hw_random/Kconfig
+++ b/drivers/char/hw_random/Kconfig
@@ -101,6 +101,19 @@ config HW_RANDOM_BCM2835
If unsure, say Y.
+config HW_RANDOM_IPROC_RNG200
+ tristate Broadcom iProc RNG200 support
+ depends on ARCH_BCM_IPROC
+ default HW_RANDOM
+ ---help---
+ This driver provides kernel-side support for the RNG200
+ hardware found on the Broadcom iProc SoCs.
+
+ To compile this driver as a module, choose M here: the
+ module will be called iproc-rng200
+
+ If unsure, say Y.
+
config HW_RANDOM_GEODE
tristate AMD Geode HW Random Number Generator support
depends on X86_32 PCI
diff --git a/drivers/char/hw_random/Makefile b/drivers/char/hw_random/Makefile
index 0b4cd57..055bb01 100644
--- a/drivers/char/hw_random/Makefile
+++ b/drivers/char/hw_random/Makefile
@@ -28,5 +28,6 @@ obj-$(CONFIG_HW_RANDOM_POWERNV) += powernv-rng.o
obj-$(CONFIG_HW_RANDOM_EXYNOS) += exynos-rng.o
obj-$(CONFIG_HW_RANDOM_TPM) += tpm-rng.o
obj-$(CONFIG_HW_RANDOM_BCM2835) += bcm2835-rng.o
+obj-$(CONFIG_HW_RANDOM_IPROC_RNG200) += iproc-rng200.o
obj-$(CONFIG_HW_RANDOM_MSM) += msm-rng.o
obj-$(CONFIG_HW_RANDOM_XGENE) += xgene-rng.o
diff --git a/drivers/char/hw_random/iproc-rng200.c
b/drivers/char/hw_random/iproc-rng200.c
new file mode 100644
index 000..4643aa9
--- /dev/null
+++ b/drivers/char/hw_random/iproc-rng200.c
@@ -0,0 +1,239 @@
+/*
+* Copyright (C) 2014 Broadcom Corporation
+*
+* 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 version 2.
+*
+* This program is distributed as is WITHOUT ANY WARRANTY of any
+* kind, whether express or implied; without even the implied warranty
+* of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+* GNU General Public License for more details.
+*/
+/*
+ * DESCRIPTION: The Broadcom iProc RNG200 Driver
+ */
+
+#include linux/hw_random.h
+#include linux/init.h
+#include linux/io.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/of_address.h
+#include linux/of_platform.h
+#include linux/platform_device.h
+#include linux/delay.h
+
+
+/* Registers */
+#define RNG_CTRL_OFFSET 0x00
+#define RNG_CTRL_RNG_RBGEN_MASK 0x1FFF
+#define RNG_CTRL_RNG_RBGEN_ENABLE0x0001
+#define RNG_CTRL_RNG_RBGEN_DISABLE 0x
+
+#define RNG_SOFT_RESET_OFFSET0x04
+#define RNG_SOFT_RESET_RNG_SOFT_RESET_MASK 0x0001
+#define RNG_SOFT_RESET_RNG_SOFT_RESET_ACTIVE 0x0001
+#define RNG_SOFT_RESET_RNG_SOFT_RESET_CLEAR 0x
+
+#define RBG_SOFT_RESET_OFFSET0x08
+#define RBG_SOFT_RESET_RNG_SOFT_RESET_MASK 0x0001
+#define RBG_SOFT_RESET_RNG_SOFT_RESET_ACTIVE 0x0001
+#define RBG_SOFT_RESET_RNG_SOFT_RESET_CLEAR 0x
+
+#define RNG_INT_STATUS_OFFSET0x18
+#define RNG_INT_STATUS_MASTER_FAIL_LOCKOUT_IRQ_MASK 0x8000
+#define RNG_INT_STATUS_STARTUP_TRANSITIONS_MET_IRQ_MASK 0x0002
+#define RNG_INT_STATUS_NIST_FAIL_IRQ_MASK0x0020
+#define RNG_INT_STATUS_TOTAL_BITS_COUNT_IRQ_MASK 0x0001
+
+#define RNG_FIFO_DATA_OFFSET 0x20
+
+#define RNG_FIFO_COUNT_OFFSET0x24
+#define RNG_FIFO_COUNT_RNG_FIFO_COUNT_MASK 0x00FF
+
+static void iproc_rng200_restart(void __iomem *rng_base)
+{
+ uint32_t val;
+
+ /* Disable RBG */
+ val = ioread32(rng_base + RNG_CTRL_OFFSET);
+ val = ~RNG_CTRL_RNG_RBGEN_MASK;
+ val |= RNG_CTRL_RNG_RBGEN_DISABLE;
+ iowrite32(val, rng_base + RNG_CTRL_OFFSET);
+
+ /* Clear all interrupt status */
+ iowrite32(0xUL, rng_base + RNG_INT_STATUS_OFFSET);
+
+ /* Reset RNG and RBG */
+ val = ioread32(rng_base + RBG_SOFT_RESET_OFFSET);
+ val = ~RBG_SOFT_RESET_RNG_SOFT_RESET_MASK;
+ val |= RBG_SOFT_RESET_RNG_SOFT_RESET_ACTIVE;
+ iowrite32(val, rng_base + RBG_SOFT_RESET_OFFSET);
+
+ val = ioread32(rng_base +
Re: [PATCH v5 0/6] hwmon: thermal: Odroid U3: Provide support for Odroid U3 fan
On Wed, Feb 25, 2015 at 02:29:18PM -0400, Eduardo Valentin wrote: Guenter, On Wed, Feb 25, 2015 at 09:18:20AM -0800, Guenter Roeck wrote: On Wed, Feb 25, 2015 at 04:34:16PM +0100, Lukasz Majewski wrote: Presented patches add support for Odroid's U3 optional CPU FAN, which uses PWM subsystem for low level control. After successful probe it registers itself as a cooling device for thermal subsystem. This driver also supports devices without DTS specified. To provide correct functionality, new properties to device tree description for Exynos4412 and in particular Odroid U3 have been added. Those patches were tested at Exynos4412 - Odroid U3 board. Patches were applied on: linux-soc-thermal/fixes branch (Linux v4.0-rc1) SHA1: b71d399c7f2fe06b60b96155ec0b9ae167334e4a Kamil Debski (1): ARM: dts: Add pwm-fan node to the Odroid-U3 board Lukasz Majewski (5): Documentation: dts: Documentation entry to explain how to use PWM FAN as a cooling device ARM: dts: Add properties to use pwm-fan device as a cooling device in Odroid U3 hwmon: pwm-fan: Extract __set_pwm() function to only modify PWM duty cycle hwmon: pwm-fan: Read PWM FAN configuration from device tree hwmon: pwm-fan: Code for using PWM FAN as a cooling device .../devicetree/bindings/hwmon/pwm-fan.txt | 25 +++- arch/arm/boot/dts/exynos4.dtsi | 2 +- arch/arm/boot/dts/exynos4412-odroidu3.dts | 43 ++ drivers/hwmon/pwm-fan.c| 166 +++-- 4 files changed, 220 insertions(+), 16 deletions(-) For the series: Acked-by: Guenter Roeck li...@roeck-us.net Should I take it through hwmon ? Might make sense given the majority of the changes is in hwmon code. I believe the series should go via your tree, yes. I had only minor comments in the code added for the cooling device code, as it lacks the unregistration call in the .remove callback. Also, the DTS changes may generate conflicts with platform code. Lukasz may probably ask Kukjin Kim to add them via the samsung tree. Ok, I'll wait for the updated patch and then add the hwmon parts to hwmon-next. Thanks, 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/1] Documentation/sysctl/kernel.txt: header
On Wed, Feb 25, 2015 at 10:43 AM, Heinrich Schuchardt xypron.g...@gmx.de wrote: The header of Documentation/sysctl/kernel.txt should not refer to Linux 2.2 because most of the lines were changed after that release. The authors that placed a copyright notice produced less than half of the lines. So give credit to the other authors. Replace legal blurb by a more precise term. Signed-off-by: Heinrich Schuchardt xypron.g...@gmx.de Seems right to me. :) Acked-by: Kees Cook keesc...@chromium.org Thanks! -Kees --- Documentation/sysctl/kernel.txt | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt index 83ab256..999df6b 100644 --- a/Documentation/sysctl/kernel.txt +++ b/Documentation/sysctl/kernel.txt @@ -1,13 +1,16 @@ -Documentation for /proc/sys/kernel/* kernel version 2.2.10 +Documentation for /proc/sys/kernel/* + (c) 1998, 1999, Rik van Riel r...@nl.linux.org (c) 2009,Shen Fengs...@cn.fujitsu.com -For general info and legal blurb, please look in README. +For other authors see the commit history. + +For general info and disclaimer, please look in README. == This file contains documentation for the sysctl files in -/proc/sys/kernel/ and is valid for Linux kernel version 2.2. +/proc/sys/kernel/. The files in this directory can be used to tune and monitor miscellaneous and general things in the operation of the Linux -- 2.1.4 -- Kees Cook Chrome OS Security -- 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] mmc: dw_mmc: Only enable CD after setup and only if needed
Hello Doug, On 02/25/2015 07:11 PM, Doug Anderson wrote: We really don't want to get a card detect interrupt during probe time since it can confuse things. Let's disable the card detect interrupt until we're in a really good place: the end of probe. Let's also simply avoid enabling the card detect interrupt if it's not used. It appears that (at least on rk3288) when vqmmc is turned on it can cause a bogus card detect interrupt. That meant that we were getting a predictable card detect interrupt while we were in mmc_add_host(). On the version of the kernel I'm working with at least (3.14), this is not a great time to get a card detect interrupt since I think that we don't grab all the needed locks in mmc_add_host() and children. I put stack dumps in dw_mci_setup_bus() and found that I could see two distinct stack crawls that looked like: Caller one: * dw_mci_setup_bus * dw_mci_set_ios * mmc_power_up * mmc_start_host * mmc_add_host Caller two: * dw_mci_setup_bus * dw_mci_set_ios * mmc_set_chip_select * mmc_go_idle * mmc_rescan * process_one_work * worker_thread * kthread Signed-off-by: Doug Anderson diand...@chromium.org On an Exynos5250 Snow, Exynos5420 Peach Pit and Exynos5800 Peach Pi: Tested-by: Javier Martinez Canillas javier.marti...@collabora.co.uk Best regards, Javier -- 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/2] hwrng: iproc-rng200 - Add Broadcom IPROC RNG driver
On Wednesday 25 February 2015 10:16:24 Scott Branden wrote:
This adds a driver for random number generator present on Broadcom
IPROC devices.
Reviewed-by: Ray Jui r...@broadcom.com
Signed-off-by: Scott Branden sbran...@broadcom.com
The driver looks reasonable overall, I have just one question about
something that sticks out:
+ while ((num_remaining 0) time_before(jiffies, idle_endtime)) {
...
+
+ /* Are there any random numbers available? */
+ if ((ioread32(rng_base + RNG_FIFO_COUNT_OFFSET)
+ RNG_FIFO_COUNT_RNG_FIFO_COUNT_MASK) 0) {
...
+ } else {
+ if (!wait)
+ /* Cannot wait, return immediately */
+ return max - num_remaining;
+
+ /* Can wait, give others chance to run */
+ cpu_relax();
+ }
+ }
+
It looks like you do a busy-loop around cpu_relax here if asked to wait.
Is this intentional? I would normally expect either cond_resched() or
some msleep() instead.
Arnd
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 0/4] Add pinctrl support to Broadcom Cygnus SoC
On Tue, Feb 03, 2015 at 06:09:57PM -0800, Ray Jui wrote: This patchset contains the initial pinctrl (IOMUX) support for the Broadcom Cygnus SoC. The Cygnus IOMUX controller supports group based mux configuration and allows certain pins to be muxed to GPIO function individually Changes from v3: - Fix the driver to have more proper use of const in various places - Other minor improvements Changes from v2: - Consolidate all Broadcom pinctrl drivers into drivers/pinctrl/bcm/* - Change the Cygnus IOMUX driver to use standard Linux pinctrl subnode properties such as function and groups for pinmux configuration, instead of non-standard properties such as brcm,function and brcm,group - Use real function names like spi0, lcd, key, and etc. instead of HW specific mux names like alt1, alt2, alt3, and etc. - Add suffix grp to all group names - Add support to allow individual pins to be muxed to GPIO function through subsystem callbacks gpio_request_enable and gpio_disable_free, and get rid of all GPIO groups - Other minor improvements in the driver Changes from v1: - Fix a typo in device tree binding document FWIW I tested this series on BCM958305K SVK. Tested-by: Dmitry Torokhov d...@chromium.org Thanks. -- Dmitry -- 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/2] mmc: dw_mmc: Only enable CD after setup and only if needed
We really don't want to get a card detect interrupt during probe time
since it can confuse things. Let's disable the card detect interrupt
until we're in a really good place: the end of probe. Let's also
simply avoid enabling the card detect interrupt if it's not used.
It appears that (at least on rk3288) when vqmmc is turned on it can
cause a bogus card detect interrupt. That meant that we were
getting a predictable card detect interrupt while we were in
mmc_add_host(). On the version of the kernel I'm working with at
least (3.14), this is not a great time to get a card detect interrupt
since I think that we don't grab all the needed locks in
mmc_add_host() and children. I put stack dumps in dw_mci_setup_bus()
and found that I could see two distinct stack crawls that looked like:
Caller one:
* dw_mci_setup_bus
* dw_mci_set_ios
* mmc_power_up
* mmc_start_host
* mmc_add_host
Caller two:
* dw_mci_setup_bus
* dw_mci_set_ios
* mmc_set_chip_select
* mmc_go_idle
* mmc_rescan
* process_one_work
* worker_thread
* kthread
Signed-off-by: Doug Anderson diand...@chromium.org
---
drivers/mmc/host/dw_mmc.c | 41 ++---
1 file changed, 38 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 4d2e3c2..8df2a92 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -2574,6 +2574,34 @@ static struct dw_mci_board *dw_mci_parse_dt(struct
dw_mci *host)
}
#endif /* CONFIG_OF */
+static void dw_mci_enable_cd(struct dw_mci *host)
+{
+ struct dw_mci_board *brd = host-pdata;
+ unsigned long irqflags;
+ u32 temp;
+ int i;
+
+ /* No need for CD if broken card detection */
+ if (brd-quirks DW_MCI_QUIRK_BROKEN_CARD_DETECTION)
+ return;
+
+ /* No need for CD if all slots have a non-error GPIO */
+ for (i = 0; i host-num_slots; i++) {
+ struct dw_mci_slot *slot = host-slot[i];
+
+ if (IS_ERR_VALUE(mmc_gpio_get_cd(slot-mmc)))
+ break;
+ }
+ if (i == host-num_slots)
+ return;
+
+ spin_lock_irqsave(host-irq_lock, irqflags);
+ temp = mci_readl(host, INTMASK);
+ temp |= SDMMC_INT_CD;
+ mci_writel(host, INTMASK, temp);
+ spin_unlock_irqrestore(host-irq_lock, irqflags);
+}
+
int dw_mci_probe(struct dw_mci *host)
{
const struct dw_mci_drv_data *drv_data = host-drv_data;
@@ -2747,13 +2775,13 @@ int dw_mci_probe(struct dw_mci *host)
host-num_slots = ((mci_readl(host, HCON) 1) 0x1F) + 1;
/*
-* Enable interrupts for command done, data over, data empty, card det,
+* Enable interrupts for command done, data over, data empty,
* receive ready and error such as transmit, receive timeout, crc error
*/
mci_writel(host, RINTSTS, 0x);
mci_writel(host, INTMASK, SDMMC_INT_CMD_DONE | SDMMC_INT_DATA_OVER |
SDMMC_INT_TXDR | SDMMC_INT_RXDR |
- DW_MCI_ERROR_FLAGS | SDMMC_INT_CD);
+ DW_MCI_ERROR_FLAGS);
mci_writel(host, CTRL, SDMMC_CTRL_INT_ENABLE); /* Enable mci interrupt
*/
dev_info(host-dev, DW MMC controller at irq %d,
@@ -2770,6 +2798,9 @@ int dw_mci_probe(struct dw_mci *host)
init_slots++;
}
+ /* Now that slots are all setup, we can enable card detect */
+ dw_mci_enable_cd(host);
+
if (init_slots) {
dev_info(host-dev, %d slots initialized\n, init_slots);
} else {
@@ -2864,7 +2895,7 @@ int dw_mci_resume(struct dw_mci *host)
mci_writel(host, RINTSTS, 0x);
mci_writel(host, INTMASK, SDMMC_INT_CMD_DONE | SDMMC_INT_DATA_OVER |
SDMMC_INT_TXDR | SDMMC_INT_RXDR |
- DW_MCI_ERROR_FLAGS | SDMMC_INT_CD);
+ DW_MCI_ERROR_FLAGS);
mci_writel(host, CTRL, SDMMC_CTRL_INT_ENABLE);
for (i = 0; i host-num_slots; i++) {
@@ -2876,6 +2907,10 @@ int dw_mci_resume(struct dw_mci *host)
dw_mci_setup_bus(slot, true);
}
}
+
+ /* Now that slots are all setup, we can enable card detect */
+ dw_mci_enable_cd(host);
+
return 0;
}
EXPORT_SYMBOL(dw_mci_resume);
--
2.2.0.rc0.207.ga3a616c
--
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 0/2] Add support for Broadcom RNG200
This series of patchsets contains the Broadcom Random Number Generator driver and device tree binding documentation. Changes from v1: added \n to 2 dev_err messages Scott Branden (2): hwrng: iproc-rng200 - Add device tree bindings hwrng: iproc-rng200 - Add Broadcom IPROC RNG driver .../bindings/hwrng/brcm,iproc-rng200.txt | 12 ++ drivers/char/hw_random/Kconfig | 13 ++ drivers/char/hw_random/Makefile| 1 + drivers/char/hw_random/iproc-rng200.c | 239 + 4 files changed, 265 insertions(+) create mode 100644 Documentation/devicetree/bindings/hwrng/brcm,iproc-rng200.txt create mode 100644 drivers/char/hw_random/iproc-rng200.c -- 2.3.0 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] gpio: support for GPIO forwarding
On Wed, Feb 25, 2015 at 10:34:45AM +0900, Alexandre Courbot wrote: On Wed, Feb 25, 2015 at 5:34 AM, David Cohen david.a.co...@linux.intel.com wrote: Hi, If we decide to go ahead with the solution proposed by this patch for practical reasons (which are good reasons indeed), I still have one problem with its current form. As the discussion highlighted, this is an ACPI problem, so I'd very much like it to be confined to the ACPI GPIO code, to be enabled only when ACPI is, and to use function names that start with acpi_gpio. The current implementation leverages platform lookup, making said lookup less efficient in the process and bringing confusion about its purpose. Although the two processes are indeed similar, they are separate things: one is a legitimate way to map GPIOs, the other is a fixup for broken firmware. I suppose we all agree this is a hackish fix, so let's confine it as much as we can. Are we considering MFD cases hackish as well? i.e. if we have a driver that needs to register children devices and this driver needs to pass GPIO to a child. In that case wouldn't the GPIO be best defined in the child node itself, for the child device's driver to directly probe? In my case [1] I need 2 virtual devices (and more in future) to be part of an USB OTG port control. I call it virtual because they are too simple components connected to no bus and controlled by GPIOs: - a fixed regulator controlled by GPIO - a generic mux controlled by GPIO I'd need to request official ACPI HID for them in order to make them self-sufficient. I can go ahead with this approach, but we have many examples of drivers on upstream that are platform driver expecting to receive gpio via platform data (e.g. extcon-gpio). The ACPI table of some products on market were defined following this concept and won't change anymore. Br, David [1] https://lkml.org/lkml/2015/2/19/411 -- 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: 0001-media-vb2-Fill-vb2_buffer-with-bytesused-from-user.patch
Sudip, On Wed, Feb 25, 2015 at 03:29:22PM +0800, Sudip JAIN wrote: Dear Maintainer, PFA attached patch that prevents user from being returned garbage bytesused value from vb2 framework. Regards, Sudip Jain Patches should never be submitted as attachments, they should be inline. See Documentation/SubmittingPatches for more info. [...] -- - Jeremiah Mahler -- 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] thermal: armada: read stable temp on Armada XP
On 02/25/2015 02:04 PM, Gregory CLEMENT wrote: My conclusions about these registers are based on experimental data. The documentation is very sparse, but the Thermal Manager Control and Status Register looks like the preferred register given the way it is laid out in the public spec. Ezequiel, as you worked on this do you know why we used the Thermal Sensor Status Register instead of the Thermal Manager Control and Status Register ? My first guess is that the giving the name of the registers the 1st one made more sens to use for a thermal sensor. Actually, we based this driver in the vendor bootloader. The specs weren't of much use back then. -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] mmc: dw_mmc: Make sure we only adjust the clock when power is on
Hello Doug, On 02/20/2015 07:57 PM, Doug Anderson wrote: It appears that we can confuse things if we try to turn on the MMC clock when the power is off. Adjust is so that we turn the clock on (using dw_mci_setup_bus) after power is all the way on and we turn the clock off before the power goes off. Signed-off-by: Doug Anderson diand...@chromium.org On an Exynos5250 Snow, Exynos5420 Peach Pit and Exynos5800 Peach Pi: Tested-by: Javier Martinez Canillas javier.marti...@collabora.co.uk Best regards, Javier -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 0/6] hwmon: thermal: Odroid U3: Provide support for Odroid U3 fan
Guenter, On Wed, Feb 25, 2015 at 09:18:20AM -0800, Guenter Roeck wrote: On Wed, Feb 25, 2015 at 04:34:16PM +0100, Lukasz Majewski wrote: Presented patches add support for Odroid's U3 optional CPU FAN, which uses PWM subsystem for low level control. After successful probe it registers itself as a cooling device for thermal subsystem. This driver also supports devices without DTS specified. To provide correct functionality, new properties to device tree description for Exynos4412 and in particular Odroid U3 have been added. Those patches were tested at Exynos4412 - Odroid U3 board. Patches were applied on: linux-soc-thermal/fixes branch (Linux v4.0-rc1) SHA1: b71d399c7f2fe06b60b96155ec0b9ae167334e4a Kamil Debski (1): ARM: dts: Add pwm-fan node to the Odroid-U3 board Lukasz Majewski (5): Documentation: dts: Documentation entry to explain how to use PWM FAN as a cooling device ARM: dts: Add properties to use pwm-fan device as a cooling device in Odroid U3 hwmon: pwm-fan: Extract __set_pwm() function to only modify PWM duty cycle hwmon: pwm-fan: Read PWM FAN configuration from device tree hwmon: pwm-fan: Code for using PWM FAN as a cooling device .../devicetree/bindings/hwmon/pwm-fan.txt | 25 +++- arch/arm/boot/dts/exynos4.dtsi | 2 +- arch/arm/boot/dts/exynos4412-odroidu3.dts | 43 ++ drivers/hwmon/pwm-fan.c| 166 +++-- 4 files changed, 220 insertions(+), 16 deletions(-) For the series: Acked-by: Guenter Roeck li...@roeck-us.net Should I take it through hwmon ? Might make sense given the majority of the changes is in hwmon code. I believe the series should go via your tree, yes. I had only minor comments in the code added for the cooling device code, as it lacks the unregistration call in the .remove callback. Also, the DTS changes may generate conflicts with platform code. Lukasz may probably ask Kukjin Kim to add them via the samsung tree. BR, Eduardo Valentin Thanks, Guenter signature.asc Description: Digital signature
Re: [PATCH 1/3] x86: Move msr accesses out of line
On Wed, Feb 25, 2015 at 07:20:32PM +0100, Andi Kleen wrote: Also we do quite a few RDMSRs, which are not necessarily serializing. RDMSR is not serializing. Not even WRMSR when to certain ranges, see section 8.3 in the SDM 3A. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. -- -- 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 1/4] mm: throttle MADV_FREE
On Wed, Feb 25, 2015 at 04:11:18PM +0900, Minchan Kim wrote:
On Wed, Feb 25, 2015 at 09:08:09AM +0900, Minchan Kim wrote:
Hi Michal,
On Tue, Feb 24, 2015 at 04:43:18PM +0100, Michal Hocko wrote:
On Tue 24-02-15 17:18:14, Minchan Kim wrote:
Recently, Shaohua reported that MADV_FREE is much slower than
MADV_DONTNEED in his MADV_FREE bomb test. The reason is many of
applications went to stall with direct reclaim since kswapd's
reclaim speed isn't fast than applications's allocation speed
so that it causes lots of stall and lock contention.
I am not sure I understand this correctly. So the issue is that there is
huge number of MADV_FREE on the LRU and they are not close to the tail
of the list so the reclaim has to do a lot of work before it starts
dropping them?
No, Shaohua already tested deactivating of hinted pages to head/tail
of inactive anon LRU and he said it didn't solve his problem.
I thought main culprit was scanning/rotating/throttling in
direct reclaim path.
I investigated my workload and found most of slowness came from swapin.
1) dontneed: 1,612 swapin
2) madvfree: 879,585 swapin
If we find hinted pages were already swapped out when syscall is called,
it's pointless to keep the pages in pte. Instead, free the cold page
because swapin is more expensive than (alloc page + zeroing).
I tested below quick fix and reduced swapin from 879,585 to 1,878.
Elapsed time was
1) dontneed: 6.10user 233.50system 0:50.44elapsed
2) madvfree + below patch: 6.70user 339.14system 1:04.45elapsed
Although it was not good as throttling, it's better than old and
it's orthogoral with throttling so I hope to merge this first
than arguable throttling. Any comments?
diff --git a/mm/madvise.c b/mm/madvise.c
index 6d0fcb8921c2..d41ae76d3e54 100644
--- a/mm/madvise.c
+++ b/mm/madvise.c
@@ -274,7 +274,9 @@ static int madvise_free_pte_range(pmd_t *pmd, unsigned
long addr,
spinlock_t *ptl;
pte_t *pte, ptent;
struct page *page;
+ swp_entry_t entry;
unsigned long next;
+ int rss = 0;
next = pmd_addr_end(addr, end);
if (pmd_trans_huge(*pmd)) {
@@ -293,9 +295,19 @@ static int madvise_free_pte_range(pmd_t *pmd, unsigned
long addr,
for (; addr != end; pte++, addr += PAGE_SIZE) {
ptent = *pte;
- if (!pte_present(ptent))
+ if (pte_none(ptent))
continue;
+ if (!pte_present(ptent)) {
+ entry = pte_to_swp_entry(ptent);
+ if (non_swap_entry(entry))
+ continue;
+ rss--;
+ free_swap_and_cache(entry);
+ pte_clear_not_present_full(mm, addr, pte, tlb-fullmm);
+ continue;
+ }
+
page = vm_normal_page(vma, addr, ptent);
if (!page)
continue;
@@ -326,6 +338,14 @@ static int madvise_free_pte_range(pmd_t *pmd, unsigned
long addr,
set_pte_at(mm, addr, pte, ptent);
tlb_remove_tlb_entry(tlb, pte, addr);
}
+
+ if (rss) {
+ if (current-mm == mm)
+ sync_mm_rss(mm);
+
+ add_mm_counter(mm, MM_SWAPENTS, rss);
+ }
+
This looks make sense, but I'm wondering why it can help and if this can help
real workload. Let me have an example. Say there is 1G memory, workload uses
800M memory with DONTNEED, there should be no swap. With FREE, workload might
use more than 1G memory and trigger swap. I thought the case (DONTNEED doesn't
trigger swap) is more suitable to evaluate the performance of the patch.
Thanks,
Shaohua
--
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] thermal: exynos: Fix wrong control of power down detection mode for Exynos7
On Wed, Feb 25, 2015 at 01:25:08PM +0100, Lukasz Majewski wrote:
Hi Eduardo,
Hi Lukasz,
On Wed, Feb 25, 2015 at 2:33 PM, Lukasz Majewski
l.majew...@samsung.com wrote:
Hi Abhilash,
This patch fixes the wrong control of PD_DET_EN (power down
detection mode) for Exynos7 because exynos7_tmu_control() always
enables the power down detection mode regardless 'on' parameter.
Cc: Zhang Rui rui.zh...@intel.com
Cc: Eduardo Valentin edubez...@gmail.com
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
---
drivers/thermal/samsung/exynos_tmu.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/thermal/samsung/exynos_tmu.c
b/drivers/thermal/samsung/exynos_tmu.c index 933cd80..a60f527
100644 --- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -682,6 +682,7 @@ static void exynos7_tmu_control(struct
platform_device *pdev, bool on)
if (on) {
con |= (1 EXYNOS_TMU_CORE_EN_SHIFT);
+ con |= (1 EXYNOS7_PD_DET_EN_SHIFT);
interrupt_en =
(of_thermal_is_trip_valid(tz, 7)
EXYNOS7_TMU_INTEN_RISE7_SHIFT) |
@@ -704,9 +705,9 @@ static void exynos7_tmu_control(struct
platform_device *pdev, bool on) interrupt_en
EXYNOS_TMU_INTEN_FALL0_SHIFT; } else {
con = ~(1 EXYNOS_TMU_CORE_EN_SHIFT);
+ con = ~(1 EXYNOS7_PD_DET_EN_SHIFT);
interrupt_en = 0; /* Disable all interrupts */
}
- con |= 1 EXYNOS7_PD_DET_EN_SHIFT;
writel(interrupt_en, data-base + EXYNOS7_TMU_REG_INTEN);
writel(con, data-base + EXYNOS_TMU_REG_CONTROL);
Could you test this patch if it isn't introducing any regression on
your HW?
The patch does not cause any regression on exynos7 and seems
logically correct.
Tested-by: Abhilash Kesavan a.kesa...@samsung.com
Eduardo, it is up to you if you prefer to take this fix directly or via
the new thermal-samsung tree ?
From when shall I regard myself as a maintainer? :-)
Yeah. Go ahead and collect it.
Regards,
Abhilash
--
Best regards,
Lukasz Majewski
Samsung RD Institute Poland (SRPOL) | Linux Platform Group
--
Best regards,
Lukasz Majewski
Samsung RD Institute Poland (SRPOL) | Linux Platform Group
signature.asc
Description: Digital signature
Re: [PATCH 1/1] Documentation/sysctl/kernel.txt: header
On Wed, 25 Feb 2015 19:43:17 +0100 Heinrich Schuchardt xypron.g...@gmx.de wrote: +For other authors see the commit history. + +For general info and disclaimer, please look in README. It generally seems fine, but the above text could just as reasonably be put into every file in the tree. How about if we just take it out? Thanks, jon -- 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 v5] kernel/fork.c: new function for max_threads
On 25.02.2015 11:17, Ingo Molnar wrote: * David Rientjes rient...@google.com wrote: The problem is with the structure of your patchset. You want three patches. There's one bugfix patch, a preparation patch, and a feature patch. The bugfix patch should come first so that it can be applied, possibly, to stable kernels and doesn't depend on unnecessary preparation patches for features. 1/3: change the implementation of fork_init(), with commentary, to avoid the divide by zero on certain arches, enforce the limits, and deal with variable types to prevent overflow. This is the most urgent patch and fixes a bug. 2/3: simply extract the fixed fork_init() implementation into a new set_max_threads() in preparation to use it for threads-max, (hint: UINT_MAX and ignored arguments should not appear in this patch), 3/3: use the new set_max_threads() implementation for threads-max with an update to the documentation. I disagree strongly: it's better to first do low-risk cleanups, then do any fix and other changes. This approach has four advantages: - it makes the bug fix more apparent, in the context of an already cleaned up code. - it strengthens the basic principle that 'substantial work should be done on clean code'. - on the off chance that the bugfix introduces problems _upstream_, it's much easier to revert in a late -rc kernel, than to first revert the cleanups. This happens in practice occasionally, so it's not a theoretical concern. - the _backport_ to the -stable kernel will be more robust as well, because under your proposed structure, what gets tested upstream is the fix+cleanup, while the backport will only be the fix, which does not get tested by upstream in isolation. If there's any (unintended) side effect of the cleanup that happens to be an improvement, then we'll break -stable! It is true that this makes backports a tiny bit more involved (2 cherry-picks instead of just one), but -stable kernels can backport preparatory patches just fine, and it's actually an advantage to have -stable kernel code match the upstream version as much as possible. Thanks, Ingo -- Hello David, to my understanding the biggest no-go for you was that patch 1/3 introduces a function argument that is not needed until patch 3/3. Could you accept the sequence proposed by Ingo if I leave away the argument max_threads_suggested in patch 1 and 2 and only introduce it in patch 3? So patch 1/4 will refactor the code that may result in division by zero to new function static void set_max_threads(void). Furthermore it will change the interface of fork_init to void __init fork_init(void). Patch 2/4 keeps the interface static void set_max_threads(void) but corrects the coding using div64_u64. Patch 3/4 changes the interface to static void set_max_threads(unsigned int max_threads_suggested), calls this function in fork_init with value UINT_MAX and calls it when threads-max is set with the user value. Patch 4/4 adds the necessary information about theads-max in Documentation/sysctl/kernel.txt. I would not like to put this in patch 3/4 as Jonathan Corbet uses a separate git tree. Best regards Heinrich -- 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] spi: spidev_test: Added functionalities
This is a patch that add functionalities to the spidev_test tool found
in Documentation/spi/spidev_test.c.
- Cleaned hexadecimal dump
- Added verbose mode to see the transmitting sequence
- Added input buffer from the terminal. Now it is possible to send
string and hexadecimal data as an input parameter:
Example that shows verbose mode and a sending sequence:
root@microZed:~# ./a.out -D /dev/spidev32766.1 -p \x23ab1 -v
spi mode: 0x0
bits per word: 8
max speed: 50 Hz (500 KHz)
TX | 23 61 62 31 __ __ __ __ | #ab1
RX | FF FF FF FF __ __ __ __ |
modified: Documentation/spi/spidev_test.c
Signed-off-by: Adrian Remonda adrianremo...@gmail.com
---
Documentation/spi/spidev_test.c | 118 +---
1 file changed, 98 insertions(+), 20 deletions(-)
diff --git a/Documentation/spi/spidev_test.c b/Documentation/spi/spidev_test.c
index 3a2f9d59edab..7fe5ba4b9072 100644
--- a/Documentation/spi/spidev_test.c
+++ b/Documentation/spi/spidev_test.c
@@ -15,6 +15,7 @@
#include unistd.h
#include stdio.h
#include stdlib.h
+#include string.h
#include getopt.h
#include fcntl.h
#include sys/ioctl.h
@@ -34,24 +35,55 @@ static uint32_t mode;
static uint8_t bits = 8;
static uint32_t speed = 50;
static uint16_t delay;
+static int verbose;
-static void transfer(int fd)
+uint8_t default_tx[] = {
+ 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
+ 0x40, 0x00, 0x00, 0x00, 0x00, 0x95,
+ 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
+ 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
+ 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
+ 0xF0, 0x0D,
+};
+
+uint8_t default_rx[ARRAY_SIZE(default_tx)] = {0, };
+char *input_tx;
+
+static void hexDump(const void *src, size_t length, size_t bLine, char *prefix)
+{
+ int i = 0;
+ char *address = (char *)src;
+ char *line = (char *)address;
+ unsigned char c;
+
+ printf(%s | , prefix);
+ while (length-- 0) {
+ printf(%02X , (unsigned char)*address++);
+ if (!(++i % bLine) || (length == 0 i % bLine)) {
+ if (length == 0) {
+ while (i++ % bLine)
+ printf(__ );
+ }
+ printf( | ); /* right close */
+ while (line address) {
+ c = *line++;
+ printf(%c, (c 33 || c == 255) ? 0x2E : c);
+ }
+ printf(\n);
+ if (length 0)
+ printf(%s | , prefix);
+ }
+ }
+}
+
+static void transfer(int fd, uint8_t const *tx, uint8_t const *rx, size_t len)
{
int ret;
- uint8_t tx[] = {
- 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
- 0x40, 0x00, 0x00, 0x00, 0x00, 0x95,
- 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
- 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
- 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
- 0xDE, 0xAD, 0xBE, 0xEF, 0xBA, 0xAD,
- 0xF0, 0x0D,
- };
- uint8_t rx[ARRAY_SIZE(tx)] = {0, };
+
struct spi_ioc_transfer tr = {
.tx_buf = (unsigned long)tx,
.rx_buf = (unsigned long)rx,
- .len = ARRAY_SIZE(tx),
+ .len = len,
.delay_usecs = delay,
.speed_hz = speed,
.bits_per_word = bits,
@@ -76,27 +108,54 @@ static void transfer(int fd)
if (ret 1)
pabort(can't send spi message);
- for (ret = 0; ret ARRAY_SIZE(tx); ret++) {
- if (!(ret % 6))
- puts();
- printf(%.2X , rx[ret]);
+ if (verbose)
+ hexDump(tx, len, 32, TX);
+ hexDump(rx, len, 32, RX);
+}
+
+/*
+ * Unescape - process hexadecimal escape character
+ * converts shell input \x23 - 0x23
+ */
+int unespcape(char *dst, char *src, size_t len)
+{
+ int ret = 0;
+ char *pSrc = src;
+ char *pDst = dst;
+ unsigned int ch;
+
+ while (*pSrc) {
+ if (*pSrc == '\\' *(pSrc+1) == 'x') {
+ sscanf(pSrc + 2, %2x, ch);
+ pSrc += 4;
+ *pDst++ = (unsigned char)ch;
+ } else {
+ *pDst++ = *pSrc++;
+ }
+
+
+ ret++;
}
- puts();
+ return ret;
+
}
static void print_usage(const char *prog)
{
+
printf(Usage: %s [-DsbdlHOLC3]\n, prog);
puts( -D --device device to use (default /dev/spidev1.1)\n
-s --speedmax speed (Hz)\n
-d --delaydelay (usec)\n
- -b --bpw bits per word \n
+ -b --bpw bits per word\n
-l --loop loopback\n
-H --cpha clock phase\n
-O --cpol clock polarity\n
Re: [PATCH v2] ARM: dts: am335x-bone-common: enable aes and sham
On Wed, Feb 25, 2015 at 12:52 PM, Matt Porter mpor...@konsulko.com wrote: Beaglebone Black doesn't have AES and SHAM enabled like the original Beaglebone White dts. This breaks applications that leverage the crypto blocks so fix this by enabling these nodes in the am335x-bone-common.dtsi. With this change, enabling the nodes in am335x-bone.dts is no longer required so remove them. Signed-off-by: Matt Porter mpor...@konsulko.com Looks good! Wonder why didn't we do this sooner! ;) Acked-by: Robert Nelson robertcnel...@gmail.com Regards, -- Robert Nelson http://www.rcn-ee.com/ -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] Documentation/sysctl/kernel.txt: header
On 25.02.2015 20:01, Jonathan Corbet wrote: On Wed, 25 Feb 2015 19:43:17 +0100 Heinrich Schuchardt xypron.g...@gmx.de wrote: +For other authors see the commit history. Yes I can delete it. + +For general info and disclaimer, please look in README. It generally seems fine, but the above text could just as reasonably be put into every file in the tree. How about if we just take it out? Thanks, jon Most directories in Documentation do not have a README. So refering to it seems ok. I guess the chapter Legal blurb could be deleted from README. That information is already in /COPYING. So maybe we should replace -For general info and legal blurb, please look in README. by +For an overview of sysctl, please look in README. and in a separate patch remove the Legal blurb section from README. Best regards Heinrich -- 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] New of_io_release_and_unmap()
On Wednesday 25 February 2015 11:20:41 Joshua Clayton wrote: Hello folks, I notice that io_request_and_map has no inverse. I would like to add a new function to undo what it does. What do you want to use this for? So far all users are in essential drivers (clk and clocksource) that result in a boot failure if this goes wrong. Normal drivers can probably always use devm_ioremap_resource(), which has an automatic cleanup. Arnd -- 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] serial: 8250_dw: Fix get_mctrl behaviour
On Wednesday 25 February 2015 11:04:16 Jonathan Richardson wrote: +- msr-override : array of strings to be used to override the individual + modem status signals for DCD, DSR, CTS, and RI. If the property is not + present, the individual signals are obtained from the modem status register. + Strings accepted are dcd, dsr, cts, and ri. If dcd, dsr, or + cts are present, these signals will always be reported as active. If + ri is present, this signal will always be reported as inactive. Did you copy this definition from another driver? If not, we should try to come up with a more natural way to do it. How about defining four boolean properties instead, like dcd-override dsr-override cts-override ri-override Simplifies the parser and the binding. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] Thermal SoC management updates for v4.0-rc2
Hello Rui, Please pull from git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal.git fixes to receive Thermal SoC Management updates for v4.0-rc2 with top-most b71d399c7f2fe06b60b96155ec0b9ae167334e4a: thermal: exynos: Clean-up code to use oneline entry for exynos compatible table (2015-02-24 15:00:00 -0400) on top of commit c517d838eb7d07bbe9507871fab3931deccff539: Linux 4.0-rc1 (2015-02-22 18:21:14 -0800) Specifics: - Fixes in RCAR thermal driver to remove race conditions and fix fail path - Fixes in TI thermal driver: removal of unnecessary code and build fix if !CONFIG_PM_SLEEP - Cleanups in exynos thermal driver - Add stubs for include/linux/thermal.h. Now drivers using thermal calls but that also work without CONFIG_THERMAL will be able to compile for systems that don't care about thermal. BR, Eduardo Valentin Chanwoo Choi (1): thermal: exynos: Clean-up code to use oneline entry for exynos compatible table Geert Uytterhoeven (2): thermal: rcar: Fix race condition between init and interrupt thermal: rcar: Make error and remove paths symmetrical with init Grygorii Strashko (1): thermal: ti-soc-thermal: bandgap: Fix build warning if !CONFIG_PM_SLEEP Markus Elfring (1): ti-soc-thermal: Delete an unnecessary check before the function call cpufreq_cooling_unregister Nishanth Menon (1): thermal: Introduce dummy functions when thermal is not defined drivers/thermal/rcar_thermal.c | 26 +- drivers/thermal/samsung/exynos_tmu.c | 38 --- drivers/thermal/ti-soc-thermal/ti-bandgap.c| 2 +- drivers/thermal/ti-soc-thermal/ti-thermal-common.c | 2 +- include/linux/thermal.h| 56 +- 5 files changed, 77 insertions(+), 47 deletions(-) signature.asc Description: Digital signature
Re: [PATCH 2/4] i2c: sunxi: Add Reduced Serial Bus (RSB) DT bindings documentation
On Tuesday 24 February 2015 22:32:57 Chen-Yu Tsai wrote:
On Tue, Feb 24, 2015 at 10:17 PM, Arnd Bergmann a...@arndb.de wrote:
On Tuesday 24 February 2015 22:01:26 Chen-Yu Tsai wrote:
On Tue, Feb 24, 2015 at 6:37 PM, Arnd Bergmann a...@arndb.de wrote:
On Tuesday 24 February 2015 18:29:02 Chen-Yu Tsai wrote:
+ rsb@01f03400 {
+ compatible = allwinner,sun8i-a23-rsb;
+ reg = 0x01f03400 0x400;
+ interrupts = 0 39 4;
+ clocks = apb0_gates 3;
+ clock-frequency = 300;
+ resets = apb0_rst 3;
+
+ axp223: pmic@2d {
+ compatible = x-powers,axp223,
x-powers,axp221;
+ reg = 0x2d;
+ allwinner,rsb-hw-addr = 0x3e3;
+
+ /* ... */
+ };
+ };
I don't really understand the need for having two addresses (runtime
and hardware). Could the runtime address be configured at runtime?
You can, though the driver doesn't support this. I don't think the
I2C subsystem allows arbitrary device insertion during normal
operation, but maybe i2c-dev? I've tried using different addresses
for devices so they do get changed during the probe phase, just
to be sure that the code works, and it's not just sitting at
the address the bootloader used.
In any case, the distinction is more like burnt-in or hardwired
addresses vs software configurable addresses.
The simplest binding would the probably be to only put the
hardware address into the 'reg' property and always assign the
logical addresses dynamically.
Would that add a lot of complexity or does it have any other
downsides?
The hardware address is 12 bits wide. Any address higher than
0x3ff will be rejected by the I2C core. The AC100 is at 0xe89.
Assigning addresses dynamically means the driver has to keep
a lookup table to map the hardware address to the logical
address to issue the command to.
There's also the issue of dynamically assigned address colliding
with unlisted devices, though I think this would only happen in
the development / bring up phase of the device.
I think the first issue pretty much rules out putting the
hardware address into 'reg'.
Putting the logical address in the 'reg' property allows the
user to poke unlisted devices using i2c-tools, though this
is not so useful to the average user.
Ok, fair enough. Your approach seems reasonable then, but it
might be helpful to add your explanation to the changelog of the
patch that introduces the binding.
Arnd
--
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] net/core/dev.c : Race condition in net_tx_action.
On Wed, 2015-02-25 at 19:50 +0200, Ameen Ali wrote:
Transmitting asynchronously on all the network devices available we will
notice the following behaviour:
a) The instruction if (sd-completion_queue) { saves on a CPU register the
pointer value (register contents is used for the comparison)
b) The interupt is disabled (using local_irq_disable)
c) when the content of clist is updated, the register is used, instead of
re-read the completion_queue variable.
So, when a low-level tx interrupt arrives after the latching of
completion_queue, but before local_irq_disable,
the value stored in clist reflect the situation before low-level tx
interrupt, resulting in a sk_buff leak
---
net/core/dev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 8f9710c..db3e59e 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -3413,7 +3413,7 @@ EXPORT_SYMBOL(netif_rx_ni);
static void net_tx_action(struct softirq_action *h)
{
- struct softnet_data *sd = this_cpu_ptr(softnet_data);
+ volatile struct softnet_data *sd = __get_cpu_var(softnet_data);
if (sd-completion_queue) {
struct sk_buff *clist;
Seems real bug is elsewhere. This is becoming a FAQ.
Which arch are you using, and which compiler ?
volatile are highly discouraged in favor of ACCESS_ONCE, READ_ONCE(),
WRITE_ONCE() : read
Documentation/volatile-considered-harmful.txt:19:safe
local_irq_disable() acts as a barrier the compiler should reload the
value from memory.
--
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/3] kernel/sysctl.c: threads-max observe limits
On 24.02.2015 23:20, David Rientjes wrote: On Tue, 24 Feb 2015, Heinrich Schuchardt wrote: Users can change the maximum number of threads by writing to /proc/sys/kernel/threads-max. With the patch the value entered is checked against the same limits that apply when fork_init is called. Correct me if I'm wrong, but this is a change in functionality (without update to Documentation/sysctl/kernel.txt which describes threads-max) since it does not allow the value to be lowered as before from the calculation involving totalram_pages. The value passed to set_max_threads() only caps the value. threads_max is set to the value the user inputs if it is inside the interval [20, FUTEX_TID_MASK] and it is capped by the value calculated from totalram_pages. So lowering and raising is still possible (inside the limits). I believe this information should be added to the documentation cited above which mentions threads-max since users will otherwise be unfamiliar with the limits imposed. Hello David, I guess the documentation fix should be put into a separate patch (of the same patch series) as Jonathan Corbet uses a separate git tree to consolidate documentation changes. Is that ok with you? Best regards Heinrich -- 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] Add a quirk for the Dell XPS 13 (2015) when in PS/2 mode.
On 02/20/2015 02:41 PM, Pali Rohár wrote: On Friday 20 February 2015 20:56:23 Mario Limonciello wrote: resetafter=0 means to never reset (even if driver receive e.g thousand invalid packets). I think this is very dangerous if there will be other bugs either in linux driver or some other HW problems. For ALPS issue I added resetafter = pktsize * 2 (Allow 2 invalid packets without resetting device). Cannot you find something similar for synaptics touchpads on XPS? (pktsize for ALPS is 6, no idea how big are synaptics packets). Pali, I've done some experimentation with increasing the size to resetafter to up to pktsize * 4. It will decrease the number of occurrences of this problem, but the problem still occurs eventually. pktsize for synaptics is 6 as well. Would you recommend to continue to go higher than that? Since out_of_sync_cnt is reset when a full packet gets received, some arbitrarily high number should likely fix it to. That being said, if you try to more closely follow what Windows does for the mouse, it's not issuing a reconnect no matter how much bad data is received. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 3/6] ARM: dts: Add properties to use pwm-fan device as a cooling device in Odroid U3
On Wed, Feb 25, 2015 at 04:34:19PM +0100, Lukasz Majewski wrote:
With those bindings it is possible to use pwm-fan device available in
Odroid U3 as a cooling device.
Signed-off-by: Lukasz Majewski l.majew...@samsung.com
Acked-by: Eduardo Valentin edubez...@gmail.com
---
Changes for v2:
- Rename cooling-pwm-values property to cooling-levels
Changes for v3:
- Change patch's topic to ARM dts
- Reduce maximal cooling-level to 230 from 255
Changes for v4:
- None
Changes for v5:
- None
---
arch/arm/boot/dts/exynos4412-odroidu3.dts | 33
++-
1 file changed, 32 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/exynos4412-odroidu3.dts
b/arch/arm/boot/dts/exynos4412-odroidu3.dts
index 4c04837..abcfa3c 100644
--- a/arch/arm/boot/dts/exynos4412-odroidu3.dts
+++ b/arch/arm/boot/dts/exynos4412-odroidu3.dts
@@ -32,9 +32,40 @@
};
};
- pwm-fan {
+ fan0: pwm-fan {
compatible = pwm-fan;
pwms = pwm 0 1 0;
+ cooling-min-state = 0;
+ cooling-max-state = 3;
+ #cooling-cells = 2;
+ cooling-levels = 0 102 170 230;
+ };
+
+ thermal-zones {
+ cpu_thermal: cpu-thermal {
+ cooling-maps {
+ map0 {
+ trip = cpu_alert1;
+ cooling-device = cpu0 7 7;
+ };
+ map1 {
+ trip = cpu_alert2;
+ cooling-device = cpu0 13 13;
+ };
+ map2 {
+ trip = cpu_alert0;
+ cooling-device = fan0 0 1;
+ };
+ map3 {
+ trip = cpu_alert1;
+ cooling-device = fan0 1 2;
+ };
+ map4 {
+ trip = cpu_alert2;
+ cooling-device = fan0 2 3;
+ };
+ };
+ };
};
};
--
2.0.0.rc2
signature.asc
Description: Digital signature
Re: [PATCH v1 4/7] thermal: introduce the Power Allocator governor
On Wed, Feb 25, 2015 at 02:48:49PM +, Javi Merino wrote: Hi Eduardo, On Tue, Feb 24, 2015 at 06:21:26PM +, Eduardo Valentin wrote: On Wed, Jan 28, 2015 at 05:00:35PM +, Javi Merino wrote: + +k_d +--- + +`k_d` configures the PID loop's derivative term constant. It's +recommended to leave it as the default: 0. + I know we are considering K_d = 0. However, ... yet another big cut + /* + * Calculate the derivative term + * + * We do err - prev_err, so with a positive k_d, a decreasing + * error (i.e. driving closer to the line) results in less + * power being applied, slowing down the controller) + */ + d = mul_frac(tz-tzp-k_d, err - params-prev_err); ... Shouldn't the above d component consider the rate of changes over time of the error? I would expect you should do: d = k_d * (dE / dt) or d = K_d * ((err - params-prev_err) / sampling_period) in plain C: + d = mul_frac(tz-tzp-k_d, err - params-prev_err); + d /= tz-passive_polling; /* might require fixed point division */ Could do. To be honest, both k_d and passive_polling are constants so Yes, I agree that they are constants. But if you deploy the thermal zone with different sampling period on different devices, then the behavior will change. I don't think you get anything by doing this other than the added complexity of the fixed point division. As you said, the default k_d is 0, so I'm not strongly against it. OK. Then I would prefer to add the division, as it makes the code aligned to the concept. Cheers, Javi signature.asc Description: Digital signature
Re: [PATCH] rcu: Remove reduplicate check of cpu_online
On Wed, Feb 25, 2015 at 05:09:46PM +0800, Yao Dongdong wrote: The calling function invoke_rcu_core will check it. Signed-off-by: Yao Dongdong yaodongd...@huawei.com Hmmm... That is a fastpath, but invoke_rcu_core() is visible to the compiler, which should inline anyway. I took this patch for 4.1, but updated the title and commit log as follows: rcu: Remove redundant check of cpu_online() Because invoke_cpu_core() checks whether the current CPU is online, there is no need for __call_rcu_core() to redundantly check it. There should not be any performance degradation because the called function is visible to the compiler. This commit therefore removes the redundant check. Thanx, Paul --- kernel/rcu/tree.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c index 48d640c..e5f9b7e 100644 --- a/kernel/rcu/tree.c +++ b/kernel/rcu/tree.c @@ -2741,7 +2741,7 @@ static void __call_rcu_core(struct rcu_state *rsp, struct rcu_data *rdp, * If called from an extended quiescent state, invoke the RCU * core in order to force a re-evaluation of RCU's idleness. */ - if (!rcu_is_watching() cpu_online(smp_processor_id())) + if (!rcu_is_watching()) invoke_rcu_core(); /* If interrupts were disabled or CPU offline, don't invoke RCU core. */ -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] serial: 8250_dw: Fix get_mctrl behaviour
Fixed behaviour of get_mctrl() serial driver function as documented in:
https://www.kernel.org/doc/Documentation/serial/driver
Added device-tree property 'msr-override' specific to the Synopsis 8250
DesignWare UART driver. Allows one to force Data Carrier Detect,
Clear To Send, and Data Set Ready signals to permanently be reported as
active. The Ring indicator can be forced to be reported as inactive.
It is possible that if modem control signalling is enabled on a port
that doesn't have these pins (e.g. - a simple two wire Tx/Rx port), the
driver can hang indefinitely waiting for the state to change. The new
DT properties allow the driver to ignore the state of these pins on
serial ports that don't support them, as recommended in the kernel
documentation.
Reviewed-by: JD (Jiandong) Zheng jdzh...@broadcom.com
Reviewed-by: Jonathan Richardson jonat...@broadcom.com
Reviewed-by: Scott Branden sbran...@broadcom.com
Tested-by: Scott Branden sbran...@broadcom.com
Tested-by: Jonathan Richardson jonat...@broadcom.com
Signed-off-by: Jonathan Richardson jonat...@broadcom.com
---
.../bindings/serial/snps-dw-apb-uart.txt |7
drivers/tty/serial/8250/8250_dw.c | 41
2 files changed, 48 insertions(+)
diff --git a/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.txt
b/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.txt
index 7f76214..010e52b 100644
--- a/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.txt
+++ b/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.txt
@@ -21,6 +21,12 @@ Optional properties:
- reg-io-width : the size (in bytes) of the IO accesses that should be
performed on the device. If this property is not present then single byte
accesses are used.
+- msr-override : array of strings to be used to override the individual
+ modem status signals for DCD, DSR, CTS, and RI. If the property is not
+ present, the individual signals are obtained from the modem status register.
+ Strings accepted are dcd, dsr, cts, and ri. If dcd, dsr, or
+ cts are present, these signals will always be reported as active. If
+ ri is present, this signal will always be reported as inactive.
Example:
@@ -31,6 +37,7 @@ Example:
interrupts = 10;
reg-shift = 2;
reg-io-width = 4;
+ msr-override = dcd, dsr, cts, ri
};
Example with one clock:
diff --git a/drivers/tty/serial/8250/8250_dw.c
b/drivers/tty/serial/8250/8250_dw.c
index 555de07..06dc873 100644
--- a/drivers/tty/serial/8250/8250_dw.c
+++ b/drivers/tty/serial/8250/8250_dw.c
@@ -59,6 +59,8 @@ struct dw8250_data {
u8 usr_reg;
int last_mcr;
int line;
+ int msr_mask_on;
+ int msr_mask_off;
struct clk *clk;
struct clk *pclk;
struct reset_control*rst;
@@ -81,6 +83,12 @@ static inline int dw8250_modify_msr(struct uart_port *p, int
offset, int value)
value = ~UART_MSR_DCTS;
}
+ /* Override any modem control signals if needed */
+ if (offset == UART_MSR) {
+ value |= d-msr_mask_on;
+ value = ~d-msr_mask_off;
+ }
+
return value;
}
@@ -290,6 +298,8 @@ static int dw8250_probe_of(struct uart_port *p,
u32 val;
bool has_ucv = true;
int id;
+ int msr_cnt, i;
+ const char *inp_name;
#ifdef CONFIG_64BIT
if (of_device_is_compatible(np, cavium,octeon-3860-uart)) {
@@ -334,6 +344,37 @@ static int dw8250_probe_of(struct uart_port *p,
if (id = 0)
p-line = id;
+ msr_cnt = of_property_count_strings(np, msr-override);
+
+ if (msr_cnt 0) {
+ for (i = 0; i msr_cnt; i++) {
+ of_property_read_string_index(np, msr-override, i,
+ inp_name);
+
+ if (!strcmp(dcd, inp_name)) {
+ /* Always report DCD as active */
+ data-msr_mask_on |= UART_MSR_DCD;
+ data-msr_mask_off |= UART_MSR_DDCD;
+ } else if (!strcmp(dsr, inp_name)) {
+ /* Always report DSR as active */
+ data-msr_mask_on |= UART_MSR_DSR;
+ data-msr_mask_off |= UART_MSR_DDSR;
+ } else if (!strcmp(cts, inp_name)) {
+ /* Always report CTS as active */
+ data-msr_mask_on |= UART_MSR_CTS;
+ data-msr_mask_off |= UART_MSR_DCTS;
+ } else if (!strcmp(ri, inp_name)) {
+ /* Always report Ring indicator as inactive */
+
Re: [PATCH v5 1/6] Documentation: dts: Documentation entry to explain how to use PWM FAN as a cooling device
On Wed, Feb 25, 2015 at 03:11:24PM -0400, Eduardo Valentin wrote:
On Wed, Feb 25, 2015 at 04:34:17PM +0100, Lukasz Majewski wrote:
Explanation of several properties, which allow PWM fan working as a cooling
device, have been embraced in this commit.
Signed-off-by: Lukasz Majewski l.majew...@samsung.com
---
Changes for v2:
- Rename cooling-pwm-values to cooling-levels
- Remove default-pulse-width property and stick to default hwmon policy
Changes for v3:
- Changing commit title from hwmon: dts: Doc: to Documentation: dts
- Remove unnecessary properties
- Set maximal cooling level to 230 instead of 255
Changes for v4:
- None
Changes for v5:
- Move thermal-zones description to example section
- Extending example section
---
.../devicetree/bindings/hwmon/pwm-fan.txt | 25
+-
1 file changed, 24 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/hwmon/pwm-fan.txt
b/Documentation/devicetree/bindings/hwmon/pwm-fan.txt
index 610757c..645251b 100644
--- a/Documentation/devicetree/bindings/hwmon/pwm-fan.txt
+++ b/Documentation/devicetree/bindings/hwmon/pwm-fan.txt
@@ -3,10 +3,33 @@ Bindings for a fan connected to the PWM lines
Required properties:
- compatible : pwm-fan
- pwms : the PWM that is used to control the PWM fan
+- cooling-levels : PWM duty cycle values in a range from 0 to 255
+ which correspond to thermal cooling states
Example:
- pwm-fan {
+ fan0: pwm-fan {
compatible = pwm-fan;
status = okay;
pwms = pwm 0 1 0;
+ cooling-levels = 0 102 170 230;
+ };
+
+ thermal-zones {
+ cpu_thermal: cpu-thermal {
+ cooling-min-state = 0;
+ cooling-max-state = 3;
+ #cooling-cells = 2;
+ trips {
+ cpu_alert1: cpu-alert1 {
+ temperature = 10; /* millicelsius */
+ hysteresis = 2000; /* millicelsius */
+ type = passive;
+ };
+ };
+ cooling-maps {
+ map0 {
+trip = cpu_alert1;
+cooling-device = fan0 0 1;
+ };
+ };
The above example has two issues:
(1) it is wrong, as the cooling device properties are in the thermal
zone node.
(2) has a misalignment / tabulation
Can you please fix that in your next version too?
Apart from the above two issues you may add my
Acked-by: Eduardo Valentin edubez...@gmail.com
};
--
2.0.0.rc2
signature.asc
Description: Digital signature
Re: [PATCH v5 0/6] Add common clock support for Broadcom iProc architecture
On Wed, Feb 04, 2015 at 04:54:59PM -0800, Ray Jui wrote: This patchset contains the initial common clock support for Broadcom's iProc family of SoCs. The iProc clock architecture comprises of various PLLs, e.g., ARMPLL, GENPLL, LCPLL0, MIPIPLL, and etc. An onboard crystal serves as the basic reference clock for these PLLs. Each PLL may have several leaf clocks. One special group of clocks is the ASIU clocks, which are dervied directly from the crystal reference clock. This patchset also contains the basic clock support for the Broadcom Cygnus SoC, which implements the iProc clock architecture Changes from v4: - Add of_clk_get_parent_rate helper function into the clock framework - Switch to use of_clk_get_parent_rate in the iProc PLL clock driver Changes from v3: - Fix incorrect use of passing in of_clk_src_onecell_get when adding ARM PLL and other iProc PLLs as clock provider. These PLLs have zero cells in DT and thefore of_clk_src_simple_get should be used instead - Rename Cygnus MIPI PLL Channel 2 clock from BCM_CYGNUS_MIPIPLL_CH2_UNUSED to BCM_CYGNUS_MIPIPLL_CH2_V3D, since a 3D graphic rendering engine has been integrated into Cygnus revision B0 and has its core clock running off MIPI PLL Channel 2 - Changed default MIPI PLL VCO frequency from 1.75 GHz to 2.1 GHz. This allows us to derive 300 MHz V3D clock from channel 2 through the post divisor Changes from v2: - Re-arrange Cygnus clock/pll init functions so each init function is right next to its clock table - Removed #defines for number of clocks in Cygnus. Have the number of clocks automatically determined based on array size of the clock table Changes from v1: - Separate drivers/clk/Makefile change for drivers/clk/bcm out to a standalone patch FWIW I tested this series on BCM958305K SVK. Tested-by: Dmitry Torokhov d...@chromium.org Thanks. -- Dmitry -- 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] ipc/sem.c: Add one more memory barrier to sem_lock().
Hi,
What do you think about the following patch for sem_lock()?
Other options:
1) I don't like
#define smp_mb__after_unlock_wait() smp_rmb()
I think it is too specific: the last block in sem_lock uses
if (sma-complex_count == 0) {
smp_rmb();
return;
}
2) What about
#define smp_aquire__after_control_barrier() smp_rmb()
Best regards,
Manfred
x
sem_lock() does not properly pair memory barriers.
Theoretially an acquire barrier would the right operation.
But since the existing control boundary is a write memory barrier,
it is cheaper use an smp_rmb().
Signed-off-by: Manfred Spraul manf...@colorfullife.com
---
ipc/sem.c | 26 +-
1 file changed, 25 insertions(+), 1 deletion(-)
diff --git a/ipc/sem.c b/ipc/sem.c
index 9284211..d43011d 100644
--- a/ipc/sem.c
+++ b/ipc/sem.c
@@ -267,6 +267,10 @@ static void sem_wait_array(struct sem_array *sma)
if (sma-complex_count) {
/* The thread that increased sma-complex_count waited on
* all sem-lock locks. Thus we don't need to wait again.
+*
+* The is no need for memory barriers: with
+* complex_count0, all threads acquire/release
+* sem_perm.lock, thus spin_lock/unlock is the barrier.
*/
return;
}
@@ -275,6 +279,20 @@ static void sem_wait_array(struct sem_array *sma)
sem = sma-sem_base + i;
spin_unlock_wait(sem-lock);
}
+ /*
+* We own sem_perm.lock, all owners of sma-sem_base[i].lock have
+* dropped their locks. But we still need a memory barrier:
+* - The lock dropping thread did a spin_unlock(), which is the
+* release memory barrier.
+* - But the spin_unlock(sma-sem_base[i].lock) might have
+* happened after this thread did spin_lock(sma-sem_perm.lock),
+* thus the acquire memory barrier in this thread is missing.
+* - spin_unlock_wait() is internally a loop, thus we have a control
+* boundary. As writes are not speculated, we have already a barrier
+* for writes. Reads can be performed speculatively, therefore a
+* smp_rmb() is necessary.
+*/
+ smp_rmb();
}
/*
@@ -341,7 +359,13 @@ static inline int sem_lock(struct sem_array *sma, struct
sembuf *sops,
* Thus: if is now 0, then it will stay 0.
*/
if (sma-complex_count == 0) {
- /* fast path successful! */
+ /*
+* Fast path successful!
+* We only need a final memory barrier.
+* (see sem_wait_array() for details).
+*/
+ smp_rmb();
+
return sops-sem_num;
}
}
--
2.1.0
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] mmc: dw_mmc: Don't crash if we get an interrupt before slot has initted
It's unlikely that this is really needed on any single-slot systems
where we disable card detects until the end of probe, but it still
seems safer to check to make sure that a slot has been initted before
we try to dereference it to find the SDIO interrupt mask.
Signed-off-by: Doug Anderson diand...@chromium.org
---
drivers/mmc/host/dw_mmc.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 8df2a92..1c909ad 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -2156,6 +2156,10 @@ static irqreturn_t dw_mci_interrupt(int irq, void
*dev_id)
/* Handle SDIO Interrupts */
for (i = 0; i host-num_slots; i++) {
struct dw_mci_slot *slot = host-slot[i];
+
+ if (!slot)
+ continue;
+
if (pending SDMMC_INT_SDIO(slot-sdio_id)) {
mci_writel(host, RINTSTS,
SDMMC_INT_SDIO(slot-sdio_id));
--
2.2.0.rc0.207.ga3a616c
--
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] mmc: dw_mmc: Don't start commands while busy
Hello Doug, On 02/20/2015 09:31 PM, Doug Anderson wrote: We've seen problems on some WiFi modules where we seem to send a CMD53 (which requires the data lines) while the module is asserting busy. We shouldn't do that. The Designware Databook says that before issuing a new data transfer command we should check for busy, so that's what we'll do. We'll leverage the existing dw_mmc knowledge about whether it should wait for the previous command to finish to know whether we should check for busy before sending the command. This means we won't end up incorrectly waiting for things like CMD52 (SDIO) or CMD13 (SD) which don't use the data line. Note that this also has the advantage of making sure that we don't change the clock while the card is busy, too. Signed-off-by: Doug Anderson diand...@chromium.org On an Exynos5250 Snow, Exynos5420 Peach Pit and Exynos5800 Peach Pi: Tested-by: Javier Martinez Canillas javier.marti...@collabora.co.uk Best regards, Javier -- 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] drm/i915: fix failure to power off after hibernate
On ti, 2015-02-24 at 20:00 +0100, Bjørn Mork wrote: Imre Deak imre.d...@intel.com writes: The poweroff handlers undo the actions of the thaw handlers. As the original commit stated saving the registers is not needed there, but it's also not a big overhead and there should be no problem doing it. We are planning to optimize the hibernation sequence by for example not shutting down the display between freeze and thaw, and also getting rid of unnecessary steps at the power off phase. But before that we want to actually unify things rather than having special cases, as maintaining the special code paths caused already quite a lot of problems for us so far. That sounds like a worthy goal. I don't understand what you hope to achieve by having a poweroff_late hook, since there aren't really anything useful left to do at the point it is called, but if you want a dummy callback there for code structure reasons then fine. There are the following reasons for shutting down the device properly during hibernation: - ACPI mandates that the OSPM (the kernel in our case) puts all devices into D3 that are not wake-up sources (i915 is not) (Kudos to Ville for pointing this out) - Embedded panels have a well defined shutdown sequence. We don't have any good reason to not follow this, in fact for some panels the subsequent reinitialization could be problematic in case of a hard power-off. (Thanks to Jani for this info) In fact the only reason why we didn't put the device into PCI D3 before the patch you bisected, is kind of arbitrary. The PCI core puts every device into D3 unless its driver saves the device's PCI state on its own. Since before that patch we did save the state, but haven't put the device into D3 it stayed in D0. That was definitely not intentional and as such we depended on the BIOS to correct this for us afterwards. But you cannot just run around breaking stuff while slowly moving towards this goal over multiple releases... v3.19 is currently broken and that seems totally unnecessary. In any case: You should have noticed this problem while testing your patches. The breakage is 100% reproducible. Unfortunately I had to do a bisect to realize what you had done to the i915 driver, something I unfortunately didn't find time to do before v3.19 was released. But I do find it unnecessary to release with such bugs. Any attempt to exercise the code path you modified would have revealed the bug. We tested these patches on numerous platforms and haven't seen the issue you reported. Based on your feedback the current assumption is that this is a bug in your BIOS, which tries to access the device despite it being powered down. We're trying our best to test each change we commit on a big set of platforms, but - especially on older hardware with random BIOS versions/configurations - full coverage is not possible. So we depend on reports like yours a lot to fill in the gaps. Reverting the commit may hide some other issue, so before doing that could you try the following patch: http://lists.freedesktop.org/archives/intel-gfx/2015-February/060529.html Makes no difference. I assume that patch fixes an unrelated bug? The age and reported symptoms indicates so. Note that I am reporting a regression introduced after v3.18, while that seems to fix a bug introduced in v3.17. Both v3.17 and v3.18 (including v3.18.6), as well as earlier releases, work fine for me. Ok, thanks for trying. If with that you still get the hang could you try on top of that the patch below, first having only pci_set_power_state uncommented, then both pci_set_power_state and pci_disable_device uncommented? That patch fixes the problem, with only pci_set_power_state commented out. Do you still want me to try with pci_disable_device() commented out as well? No, but it would help if you could still try the two attached patch separately, without any of the previous workarounds. Based on the result, we'll follow up with a fix that adds for your specific platform either of the attached workarounds or simply avoids putting the device into D3 (corresponding to the patch you already tried). Thanks, Imre From fe8b90c976f14eab80cb6715d0405157163d316e Mon Sep 17 00:00:00 2001 From: Imre Deak imre.d...@intel.com Date: Wed, 25 Feb 2015 19:38:53 +0200 Subject: [PATCH] drm/i915: zero PCI_COMMAND at the end of hibernation Signed-off-by: Imre Deak imre.d...@intel.com --- drivers/gpu/drm/i915/i915_drv.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index 4badb23..b226cc6 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -653,6 +653,8 @@ static int i915_drm_suspend_late(struct drm_device *drm_dev) pci_disable_device(drm_dev-pdev); pci_set_power_state(drm_dev-pdev, PCI_D3hot); + pci_write_config_word(drm_dev-pdev, PCI_COMMAND, 0); + return 0; } -- 2.1.0 From
Re: [PATCH] thermal: armada: read stable temp on Armada XP
Hi Ezequiel, On 25/02/2015 19:17, Ezequiel Garcia wrote: On 02/25/2015 02:04 PM, Gregory CLEMENT wrote: My conclusions about these registers are based on experimental data. The documentation is very sparse, but the Thermal Manager Control and Status Register looks like the preferred register given the way it is laid out in the public spec. Ezequiel, as you worked on this do you know why we used the Thermal Sensor Status Register instead of the Thermal Manager Control and Status Register ? My first guess is that the giving the name of the registers the 1st one made more sens to use for a thermal sensor. Actually, we based this driver in the vendor bootloader. The specs weren't of much use back then. Thanks for your prompt feedback. So we don't have much more information about the sensor. :( I will try to get information from Marvell. Tyler, In the meantime could you double check your values? The temperature on my board seemed broken on my board. If needed I can check on an other board. By the way on which board/product did you try it? Thanks, Gregory -- Gregory Clement, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] thermal: armada: read stable temp on Armada XP
On Wed, Feb 25, 2015 at 05:10:14PM +0100, Gregory CLEMENT wrote: Hi Tyler, Eduardo, On 24/02/2015 20:56, Tyler Hall wrote: Eduardo, On Tue, Feb 24, 2015 at 1:36 PM, Eduardo Valentin edubez...@gmail.com wrote: The fix seams reasonable. Although, it remains the question what is applicability to other Armada chips? Besides, shouldn't we simply use it by default? Also, do you plan to send updates in the DTS files? As far as I can tell, Armada 370 is already using the equivalent of this register I'd like to use in Armada XP. I'm not sure about the other mvebu platforms. I couldn't just change the device tree for XP to instantiate the 370 sensor, however, as they have different initialization routines. Possibly Eziquiel can comment on the significance of the differences between armadaxp_init_sensor() and armada370_init_sensor(). I would like to change the default going forward, but I don't think it can be changed on platforms using an older DTB. Here you introduced a new kind of thermal sensor, at least from the point of view of the device tree. You used a new compatible string associated to a different register. By using it by default do you mean removing marvell,armadaxp-thermal and adding armadaxp-filtered-thermal instead ? Does that new thermal sensors only improve the stability or does it also modify the value? In the second case it will more or less break the user space expectation. Yeah, I agree here. We need to understand if this is: (1) a fix of which register to use. In that case, the old dtbs are essentially wrong, and the driver would need to adapt, I would say. (2) a way to report better temperature extrapolations. then, this is essentially a new temp sensor, and we should have two separated compatible. in other words, just keep the patch the way it is. I had planned to submit the dts change separately. It's not clear to me how that's supposed to be handled if they might go through different trees. For this, there is no problem be handled in a different tree. At the end we will need both the a new dts and a new driver to use it, so the fact that the dts or the driver patch is merged in mainline first is not important. Yes. Typically I ask to see the complete series, even if I am not taking the DTS changes. That is, you send a complete series, with changes in the kernel code and in the DTS, copying the required audience (from kernel side and from DT side). Once the changes are accepted, the patches will be picked by the correct tree maintainer. It is common that DTS changes go via the platform tree, to avoid conflicts though. In this way, we can have a look if the whole set of changes are going to make sense, instead of guessing if future DTS changes will be correct. Thanks, Gregory Thanks, Tyler -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Gregory Clement, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com signature.asc Description: Digital signature
[PATCH 1/1] Documentation/sysctl/kernel.txt: header
The header of Documentation/sysctl/kernel.txt should not refer to Linux 2.2 because most of the lines were changed after that release. The authors that placed a copyright notice produced less than half of the lines. So give credit to the other authors. Replace legal blurb by a more precise term. Signed-off-by: Heinrich Schuchardt xypron.g...@gmx.de --- Documentation/sysctl/kernel.txt | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt index 83ab256..999df6b 100644 --- a/Documentation/sysctl/kernel.txt +++ b/Documentation/sysctl/kernel.txt @@ -1,13 +1,16 @@ -Documentation for /proc/sys/kernel/* kernel version 2.2.10 +Documentation for /proc/sys/kernel/* + (c) 1998, 1999, Rik van Riel r...@nl.linux.org (c) 2009,Shen Fengs...@cn.fujitsu.com -For general info and legal blurb, please look in README. +For other authors see the commit history. + +For general info and disclaimer, please look in README. == This file contains documentation for the sysctl files in -/proc/sys/kernel/ and is valid for Linux kernel version 2.2. +/proc/sys/kernel/. The files in this directory can be used to tune and monitor miscellaneous and general things in the operation of the Linux -- 2.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/
Re: [PATCH 2/3 v3] x86: entry_64.S: always allocate complete struct pt_regs
On 02/25/2015 01:37 PM, Andrey Wagin wrote: 2015-02-13 0:54 GMT+03:00 Denys Vlasenko dvlas...@redhat.com: 64-bit code was using six stack slots less by not saving/restoring registers which are callee-preserved according to C ABI, and not allocating space for them. Only when syscall needed a complete struct pt_regs, the complete area was allocated and filled in. As an additional twist, on interrupt entry a slightly less truncated pt_regs trick is used, to make nested interrupt stacks easier to unwind. This proved to be a source of significant obfuscation and subtle bugs. For example, stub_fork had to pop the return address, extend the struct, save registers, and push return address back. Ugly. ia32_ptregs_common pops return address and returns via jmp insn, throwing a wrench into CPU return stack cache. This patch changes code to always allocate a complete struct pt_regs. The saving of registers is still done lazily. Partial pt_regs trick on interrupt stack is retained. Macros which manipulate struct pt_regs on stack are reworked: ALLOC_PT_GPREGS_ON_STACK allocates the structure. SAVE_C_REGS saves to it those registers which are clobbered by C code. SAVE_EXTRA_REGS saves to it all other registers. Corresponding RESTORE_* and REMOVE_PT_GPREGS_FROM_STACK macros reverse it. ia32_ptregs_common, stub_fork and friends lost their ugly dance with return pointer. LOAD_ARGS32 in ia32entry.S now uses symbolic stack offsets instead of magic numbers. error_entry and save_paranoid now use SAVE_C_REGS + SAVE_EXTRA_REGS instead of having it open-coded yet again. Patch was run-tested: 64-bit executables, 32-bit executables, strace works. Timing tests did not show measurable difference in 32-bit and 64-bit syscalls. Hello Denys, My test vm doesn't boot with this patch. Could you help to investigate this issue? I think I found it. This part of my patch is possibly wrong: @@ -171,9 +171,9 @@ static inline int arch_irqs_disabled(void) #define ARCH_LOCKDEP_SYS_EXIT_IRQ \ TRACE_IRQS_ON; \ sti; \ - SAVE_REST; \ + SAVE_EXTRA_REGS; \ LOCKDEP_SYS_EXIT; \ - RESTORE_REST; \ + RESTORE_EXTRA_REGS; \ cli; \ TRACE_IRQS_OFF; The SAVE_REST here is intended to really *push* extra regs on stack, but the patch changed it so that they are written to existing stack slots above. From code inspection it should work in almost all cases, but some locations where it is used are really obscure. If there are places where *pushing* regs is really necessary, this can corrupt rbp,rbx,r12-15 registers. Your config has CONFIG_LOCKDEP=y, I think it's worth trying whether the bug was here. Please find updated patch attached. Can you try it? -- vda From 80c82370dcb8cd85c3b981ce62f63f74eff0df2c Mon Sep 17 00:00:00 2001 From: Denys Vlasenko dvlas...@redhat.com Date: Wed, 25 Feb 2015 19:32:14 +0100 Subject: [PATCH v2] x86: entry_64.S: always allocate complete struct pt_regs 64-bit code was using six stack slots less by not saving/restoring registers which are callee-preserved according to C ABI, and not allocating space for them. Only when syscall needed a complete struct pt_regs, the complete area was allocated and filled in. As an additional twist, on interrupt entry a slightly less truncated pt_regs trick is used, to make nested interrupt stacks easier to unwind. This proved to be a source of significant obfuscation and subtle bugs. For example, stub_fork had to pop the return address, extend the struct, save registers, and push return address back. Ugly. ia32_ptregs_common pops return address and returns via jmp insn, throwing a wrench into CPU return stack cache. This patch changes code to always allocate a complete struct pt_regs. The saving of registers is still done lazily. Partial pt_regs trick on interrupt stack is retained. Macros which manipulate struct pt_regs on stack are reworked: ALLOC_PT_GPREGS_ON_STACK allocates the structure. SAVE_C_REGS saves to it those registers which are clobbered by C code. SAVE_EXTRA_REGS saves to it all other registers. Corresponding RESTORE_* and REMOVE_PT_GPREGS_FROM_STACK macros reverse it. ia32_ptregs_common, stub_fork and friends lost their ugly dance with return pointer. LOAD_ARGS32 in ia32entry.S now uses symbolic stack offsets instead of magic numbers. error_entry and save_paranoid now use SAVE_C_REGS + SAVE_EXTRA_REGS instead of having it open-coded yet again. Patch was run-tested: 64-bit executables, 32-bit executables, strace works. Timing tests did not show measurable difference in 32-bit and 64-bit syscalls. Signed-off-by: Denys Vlasenko dvlas...@redhat.com CC: Linus Torvalds torva...@linux-foundation.org CC: Oleg Nesterov o...@redhat.com CC: Borislav Petkov b...@alien8.de CC: H. Peter Anvin h...@zytor.com CC: Andy Lutomirski l...@amacapital.net CC: Frederic Weisbecker fweis...@gmail.com CC: X86 ML x...@kernel.org CC: Alexei Starovoitov a...@plumgrid.com CC: Will Drewry
[PATCH] ARM: OMAP4: remove dead kconfig option OMAP4_ERRATA_I688
The Kconfig-Option OMAP4_ERRATA_I688 is never visible due to a
contradiction in it's dependencies.
The option requires ARCH_MULTIPLATFORM to be 'disabled'. However, an
enclosing menu requires either ARCH_MULTI_V6 or ARCH_MULTI_V7 to be
enabled. These options inherit a dependency from an enclosing menu,
that requires ARCH_MULTIPLATFORM to be 'enabled'.
This is a contradiction and made this option also unavailable for
non-multiplatform configurations.
Since there are no selects on OMAP4_ERRATA_I688, which would ignore
dependencies, the code related to that option is dead and can be
removed.
This (logical) defect has been found with the undertaker tool.
(https://undertaker.cs.fau.de)
Signed-off-by: Stefan Hengelein stefan.hengel...@fau.de
---
Tony Lindgren suggested to remove the code since nobody complained for
a few years and Santosh Shilimkar agreed.
https://lkml.org/lkml/2015/2/25/449
---
As far as I see, this should remove all the code related to
OMAP4_ERRATA_I688, I hope I didn't remove too much.
---
arch/arm/mach-omap2/Kconfig| 21
arch/arm/mach-omap2/common.c | 1 -
arch/arm/mach-omap2/common.h | 3 --
arch/arm/mach-omap2/io.c | 2 --
arch/arm/mach-omap2/omap-secure.h | 7
arch/arm/mach-omap2/omap4-common.c | 69 --
arch/arm/mach-omap2/sleep44xx.S| 2 --
7 files changed, 105 deletions(-)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 2b8e477..c7f4d9a 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -278,27 +278,6 @@ config OMAP3_SDRC_AC_TIMING
wish to say no. Selecting yes without understanding what is
going on could result in system crashes;
-config OMAP4_ERRATA_I688
- bool OMAP4 errata: Async Bridge Corruption
- depends on (ARCH_OMAP4 || SOC_OMAP5) !ARCH_MULTIPLATFORM
- select ARCH_HAS_BARRIERS
- help
- If a data is stalled inside asynchronous bridge because of back
- pressure, it may be accepted multiple times, creating pointer
- misalignment that will corrupt next transfers on that data path
- until next reset of the system (No recovery procedure once the
- issue is hit, the path remains consistently broken). Async bridge
- can be found on path between MPU to EMIF and MPU to L3 interconnect.
- This situation can happen only when the idle is initiated by a
- Master Request Disconnection (which is trigged by software when
- executing WFI on CPU).
- The work-around for this errata needs all the initiators connected
- through async bridge must ensure that data path is properly drained
- before issuing WFI. This condition will be met if one Strongly ordered
- access is performed to the target right before executing the WFI.
- In MPU case, L3 T2ASYNC FIFO and DDR T2ASYNC FIFO needs to be drained.
- IO barrier ensure that there is no synchronisation loss on initiators
- operating on both interconnect port simultaneously.
endmenu
endif
diff --git a/arch/arm/mach-omap2/common.c b/arch/arm/mach-omap2/common.c
index 484cdad..eae6a0e 100644
--- a/arch/arm/mach-omap2/common.c
+++ b/arch/arm/mach-omap2/common.c
@@ -30,5 +30,4 @@ int __weak omap_secure_ram_reserve_memblock(void)
void __init omap_reserve(void)
{
omap_secure_ram_reserve_memblock();
- omap_barrier_reserve_memblock();
}
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index 46e2458..cf3cf22 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -200,9 +200,6 @@ void __init omap4_map_io(void);
void __init omap5_map_io(void);
void __init ti81xx_map_io(void);
-/* omap_barriers_init() is OMAP4 only */
-void omap_barriers_init(void);
-
/**
* omap_test_timeout - busy-loop, testing a condition
* @cond: condition to test until it evaluates to true
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index c4871c5..1eeff6b 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -306,7 +306,6 @@ void __init am33xx_map_io(void)
void __init omap4_map_io(void)
{
iotable_init(omap44xx_io_desc, ARRAY_SIZE(omap44xx_io_desc));
- omap_barriers_init();
}
#endif
@@ -314,7 +313,6 @@ void __init omap4_map_io(void)
void __init omap5_map_io(void)
{
iotable_init(omap54xx_io_desc, ARRAY_SIZE(omap54xx_io_desc));
- omap_barriers_init();
}
#endif
/*
diff --git a/arch/arm/mach-omap2/omap-secure.h
b/arch/arm/mach-omap2/omap-secure.h
index dec2b05..af2851f 100644
--- a/arch/arm/mach-omap2/omap-secure.h
+++ b/arch/arm/mach-omap2/omap-secure.h
@@ -70,13 +70,6 @@ extern u32 rx51_secure_dispatcher(u32 idx, u32 process, u32
flag, u32 nargs,
extern u32 rx51_secure_update_aux_cr(u32 set_bits, u32 clear_bits);
extern u32 rx51_secure_rng_call(u32 ptr, u32 count, u32 flag);
-#ifdef CONFIG_OMAP4_ERRATA_I688
Re: [PATCH 4/4] net/core/dev.c : Race condition in net_tx_action.
From: Ameen Ali ameenali...@gmail.com
Date: Wed, 25 Feb 2015 19:50:59 +0200
@@ -3413,7 +3413,7 @@ EXPORT_SYMBOL(netif_rx_ni);
static void net_tx_action(struct softirq_action *h)
{
- struct softnet_data *sd = this_cpu_ptr(softnet_data);
+ volatile struct softnet_data *sd = __get_cpu_var(softnet_data);
volatile is never an appropriate solution to a race condition
--
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] ARM: dts: am335x-bone-common: enable aes and sham
Beaglebone Black doesn't have AES and SHAM enabled like the
original Beaglebone White dts. This breaks applications that
leverage the crypto blocks so fix this by enabling these nodes
in the am335x-bone-common.dtsi. With this change, enabling the
nodes in am335x-bone.dts is no longer required so remove them.
Signed-off-by: Matt Porter mpor...@konsulko.com
---
arch/arm/boot/dts/am335x-bone-common.dtsi | 8
arch/arm/boot/dts/am335x-bone.dts | 8
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi
b/arch/arm/boot/dts/am335x-bone-common.dtsi
index 6cc25ed..12cdb2b 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -300,3 +300,11 @@
cd-gpios = gpio0 6 GPIO_ACTIVE_HIGH;
cd-inverted;
};
+
+aes {
+ status = okay;
+};
+
+sham {
+ status = okay;
+};
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone.dts
index 83d40f7..6b849372 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -24,11 +24,3 @@
mmc1 {
vmmc-supply = ldo3_reg;
};
-
-sham {
- status = okay;
-};
-
-aes {
- status = okay;
-};
--
1.8.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/
Re: [PATCH 2/2] mmc: dw_mmc: Don't crash if we get an interrupt before slot has initted
Hello Doug, On 02/25/2015 07:11 PM, Doug Anderson wrote: It's unlikely that this is really needed on any single-slot systems where we disable card detects until the end of probe, but it still seems safer to check to make sure that a slot has been initted before we try to dereference it to find the SDIO interrupt mask. Signed-off-by: Doug Anderson diand...@chromium.org On an Exynos5250 Snow, Exynos5420 Peach Pit and Exynos5800 Peach Pi: Tested-by: Javier Martinez Canillas javier.marti...@collabora.co.uk Best regards, Javier -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 1/6] Documentation: dts: Documentation entry to explain how to use PWM FAN as a cooling device
On Wed, Feb 25, 2015 at 04:34:17PM +0100, Lukasz Majewski wrote:
Explanation of several properties, which allow PWM fan working as a cooling
device, have been embraced in this commit.
Signed-off-by: Lukasz Majewski l.majew...@samsung.com
---
Changes for v2:
- Rename cooling-pwm-values to cooling-levels
- Remove default-pulse-width property and stick to default hwmon policy
Changes for v3:
- Changing commit title from hwmon: dts: Doc: to Documentation: dts
- Remove unnecessary properties
- Set maximal cooling level to 230 instead of 255
Changes for v4:
- None
Changes for v5:
- Move thermal-zones description to example section
- Extending example section
---
.../devicetree/bindings/hwmon/pwm-fan.txt | 25
+-
1 file changed, 24 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/hwmon/pwm-fan.txt
b/Documentation/devicetree/bindings/hwmon/pwm-fan.txt
index 610757c..645251b 100644
--- a/Documentation/devicetree/bindings/hwmon/pwm-fan.txt
+++ b/Documentation/devicetree/bindings/hwmon/pwm-fan.txt
@@ -3,10 +3,33 @@ Bindings for a fan connected to the PWM lines
Required properties:
- compatible : pwm-fan
- pwms : the PWM that is used to control the PWM fan
+- cooling-levels : PWM duty cycle values in a range from 0 to 255
+ which correspond to thermal cooling states
Example:
- pwm-fan {
+ fan0: pwm-fan {
compatible = pwm-fan;
status = okay;
pwms = pwm 0 1 0;
+ cooling-levels = 0 102 170 230;
+ };
+
+ thermal-zones {
+ cpu_thermal: cpu-thermal {
+ cooling-min-state = 0;
+ cooling-max-state = 3;
+ #cooling-cells = 2;
+ trips {
+ cpu_alert1: cpu-alert1 {
+ temperature = 10; /* millicelsius */
+ hysteresis = 2000; /* millicelsius */
+ type = passive;
+ };
+ };
+ cooling-maps {
+ map0 {
+ trip = cpu_alert1;
+ cooling-device = fan0 0 1;
+ };
+ };
The above example has two issues:
(1) it is wrong, as the cooling device properties are in the thermal
zone node.
(2) has a misalignment / tabulation
Can you please fix that in your next version too?
};
--
2.0.0.rc2
signature.asc
Description: Digital signature
[RFC] New of_io_release_and_unmap()
Hello folks, I notice that io_request_and_map has no inverse. I would like to add a new function to undo what it does. Joshua Clayton (1): of/address: Add of_io_release_and_unmap() drivers/of/address.c | 29 + include/linux/of_address.h | 2 ++ 2 files changed, 31 insertions(+) -- 2.1.0 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 1/3] mmc: core: Add mmc_regulator_set_vqmmc()
Ulf, On Mon, Dec 15, 2014 at 4:22 PM, Doug Anderson diand...@chromium.org wrote: This adds logic to the MMC core to set VQMMC. This is expected to be called by MMC drivers like dw_mmc as part of (or instead of) their start_signal_voltage_switch() callback. A few notes: * When setting the signal voltage to 3.3V we do our best to make VQMMC and VMMC match. It's been reported that this makes some old cards happy since they were tested back in the day before UHS when VQMMC and VMMC were provided by the same regulator. A nice side effect of this is that we don't end up on the hairy edge of VQMMC (2.7V), which some EEs claim is a little too close to the minimum for comfort. * When setting the signal voltage to 1.8V or 1.2V we aim for that specific voltage instead of picking the lowest one in the range. * We very purposely don't print errors in mmc_regulator_set_vqmmc(). There are cases where the MMC core will try several different voltages and we don't want to pollute the logs. Signed-off-by: Doug Anderson diand...@chromium.org Reviewed-by: Andrew Bresticker abres...@chromium.org --- Changes in v3: None Changes in v2: - Now use existing regulator_set_voltage_tol() function. drivers/mmc/core/core.c | 51 include/linux/mmc/host.h | 7 +++ 2 files changed, 58 insertions(+) Do you know the status of this patch and its partner patch (mmc: dw_mmc: Use mmc_regulator_set_vqmmc in start_signal_voltage_switch - https://patchwork.kernel.org/patch/5498551/)? I'm happy to repost them or address feedback. Thanks! :) -Doug -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] capabilities: Ambient capability set V1
On Wed, 25 Feb 2015, Serge Hallyn wrote: Yeah we could make this Well doing that breaks su. Its best to leave perm bits untouched. christoph@fujitsu-haswell:~$ su setgid: Operation not permitted -- 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] x86: svm: don't intercept CR0 TS or MP bit write
2015-02-24 15:25-0600, Joel Schopp:
- clr_cr_intercept(svm, INTERCEPT_CR0_WRITE);
} else {
set_cr_intercept(svm, INTERCEPT_CR0_READ);
(There is no point in checking fpu_active if cr0s are equal.)
- set_cr_intercept(svm, INTERCEPT_CR0_WRITE);
KVM uses lazy FPU and the state is undefined before the first access.
We set cr0.ts when !svm-vcpu.fpu_active to detect the first access, but
if we allow the guest to clear cr0.ts without exiting, it can access FPU
with undefined state.
Thanks for the valuable feedback. It's apparent I hadn't thought
through the interaction with lazy FPU and will need to go back and
rethink my approach here.
I don't think we can gain much without sacrificing some laziness, like:
when a guest with lazy FPU clears CR0.TS, it is going to use that FPU,
so we could pre-load FPU in this case and drop the write intercept too;
guests that unconditionally clear CR0.TS would perform worse though.
It's going to take a lot of time, but two hunks in your patch, that made
selective intercept benefit from decode assists, look useful even now.
Would you post them separately?
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 V7 03/11] USB: f81232: implement RX bulk-in EP
On Tue, Feb 24, 2015 at 06:16:18PM +0800, Peter Hung wrote:
The F81232 bulk-in is RX data + LSR channel, data format is
[LSR+Data][LSR+Data]. , We had implemented in f81232_process_read_urb().
Signed-off-by: Peter Hung hpeter+linux_ker...@gmail.com
---
drivers/usb/serial/f81232.c | 69
+++--
1 file changed, 36 insertions(+), 33 deletions(-)
diff --git a/drivers/usb/serial/f81232.c b/drivers/usb/serial/f81232.c
index 1f29b95..419e2d6 100644
--- a/drivers/usb/serial/f81232.c
+++ b/drivers/usb/serial/f81232.c
@@ -23,6 +23,7 @@
#include linux/uaccess.h
#include linux/usb.h
#include linux/usb/serial.h
+#include linux/serial_reg.h
static const struct usb_device_id id_table[] = {
{ USB_DEVICE(0x1934, 0x0706) },
@@ -183,44 +184,46 @@ exit:
static void f81232_process_read_urb(struct urb *urb)
{
struct usb_serial_port *port = urb-context;
- struct f81232_private *priv = usb_get_serial_port_data(port);
unsigned char *data = urb-transfer_buffer;
- char tty_flag = TTY_NORMAL;
- unsigned long flags;
- u8 line_status;
+ char tty_flag;
int i;
Use an unsigned type for i.
+ u8 lsr;
- /* update line status */
- spin_lock_irqsave(priv-lock, flags);
- line_status = priv-modem_status;
- priv-modem_status = ~UART_STATE_TRANSIENT_MASK;
- spin_unlock_irqrestore(priv-lock, flags);
-
- if (!urb-actual_length)
+ if (urb-actual_length 2)
return;
- /* break takes precedence over parity, */
- /* which takes precedence over framing errors */
- if (line_status UART_BREAK_ERROR)
- tty_flag = TTY_BREAK;
- else if (line_status UART_PARITY_ERROR)
- tty_flag = TTY_PARITY;
- else if (line_status UART_FRAME_ERROR)
- tty_flag = TTY_FRAME;
- dev_dbg(port-dev, %s - tty_flag = %d\n, __func__, tty_flag);
-
- /* overrun is special, not associated with a char */
- if (line_status UART_OVERRUN_ERROR)
- tty_insert_flip_char(port-port, 0, TTY_OVERRUN);
-
- if (port-port.console port-sysrq) {
- for (i = 0; i urb-actual_length; ++i)
- if (!usb_serial_handle_sysrq_char(port, data[i]))
- tty_insert_flip_char(port-port, data[i],
- tty_flag);
- } else {
- tty_insert_flip_string_fixed_flag(port-port, data, tty_flag,
- urb-actual_length);
+ /* bulk-in data: [LSR(1Byte)+DATA(1Byte)][LSR(1Byte)+DATA(1Byte)]... */
+
+ for (i = 0; i urb-actual_length; i += 2) {
Again, what if the length is not a multiple of 2?
+ tty_flag = TTY_NORMAL;
+ lsr = data[i + 0];
Just use data[i] here.
+
+ if (lsr UART_LSR_BRK_ERROR_BITS) {
+ if (lsr UART_LSR_BI) {
+ tty_flag = TTY_BREAK;
+ port-icount.brk++;
+ usb_serial_handle_break(port);
+ } else if (lsr UART_LSR_PE) {
+ tty_flag = TTY_PARITY;
+ port-icount.parity++;
+ } else if (lsr UART_LSR_FE) {
+ tty_flag = TTY_FRAME;
+ port-icount.frame++;
+ }
+
+ if (lsr UART_LSR_OE) {
+ port-icount.overrun++;
+ tty_insert_flip_char(port-port, 0,
+ TTY_OVERRUN);
Use at least two tabs indentation for continuation lines.
+ }
+ }
+
+ if (port-port.console port-sysrq) {
+ if (usb_serial_handle_sysrq_char(port, data[i + 1]))
+ continue;
+ }
+
+ tty_insert_flip_char(port-port, data[i + 1], tty_flag);
}
tty_flip_buffer_push(port-port);
Looks good now, otherwise.
Thanks,
Johan
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 6/7] power: da9150: Add DT binding documentation for charger
On 18/02/15 14:08, Adam Thomson wrote:
Signed-off-by: Adam Thomson adam.thomson.opensou...@diasemi.com
Acked-by: Jonathan Cameron ji...@kernel.org
---
.../devicetree/bindings/power/da9150-charger.txt | 26
++
1 file changed, 26 insertions(+)
create mode 100644 Documentation/devicetree/bindings/power/da9150-charger.txt
diff --git a/Documentation/devicetree/bindings/power/da9150-charger.txt
b/Documentation/devicetree/bindings/power/da9150-charger.txt
new file mode 100644
index 000..f390666
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/da9150-charger.txt
@@ -0,0 +1,26 @@
+Dialog Semiconductor DA9150 Charger Power Supply bindings
+
+Required properties:
+- compatible: dlg,da9150-charger for DA9150 Charger Power Supply
+
+Optional properties:
+- io-channels: List of phandle and IIO specifier pairs
+- io-channel-names: List of channel names used by charger
+ [CHAN_IBUS, CHAN_VBUS, CHAN_TJUNC, CHAN_VBAT]
+ (See Documentation/devicetree/bindings/iio/iio-bindings.txt for further
info)
+
+
+Example:
+
+ da9150-charger {
+ compatible = dlg,da9150-charger;
+
+ io-channels = gpadc 0,
+ gpadc 2,
+ gpadc 8,
+ gpadc 5;
+ io-channel-names = CHAN_IBUS,
+CHAN_VBUS,
+CHAN_TJUNC,
+CHAN_VBAT;
+ };
--
1.9.3
--
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 3.14 00/17] 3.14.34-stable review
On 02/24/2015 07:10 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.14.34 release. There are 17 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Fri Feb 27 02:08:17 UTC 2015. Anything received after that time might be too late. The whole patch series can be found in one patch at: kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.14.34-rc1.gz and the diffstat can be found below. thanks, greg k-h Compiled and booted on my test system. No dmesg regressions. thanks, -- Shuah -- Shuah Khan Sr. Linux Kernel Developer Open Source Innovation Group Samsung Research America (Silicon Valley) shua...@osg.samsung.com | (970) 217-8978 -- 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.18 00/20] 3.18.8-stable review
On 02/24/2015 07:10 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.18.8 release. There are 20 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Fri Feb 27 02:08:41 UTC 2015. Anything received after that time might be too late. The whole patch series can be found in one patch at: kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.18.8-rc1.gz and the diffstat can be found below. thanks, greg k-h Compiled and booted on my test system. No dmesg regressions. thanks, -- Shuah -- Shuah Khan Sr. Linux Kernel Developer Open Source Innovation Group Samsung Research America (Silicon Valley) shua...@osg.samsung.com | (970) 217-8978 -- 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] video: ARM CLCD: Added support for FBIO_WAITFORVSYNC
Added ioctl and interrupt handler functions to support FBIO_WAITFORVSYNC
Also corrected documentation to make interrupts and interrupt-names
optional as they are not required properties.
Reviewed-by: Ray Jui r...@broadcom.com
Reviewed-by: Scott Branden sbran...@broadcom.com
Signed-off-by: Arun Ramamurthy arun.ramamur...@broadcom.com0
---
.../devicetree/bindings/video/arm,pl11x.txt| 11 +--
drivers/video/fbdev/amba-clcd.c| 82 ++
include/linux/amba/clcd.h | 4 ++
3 files changed, 89 insertions(+), 8 deletions(-)
diff --git a/Documentation/devicetree/bindings/video/arm,pl11x.txt
b/Documentation/devicetree/bindings/video/arm,pl11x.txt
index 2262cdb..7d19024 100644
--- a/Documentation/devicetree/bindings/video/arm,pl11x.txt
+++ b/Documentation/devicetree/bindings/video/arm,pl11x.txt
@@ -10,14 +10,6 @@ Required properties:
- reg: base address and size of the control registers block
-- interrupt-names: either the single entry combined representing a
- combined interrupt output (CLCDINTR), or the four entries
- mbe, vcomp, lnbu, fuf representing the individual
- CLCDMBEINTR, CLCDVCOMPINTR, CLCDLNBUINTR, CLCDFUFINTR interrupts
-
-- interrupts: contains an interrupt specifier for each entry in
- interrupt-names
-
- clock-names: should contain clcdclk and apb_pclk
- clocks: contains phandle and clock specifier pairs for the entries
@@ -54,6 +46,9 @@ Optional properties:
It can be used to configure a virtual y resolution. It
must be a value larger than the actual y resolution.
+- interrupts: contains an interrupt specifier for the clcd vcomp interrupt
+This is required for the driver to handle FBIO_WAITFORVSYNC ioctls.
+
Required sub-nodes:
- port: describes LCD panel signals, following the common binding
diff --git a/drivers/video/fbdev/amba-clcd.c b/drivers/video/fbdev/amba-clcd.c
index 3bc09ad..9f7a58c 100644
--- a/drivers/video/fbdev/amba-clcd.c
+++ b/drivers/video/fbdev/amba-clcd.c
@@ -30,6 +30,8 @@
#include linux/of.h
#include linux/of_address.h
#include linux/of_graph.h
+#include linux/of_irq.h
+#include linux/interrupt.h
#include video/display_timing.h
#include video/of_display_timing.h
#include video/videomode.h
@@ -466,6 +468,73 @@ static int clcdfb_pan_display(struct fb_var_screeninfo
*var,
return 0;
}
+static int clcdfb_ioctl(struct fb_info *info,
+ unsigned int cmd, unsigned long args)
+{
+ struct clcd_fb *fb = to_clcd(info);
+ int retval = 0;
+ u32 val, ienb_val;
+
+ switch (cmd) {
+ case FBIO_WAITFORVSYNC:{
+ if (fb-lcd_irq = 0) {
+ retval = -EINVAL;
+ break;
+ }
+ /* disable Vcomp interrupts */
+ ienb_val = readl(fb-regs + fb-off_ienb);
+ ienb_val = ~CLCD_PL111_IENB_VCOMP;
+ writel(ienb_val, fb-regs + fb-off_ienb);
+
+ /* clear Vcomp interrupt */
+ writel(CLCD_PL111_IENB_VCOMP, fb-regs + CLCD_PL111_ICR);
+
+ /* Generate Interrupt at the start of Vsync */
+ reinit_completion(fb-wait);
+ val = readl(fb-regs + fb-off_cntl);
+ val = ~(CNTL_LCDVCOMP(3));
+ writel(val, fb-regs + fb-off_cntl);
+
+ /* enable Vcomp interrupt */
+ ienb_val = readl(fb-regs + fb-off_ienb);
+ ienb_val |= CLCD_PL111_IENB_VCOMP;
+ writel(ienb_val, fb-regs + fb-off_ienb);
+ if (!wait_for_completion_interruptible_timeout
+ (fb-wait, HZ/10))
+ retval = -ETIMEDOUT;
+ break;
+ }
+ default:
+ retval = -ENOIOCTLCMD;
+ break;
+ }
+ return retval;
+}
+
+static irqreturn_t clcd_interrupt(int irq, void *data)
+{
+ struct clcd_fb *fb = data;
+ u32 val;
+
+ /* check for vsync interrupt */
+ val = readl(fb-regs + CLCD_PL111_MIS);
+
+ if (val CLCD_PL111_IENB_VCOMP) {
+ val = readl(fb-regs + fb-off_ienb);
+ val = ~CLCD_PL111_IENB_VCOMP;
+
+ /* disable Vcomp interrupts */
+ writel(val, fb-regs + fb-off_ienb);
+
+ /* clear Vcomp interrupt */
+ writel(CLCD_PL111_IENB_VCOMP, fb-regs + CLCD_PL111_ICR);
+
+ complete(fb-wait);
+ return IRQ_HANDLED;
+ }
+ return IRQ_NONE;
+}
+
static struct fb_ops clcdfb_ops = {
.owner = THIS_MODULE,
.fb_check_var = clcdfb_check_var,
@@ -477,6 +546,7 @@ static struct fb_ops clcdfb_ops = {
.fb_imageblit = cfb_imageblit,
.fb_mmap= clcdfb_mmap,
.fb_pan_display = clcdfb_pan_display,
+ .fb_ioctl = clcdfb_ioctl,
};
static int clcdfb_register(struct clcd_fb *fb)
@@ -753,6 +823,18 @@ static int
Re: [patch -rt 1/2] KVM: use simple waitqueue for vcpu-wq
* Peter Zijlstra | 2015-02-18 15:03:20 [+0100]:
On Tue, Feb 17, 2015 at 06:44:19PM +0100, Sebastian Andrzej Siewior wrote:
* Peter Zijlstra | 2015-01-21 16:07:16 [+0100]:
On Tue, Jan 20, 2015 at 01:16:13PM -0500, Steven Rostedt wrote:
I'm actually wondering if we should just nuke the _interruptible()
version of swait. As it should only be all interruptible or all not
interruptible, that the swait_wake() should just do the wake up
regardless. In which case, swait_wake() is good enough. No need to have
different versions where people may think do something special.
Peter?
Yeah, I think the lastest thing I have sitting here on my disk only has
the swake_up() which does TASK_NORMAL, no choice there.
what is the swait status in terms of mainline? This sounds like it
beeing worked on.
I could take the series but then I would drop it again if the mainline
implementation changes…
Well, 'worked' on might be putting too much on it, its one of the many
many 'spare' time things that never get attention unless people bug me
;-)
The below is my current patch, I've not actually tried it yet, I (think
I) had one patch doing some conversions but I'm having trouble locating
it.
Mostly-Signed-off-by: Peter Zijlstra (Intel) pet...@infradead.org
---
include/linux/swait.h | 172
++
kernel/sched/swait.c | 122 +++
2 files changed, 294 insertions(+)
--- /dev/null
+++ b/include/linux/swait.h
@@ -0,0 +1,172 @@
+#ifndef _LINUX_SWAIT_H
+#define _LINUX_SWAIT_H
+
+#include linux/list.h
+#include linux/stddef.h
+#include linux/spinlock.h
+#include asm/current.h
+
+/*
+ * Simple wait queues
+ *
+ * While these are very similar to the other/complex wait queues (wait.h) the
+ * most important difference is that the simple waitqueue allows for
+ * deterministic behaviour -- IOW it has strictly bounded IRQ and lock hold
+ * times.
+ *
+ * In order to make this so, we had to drop a fair number of features of the
+ * other waitqueue code; notably:
+ *
+ * - mixing INTERRUPTIBLE and UNINTERRUPTIBLE sleeps on the same waitqueue;
+ *all wakeups are TASK_NORMAL in order to avoid O(n) lookups for the right
+ *sleeper state.
+ *
+ * - the exclusive mode; because this requires preserving the list order
+ *and this is hard.
+ *
+ * - custom wake functions; because you cannot give any guarantees about
+ *random code.
+ *
+ * As a side effect of this; the data structures are slimmer.
+ *
+ * One would recommend using this wait queue where possible.
+ */
+
+struct task_struct;
+
+struct swait_queue_head {
+ raw_spinlock_t lock;
+ struct list_headtask_list;
+};
+
+struct swait_queue {
+ struct task_struct *task;
+ struct list_headtask_list;
I would prefer something different than task_list here since this is an
item. Scrolling down you tried to use node once so maybe that would be
good here :)
+};
+
+#define __SWAITQUEUE_INITIALIZER(name) { \
+ .task = current, \
+ .task_list = LIST_HEAD_INIT((name).task_list), \
+}
+
+#define DECLARE_SWAITQUEUE(name) \
+ struct swait_queue name = __SWAITQUEUE_INITIALIZER(name)
+
+#define __SWAIT_QUEUE_HEAD_INITIALIZER(name) {
\
+ .lock = __RAW_SPIN_LOCK_UNLOCKED(name.lock), \
+ .task_list = LIST_HEAD_INIT((name).task_list), \
+}
+
+#define DECLARE_SWAIT_QUEUE_HEAD(name)
\
+ struct swait_queue_head name = __SWAIT_QUEUE_HEAD_INITIALIZER(name)
+
+extern void __init_swait_queue_head(struct swait_queue_head *q, const char
*name,
+ struct lock_class_key *key);
+
+#define init_swait_queue_head(q) \
+ do {\
+ static struct lock_class_key __key; \
+ __init_swait_queue_head((q), #q, __key); \
+ } while (0)
+
+#ifdef CONFIG_LOCKDEP
+# define __SWAIT_QUEUE_HEAD_INIT_ONSTACK(name)\
+ ({ init_swait_queue_head(name); name; })
+# define DECLARE_SWAIT_QUEUE_HEAD_ONSTACK(name) \
+ struct swait_queue_head name = __SWAIT_QUEUE_HEAD_INIT_ONSTACK(name)
+#else
+# define DECLARE_SWAIT_QUEUE_HEAD_ONSTACK(name) \
+ DECLARE_SWAIT_QUEUE_HEAD(name)
+#endif
+
+static inline int swait_active(struct swait_queue_head *q)
+{
+ return !list_empty(q-task_list);
In RT there was a smp_mb() which you dropped and I assume you had
reasons for it. I assumed that one can perform list_empty_careful()
without a lock if the items were removed with list_del_init(). But since
nothing in -RT blow up so far I guess this here is legal, too :)
+}
+
+extern void
[PATCH] video: ARM CLCD: Correcting timing checks for STN and TFT dispalys
The minimum values for timing parameters such as left margin,
right margin etc are different for STN and TFT dispalys.
This commit fixes a check that does not account for
this difference.
Reviewed-by: Ray Jui r...@broadcom.com
Reviewed-by: Scott Branden sbran...@broadcom.com
Signed-off-by: Arun Ramamurthy arun.ramamur...@broadcom.com
---
include/linux/amba/clcd.h | 32 ++--
1 file changed, 22 insertions(+), 10 deletions(-)
diff --git a/include/linux/amba/clcd.h b/include/linux/amba/clcd.h
index 6a3bc2d..0fe8a17 100644
--- a/include/linux/amba/clcd.h
+++ b/include/linux/amba/clcd.h
@@ -288,16 +288,28 @@ static inline int clcdfb_check(struct clcd_fb *fb, struct
fb_var_screeninfo *var
var-xres_virtual = var-xres = (var-xres + 15) ~15;
var-yres_virtual = var-yres = (var-yres + 1) ~1;
-#define CHECK(e,l,h) (var-e l || var-e h)
- if (CHECK(right_margin, (5+1), 256) || /* back porch */
- CHECK(left_margin, (5+1), 256) || /* front porch */
- CHECK(hsync_len, (5+1), 256) ||
- var-xres 4096 ||
- var-lower_margin 255 || /* back porch */
- var-upper_margin 255 || /* front porch */
- var-vsync_len 32 ||
- var-yres 1024)
- return -EINVAL;
+#define CHECK(e, l, h) (var-e l || var-e h)
+ if (!(fb-panel-cntl CNTL_LCDTFT)) {
+ if (CHECK(right_margin, (5+1), 256) || /* back porch */
+ CHECK(left_margin, (5+1), 256) || /* front porch */
+ CHECK(hsync_len, (5+1), 256) ||
+ var-xres 4096 ||
+ var-lower_margin 255 || /* back porch */
+ var-upper_margin 255 || /* front porch */
+ var-vsync_len 32 ||
+ var-yres 1024)
+ return -EINVAL;
+ } else {
+ if (CHECK(right_margin, 1, 256) || /* back porch */
+ CHECK(left_margin, 1, 256) || /* front porch */
+ CHECK(hsync_len, 1, 256) ||
+ var-xres 4096 ||
+ var-lower_margin 255 || /* back porch */
+ var-upper_margin 255 || /* front porch */
+ var-vsync_len 32 ||
+ var-yres 1024)
+ return -EINVAL;
+ }
#undef CHECK
/* single panel mode: PCD = max(PCD, 1) */
--
2.3.0
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/7] perf bench: Fix order of arguments to memcpy_alloc_mem
From: Bruce Merry bme...@ska.ac.za This was causing the destination instead of the source to be filled. As a result, the source was typically all mapped to one zero page, and hence very cacheable. Signed-off-by: Bruce Merry bme...@ska.ac.za Acked-by: Ingo Molnar mi...@kernel.org Cc: Paul Mackerras pau...@samba.org Cc: Peter Zijlstra pet...@infradead.org Link: http://lkml.kernel.org/r/20150115092022.GA11292@kryton Signed-off-by: Arnaldo Carvalho de Melo a...@redhat.com --- tools/perf/bench/mem-memcpy.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/perf/bench/mem-memcpy.c b/tools/perf/bench/mem-memcpy.c index 6c14afe8c1b1..db1d3a29d97f 100644 --- a/tools/perf/bench/mem-memcpy.c +++ b/tools/perf/bench/mem-memcpy.c @@ -289,7 +289,7 @@ static u64 do_memcpy_cycle(const struct routine *r, size_t len, bool prefault) memcpy_t fn = r-fn.memcpy; int i; - memcpy_alloc_mem(src, dst, len); + memcpy_alloc_mem(dst, src, len); if (prefault) fn(dst, src, len); @@ -312,7 +312,7 @@ static double do_memcpy_gettimeofday(const struct routine *r, size_t len, void *src = NULL, *dst = NULL; int i; - memcpy_alloc_mem(src, dst, len); + memcpy_alloc_mem(dst, src, len); if (prefault) fn(dst, src, len); -- 1.9.3 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL 0/7] perf/urgent fixes
Hi Ingo, Please consider pulling, - Arnaldo The following changes since commit 2a6730c8b6e075adf826a89a3e2caa705807afdb: kprobes/x86: Check for invalid ftrace location in __recover_probed_insn() (2015-02-21 10:33:31 +0100) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git tags/perf-urgent-for-mingo for you to fetch changes up to 4861f87cd3d133f03e3b39b6650f4e12f1a9e421: perf tools: Make sparc64 arch point to sparc (2015-02-25 17:39:17 -0300) perf/urgent fixes: Infrastructure: - pthread_attr_setaffinity_np feature detection build fixes (Adrian Hunter, Josh Boyer) - Fix probing for PERF_FLAG_FD_CLOEXEC flag (Adrian Hunter) - Fix order of arguments to memcpy_alloc_mem in 'perf bench' (Bruce Merry) - Sparc64 and Aarch64 build and segfault fixes (David Ahern) Signed-off-by: Arnaldo Carvalho de Melo a...@redhat.com Adrian Hunter (2): perf tools: Fix pthread_attr_setaffinity_np build error perf tools: Fix probing for PERF_FLAG_FD_CLOEXEC flag Bruce Merry (1): perf bench: Fix order of arguments to memcpy_alloc_mem David Ahern (3): perf top: Fix SIGBUS on sparc64 perf symbols: Define EM_AARCH64 for older OSes perf tools: Make sparc64 arch point to sparc Josh Boyer (1): perf tools: Define _GNU_SOURCE on pthread_attr_setaffinity_np feature check tools/perf/bench/mem-memcpy.c | 4 ++-- tools/perf/config/Makefile.arch| 4 tools/perf/config/feature-checks/Makefile | 2 +- .../feature-checks/test-pthread-attr-setaffinity-np.c | 3 ++- tools/perf/util/cloexec.c | 18 +++--- tools/perf/util/evlist.h | 2 +- tools/perf/util/symbol-elf.c | 5 + 7 files changed, 30 insertions(+), 8 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Xen-devel] [PATCH v3 0/2] x86/arm64: add xenconfig
On Wed, Feb 25, 2015 at 12:49 PM, David Rientjes rient...@google.com wrote: Woohoo, so does this mean that Luis's series will finally be merged into a tree somewhere? It's been a lengthy wait to try to get this merged. David Rientjes (as I'm also Cc'ing David Vrabel), I am reworking Xen's kconfig stuff right now, so perhaps what is best is for this series to be folded under those changes and I'd submit them as the last series in the changes. That would avoid collateral changes as I revamp tons of Xen kconfig things. This would then go under David Vrabel's tree, but since it involves x86 stuff its unclear if its OK for that -- I think so? Let me know. Luis -- 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/7] perf top: Fix SIGBUS on sparc64
From: David Ahern david.ah...@oracle.com
perf-top is terminating due to SIGBUS on sparc64. git bisect points to:
commit 82396986032915c1572bfb74b224fcc2e4e8ba7c
Author: Arnaldo Carvalho de Melo a...@redhat.com
Date: Mon Sep 8 13:26:35 2014 -0300
perf evlist: Refcount mmaps
We need to know how many fds are using a perf mmap via
PERF_EVENT_IOC_SET_OUTPUT, so that we can know when to ditch an mmap,
refcount it.
This commit added 'int refcnt' to struct perf_mmap and the addition makes the
event_copy element no longer 8-byte aligned.
Fix by adding __attribute__((aligned(8))) to the event_copy struct
member.
Signed-off-by: David Ahern david.ah...@oracle.com
Link:
http://lkml.kernel.org/r/1424304198-92028-1-git-send-email-david.ah...@oracle.com
[ Switched from 'int pad;' to using __attribute__, David tested/acked that ]
Signed-off-by: Arnaldo Carvalho de Melo a...@redhat.com
---
tools/perf/util/evlist.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/perf/util/evlist.h b/tools/perf/util/evlist.h
index c94a9e03ecf1..e99a67632831 100644
--- a/tools/perf/util/evlist.h
+++ b/tools/perf/util/evlist.h
@@ -28,7 +28,7 @@ struct perf_mmap {
int mask;
int refcnt;
unsigned int prev;
- char event_copy[PERF_SAMPLE_MAX_SIZE];
+ char event_copy[PERF_SAMPLE_MAX_SIZE]
__attribute__((aligned(8)));
};
struct perf_evlist {
--
1.9.3
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] HID: uclogic: merge hid-huion driver in hid-uclogic
On 02/25/2015 02:05 AM, Benjamin Tissoires wrote: From: Nikolai Kondrashov nikolai.kondras...@redhat.com Merge the hid-huion driver into hid-uclogic as all the devices supported by hid-huion are in fact UC-Logic devices. Signed-off-by: Benjamin Tissoires benjamin.tissoi...@redhat.com --- Changed from the original patch: - update Makefile, Kconfig accordingly - remove one extra pr_err when kzalloc failed (raised by checkpatch.pl) drivers/hid/Kconfig | 8 +- drivers/hid/Makefile | 1 - drivers/hid/hid-huion.c | 290 -- drivers/hid/hid-uclogic.c | 229 +++- 4 files changed, 229 insertions(+), 299 deletions(-) delete mode 100644 drivers/hid/hid-huion.c diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig index 152b006..8a55fd7 100644 --- a/drivers/hid/Kconfig +++ b/drivers/hid/Kconfig @@ -286,12 +286,6 @@ config HID_GT683R Currently the following devices are know to be supported: - MSI GT683R -config HID_HUION - tristate Huion tablets - depends on USB_HID - ---help--- - Support for Huion 580 tablet. - config HID_KEYTOUCH tristate Keytouch HID devices depends on HID @@ -314,7 +308,7 @@ config HID_UCLOGIC tristate UC-Logic depends on HID ---help--- - Support for UC-Logic tablets. + Support for UC-Logic and Huion tablets. I'm not sure this is worth changing. We'll need to at least add Yiynova and Ugee here later, which we're likely to forget. Meanwhile, essentially, they're UC-Logic underneath. Apart from this (which can be left as is, IMHO): Reviewed-by: Nikolai Kondrashov spbn...@gmail.com BTW, will you be submitting changes to digimend-kernel-drivers to align it with what you're submitting upstream? Nick -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/7] perf tools: Define _GNU_SOURCE on pthread_attr_setaffinity_np feature check
From: Josh Boyer jwbo...@fedoraproject.org The man page for pthread_attr_set_affinity_np states that _GNU_SOURCE must be defined before pthread.h is included in order to get the proper function declaration. Define this in the Makefile. Without this defined, the feature check fails on a Fedora system with gcc5 and then the perf build later fails with conflicting prototypes for the function. Signed-off-by: Josh Boyer jwbo...@fedoraproject.org Cc: Jiri Olsa jo...@kernel.org Cc: Peter Zijlstra a.p.zijls...@chello.nl Cc: Vineet Gupta vineet.gup...@synopsys.com Link: http://lkml.kernel.org/r/20150211162404.ga15...@hansolo.redhat.com Signed-off-by: Arnaldo Carvalho de Melo a...@redhat.com --- tools/perf/config/feature-checks/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/perf/config/feature-checks/Makefile b/tools/perf/config/feature-checks/Makefile index 42ac05aaf8ac..b32ff3372514 100644 --- a/tools/perf/config/feature-checks/Makefile +++ b/tools/perf/config/feature-checks/Makefile @@ -49,7 +49,7 @@ test-hello.bin: $(BUILD) test-pthread-attr-setaffinity-np.bin: - $(BUILD) -Werror -lpthread + $(BUILD) -D_GNU_SOURCE -Werror -lpthread test-stackprotector-all.bin: $(BUILD) -Werror -fstack-protector-all -- 1.9.3 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/7] perf tools: Fix pthread_attr_setaffinity_np build error
From: Adrian Hunter adrian.hun...@intel.com
Feature detection for pthread_attr_setaffinity_np was failing, producing
this error:
In file included from bench/futex-hash.c:17:0:
bench/futex.h:73:19: error: conflicting types for
‘pthread_attr_setaffinity_np’
static inline int pthread_attr_setaffinity_np(pthread_attr_t *attr,
^
In file included from bench/futex.h:72:0,
from bench/futex-hash.c:17:
/usr/include/pthread.h:407:12: note: previous declaration of
‘pthread_attr_setaffinity_np’ was here
extern int pthread_attr_setaffinity_np (pthread_attr_t *__attr,
^
make[3]: *** [bench/futex-hash.o] Error 1
make[2]: *** [bench] Error 2
make[2]: *** Waiting for unfinished jobs
This was because compiling test-pthread-attr-setaffinity-np.c
failed due to the function arguments:
test-pthread-attr-setaffinity-np.c: In function ‘main’:
test-pthread-attr-setaffinity-np.c:11:2: warning: null argument where
non-null required (argument 3) [-Wnonnull]
ret = pthread_attr_setaffinity_np(thread_attr, 0, NULL);
^
So fix the arguments.
Signed-off-by: Adrian Hunter adrian.hun...@intel.com
Tested-by: Stephane Eranian eran...@google.com
Cc: Jiri Olsa jo...@redhat.com
Link:
http://lkml.kernel.org/r/1424774766-24194-1-git-send-email-adrian.hun...@intel.com
Signed-off-by: Arnaldo Carvalho de Melo a...@redhat.com
---
tools/perf/config/feature-checks/test-pthread-attr-setaffinity-np.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
a/tools/perf/config/feature-checks/test-pthread-attr-setaffinity-np.c
b/tools/perf/config/feature-checks/test-pthread-attr-setaffinity-np.c
index 0a0d3ecb4e8a..2b81b72eca23 100644
--- a/tools/perf/config/feature-checks/test-pthread-attr-setaffinity-np.c
+++ b/tools/perf/config/feature-checks/test-pthread-attr-setaffinity-np.c
@@ -5,10 +5,11 @@ int main(void)
{
int ret = 0;
pthread_attr_t thread_attr;
+ cpu_set_t cs;
pthread_attr_init(thread_attr);
/* don't care abt exact args, just the API itself in libpthread */
- ret = pthread_attr_setaffinity_np(thread_attr, 0, NULL);
+ ret = pthread_attr_setaffinity_np(thread_attr, sizeof(cs), cs);
return ret;
}
--
1.9.3
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/4] HID: uclogic: Set quirks from inside the driver
On 02/25/2015 02:05 AM, Benjamin Tissoires wrote: Based on a patch from: Nikolai Kondrashov nikolai.kondras...@redhat.com Most of the tablets handled by hid-uclogic already uses MULTI_INPUT. *use Fot the ones which are not quirked in usbhid/hidquirks, they have a *For custom report descriptor which contains only one report per HID interface. For those tablets HID_QUIRK_MULTI_INPUT is transparent. According to https://github.com/DIGImend/tablets, the only problematic tablet currently handled by hid-uclogic is the TWHA60 v3. This tablet presents different report descriptors from the ones currently quirked. This is not a problem per se, given that this tablet is not supported currently in this version (it needs the same command than a Huion to *as a Huion start forwarding events). Thanks, Benjamin. this will make further merges easier. Regardless of the Grammar Nazi comments above (fixing is up to you): Reviewed-by: Nikolai Kondrashov spbn...@gmail.com Nick -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] clk: Missing set_phase op is an error
Quoting Stephen Boyd (2015-02-02 14:09:43)
If a clock's clk_ops doesn't have the set_phase op set we should
return an error from clk_set_phase(). This way clock consumers
know that when they tried to set a phase it didn't work, as
opposed to the current behavior where the return value is 0
meaning success.
Signed-off-by: Stephen Boyd sb...@codeaurora.org
Applied to clk-next.
Thanks,
Mike
---
drivers/clk/clk.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index a29daf9edea4..b82714a84f5e 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -2069,10 +2069,10 @@ EXPORT_SYMBOL_GPL(clk_set_parent);
*/
int clk_set_phase(struct clk *clk, int degrees)
{
- int ret = 0;
+ int ret = -EINVAL;
if (!clk)
- goto out;
+ return 0;
/* sanity check degrees */
degrees %= 360;
@@ -2081,18 +2081,14 @@ int clk_set_phase(struct clk *clk, int degrees)
clk_prepare_lock();
- if (!clk-core-ops-set_phase)
- goto out_unlock;
-
- ret = clk-core-ops-set_phase(clk-core-hw, degrees);
+ if (clk-core-ops-set_phase)
+ ret = clk-core-ops-set_phase(clk-core-hw, degrees);
if (!ret)
clk-core-phase = degrees;
-out_unlock:
clk_prepare_unlock();
-out:
return ret;
}
EXPORT_SYMBOL_GPL(clk_set_phase);
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -v2] mm, oom: do not fail __GFP_NOFAIL allocation if oom killer is disbaled
On Wed, 25 Feb 2015, Michal Hocko wrote: diff --git a/mm/page_alloc.c b/mm/page_alloc.c index 2d224bbdf8e8..c2ff40a30003 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -2363,7 +2363,8 @@ __alloc_pages_may_oom(gfp_t gfp_mask, unsigned int order, goto out; } /* Exhausted what can be done so it's blamo time */ - if (out_of_memory(ac-zonelist, gfp_mask, order, ac-nodemask, false)) + if (out_of_memory(ac-zonelist, gfp_mask, order, ac-nodemask, false) + || WARN_ON_ONCE(gfp_mask __GFP_NOFAIL)) *did_some_progress = 1; out: oom_zonelist_unlock(ac-zonelist, gfp_mask); Eek, not sure we actually need to play any games with did_some_progress, it might be clearer just to do this diff --git a/mm/page_alloc.c b/mm/page_alloc.c --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -2760,7 +2760,7 @@ retry: did_some_progress); if (page) goto got_pg; - if (!did_some_progress) + if (!did_some_progress !(gfp_mask __GFP_NOFAIL)) goto nopage; } /* Wait for some write requests to complete then retry */ Either way you decide, feel free to add my Acked-by: David Rientjes rient...@gooogle.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V7 08/11] USB: f81232: implement set_termios()
On Tue, Feb 24, 2015 at 06:16:23PM +0800, Peter Hung wrote:
The original driver had do not any h/w change in driver.
This patch implements with configure H/W for
baud/parity/word length/stop bits functional in f81232_set_termios().
This patch also implement DTR/RTS control when baudrate B0.
We drop DTR/RTS when B0, otherwise enable it.
Signed-off-by: Peter Hung hpeter+linux_ker...@gmail.com
---
drivers/usb/serial/f81232.c | 106
++--
1 file changed, 102 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/serial/f81232.c b/drivers/usb/serial/f81232.c
index f5c9060..0c96b9a 100644
--- a/drivers/usb/serial/f81232.c
+++ b/drivers/usb/serial/f81232.c
@@ -31,14 +31,19 @@ static const struct usb_device_id id_table[] = {
};
MODULE_DEVICE_TABLE(usb, id_table);
+/* Maximum baudrate for F81232 */
+#define F81232_MAX_BAUDRATE 115200
+
/* USB Control EP parameter */
#define F81232_REGISTER_REQUEST 0xA0
#define F81232_GET_REGISTER 0xc0
#define F81232_SET_REGISTER 0x40
#define SERIAL_BASE_ADDRESS 0x0120
+#define RECEIVE_BUFFER_REGISTER (0x00 + SERIAL_BASE_ADDRESS)
#define INTERRUPT_ENABLE_REGISTER(0x01 + SERIAL_BASE_ADDRESS)
#define FIFO_CONTROL_REGISTER(0x02 + SERIAL_BASE_ADDRESS)
+#define LINE_CONTROL_REGISTER(0x03 + SERIAL_BASE_ADDRESS)
#define MODEM_CONTROL_REGISTER (0x04 + SERIAL_BASE_ADDRESS)
#define MODEM_STATUS_REGISTER(0x06 + SERIAL_BASE_ADDRESS)
@@ -64,6 +69,14 @@ struct f81232_private {
struct usb_serial_port *port;
};
+static int calc_baud_divisor(u32 baudrate)
+{
+ if (!baudrate)
+ return 0;
Check no longer needed since you added the check at the call site. Just
add a comment. In fact it look like you can get rid of this function
now.
+ else
+ return DIV_ROUND_CLOSEST(F81232_MAX_BAUDRATE, baudrate);
+}
+
static int f81232_get_register(struct usb_serial_port *port, u16 reg, u8
*data)
{
int status;
@@ -369,6 +382,52 @@ static void f81232_break_ctl(struct tty_struct *tty, int
break_state)
*/
}
+static void f81232_set_baudrate(struct usb_serial_port *port, int baudrate)
+{
+ u8 divisor, lcr;
+ int status = 0;
+
+ if (!baudrate)
+ return;
+
+ divisor = calc_baud_divisor(baudrate);
+
+ status = f81232_get_register(port, LINE_CONTROL_REGISTER,
+ lcr); /* get LCR */
+ if (status) {
+ dev_err(port-dev, %s failed to get LCR: %d\n,
+ __func__, status);
+ }
+
+ status = f81232_set_register(port, LINE_CONTROL_REGISTER,
+ lcr | UART_LCR_DLAB); /* Enable DLAB */
+ if (status) {
+ dev_err(port-dev, %s failed to set DLAB: %d\n,
+ __func__, status);
+ }
+
+ status = f81232_set_register(port, RECEIVE_BUFFER_REGISTER,
+ divisor 0x00ff); /* low */
+ if (status) {
+ dev_err(port-dev, %s failed to set baudrate MSB: %d\n,
+ __func__, status);
+ }
+
+ status = f81232_set_register(port, INTERRUPT_ENABLE_REGISTER,
+ (divisor 0xff00) 8); /* high */
+ if (status) {
+ dev_err(port-dev, %s failed to set baudrate LSB: %d\n,
+ __func__, status);
+ }
+
+ status = f81232_set_register(port, LINE_CONTROL_REGISTER,
+ lcr ~UART_LCR_DLAB);
+ if (status) {
+ dev_err(port-dev, %s failed to set DLAB: %d\n,
+ __func__, status);
+ }
+}
Again, what about the error handling? No need to continue setting the
other registers should the first one fail, right? And you always want to
restore LCR to its previous value.
+
static int f81232_port_enable(struct usb_serial_port *port, int enable)
{
u8 data = 0;
@@ -399,15 +458,54 @@ static int f81232_port_enable(struct usb_serial_port
*port, int enable)
static void f81232_set_termios(struct tty_struct *tty,
struct usb_serial_port *port, struct ktermios *old_termios)
{
- /* FIXME - Stubbed out for now */
+ u8 new_lcr = 0;
+ int status = 0;
+
/* Don't change anything if nothing has changed */
if (old_termios !tty_termios_hw_change(tty-termios, old_termios))
return;
- /* Do the real work here... */
- if (old_termios)
- tty_termios_copy_hw(tty-termios, old_termios);
+ if (C_BAUD(tty) == B0)
+ f81232_set_mctrl(port, 0, TIOCM_DTR | TIOCM_RTS);
+ else if (old_termios (old_termios-c_cflag CBAUD) == B0)
+ f81232_set_mctrl(port, TIOCM_DTR | TIOCM_RTS, 0);
+
+ f81232_set_baudrate(port, tty_get_baud_rate(tty));
Check for B0 here instead of in the helper.
And what about unsupported baudrates (e.g. 115200 baud)? You should
return the baudrate actually
Re: [PATCH V7 06/11] USB: f81232: implement MCR/MSR function
On Tue, Feb 24, 2015 at 06:16:21PM +0800, Peter Hung wrote:
This patch implement relative MCR/MSR function, such like
tiocmget()/tiocmset()/dtr_rts()/carrier_raised()
original f81232_carrier_raised() compared with wrong value UART_DCD.
It's should compared with UART_MSR_DCD.
Signed-off-by: Peter Hung hpeter+linux_ker...@gmail.com
This patch as well as a few of the other patches in v7 now have
checkpatch warnings and errors.
---
drivers/usb/serial/f81232.c | 103
++--
1 file changed, 81 insertions(+), 22 deletions(-)
diff --git a/drivers/usb/serial/f81232.c b/drivers/usb/serial/f81232.c
index 339be30..21f606f 100644
--- a/drivers/usb/serial/f81232.c
+++ b/drivers/usb/serial/f81232.c
@@ -37,6 +37,7 @@ MODULE_DEVICE_TABLE(usb, id_table);
#define F81232_SET_REGISTER 0x40
#define SERIAL_BASE_ADDRESS 0x0120
+#define MODEM_CONTROL_REGISTER (0x04 + SERIAL_BASE_ADDRESS)
#define MODEM_STATUS_REGISTER(0x06 + SERIAL_BASE_ADDRESS)
#define CONTROL_DTR 0x01
@@ -55,7 +56,7 @@ MODULE_DEVICE_TABLE(usb, id_table);
struct f81232_private {
struct mutex lock;
- u8 line_control;
+ u8 modem_control;
u8 modem_status;
struct work_struct interrupt_work;
struct usb_serial_port *port;
@@ -198,6 +199,52 @@ static void f81232_read_msr(struct usb_serial_port *port)
wake_up_interruptible(port-port.delta_msr_wait);
}
+static int f81232_set_mctrl(struct usb_serial_port *port,
+unsigned int set, unsigned int clear)
+{
+ u8 urb_value;
+ int status;
+ struct f81232_private *priv = usb_get_serial_port_data(port);
+
+ if (((set | clear) (TIOCM_DTR | TIOCM_RTS)) == 0)
+ return 0; /* no change */
+
+ /* 'set' takes precedence over 'clear' */
+ clear = ~set;
+
+ /* force enable interrupt with OUT2 */
+ mutex_lock(priv-lock);
+ urb_value = UART_MCR_OUT2 | priv-modem_control;
+ mutex_unlock(priv-lock);
So this is one of the places where the port mute should protect the
whole operation.
+
+ if (clear TIOCM_DTR)
+ urb_value = ~UART_MCR_DTR;
+
+ if (clear TIOCM_RTS)
+ urb_value = ~UART_MCR_RTS;
+
+ if (set TIOCM_DTR)
+ urb_value |= UART_MCR_DTR;
+
+ if (set TIOCM_RTS)
+ urb_value |= UART_MCR_RTS;
+
+ dev_dbg(port-dev, %s new:%02x old:%02x\n, __func__,
+ urb_value, priv-modem_control);
+
+ status = f81232_set_register(port, MODEM_CONTROL_REGISTER, urb_value);
+ if (status) {
+ dev_err(port-dev, %s set MCR status 0\n, __func__);
+ return status;
+ } else {
+ mutex_lock(priv-lock);
+ priv-modem_control = urb_value;
+ mutex_unlock(priv-lock);
+ }
No need for else-branch as you return on errors.
+
+ return 0;
+}
Johan
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V7 07/11] USB: f81232: implement port_enable function
On Tue, Feb 24, 2015 at 06:16:22PM +0800, Peter Hung wrote:
We put FCR/IER initial step to f81232_port_enable(). When port is open,
it set MSR interrupt on. Otherwise set it off.
Signed-off-by: Peter Hung hpeter+linux_ker...@gmail.com
---
drivers/usb/serial/f81232.c | 39 +++
1 file changed, 39 insertions(+)
diff --git a/drivers/usb/serial/f81232.c b/drivers/usb/serial/f81232.c
index 21f606f..f5c9060 100644
--- a/drivers/usb/serial/f81232.c
+++ b/drivers/usb/serial/f81232.c
@@ -37,6 +37,8 @@ MODULE_DEVICE_TABLE(usb, id_table);
#define F81232_SET_REGISTER 0x40
#define SERIAL_BASE_ADDRESS 0x0120
+#define INTERRUPT_ENABLE_REGISTER(0x01 + SERIAL_BASE_ADDRESS)
+#define FIFO_CONTROL_REGISTER(0x02 + SERIAL_BASE_ADDRESS)
#define MODEM_CONTROL_REGISTER (0x04 + SERIAL_BASE_ADDRESS)
#define MODEM_STATUS_REGISTER(0x06 + SERIAL_BASE_ADDRESS)
@@ -367,6 +369,33 @@ static void f81232_break_ctl(struct tty_struct *tty, int
break_state)
*/
}
+static int f81232_port_enable(struct usb_serial_port *port, int enable)
Split this in two functions, enable and disable, since you don't need to
set FCR on close.
+{
+ u8 data = 0;
+ int status;
+
+ /* fifo on, trigger8, clear TX/RX*/
+ data = UART_FCR_TRIGGER_8 | UART_FCR_ENABLE_FIFO | UART_FCR_CLEAR_RCVR
+ | UART_FCR_CLEAR_XMIT;
Put the final | before the line break.
+
+ status = f81232_set_register(port, FIFO_CONTROL_REGISTER, data);
+ if (status) {
+ dev_err(port-dev, %s failed to set FCR: %d\n, __func__,
status);
+ return status;
+ }
+
+ /* MSR Interrupt only, LSR will read from Bulk-in odd byte */
+ data = enable ? UART_IER_MSI : 0;
+
+ status = f81232_set_register(port, INTERRUPT_ENABLE_REGISTER, data);
+ if (status) {
+ dev_err(port-dev, %s failed to set IER: %d\n, __func__,
status);
+ return status;
+ }
+
+ return 0;
+}
+
static void f81232_set_termios(struct tty_struct *tty,
struct usb_serial_port *port, struct ktermios *old_termios)
{
@@ -418,6 +447,12 @@ static int f81232_open(struct tty_struct *tty, struct
usb_serial_port *port)
{
int result;
+ result = f81232_port_enable(port, 1);
+ if (result) {
+ dev_err(port-dev, %s - init fail: %d\n, __func__, result);
+ return result;
You already log the error in port_enable.
+ }
+
/* Setup termios */
if (tty)
f81232_set_termios(tty, port, NULL);
@@ -440,6 +475,10 @@ static int f81232_open(struct tty_struct *tty, struct
usb_serial_port *port)
static void f81232_close(struct usb_serial_port *port)
{
+ int result = f81232_port_enable(port, 0);
Separate the declaration from the function call.
+ if (result)
+ dev_err(port-dev, %s - init fail: %d\n, __func__, result);
+
Already logged as well.
usb_serial_generic_close(port);
usb_kill_urb(port-interrupt_in_urb);
}
Johan
--
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] Add a quirk for the Dell XPS 13 (2015) when in PS/2 mode.
On Wednesday 25 February 2015 19:48:55 Mario Limonciello wrote: On 02/20/2015 02:41 PM, Pali Rohár wrote: On Friday 20 February 2015 20:56:23 Mario Limonciello wrote: resetafter=0 means to never reset (even if driver receive e.g thousand invalid packets). I think this is very dangerous if there will be other bugs either in linux driver or some other HW problems. For ALPS issue I added resetafter = pktsize * 2 (Allow 2 invalid packets without resetting device). Cannot you find something similar for synaptics touchpads on XPS? (pktsize for ALPS is 6, no idea how big are synaptics packets). Pali, I've done some experimentation with increasing the size to resetafter to up to pktsize * 4. It will decrease the number of occurrences of this problem, but the problem still occurs eventually. pktsize for synaptics is 6 as well. Would you recommend to continue to go higher than that? Since out_of_sync_cnt is reset when a full packet gets received, some arbitrarily high number should likely fix it to. That being said, if you try to more closely follow what Windows does for the mouse, it's not issuing a reconnect no matter how much bad data is received. I believe problem is similar to one as with ALPS devices. Driver always receive 6 bytes packet of data (no new byte is inserted and no byte is never lost), just one byte in packet is incorrect (does not match specification). Setting resetafter to 0 prevent problems when driver enters into undefined state (either by bug in driver of other SW/HW problem). So I think setting resetafter to 0 is not good idea. But if we know that setting resetafter to 4*pktsize is not enough (e.g. with experimenting you saw that driver received more then 4 invalid packets consecutively), set it to higher value. I think it is still good idea to ignore maximally as many packets which can be received in time which is equal to resetting device. E.g. when period of time in which we are dropping all packets is higher then time needed to reset touchpad, we should stop dropping packets and immediately reset touchpad. In this case we could hit maybe problem in driver (there can be bugs) or touchpad is in some bad state and out-of-sync... So if your tests show that there are never invalid 10 packets consecutively, then set resetafter to 10 packets. Value 10 is still not high and if it fix problem with touchpad I think it is acceptable. But rather ask Dmitry what he thinks about it. This is just my opinion. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: [PATCH 2/2] iio: jsa1212: Constify struct regmap_config
On 24/02/15 09:41, Krzysztof Kozlowski wrote:
The regmap_config struct may be const because it is not modified by the
driver and regmap_init() accepts pointer to const.
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
Applied to the togreg branch of iio.git. I'm having another of my periodic
days in a clean room (with a very dirty laptop), so will be a day or two before
I'm back home and can push out as testing for the autobuilders to play.
On the plus side, the machine I'm working on isn't running so lots of time
for patch review...
Jonathan
---
drivers/iio/light/jsa1212.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iio/light/jsa1212.c b/drivers/iio/light/jsa1212.c
index 29de7e7d9562..3a3af89beaf9 100644
--- a/drivers/iio/light/jsa1212.c
+++ b/drivers/iio/light/jsa1212.c
@@ -308,7 +308,7 @@ static bool jsa1212_is_volatile_reg(struct device *dev,
unsigned int reg)
}
}
-static struct regmap_config jsa1212_regmap_config = {
+static const struct regmap_config jsa1212_regmap_config = {
.name = JSA1212_REGMAP_NAME,
.reg_bits = 8,
.val_bits = 8,
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V7 05/11] USB: f81232: implement read IIR/MSR with endpoint
On Tue, Feb 24, 2015 at 06:16:20PM +0800, Peter Hung wrote:
The interrupt endpoint will report current IIR. If we got IIR with MSR changed
, We will do read MSR with interrupt_work worker to do f81232_read_msr()
function.
We also confirmd MSR strange delta value is not locking-issue. The issue
is set MCR get MSR before IIR notice with MSR changed (Loopback only).
But you are still not doing the actual register access under the mutex,
so this still sounds like it could be due to the shadow registers not
matching the hardware registers.
You need to update dtr_rts as well.
When we use RS232 loopback, assume doing RTS change will cause
CTS change, DTR change will cause DCD/DSR change too.
Sometimes we got 7~4 bits of MSR changed but the 3~0 bits of
MSR(delta) maybe not changed when set get MCR rapidly.
So we add more check not only UART_MSR_ANY_DELTA but also with
comparing DCD/RI/DSR/CTS change with old value. Because of the state
bit is always correct, we direct save msr when read.
The following step to reproduce this problem with while loop step 1~4:
1. ioctl(fd, TIOCMSET, data) to set RTS or DTR
2. ioctl(fd, TIOCMGET, data) to read CTS or DCD/DSR state
3. ioctl(fd, TIOCMSET, data) to unset RTS or DTR
4. ioctl(fd, TIOCMGET, data) to read CTS or DCD/DSR state
Signed-off-by: Peter Hung hpeter+linux_ker...@gmail.com
---
drivers/usb/serial/f81232.c | 106
1 file changed, 98 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/serial/f81232.c b/drivers/usb/serial/f81232.c
index bf072fe..339be30 100644
--- a/drivers/usb/serial/f81232.c
+++ b/drivers/usb/serial/f81232.c
@@ -36,6 +36,9 @@ MODULE_DEVICE_TABLE(usb, id_table);
#define F81232_GET_REGISTER 0xc0
#define F81232_SET_REGISTER 0x40
+#define SERIAL_BASE_ADDRESS 0x0120
+#define MODEM_STATUS_REGISTER(0x06 + SERIAL_BASE_ADDRESS)
+
#define CONTROL_DTR 0x01
#define CONTROL_RTS 0x02
@@ -54,6 +57,8 @@ struct f81232_private {
struct mutex lock;
u8 line_control;
u8 modem_status;
+ struct work_struct interrupt_work;
+ struct usb_serial_port *port;
};
static int f81232_get_register(struct usb_serial_port *port, u16 reg, u8
*data)
@@ -130,17 +135,92 @@ static int f81232_set_register(struct usb_serial_port
*port, u16 reg, u8 data)
kfree(tmp);
return status;
}
+
+static void f81232_read_msr(struct usb_serial_port *port)
+{
+ int status;
+ u8 current_msr, prev_msr;
+ u8 msr_mask = ~UART_MSR_ANY_DELTA;
+ u8 msr_changed_bit;
+ struct tty_struct *tty;
+ struct f81232_private *priv = usb_get_serial_port_data(port);
+
+ status = f81232_get_register(port, MODEM_STATUS_REGISTER,
+ current_msr);
+ if (status) {
+ dev_err(port-dev, %s fail, status: %d\n, __func__, status);
+ return;
+ }
+
+ /*
+ * The 7~4 bits of MSR will change but the 3~0 bits of MSR(delta)
+ * maybe not change when set MCR get MSR rapidly.
+ *
+ * So we add more check with comparing DCD/RI/DSR/CTS
+ * change. and direct save msr when read.
+ */
The asterisks should be aligned.
+
+ mutex_lock(priv-lock);
+ prev_msr = priv-modem_status;
+ priv-modem_status = current_msr;
+ mutex_unlock(priv-lock);
+
+ if (!(current_msr UART_MSR_ANY_DELTA)
+ !((prev_msr ^ current_msr) msr_mask))
+ return;
+
+ /* find checked delta bits set */
+ msr_changed_bit =
+ (current_msr UART_MSR_ANY_DELTA) 4;
+
+ /* append with not delta but changed bits */
+ msr_changed_bit |= (prev_msr ^ current_msr) msr_mask;
+
+ if (msr_changed_bit UART_MSR_CTS)
+ port-icount.cts++;
+ if (msr_changed_bit UART_MSR_DSR)
+ port-icount.dsr++;
+ if (msr_changed_bit UART_MSR_RI)
+ port-icount.rng++;
+ if (msr_changed_bit UART_MSR_DCD) {
+
No empty line.
+ port-icount.dcd++;
+ tty = tty_port_tty_get(port-port);
+ if (tty) {
+
No empty line.
+ usb_serial_handle_dcd_change(port, tty,
+ current_msr UART_MSR_DCD);
+
+ tty_kref_put(tty);
+ }
+ }
+
+ wake_up_interruptible(port-port.delta_msr_wait);
+}
Johan
--
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/
