linux-next: Tree for Aug 27
Hi all, Changes since 20140826: The net tree lost its build failure. The usb.current tree gained a build failure for which I reverted a commit. The mfd tree lost its build failure. The percpu tree gained a build failure so I used the version from next-20140826. The staging tree still had its build failure for which I applied a fix patch. The akpm-current tree lost its build failure. The akpm tree lost its build failure and a patch that turned up elsewhere. Non-merge commits (relative to Linus' tree): 2028 2105 files changed, 56310 insertions(+), 35111 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use git pull to do so as that will try to merge the new linux-next release with the old one. You should use git fetch and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64 and a multi_v7_defconfig for arm. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (this fails its final link) and i386, sparc, sparc64 and arm defconfig. Below is a summary of the state of the merge. I am currently merging 220 trees (counting Linus' and 30 trees of patches pending for Linus' tree). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (68e370289c29 Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux) Merging fixes/master (23cf8d3ca0fd powerpc: Fix attempt to move .org backwards error) Merging kbuild-current/rc-fixes (7d1311b93e58 Linux 3.17-rc1) Merging arc-current/for-curr (89ca3b881987 Linux 3.15-rc4) Merging arm-current/fixes (e57e41931134 ARM: wire up memfd_create syscall) Merging m68k-current/for-linus (9117710a5997 m68k/sun3: Remove define statement no longer needed) Merging metag-fixes/fixes (ffe6902b66aa asm-generic: remove _STK_LIM_MAX) Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5) Merging powerpc-merge/merge (396a34340cdf powerpc: Fix endianness of flash_block_list in rtas_flash) Merging sparc/master (451fd72219dd Merge tag 'pwm/for-3.17-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm) Merging net/master (2d39d120781a mvneta: Add missing if_vlan.h include.) Merging ipsec/master (21009686662f net: phy: smsc: move smsc_phy_config_init reset part in a soft_reset function) Merging sound-current/for-linus (94a988a8ab91 ALSA: pcm: Fix the silence data for DSD formats) Merging pci-current/for-linus (8d7004a6904c PCI: spear: Remove module option) Merging wireless/master (c66517165610 rtlwifi: rtl8192cu: Add new ID) Merging driver-core.current/driver-core-linus (52addcf9d666 Linux 3.17-rc2) Merging tty.current/tty-linus (52addcf9d666 Linux 3.17-rc2) Merging usb.current/usb-linus (039368901ad0 usb: ehci/ohci-exynos: Fix PHY getting sequence) [master e4fe9423adda] Revert usb: hub: Prevent hub autosuspend if usbcore.autosuspend is -1 Merging usb-gadget-fixes/fixes (5d19703822da usb: gadget: remove $(PWD) in ccflags-y) Merging usb-serial-fixes/usb-linus (646907f5bfb0 USB: ftdi_sio: Added PID for new ekey device) Merging staging.current/staging-linus (a2fa6721c723 staging: r8188eu: Add new USB ID) Merging char-misc.current/char-misc-linus (72ad366f687d thunderbolt: Clear hops before overwriting) Merging input-current/for-linus (a2418fc4a13b Input: elantech - add support for trackpoint found on some v3 models) Merging md-current/for-linus (d47648fcf061 raid5: avoid finding discard stripe) Merging crypto-current/master (ce5481d01f67 crypto: drbg - fix failure of generating multiple of 2**16 bytes) Merging ide/master (a53dae49b2fe ide: use module_platform_driver()) Merging dwmw2/master (5950f0803ca9 pcmcia: remove RPX board stuff) Merging devicetree-current/devicetree/merge (5a12a597a862 arm: Add devicetree fixup machine function) Merging rr-fixes/fixes (ff7e0055bb5d module: Clean up ro/nx after early module load failures) Merging vfio-fixes/for-linus (239a87020b26 Merge branch 'for-joerg/arm-smmu/fixes' of
Re: [PATCH RFC v7 net-next 00/28] BPF syscall
From: Alexei Starovoitov a...@plumgrid.com Date: Tue, 26 Aug 2014 19:29:14 -0700 posting whole thing again as RFC to get feedback on syscall only. If syscall bpf(int cmd, union bpf_attr *attr, unsigned int size) is ok, I'm personally not reviewing such a large patch series, sorry. You need to submit smaller sets if you want to get reasonable review of your changes and ideas. -- 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] ice1712: Replacing hex with #defines
At Tue, 26 Aug 2014 23:21:48 -0500, Konstantinos Tsimpoukas wrote: Adds to te readability of the ice1712 driver. Signed-off-by: Konstantinos Tsimpoukas kostaslinu...@gmail.com Thanks, applied. Takashi --- sound/pci/ice1712/ice1712.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/pci/ice1712/ice1712.c b/sound/pci/ice1712/ice1712.c index 87f7fc4..206ed2c 100644 --- a/sound/pci/ice1712/ice1712.c +++ b/sound/pci/ice1712/ice1712.c @@ -2528,7 +2528,7 @@ static int snd_ice1712_free(struct snd_ice1712 *ice) if (!ice-port) goto __hw_end; /* mask all interrupts */ - outb(0xc0, ICEMT(ice, IRQ)); + outb(ICE1712_MULTI_CAPTURE | ICE1712_MULTI_PLAYBACK, ICEMT(ice, IRQ)); outb(0xff, ICEREG(ice, IRQMASK)); /* --- */ __hw_end: -- 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: Oops: 17 SMP ARM (v3.16-rc2)
Hi Iain, Russell and Fabio, The config is attached. Note that there's a lot of additional stuff enabled as I'm aiming for a single general purpose kernel that covers i.MX6, AM3359, Allwinner A10/A20 along with several versions of boards using those particular SoCs. Same kernel binary on all the boards I've tried this on, only real differences will be the devicetree and u-boot Amazingly we have been able to run a complete nightly test on eight i.MX6 boards without hickups using Iain's config! We had to modify it slightly to get it to boot, please find attached patch and Iain's patched config. On Russell's suggestion we also began to disable flow control on the machines. However it did not seem to make a difference because all our Zynq cards stalled during the same test run (using our own Zynq config). Iain's config seems promising and we will continue to run tests during the next couple of days. We will also try to adapt Iain's config to our Zynq board. Many thanks for all suggestions, patches and configs so far! Best regards, Mattis Lorentzon *** Consider the environment before printing this message. To read Autoliv's Information and Confidentiality Notice, follow this link: http://www.autoliv.com/disclaimer.html *** config.patch Description: config.patch config.gz Description: config.gz
Re: [PATCH v1 00/12] dmaengine: dw: remove slave_id, add PCI support
On Wed, Aug 20, 2014 at 9:17 AM, Hans-Christian Egtvedt egtv...@samfundet.no wrote: Around Tue 19 Aug 2014 20:29:11 +0300 or thereabout, Andy Shevchenko wrote: The patchset is targeting two things: - removal of slave_id which is deprecated (suggested by Arnd Bergmann) - support BayTrail and Braswell SoCs in PCI case They are tight with each other, thus comes in one series. The patch set was BAT tested on Braswell and BayTrail machines. We would like to push this through slave-dma tree, so, Mark, Greg, Hans-Christian, and Haavard, please, Ack them if you have no objections. I had a look through the patches touching Atmel and AVR32 related files, mostly things I originally wrote or maintain. They seem all good, feel free to push the changes through the slave-dma tree. Thank you! -- With Best Regards, Andy Shevchenko -- 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 v1 00/12] dmaengine: dw: remove slave_id, add PCI support
On Wed, Aug 27, 2014 at 1:39 AM, Greg Kroah-Hartman gre...@linuxfoundation.org wrote: On Tue, Aug 26, 2014 at 06:27:25PM +0300, Andy Shevchenko wrote: On Tue, 2014-08-19 at 20:29 +0300, Andy Shevchenko wrote: Greg, gently ping you to get your Ack (or comments) on patches 11/12 and 12/12. Oops, sorry about that, you should now have my acks for both of these. No problem and thank you! -- With Best Regards, Andy Shevchenko -- 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: [PATCHv10 2/2] arm: dts: Add Altera SDRAM EDAC bindings devicetree entries.
On Tue, Aug 26, 2014 at 03:28:10PM -0500, Dinh Nguyen wrote: If Boris is okay with driver part and everyone else is OK with the DTS portion, then I can apply the DTS patch to my tree, and Boris take the driver patch into his tree? Actually, it would be easier for everyone involved if those patches go together due to their dependency. So if you want me to take a look at the EDAC parts again and give you my ack so that you can pick them all up together and they go through your tree, let me know. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 09/26] irqchip: mxs: convert to handle_domain_irq
On Tue, Aug 26, 2014 at 11:03:24AM +0100, Marc Zyngier wrote: Use the new handle_domain_irq method to handle interrupts. Signed-off-by: Marc Zyngier marc.zyng...@arm.com Acked-by: Shawn Guo shawn@freescale.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 22/26] ARM: imx: avic: convert to handle_domain_irq
On Tue, Aug 26, 2014 at 11:03:37AM +0100, Marc Zyngier wrote: Use the new handle_domain_irq method to handle interrupts. Signed-off-by: Marc Zyngier marc.zyng...@arm.com Acked-by: Shawn Guo shawn@freescale.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 23/26] ARM: imx: tzic: convert to handle_domain_irq
On Tue, Aug 26, 2014 at 11:03:38AM +0100, Marc Zyngier wrote: Use the new handle_domain_irq method to handle interrupts. Signed-off-by: Marc Zyngier marc.zyng...@arm.com Acked-by: Shawn Guo shawn@freescale.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] regulator: max77802: set opmode to normal if off is read from hw
Tested-by: Yuvaraj Kumar CD yuvaraj...@samsung.com On Tue, Aug 26, 2014 at 5:07 PM, Javier Martinez Canillas javier.marti...@collabora.co.uk wrote: The max77802 driver reads the default operating mode (opmode) set for regulators when enabled from the hardware registers. But if a regulator is disabled and the system warm restarted, the hardware reports OFF as the opmode so the regulator is not enabled. Default to operating mode NORMAL if OFF is read from the hardware register. Reported-by: Yuvaraj Cd yuvaraj.l...@gmail.com Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk --- This patch fixes the issue reported in https://lkml.org/lkml/2014/8/25/69 drivers/regulator/max77802.c | 12 +++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/drivers/regulator/max77802.c b/drivers/regulator/max77802.c index ad1caa9..967e109 100644 --- a/drivers/regulator/max77802.c +++ b/drivers/regulator/max77802.c @@ -540,7 +540,17 @@ static int max77802_pmic_probe(struct platform_device *pdev) config.of_node = pdata-regulators[i].of_node; ret = regmap_read(iodev-regmap, regulators[i].enable_reg, val); - max77802-opmode[id] = val shift MAX77802_OPMODE_MASK; + val = val shift MAX77802_OPMODE_MASK; + + /* +* If the regulator is disabled and the system warm rebooted, +* the hardware reports OFF as the regulator operating mode. +* Default to operating mode NORMAL in that case. +*/ + if (val == MAX77802_OPMODE_OFF) + max77802-opmode[id] = MAX77802_OPMODE_NORMAL; + else + max77802-opmode[id] = val; rdev = devm_regulator_register(pdev-dev, regulators[i], config); -- 2.0.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ARM: multi_v7_defconfig: Enable Tegra AHCI driver
This enables AHCI_TEGRA by default. This driver is required for Serial ATA support on Tegra124-based boards. Signed-off-by: Mikko Perttunen mperttu...@nvidia.com --- arch/arm/configs/multi_v7_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig index 5fb95fb..affd9ee 100644 --- a/arch/arm/configs/multi_v7_defconfig +++ b/arch/arm/configs/multi_v7_defconfig @@ -132,6 +132,7 @@ CONFIG_ATA=y CONFIG_SATA_AHCI_PLATFORM=y CONFIG_AHCI_ST=y CONFIG_AHCI_SUNXI=y +CONFIG_AHCI_TEGRA=y CONFIG_SATA_HIGHBANK=y CONFIG_SATA_MV=y CONFIG_NETDEVICES=y -- 1.8.1.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/
Re: [PATCH] ASoC: fsl-sai: using 'lsb-first' property instead of 'big-endian-data'.
On Tue, Aug 26, 2014 at 7:12 PM, li.xi...@freescale.com li.xi...@freescale.com wrote: This property used for configuring whether the LSB or the MSB is transmitted first for the fifo data. I don't follow the rationale for this change. This looks like a pointless renaming. Why is this any better? This is originally to indicate whether the LSB firstly or MSB firstly will be transmitted to the CODEC or received from the CODEC, and there has nothing Relation to the memory data. Generally, if the audio data in big endian format, which will be using the bytes Reversion ? Here this can only be used to bits reversion. That's why I suggested previously: mention it in the commit comment. People will have no idea about what's the exact reason for this change. Any functional enhancement? Or a bug fix(more likely for this one). I'm not sure what I described in the previous mail is correct or not. But you probably should have added it into the commit comments. And Xiubo, this patch still hasn't fixed the issue of breaking the old DT, although system can pass during the probe() section. Thank you, Nicolin -- 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] Staging: comedi: Fix code style in jr3_pci.c
From: Vladimir A. Nazarenko nas...@ya.ru
Static variables are initialised to 0 by GCC.
Fixes checkpatch.pl error:
ERROR: do not initialise statics to 0 or NULL
#684: FILE: jr3_pci.c:684:
+ static const struct jr3_pci_board *board = NULL;
Signed-off-by: Vladimir A. Nazarenko nas...@ya.ru
---
drivers/staging/comedi/drivers/jr3_pci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/comedi/drivers/jr3_pci.c
b/drivers/staging/comedi/drivers/jr3_pci.c
index 7b20e19..81fab2d 100644
--- a/drivers/staging/comedi/drivers/jr3_pci.c
+++ b/drivers/staging/comedi/drivers/jr3_pci.c
@@ -681,7 +681,7 @@ static int jr3_pci_auto_attach(struct comedi_device *dev,
unsigned long context)
{
struct pci_dev *pcidev = comedi_to_pci_dev(dev);
- static const struct jr3_pci_board *board = NULL;
+ static const struct jr3_pci_board *board;
struct jr3_pci_dev_private *devpriv;
struct jr3_pci_subdev_private *spriv;
struct comedi_subdevice *s;
--
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: GET_RNG_SEED hypercall ABI? (Re: [PATCH v5 0/5] random,x86,kvm: Rework arch RNG seeds and get some from kvm)
Il 27/08/2014 01:58, Andy Lutomirski ha scritto: hpa pointed out that the ABI that I chose (an MSR from the KVM range and a KVM cpuid bit) is unnecessarily KVM-specific. It would be nice to allocate an MSR that everyone involved can agree on and, rather than relying on a cpuid bit, just have the guest probe for the MSR. This leads to a few questions: 1. How do we allocate an MSR? (For background, this would be an MSR that either returns 64 bits of best-effort cryptographically secure random data or fails with #GP.) Ask Intel? :) 2. For KVM, what's the right way to allow QEMU to turn the feature on and off? Is this even necessary? KVM currently doesn't seem to allow QEMU to turn any of its MSRs off; it just allows QEMU to ask it to stop advertising support. Note that QEMU is not involved in the implementation of your feature, only in advertising it. You could look at CPUID at runtime, but that would mean teaching KVM to look for the KVMKVMKVM\0\0\0 signature in the CPUID data supplied by userspace. I don't think this is particularly useful. 3. QEMU people, can you please fix your RDMSR emulation to send #GP on failure? I can work around it for this MSR in the Linux code, but for Pete's sake... :( Sure, I will look at it. Though I expect it was done because of MSRs that are missing in QEMU (similar to how Linux doesn't #GP if compiled with pvops). Paolo -- 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/
[char-misc-next 10/10] mei: move mei_hbm_hdr function from hbm.h the hbm.c
mei_hbm_hder helper function is only used in hbm.c
so there is no need to define it in a header file
Signed-off-by: Tomas Winkler tomas.wink...@intel.com
---
V2: fix kdoc
drivers/misc/mei/hbm.c | 16
drivers/misc/mei/hbm.h | 9 -
2 files changed, 16 insertions(+), 9 deletions(-)
diff --git a/drivers/misc/mei/hbm.c b/drivers/misc/mei/hbm.c
index 24534ff..a7eb244 100644
--- a/drivers/misc/mei/hbm.c
+++ b/drivers/misc/mei/hbm.c
@@ -134,6 +134,22 @@ void mei_hbm_reset(struct mei_device *dev)
}
/**
+ * mei_hbm_hdr - construct hbm header
+ *
+ * @hdr: hbm header
+ * @length: payload length
+ */
+
+static inline void mei_hbm_hdr(struct mei_msg_hdr *hdr, size_t length)
+{
+ hdr-host_addr = 0;
+ hdr-me_addr = 0;
+ hdr-length = length;
+ hdr-msg_complete = 1;
+ hdr-reserved = 0;
+}
+
+/**
* mei_hbm_cl_hdr - construct client hbm header
*
* @cl: client
diff --git a/drivers/misc/mei/hbm.h b/drivers/misc/mei/hbm.h
index efcb0d4..b7cd3d8 100644
--- a/drivers/misc/mei/hbm.h
+++ b/drivers/misc/mei/hbm.h
@@ -44,15 +44,6 @@ const char *mei_hbm_state_str(enum mei_hbm_state state);
int mei_hbm_dispatch(struct mei_device *dev, struct mei_msg_hdr *hdr);
-static inline void mei_hbm_hdr(struct mei_msg_hdr *hdr, size_t length)
-{
- hdr-host_addr = 0;
- hdr-me_addr = 0;
- hdr-length = length;
- hdr-msg_complete = 1;
- hdr-reserved = 0;
-}
-
void mei_hbm_idle(struct mei_device *dev);
void mei_hbm_reset(struct mei_device *dev);
int mei_hbm_start_req(struct mei_device *dev);
--
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] ASoC: fsl-sai: using 'lsb-first' property instead of 'big-endian-data'.
Subject: Re: [PATCH] ASoC: fsl-sai: using 'lsb-first' property instead of 'big-endian-data'. On Tue, Aug 26, 2014 at 7:12 PM, li.xi...@freescale.com li.xi...@freescale.com wrote: This property used for configuring whether the LSB or the MSB is transmitted first for the fifo data. I don't follow the rationale for this change. This looks like a pointless renaming. Why is this any better? This is originally to indicate whether the LSB firstly or MSB firstly will be transmitted to the CODEC or received from the CODEC, and there has nothing Relation to the memory data. Generally, if the audio data in big endian format, which will be using the bytes Reversion ? Here this can only be used to bits reversion. That's why I suggested previously: mention it in the commit comment. People will have no idea about what's the exact reason for this change. Any functional enhancement? Or a bug fix(more likely for this one). I'm not sure what I described in the previous mail is correct or not. But you probably should have added it into the commit comments. And Xiubo, this patch still hasn't fixed the issue of breaking the old DT, although system can pass during the probe() section. Beside LS1+, who else is using this now ? And the LS1 dts files are still doing The upstream for now. Thanks, BRs Xiubo -- 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] ASoC: fsl-sai: using 'lsb-first' property instead of 'big-endian-data'.
On Tue, Aug 26, 2014 at 11:53:56PM -0700, Nicolin Chen wrote: That's why I suggested previously: mention it in the commit comment. People will have no idea about what's the exact reason for this change. Any functional enhancement? Or a bug fix(more likely for this one). I'm not sure what I described in the previous mail is correct or not. But you probably should have added it into the commit comments. Right, this is a good idea - make sure people can understand what the goal of the change is. And Xiubo, this patch still hasn't fixed the issue of breaking the old DT, although system can pass during the probe() section. Indeed. Please do this. signature.asc Description: Digital signature
Re: [PATCH v5 4/4] drivers/hwmon/menf21bmc_hwmon: introduce MEN14F021P00 BMC HWMON driver
On Tue, Aug 26, 2014 at 10:15:41AM -0700, Guenter Roeck wrote: On Tue, Aug 26, 2014 at 07:46:53PM +0200, Andreas Werner wrote: Added driver to support the 14F021P00 BMC Hardware Monitoring. The BMC is a Board Management Controller including monitoring of the board voltages. Signed-off-by: Andreas Werner andreas.wer...@men.de Hi Andreas, Couple of additional comments below. Sorry I didn't notice earlier. Guenter --- Documentation/hwmon/menf21bmc | 49 + drivers/hwmon/Kconfig | 7 ++ drivers/hwmon/Makefile | 1 + drivers/hwmon/menf21bmc_hwmon.c | 230 4 files changed, 287 insertions(+) create mode 100644 Documentation/hwmon/menf21bmc create mode 100644 drivers/hwmon/menf21bmc_hwmon.c diff --git a/Documentation/hwmon/menf21bmc b/Documentation/hwmon/menf21bmc new file mode 100644 index 000..22b6840 --- /dev/null +++ b/Documentation/hwmon/menf21bmc @@ -0,0 +1,49 @@ +Kernel driver menf21bmc_hwmon += + +Supported chips: + * MEN 14F021P00 + Prefix: 'menf21bmc_hwmon' + Adresses scanned: - + +Author: Andreas Werner andreas.wer...@men.de + +Description +--- + +The menf21bmc is a Board Management Controller (BMC) which provides an I2C +interface to the host to access the features implemented in the BMC. + +This driver gives access to the voltage monitoring feature of the main +voltages of the board. +The voltage sensors are connected to the ADC inputs of the BMC which is +a PIC16F917 Mikrocontroller. + +Usage Notes +--- + +This driver does not auto-detect devices. You will have to instantiate the +devices explicitly. Please see Documentation/i2c/instantiating-devices for +details. + +Sysfs entries +- + +The following attributes are supported. All attributes are read only +The Limits are read once by the driver. + +in0_input +3.3V input voltage +in1_input +5.0V input voltage +in2_input +12.0V input voltage +in3_input +5V Standby input voltage +in4_input VBAT (on board battery) + +in[0-4]_minMinimum voltage limit +in[0-4]_maxMaximum voltage limit + +in0_label MON_3_3V +in1_label MON_5V +in2_label MON_12V +in3_label 5V_STANDBY +in4_label VBAT + The empty line adds a whitespace error when applying the patch. OK, will delete the line. diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig index 37908ff..db3a6eb 100644 --- a/drivers/hwmon/Kconfig +++ b/drivers/hwmon/Kconfig @@ -828,6 +828,13 @@ config SENSORS_MCP3021 This driver can also be built as a module. If so, the module will be called mcp3021. +config SENSORS_MENF21BMC_HWMON + tristate MEN 14F021P00 BMC Hardware Monitoring + depends on MFD_MENF21BMC + help + Say Y here to include support for the MEN 14F021P00 BMC + hardware monitoring. + It is customary to add a note describing how the module is called if the driver is built as module. OK i just write a line which describes the module name. config SENSORS_ADCXX tristate National Semiconductor ADCxxxSxxx depends on SPI_MASTER diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile index 1362382..56ab872 100644 --- a/drivers/hwmon/Makefile +++ b/drivers/hwmon/Makefile @@ -114,6 +114,7 @@ obj-$(CONFIG_SENSORS_MAX6650) += max6650.o obj-$(CONFIG_SENSORS_MAX6697) += max6697.o obj-$(CONFIG_SENSORS_MC13783_ADC)+= mc13783-adc.o obj-$(CONFIG_SENSORS_MCP3021) += mcp3021.o +obj-$(CONFIG_SENSORS_MENF21BMC_HWMON) += menf21bmc_hwmon.o obj-$(CONFIG_SENSORS_NCT6683) += nct6683.o obj-$(CONFIG_SENSORS_NCT6775) += nct6775.o obj-$(CONFIG_SENSORS_NTC_THERMISTOR) += ntc_thermistor.o diff --git a/drivers/hwmon/menf21bmc_hwmon.c b/drivers/hwmon/menf21bmc_hwmon.c new file mode 100644 index 000..2eaec6a --- /dev/null +++ b/drivers/hwmon/menf21bmc_hwmon.c @@ -0,0 +1,230 @@ +/* + * MEN 14F021P00 Board Management Controller (BMC) hwmon driver. + * + * This is the core hwmon driver of the MEN 14F021P00 BMC. + * The BMC monitors the board voltages which can be access with this + * driver through sysfs. + * + * Copyright (C) 2014 MEN Mikro Elektronik Nuernberg GmbH + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the + * Free Software Foundation; either version 2 of the License, or (at your + * option) any later version. + */ + +#include linux/module.h +#include linux/kernel.h +#include linux/platform_device.h +#include linux/hwmon.h +#include linux/hwmon-sysfs.h +#include linux/jiffies.h +#include linux/slab.h +#include linux/i2c.h + +#define DRV_NAME menf21bmc_hwmon + +#define
Re: GET_RNG_SEED hypercall ABI? (Re: [PATCH v5 0/5] random,x86,kvm: Rework arch RNG seeds and get some from kvm)
On 08/27/2014 12:00 AM, Paolo Bonzini wrote: Il 27/08/2014 01:58, Andy Lutomirski ha scritto: hpa pointed out that the ABI that I chose (an MSR from the KVM range and a KVM cpuid bit) is unnecessarily KVM-specific. It would be nice to allocate an MSR that everyone involved can agree on and, rather than relying on a cpuid bit, just have the guest probe for the MSR. This leads to a few questions: 1. How do we allocate an MSR? (For background, this would be an MSR that either returns 64 bits of best-effort cryptographically secure random data or fails with #GP.) Ask Intel? :) I'm going to poke around internally. Intel might as a matter of policy be reluctant to assign an MSR index specifically for software use, but I'll try to find out. -hpa -- 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] mfd: rn5t618: document device tree bindings
On Wed, Aug 27, 2014 at 12:13:57AM +0200, Beniamino Galvani wrote: This adds the device tree bindings documentation for Ricoh RN5T618. Reviwed-by: Mark Brown broo...@linaro.org signature.asc Description: Digital signature
RE: [PATCH] ASoC: fsl-sai: using 'lsb-first' property instead of 'big-endian-data'.
Subject: Re: [PATCH] ASoC: fsl-sai: using 'lsb-first' property instead of 'big-endian-data'. On Tue, Aug 26, 2014 at 11:53:56PM -0700, Nicolin Chen wrote: That's why I suggested previously: mention it in the commit comment. People will have no idea about what's the exact reason for this change. Any functional enhancement? Or a bug fix(more likely for this one). I'm not sure what I described in the previous mail is correct or not. But you probably should have added it into the commit comments. Right, this is a good idea - make sure people can understand what the goal of the change is. Okay, I will add this. Thanks, BRs Xiubo -- 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] HID: picolcd: sanity check report size in raw_event() callback
The report passed to us from transport driver could potentially be
arbitrarily large, therefore we better sanity-check it so that raw_data
that we hold in picolcd_pending structure are always kept within proper
bounds.
Cc: sta...@vger.kernel.org
Reported-by: Steven Vittitoe scvi...@google.com
Signed-off-by: Jiri Kosina jkos...@suse.cz
---
drivers/hid/hid-picolcd_core.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/hid/hid-picolcd_core.c b/drivers/hid/hid-picolcd_core.c
index acbb0210..020df3c 100644
--- a/drivers/hid/hid-picolcd_core.c
+++ b/drivers/hid/hid-picolcd_core.c
@@ -350,6 +350,12 @@ static int picolcd_raw_event(struct hid_device *hdev,
if (!data)
return 1;
+ if (size 64) {
+ hid_warn(hdev, invalid size value (%d) for picolcd raw
event\n,
+ size);
+ return 0;
+ }
+
if (report-id == REPORT_KEY_STATE) {
if (data-input_keys)
ret = picolcd_raw_keypad(data, report, raw_data+1,
size-1);
--
1.9.2
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] HID: magicmouse: sanity check report size in raw_event() callback
The report passed to us from transport driver could potentially be
arbitrarily large, therefore we better sanity-check it so that
magicmouse_emit_touch() gets only valid values of raw_id.
Cc: sta...@vger.kernel.org
Reported-by: Steven Vittitoe scvi...@google.com
Signed-off-by: Jiri Kosina jkos...@suse.cz
---
drivers/hid/hid-magicmouse.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/hid/hid-magicmouse.c b/drivers/hid/hid-magicmouse.c
index ecc2cbf..29a74c1 100644
--- a/drivers/hid/hid-magicmouse.c
+++ b/drivers/hid/hid-magicmouse.c
@@ -290,6 +290,11 @@ static int magicmouse_raw_event(struct hid_device *hdev,
if (size 4 || ((size - 4) % 9) != 0)
return 0;
npoints = (size - 4) / 9;
+ if (npoints 15) {
+ hid_warn(hdev, invalid size value (%d) for
TRACKPAD_REPORT_ID\n,
+ size);
+ return 0;
+ }
msc-ntouches = 0;
for (ii = 0; ii npoints; ii++)
magicmouse_emit_touch(msc, ii, data + ii * 9 + 4);
@@ -307,6 +312,11 @@ static int magicmouse_raw_event(struct hid_device *hdev,
if (size 6 || ((size - 6) % 8) != 0)
return 0;
npoints = (size - 6) / 8;
+ if (npoints 15) {
+ hid_warn(hdev, invalid size value (%d) for
MOUSE_REPORT_ID\n,
+ size);
+ return 0;
+ }
msc-ntouches = 0;
for (ii = 0; ii npoints; ii++)
magicmouse_emit_touch(msc, ii, data + ii * 8 + 6);
--
1.9.2
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 00/18] backlight: fix checkpatch warnings
On Wed, 27 Aug 2014, Jingoo Han wrote: This patchset fixes checkpatch warnings as follows. There is no functional change. WARNING: Missing a blank line after declarations WARNING: else is not generally useful after a break or return WARNING: void function return statements are not generally useful Changes for V2 - Added Lee Jones's Acked-by for 1~18th patches, except for 17th patch. - Fixed 17th patch, per Lee Jones's feedback. Jingoo Han (18) backlight: adp5520: add blank line after declarations backlight: adp8860: add blank line after declarations backlight: adp8870: add blank line after declarations backlight: ams369fg06: remove 'else' after a return backlight: corgi_lcd: add blank line after declarations backlight: cr_bllcd: add blank line after declarations backlight: ili922x: remove 'else' after a return backlight: ld9040: remove 'else' after a return backlight: lm3639: remove unnecessary return statements backlight: lms501kf03: remove 'else' after a return backlight: lp855x: add blank line after declarations backlight: pcf50633: add blank line after declarations backlight: s6e63m0: remove 'else' after a return backlight: tdo24m: add blank line after declarations backlight: wm831x_bl: add blank line after declarations backlight: jornada720: remove 'else' after a return backlight: jornada720: remove 'else' after a return backlight: omap1: add blank line after declarations I'll wait to see if Bryan has anything to add. If not, I'll apply them in a couple of days. --- drivers/video/backlight/adp5520_bl.c | 1 + drivers/video/backlight/adp8860_bl.c | 3 +++ drivers/video/backlight/adp8870_bl.c | 4 drivers/video/backlight/ams369fg06.c | 6 +++--- drivers/video/backlight/corgi_lcd.c | 1 + drivers/video/backlight/cr_bllcd.c | 1 + drivers/video/backlight/ili922x.c| 11 ++- drivers/video/backlight/jornada720_bl.c | 6 +++--- drivers/video/backlight/jornada720_lcd.c | 6 +- drivers/video/backlight/ld9040.c | 6 +++--- drivers/video/backlight/lm3639_bl.c | 2 -- drivers/video/backlight/lms501kf03.c | 12 ++-- drivers/video/backlight/lp855x_bl.c | 2 ++ drivers/video/backlight/omap1_bl.c | 1 + drivers/video/backlight/pcf50633-backlight.c | 1 + drivers/video/backlight/s6e63m0.c| 12 ++-- drivers/video/backlight/tdo24m.c | 2 ++ drivers/video/backlight/wm831x_bl.c | 1 + 18 files changed, 45 insertions(+), 33 deletions(-) -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/3] ARM: dts: Add Peach Pit dts entry for Atmel touchpad
Hello Andreas,
On 08/27/2014 12:53 AM, Andreas Färber wrote:
+hsi2c_8 {
+status = okay;
+clock-frequency = 333000;
+
+trackpad@4b {
+compatible=atmel,maxtouch;
+reg=0x4b;
+interrupt-parent=gpx1;
+interrupts=1 IRQ_TYPE_EDGE_FALLING;
Nit: Here's a style break (4x spaces around '=' missing).
True, these bits were copied from the downstream Chrome OS verbatim and
the missing space around '=' was there, I missed that when reviewing.
I'll re-spin and fix those style issues.
+wakeup-source;
+pinctrl-names = default;
+pinctrl-0 = trackpad_irq;
+linux,gpio-keymap = KEY_RESERVED
+ KEY_RESERVED
+ 0 /* GPIO 0 */
+ 0 /* GPIO 1 */
+ 0 /* GPIO 2 */
+ BTN_LEFT /* GPIO 3 */
+ KEY_RESERVED
+ KEY_RESERVED ;
+};
Coincidentally, I experimentally came up with a very similar DT node for
Spring the weekend:
+ trackpad@4b {
+ compatible = atmel,maxtouch;
+ reg = 0x4b;
+ interrupt-parent = gpx1;
+ interrupts = 2 IRQ_TYPE_NONE;
+ pinctrl-names = default;
+ pinctrl-0 = trackpad_irq;
+ linux,gpio-keymap = KEY_RESERVED
+ KEY_RESERVED
+ KEY_RESERVED
+ KEY_RESERVED
+ KEY_RESERVED
+ BTN_LEFT;
+ wakeup-source;
+ };
0 == KEY_RESERVED, so you can consistently use it for GPIO 0-2, too. :)
I know that the value of KEY_RESERVED is 0 but I didn't use KEY_RESERVED
for the GPIO on purpose.
What I understood is that the SPT_GPIOPWN_T19 object sends messages using
a status byte so you have a maximum of 8 GPIO but not every maXTouch
devices use all of them. So in the particular case of the device in the
Peach Pit, from the 8 possible GPIO only 4 can be used and these are pins
2-5. So in theory you could connect 3 more GPIO in case you had more
buttons (e.g: BTN_RIGHT, BTN_MIDDLE) but only 1 is used since the
Chromebook just have BTN_LEFT.
Nick sent a patch [0] that extend the atmel touchpad DT binding and the
doc says Use KEY_RESERVED for unused padding values. But is not clear
what value you should use for GPIO that are actually supported by the
device but have no keycode associated.
So by using 0 instead of KEY_RESERVED I wanted to document that pins 2-4
are actually supported and not reserved by the device but there is no
keycode associated with that GPIO.
If there was a BTN_NONE or KEY_UNUSED it would had been better but I think
that making a distinction between these two cases (reserved pin vs GPIO
available but not used) is useful.
I probably should add the two trailing _RESERVEDs, too?
I see that is used for properties that are arrays, for example
linux,keymap in Documentation/devicetree/bindings/input/matrix-keymap.txt.
With my above snippet I got an awful lot of Interrupt triggered but
zero messages warnings (which I simply commented out as quickfix).
Is that why you are using _EDGE_FALLING? Or pin-function 0xf?
(In my case the ChromeOS DT had IRQ_TYPE_NONE and pin-function 0x0.)
These are two separate but related things:
a) IRQF_TRIGGER_FALLING:
Yes, the Chrome OS DT for Peach Pit also has IRQ_TYPE_NONE but the DTS is
not correct.
If you look at the Chrome OS atmel driver
(drivers/input/touchscreen/atmel_mxt_ts.c), it passes IRQF_TRIGGER_FALLING
to request_threaded_irq():
/* Default to falling edge if no platform data provided */
irqflags = data-pdata ? data-pdata-irqflags : IRQF_TRIGGER_FALLING;
error = request_threaded_irq(client-irq, NULL, mxt_interrupt,
irqflags | IRQF_ONESHOT,
client-name, data);
The above code is wrong since is overwriting the edge/level type flags set
by OF when parsing the interrupts property so you have to use the
expected IRQ flags in your DTS.
b) pin-function 0xf instead of 0x0:
The pin-function 0x0 is GPIO input while 0xf is GPIO IRQ. Usually on other
SoCs to use a GPIO IRQ you just configure the pad as GPIO input and then
enable the pin as an interrupt but on Exynos SoC these are really two
different functions. So if you configure the pin as GPIO input and this
happens after the pin is configured as GPIO IRQ, interrupts are not triggered.
I faced that issue before [1] and was solved with Tomasz's commit:
f6a8249 pinctrl: exynos: Lock GPIOs as interrupts when used as EINTs
which changes the pinctrl-exynos driver to setup a pin as GPIO IRQ on
.irq_request_resources instead of .irq_set_type. So, with that patch even
when pin-function re-configures
[PATCH V3] ACPI / OSL: Make acpi_os_map_cleanup() use call_rcu() to avoid deadlocks
Deadlock is possible when CPU hotplug and evaluating ACPI method happen at the same time. During CPU hotplug, acpi_cpu_soft_notify() is called under the CPU hotplug lock. Then, acpi_cpu_soft_notify() calls acpi_bus_get_device() to obtain the struct acpi_device attached to the given ACPI handle. The ACPICA's namespace lock will be acquired by acpi_bus_get_device() in the process. Thus it is possible to hold the ACPICA's namespace lock under the CPU hotplug lock. Evaluating an ACPI method may involve accessing an operation region in system memory and the associated address space will be unmapped under the ACPICA's namespace lock after completing the access. Currently, osl.c uses RCU to protect memory ranges used by AML. When unmapping them it calls synchronize_rcu() in acpi_os_map_cleanup(), but that blocks CPU hotplug by acquiring the CPU hotplug lock. Thus it is possible to hold the CPU hotplug lock under the ACPICA's namespace lock. This leads to deadlocks like the following one if AML accessing operation regions in memory is executed in parallel with CPU hotplug. INFO: task bash:741 blocked for more than 30 seconds. Not tainted 3.16.0-rc5+ #671 echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. bashD 88014e214140 0 741716 0x0080 88009b9f3a10 0086 88009dcfb840 88009b9f3fd8 00014140 00014140 81c18460 81c40fc8 81c40fcc 88009dcfb840 81c40fd0 Call Trace: [817a1b29] schedule_preempt_disabled+0x29/0x70 [817a34fa] __mutex_lock_slowpath+0xca/0x1c0 [817a360f] mutex_lock+0x1f/0x2f [810bc8cc] get_online_cpus+0x2c/0x50 [8111bbd4] synchronize_sched_expedited+0x64/0x1c0 [8111bb65] synchronize_sched+0x45/0x50 [81431498] acpi_os_map_cleanup.part.7+0x14/0x3e [81795c54] acpi_os_unmap_iomem+0xe2/0xea [81795c6a] acpi_os_unmap_memory+0xe/0x14 [814459bc] acpi_ev_system_memory_region_setup+0x2d/0x97 [81459504] acpi_ut_update_ref_count+0x24d/0x2de [814596af] acpi_ut_update_object_reference+0x11a/0x18b [81459282] acpi_ut_remove_reference+0x2e/0x31 [8144ffdf] acpi_ns_detach_object+0x7b/0x80 [8144ef11] acpi_ns_delete_namespace_subtree+0x47/0x81 [81440488] acpi_ds_terminate_control_method+0x85/0x11b [81454625] acpi_ps_parse_aml+0x164/0x289 [81454da6] acpi_ps_execute_method+0x1c1/0x26c [8144f764] acpi_ns_evaluate+0x1c1/0x258 [81451f86] acpi_evaluate_object+0x126/0x22f [8144d1ac] acpi_hw_execute_sleep_method+0x3d/0x68 [8144d5cf] ? acpi_hw_enable_all_runtime_gpes+0x17/0x19 [8144deb0] acpi_hw_legacy_wake+0x4d/0x9d [8144e599] acpi_hw_sleep_dispatch+0x2a/0x2c [8144e5cb] acpi_leave_sleep_state+0x17/0x19 [8143335c] acpi_pm_finish+0x3f/0x99 [81108c49] suspend_devices_and_enter+0x139/0x560 [81109162] pm_suspend+0xf2/0x370 [81107e69] state_store+0x79/0xf0 [813bc4af] kobj_attr_store+0xf/0x20 [81284f3d] sysfs_kf_write+0x3d/0x50 [81284580] kernfs_fop_write+0xe0/0x160 [81210f47] vfs_write+0xb7/0x1f0 [81211ae6] SyS_write+0x46/0xb0 [8114d986] ? __audit_syscall_exit+0x1f6/0x2a0 [817a4ea9] system_call_fastpath+0x16/0x1b INFO: task async-enable-no:749 blocked for more than 30 seconds. Not tainted 3.16.0-rc5+ #671 echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. async-enable-no D 88014e254140 0 749 2 0x0080 88009de83bf0 0046 88009b85 88009de83fd8 00014140 00014140 880148305dc0 880149804160 7fff 0002 88009b85 Call Trace: [817a1689] schedule+0x29/0x70 [817a0b49] schedule_timeout+0x1f9/0x270 [81284bfe] ? __kernfs_create_file+0x7e/0xa0 [8128546b] ? sysfs_add_file_mode_ns+0x9b/0x160 [817a36b2] __down_common+0x93/0xd8 [817a376a] __down_timeout+0x16/0x18 [8110546c] down_timeout+0x4c/0x60 [81431f97] acpi_os_wait_semaphore+0x43/0x57 [8145a8f4] acpi_ut_acquire_mutex+0x48/0x88 [81435d1b] ? acpi_match_device+0x4f/0x4f [8145250f] acpi_get_data_full+0x3a/0x8e [81435b30] acpi_bus_get_device+0x23/0x40 [8145d839] acpi_cpu_soft_notify+0x50/0xe6 [810e1ddc] notifier_call_chain+0x4c/0x70 [810e1eee] __raw_notifier_call_chain+0xe/0x10 [810bc993] cpu_notify+0x23/0x50 [810bcb98] _cpu_up+0x168/0x180 [810bcc5c] _cpu_up_with_trace+0x2c/0xe0 [810bd050] ? disable_nonboot_cpus+0x1c0/0x1c0 [810bd06f] async_enable_nonboot_cpus+0x1f/0x70 [810dda02] kthread+0xd2/0xf0 [810dd930] ? insert_kthread_work+0x40/0x40 [817a4dfc] ret_from_fork+0x7c/0xb0 To avoid such
Re: [RFC PATCH 0/9] dt: dependencies (for deterministic driver initialization order based on the DT)
Am 26.08.2014 15:58, schrieb Jon Loeliger: I think we need to do the complete topsort *before* we attempt to do any probing. So three steps: 1) Graph Construction Add a new emit dependencies function to driver bindings. Iterate over known devices or nodes in the DT in any order. Call the emit dependencies function. It adds all dependency edges to a global graph by knowing what phandles or other pieces it will need. A driver with no emit dependencies function can be added to the graph anywhere without loss of generality. Add any additional edges for whatever reason. 2) Topsort the generated driver graph 3) Call probe for real in topsort order Alexander, I don't recall the details of your patch series. Can you please remind us if it took this approach in the kernel? Anyway, I'm leaving this discussion. I've already made a proposal which solved most mentioned problems (imho) and even offered usable patches Why should I? I've posted patches along with a lot of comments and explanations, and e.g. you are just talking that it should be made like my patches already did. And others do talk too like my patches and the accompanying comments from me which explain most stuff never have existed and just repeat what the patches already do without refering to them. Darn. I think you clearly have a pony in this race, and it would be good if you still participated. Really. Thanks. But I don't see it as a race and I don't want to take part in a race (and I usually avoid those silly contests which have become chic in the IT world). I just offered a solution (or at least a working starting point to a solution). (ok, they suffer under the not invented here syndrom, but ...). ;) There isn't a single thing in the entire Linux Kernel community that was invented here; every aspect of it was NIH'ed by *someone*. That's how it gets built, changed, maintained, fixed, etc. Might be true in an ideal open source world and might have been true for past kernel development when most people weren't full time kernel developers. But nowadays it appears to me like many parts of the kernel have become in the hands of closed groups. And they build and enforce hurdles that high, that nobody else can take them without spending an idiotic amount of time. Just like many other consortiums do, you only have to build enough rules to protect from the outside while still looking open. E.g. an example I've seen often is that someone spend a lot of time to examine and fix a bug and write a commented patch. And the only response from the maintainer was that he should add an emtpy line before a return statement and similiar silly things to enforce patch-ping-pong. Such just drives people on the other end crazy and they likely won't spend the time to post another patch (they still might fix other bugs, but just for themself). Regards, Alexander Holler -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [acpi/osl] inconsistent {SOFTIRQ-ON-W} - {IN-SOFTIRQ-R} usage.
On 2014年08月27日 10:27, Fengguang Wu wrote: Greetings, 0day kernel testing robot got the below dmesg and the first bad commit is Hi Fengguang: Thanks for report. I reworked the patch and just sent out V3 to umap memory regions in a work to avoid the dead lock. I tested the patch with your script and the issue doesn't reproduce. commit b11bc0be2f115a90949f1c26379f1288c8cde531 Author: Lan Tianyu tianyu@intel.com AuthorDate: Tue Aug 26 01:54:34 2014 +0200 Commit: Rafael J. Wysocki rafael.j.wyso...@intel.com CommitDate: Tue Aug 26 01:54:34 2014 +0200 ACPI / OSL: Make acpi_os_map_cleanup() use call_rcu() to avoid deadlocks Deadlock is possible when CPU hotplug and evaluating ACPI method happen at the same time. During CPU hotplug, acpi_cpu_soft_notify() is called under the CPU hotplug lock. Then, acpi_cpu_soft_notify() calls acpi_bus_get_device() to obtain the struct acpi_device attached to the given ACPI handle. The ACPICA's namespace lock will be acquired by acpi_bus_get_device() in the process. Thus it is possible to hold the ACPICA's namespace lock under the CPU hotplug lock. Evaluating an ACPI method may involve accessing an operation region in system memory and the associated address space will be unmapped under the ACPICA's namespace lock after completing the access. Currently, osl.c uses RCU to protect memory ranges used by AML. When unmapping them it calls synchronize_rcu() in acpi_os_map_cleanup(), but that blocks CPU hotplug by acquiring the CPU hotplug lock. Thus it is possible to hold the CPU hotplug lock under the ACPICA's namespace lock. This leads to deadlocks like the following one if AML accessing operation regions in memory is executed in parallel with CPU hotplug. INFO: task bash:741 blocked for more than 30 seconds. Not tainted 3.16.0-rc5+ #671 echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. bashD 88014e214140 0 741716 0x0080 88009b9f3a10 0086 88009dcfb840 88009b9f3fd8 00014140 00014140 81c18460 81c40fc8 81c40fcc 88009dcfb840 81c40fd0 Call Trace: [817a1b29] schedule_preempt_disabled+0x29/0x70 [817a34fa] __mutex_lock_slowpath+0xca/0x1c0 [817a360f] mutex_lock+0x1f/0x2f [810bc8cc] get_online_cpus+0x2c/0x50 [8111bbd4] synchronize_sched_expedited+0x64/0x1c0 [8111bb65] synchronize_sched+0x45/0x50 [81431498] acpi_os_map_cleanup.part.7+0x14/0x3e [81795c54] acpi_os_unmap_iomem+0xe2/0xea [81795c6a] acpi_os_unmap_memory+0xe/0x14 [814459bc] acpi_ev_system_memory_region_setup+0x2d/0x97 [81459504] acpi_ut_update_ref_count+0x24d/0x2de [814596af] acpi_ut_update_object_reference+0x11a/0x18b [81459282] acpi_ut_remove_reference+0x2e/0x31 [8144ffdf] acpi_ns_detach_object+0x7b/0x80 [8144ef11] acpi_ns_delete_namespace_subtree+0x47/0x81 [81440488] acpi_ds_terminate_control_method+0x85/0x11b [81454625] acpi_ps_parse_aml+0x164/0x289 [81454da6] acpi_ps_execute_method+0x1c1/0x26c [8144f764] acpi_ns_evaluate+0x1c1/0x258 [81451f86] acpi_evaluate_object+0x126/0x22f [8144d1ac] acpi_hw_execute_sleep_method+0x3d/0x68 [8144d5cf] ? acpi_hw_enable_all_runtime_gpes+0x17/0x19 [8144deb0] acpi_hw_legacy_wake+0x4d/0x9d [8144e599] acpi_hw_sleep_dispatch+0x2a/0x2c [8144e5cb] acpi_leave_sleep_state+0x17/0x19 [8143335c] acpi_pm_finish+0x3f/0x99 [81108c49] suspend_devices_and_enter+0x139/0x560 [81109162] pm_suspend+0xf2/0x370 [81107e69] state_store+0x79/0xf0 [813bc4af] kobj_attr_store+0xf/0x20 [81284f3d] sysfs_kf_write+0x3d/0x50 [81284580] kernfs_fop_write+0xe0/0x160 [81210f47] vfs_write+0xb7/0x1f0 [81211ae6] SyS_write+0x46/0xb0 [8114d986] ? __audit_syscall_exit+0x1f6/0x2a0 [817a4ea9] system_call_fastpath+0x16/0x1b INFO: task async-enable-no:749 blocked for more than 30 seconds. Not tainted 3.16.0-rc5+ #671 echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. async-enable-no D 88014e254140 0 749 2 0x0080 88009de83bf0 0046 88009b85 88009de83fd8 00014140 00014140 880148305dc0 880149804160 7fff 0002 88009b85 Call Trace: [817a1689] schedule+0x29/0x70 [817a0b49] schedule_timeout+0x1f9/0x270
[GIT PULL] HID
Linus, please pull from git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid.git for-linus to receive - fixes for potential memory corruption problems in magicmouse and picolcd drivers (the HW would have to be manufactured to be deliberately evil to trigger those) which were found by Steven Vittitoe - fix for false error message appearing in dmesg from logitech-dj driver, from Benjamin Tissoires Thanks. Benjamin Tissoires (1): HID: logitech-dj: prevent false errors to be shown Jiri Kosina (2): HID: magicmouse: sanity check report size in raw_event() callback HID: picolcd: sanity check report size in raw_event() callback drivers/hid/hid-logitech-dj.c | 43 -- drivers/hid/hid-logitech-dj.h | 1 + drivers/hid/hid-magicmouse.c | 10 ++ drivers/hid/hid-picolcd_core.c | 6 ++ 4 files changed, 42 insertions(+), 18 deletions(-) -- Jiri Kosina SUSE Labs -- 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] regulator: add driver for Ricoh RN5T618 regulators
On Wed, Aug 27, 2014 at 12:13:55AM +0200, Beniamino Galvani wrote: This driver supports the 3 DCDC and 7 LDO regulators available on Ricoh RN5T618 PMIC. drivers/regulator/rn5t618-regulator.c | 143 + include/linux/mfd/rn5t618.h | 14 This is fine but I can't apply it since you're patching the MFD header which you added in the first patch. It'd be better to include those changes in the first patch, making the second patch independant. signature.asc Description: Digital signature
Re: [PATCH v5 1/4] drivers/mfd/menf21bmc: introduce MEN 14F021P00 BMC MFD Core driver
On Tue, 26 Aug 2014, Andreas Werner wrote:
The MEN 14F021P00 Board Management Controller provides an
I2C interface to the host to access the feature implemented in the BMC.
The BMC is a PIC Microntroller assembled on CPCI Card from MEN Mikroelektronik
and on a few Box/Display Computer.
Added MFD Core driver, supporting the I2C communication to the device.
The MFD driver currently supports the following features:
- Watchdog
- LEDs
- Hwmon (voltage monitoring)
Signed-off-by: Andreas Werner andreas.wer...@men.de
Acked-by: Lee Jones lee.jo...@linaro.org
---
drivers/mfd/Kconfig | 12 +
drivers/mfd/Makefile| 1 +
drivers/mfd/menf21bmc.c | 132
3 files changed, 145 insertions(+)
create mode 100644 drivers/mfd/menf21bmc.c
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index b8d9ca0..6a9f101 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -453,6 +453,18 @@ config MFD_MAX8998
additional drivers must be enabled in order to use the functionality
of the device.
+config MFD_MENF21BMC
+ tristate MEN 14F021P00 Board Management Controller Support
+ depends on I2C
+ select MFD_CORE
+ help
+ Say yes here to add support for the MEN 14F021P00 BMC
+ which is a Board Management Controller connected to the I2C bus.
+ The device supports multiple sub-devices like LED, HWMON and WDT.
Nit: Whitespace error.
+ This driver provides common support for accessing the devices;
+ additional drivers must be enabled in order to use the
+ functionality of the BMC device.
+
config EZX_PCAP
bool Motorola EZXPCAP Support
depends on SPI_MASTER
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 4e2bc25..37bf336 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -169,6 +169,7 @@ obj-$(CONFIG_MFD_AS3711) += as3711.o
obj-$(CONFIG_MFD_AS3722) += as3722.o
obj-$(CONFIG_MFD_STW481X)+= stw481x.o
obj-$(CONFIG_MFD_IPAQ_MICRO) += ipaq-micro.o
+obj-$(CONFIG_MFD_MENF21BMC) += menf21bmc.o
intel-soc-pmic-objs := intel_soc_pmic_core.o intel_soc_pmic_crc.o
obj-$(CONFIG_INTEL_SOC_PMIC) += intel-soc-pmic.o
diff --git a/drivers/mfd/menf21bmc.c b/drivers/mfd/menf21bmc.c
new file mode 100644
index 000..a6eb03f
--- /dev/null
+++ b/drivers/mfd/menf21bmc.c
@@ -0,0 +1,132 @@
+/*
+ * MEN 14F021P00 Board Management Controller (BMC) MFD Core Driver.
+ *
+ * Copyright (C) 2014 MEN Mikro Elektronik Nuernberg GmbH
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include linux/kernel.h
+#include linux/device.h
+#include linux/module.h
+#include linux/i2c.h
+#include linux/mfd/core.h
+
+#define BMC_CMD_WDT_EXIT_PROD0x18
+#define BMC_CMD_WDT_PROD_STAT0x19
+#define BMC_CMD_REV_MAJOR0x80
+#define BMC_CMD_REV_MINOR0x81
+#define BMC_CMD_REV_MAIN 0x82
+
+static struct mfd_cell menf21bmc_cell[] = {
+ { .name = menf21bmc_wdt, },
+ { .name = menf21bmc_led, },
+ { .name = menf21bmc_hwmon, }
+};
+
+static int menf21bmc_wdt_exit_prod_mode(struct i2c_client *client)
+{
+ int val, ret;
+
+ val = i2c_smbus_read_byte_data(client, BMC_CMD_WDT_PROD_STAT);
+ if (val 0)
+ return val;
+
+ /*
+ * Production mode should be not active after delivery of the Board.
+ * To be sure we check it, inform the user and exit the mode
+ * if active.
+ */
+ if (val == 0x00) {
+ dev_info(client-dev,
+ BMC in production mode. Exit production mode\n);
+
+ ret = i2c_smbus_write_byte(client, BMC_CMD_WDT_EXIT_PROD);
+ if (ret 0)
+ return ret;
+ }
+
+ return 0;
+}
+
+static int
+menf21bmc_probe(struct i2c_client *client, const struct i2c_device_id *ids)
+{
+ int ret;
+ int rev_major, rev_minor, rev_main;
Really small nit (as you have to fix the whitespace err anyway):
Can you change the order of the two lines above please?
+ ret = i2c_check_functionality(client-adapter,
+ I2C_FUNC_SMBUS_BYTE_DATA |
+ I2C_FUNC_SMBUS_WORD_DATA |
+ I2C_FUNC_SMBUS_BYTE);
+ if (!ret)
+ return -ENODEV;
+
+ rev_major = i2c_smbus_read_word_data(client, BMC_CMD_REV_MAJOR);
+ if (rev_major 0) {
+ dev_err(client-dev, failed to get BMC major revision\n);
+ return rev_major;
+ }
+
+ rev_minor = i2c_smbus_read_word_data(client, BMC_CMD_REV_MINOR);
+ if (rev_minor 0) {
+
Re: [PATCH v5 3/4] zram: zram memory size limitation
On Wed, Aug 27, 2014 at 02:04:38PM +0900, Joonsoo Kim wrote:
On Wed, Aug 27, 2014 at 11:51:32AM +0900, Minchan Kim wrote:
Hey Joonsoo,
On Wed, Aug 27, 2014 at 10:26:11AM +0900, Joonsoo Kim wrote:
Hello, Minchan and David.
On Tue, Aug 26, 2014 at 08:22:29AM -0400, David Horner wrote:
On Tue, Aug 26, 2014 at 3:55 AM, Minchan Kim minc...@kernel.org wrote:
Hey Joonsoo,
On Tue, Aug 26, 2014 at 04:37:30PM +0900, Joonsoo Kim wrote:
On Mon, Aug 25, 2014 at 09:05:55AM +0900, Minchan Kim wrote:
@@ -513,6 +540,14 @@ static int zram_bvec_write(struct zram *zram,
struct bio_vec *bvec, u32 index,
ret = -ENOMEM;
goto out;
}
+
+ if (zram-limit_pages
+ zs_get_total_pages(meta-mem_pool)
zram-limit_pages) {
+ zs_free(meta-mem_pool, handle);
+ ret = -ENOMEM;
+ goto out;
+ }
+
cmem = zs_map_object(meta-mem_pool, handle, ZS_MM_WO);
Hello,
I don't follow up previous discussion, so I could be wrong.
Why this enforcement should be here?
I think that this has two problems.
1) alloc/free happens unnecessarilly if we have used memory over the
limitation.
True but firstly, I implemented the logic in zsmalloc, not zram but
as I described in cover-letter, it's not a requirement of zsmalloc
but zram so it should be in there. If every user want it in future,
then we could move the function into zsmalloc. That's what we
concluded in previous discussion.
Hmm...
Problem is that we can't avoid these unnecessary overhead in this
implementation. If we can implement this feature in zram efficiently,
it's okay. But, I think that current form isn't.
If we can add it in zsmalloc, it would be more clean and efficient
for zram but as I said, at the moment, I didn't want to put zram's
requirement into zsmalloc because to me, it's weird to enforce max
limit to allocator. It's client's role, I think.
AFAIK, many kinds of pools such as thread-pool or memory-pool have
their own limit. It's not weird for me.
Actually I don't know what is pool allocator but things you mentioned
is basically used to gaurantee *new* thread/memory, not limit although
it would implement limit.
Another question, why do you think zsmalloc is pool allocator?
IOW, What logic makes you think it's pool allocator?
If current implementation is expensive and rather hard to follow,
It would be one reason to move the feature into zsmalloc but
I don't think it makes critical trobule in zram usecase.
See below.
But I still open and will wait others's opinion.
If other guys think zsmalloc is better place, I am willing to move
it into zsmalloc.
Another idea is we could call zs_get_total_pages right before
zs_malloc
but the problem is we cannot know how many of pages are allocated
by zsmalloc in advance.
IOW, zram should be blind on zsmalloc's internal.
We did however suggest that we could check before hand to see if
max was already exceeded as an optimization.
(possibly with a guess on usage but at least using the minimum of 1
page)
In the contested case, the max may already be exceeded transiently and
therefore we know this one _could_ fail (it could also pass, but odds
aren't good).
As Minchan mentions this was discussed before - but not into great
detail.
Testing should be done to determine possible benefit. And as he also
mentions, the better place for it may be in zsmalloc, but that
requires an ABI change.
Why we hesitate to change zsmalloc API? It is in-kernel API and there
are just two users now, zswap and zram. We can change it easily.
I think that we just need following simple API change in zsmalloc.c.
zs_zpool_create(gfp_t gfp, struct zpool_ops *zpool_op)
=
zs_zpool_create(unsigned long limit, gfp_t gfp, struct zpool_ops
*zpool_op)
It's pool allocator so there is no obstacle for us to limit maximum
memory usage in zsmalloc. It's a natural idea to limit memory usage
for pool allocator.
Certainly a detailed suggestion could happen on this thread and I'm
also interested
in your thoughts, but this patchset should be able to go in as is.
Memory exhaustion avoidance probably trumps the possible thrashing at
threshold.
About alloc/free cost once if it is over the limit,
I don't think it's important to consider.
Do you have any scenario in your mind to consider alloc/free cost
when the limit is over?
2) Even if this request doesn't do new allocation, it could be failed
due to other's allocation. There is time gap between allocation and
free, so legimate user who want to use preallocated zsmalloc memory
could also see this condition true and
sync_set_bit() vs set_bit() -- what's the difference?
I'm curious about the difference. :-) sync_set_bit() is only used in drivers/hv/ and drivers/xen/ while set_bit() is used in all other places. What makes hv/xen special? Thanks, -- Dexuan -- 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 3/3] memory: tegra124-emc: Add EMC driver
On 08/26/2014 07:17 PM, Stephen Warren wrote: On 08/26/2014 07:12 AM, Tomeu Vizoso wrote: Sets the EMC clock rate based on the bandwidth requirements registered by memory clients through the PM_QOS_MEMORY_BANDWIDTH class. Note: this is just an example and not a proper driver for a external memory controller. Its only purpose is to illustrate how such a driver would set the frequency of the external memory clock based on the bandwidth requirements of memory clients. diff --git a/arch/arm/mach-tegra/tegra.c b/arch/arm/mach-tegra/tegra.c @@ -112,6 +117,11 @@ static void __init tegra_dt_init(void) parent = soc_device_to_device(soc_dev); /* + * HACK: register a platform device to probe the driver + */ +platform_device_register(tegra_emc); I don't think this is a hack, except for the bug: That should only happen on Tegra124 not on all Tegra SoCs. Do you intend all 3 patches in this series to be merged? You'd mentioned you didn't when asked about this for a previous version. I'm not sure if that's changed? Yeah, I don't want 3/3 merged because we don't have a functional EMC clock yet on T124, and because I don't know yet where will be the best place to have that code in. That depends on Mikko's work on the real EMC driver which is in a bit of flux right now. I have kept posting it just because I think it complements nicely the explanation in the cover letter, but maybe confuses more than helps. Regards, Tomeu To merge, I'd need Thierry's ack on patch 2, and Thierry's, Peter's, Mikko's, and/or Tuomas's on this patch. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH/RFC 2/2] lib: string: Make all calls to strnicmp into calls to strncasecmp
The previous patch made strnicmp into a wrapper for strncasecmp. This
patch makes all in-tree users of strnicmp call strncasecmp directly,
while still making sure that the strnicmp symbol can be used by
out-of-tree modules. It should be considered a temporary hack until
all in-tree callers have been converted.
Signed-off-by: Rasmus Villemoes li...@rasmusvillemoes.dk
---
include/linux/string.h | 2 +-
lib/string.c | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/linux/string.h b/include/linux/string.h
index d36977e..e6edfe5 100644
--- a/include/linux/string.h
+++ b/include/linux/string.h
@@ -41,7 +41,7 @@ extern int strcmp(const char *,const char *);
extern int strncmp(const char *,const char *,__kernel_size_t);
#endif
#ifndef __HAVE_ARCH_STRNICMP
-extern int strnicmp(const char *, const char *, __kernel_size_t);
+#define strnicmp strncasecmp
#endif
#ifndef __HAVE_ARCH_STRCASECMP
extern int strcasecmp(const char *s1, const char *s2);
diff --git a/lib/string.c b/lib/string.c
index 92c33e1..d171554 100644
--- a/lib/string.c
+++ b/lib/string.c
@@ -59,6 +59,7 @@ int strncasecmp(const char *s1, const char *s2, size_t len)
EXPORT_SYMBOL(strncasecmp);
#endif
#ifndef __HAVE_ARCH_STRNICMP
+#undef strnicmp
int strnicmp(const char *s1, const char *s2, size_t len)
{
return strncasecmp(s1, s2, len);
--
2.0.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/
[PATCH/RFC 0/2] lib: string: Remove duplicated function
lib/string.c contains two functions, strnicmp and strncasecmp, which do roughly the same thing, namely compare two strings case-insensitively up to a given bound. They have slightly different implementations, but the only important difference is that strncasecmp doesn't handle len==0 appropriately; it effectively becomes strcasecmp in that case. strnicmp correctly says that two strings are always equal in their first 0 characters. strncasecmp is the POSIX name for this functionality. The first patch renames the non-broken version to the standard name, and makes strnicmp into a wrapper for strncasecmp. In order not to cause in-tree users of strnicmp to pay the cost of the extra indirection, the second patch replaces the declaration of strnicmp in string.h with a macro. When and if all callers of strnicmp have been updated, that hack can be removed. Arch-specific versions of these functions could complicate matters, but fortunately the only #define of either __HAVE macro is in a !__KERNEL__ section in arch/frv/include/asm/string.h. The other problem is how to deal with modules that may be using strnicmp. The proper fix would probably involve some alias/linker magic, but I have no idea how to do that (hence the RFC). Rasmus Villemoes (2): lib: string: Remove duplicated function lib: string: Make all calls to strnicmp into calls to strncasecmp include/linux/string.h | 2 +- lib/string.c | 28 +++- 2 files changed, 12 insertions(+), 18 deletions(-) -- 2.0.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/
[PATCH/RFC 1/2] lib: string: Remove duplicated function
lib/string.c contains two functions, strnicmp and strncasecmp, which
do roughly the same thing, namely compare two strings
case-insensitively up to a given bound. They have slightly different
implementations, but the only important difference is that strncasecmp
doesn't handle len==0 appropriately; it effectively becomes strcasecmp
in that case. strnicmp correctly says that two strings are always
equal in their first 0 characters.
strncasecmp is the POSIX name for this functionality. So rename the
non-broken function to the standard name. To minimize the impact on
the rest of the kernel (and since both are exported to modules), make
strnicmp a wrapper for strncasecmp.
Signed-off-by: Rasmus Villemoes li...@rasmusvillemoes.dk
---
lib/string.c | 27 ++-
1 file changed, 10 insertions(+), 17 deletions(-)
diff --git a/lib/string.c b/lib/string.c
index 992bf30..92c33e1 100644
--- a/lib/string.c
+++ b/lib/string.c
@@ -27,14 +27,14 @@
#include linux/bug.h
#include linux/errno.h
-#ifndef __HAVE_ARCH_STRNICMP
+#ifndef __HAVE_ARCH_STRNCASECMP
/**
- * strnicmp - Case insensitive, length-limited string comparison
+ * strncasecmp - Case insensitive, length-limited string comparison
* @s1: One string
* @s2: The other string
* @len: the maximum number of characters to compare
*/
-int strnicmp(const char *s1, const char *s2, size_t len)
+int strncasecmp(const char *s1, const char *s2, size_t len)
{
/* Yes, Virginia, it had better be unsigned */
unsigned char c1, c2;
@@ -56,6 +56,13 @@ int strnicmp(const char *s1, const char *s2, size_t len)
} while (--len);
return (int)c1 - (int)c2;
}
+EXPORT_SYMBOL(strncasecmp);
+#endif
+#ifndef __HAVE_ARCH_STRNICMP
+int strnicmp(const char *s1, const char *s2, size_t len)
+{
+ return strncasecmp(s1, s2, len);
+}
EXPORT_SYMBOL(strnicmp);
#endif
@@ -73,20 +80,6 @@ int strcasecmp(const char *s1, const char *s2)
EXPORT_SYMBOL(strcasecmp);
#endif
-#ifndef __HAVE_ARCH_STRNCASECMP
-int strncasecmp(const char *s1, const char *s2, size_t n)
-{
- int c1, c2;
-
- do {
- c1 = tolower(*s1++);
- c2 = tolower(*s2++);
- } while ((--n 0) c1 == c2 c1 != 0);
- return c1 - c2;
-}
-EXPORT_SYMBOL(strncasecmp);
-#endif
-
#ifndef __HAVE_ARCH_STRCPY
/**
* strcpy - Copy a %NUL terminated string
--
2.0.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] Fix faulty logic in the case of recursive printk
On Tue 26-08-14 07:23:22, Patrick Palka wrote:
Thanks for reviewing! I have put back the call to strlen() and adjusted
the commit message accordingly.
Patrick
-- 8 --
We shouldn't set text_len in the code path that detects printk recursion
because text_len corresponds to the length of the string inside textbuf.
A few lines down from the line
text_len = strlen(recursion_msg);
is the line
text_len += vscnprintf(text + text_len, ...);
So if printk detects recursion, it sets text_len to 29 (the length of
recursion_msg) and logs an error. Then the message supplied by the
caller of printk is stored inside textbuf but offset by 29 bytes. This
means that the output of the recursive call to printk will contain 29
bytes of garbage in front of it.
This defect is caused by commit 458df9fd (printk: remove separate
printk_sched buffers and use printk buf instead) which turned the line
text_len = vscnprintf(text, ...);
into
text_len += vscnprintf(text + text_len, ...);
To fix this, this patch avoids setting text_len when logging the printk
recursion error. This patch also marks unlikely() the branch leading
up to this code.
Signed-off-by: Patrick Palka patr...@parcs.ath.cx
Looks fine to me.
Reviewed-by: Petr Mladek pmla...@suse.cz
---
kernel/printk/printk.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index e04c455..1ce7706 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -1665,15 +1665,15 @@ asmlinkage int vprintk_emit(int facility, int level,
raw_spin_lock(logbuf_lock);
logbuf_cpu = this_cpu;
- if (recursion_bug) {
+ if (unlikely(recursion_bug)) {
static const char recursion_msg[] =
BUG: recent printk recursion!;
recursion_bug = 0;
- text_len = strlen(recursion_msg);
/* emit KERN_CRIT message */
printed_len += log_store(0, 2, LOG_PREFIX|LOG_NEWLINE, 0,
- NULL, 0, recursion_msg, text_len);
+ NULL, 0, recursion_msg,
+ strlen(recursion_msg));
}
/*
--
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: sync_set_bit() vs set_bit() -- what's the difference?
On 27.08.14 at 09:30, de...@microsoft.com wrote: I'm curious about the difference. :-) sync_set_bit() is only used in drivers/hv/ and drivers/xen/ while set_bit() is used in all other places. What makes hv/xen special? I guess this would really want to be used by anything communicating with a hypervisor or a remote driver: set_bit() gets its LOCK prefix discarded when the local kernel determines it runs on a single CPU only. Obviously having knowledge of the CPU count inside a VM does not imply anything about the number of CPUs available to the host, i.e. stripping LOCK prefixes in that case would be unsafe. Jan -- 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: sync_set_bit() vs set_bit() -- what's the difference?
On 08/27/2014 09:30 AM, Dexuan Cui wrote: I'm curious about the difference. :-) sync_set_bit() is only used in drivers/hv/ and drivers/xen/ while set_bit() is used in all other places. What makes hv/xen special? In set_bit() the lock prefix will be dropped if only one processor is present. sync_set_bit() is always attributed with lock. xen and hv might require lock semantics even if the current OS is running on only one processor, as syncing with other processors running other OS's might be necessary. Juergen -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] thermal soc changes
On Fri, 2014-08-22 at 08:46 -0400, Eduardo Valentin wrote: Hello Rui, Please pull these changes. Here we have three new features: IMX driver has now support to i.mx6sx, the of-thermal now if aware of disabled thermal zones in DT, and we shall have tracing support on thermal framework. The following changes since commit 47d104ba5879790c7c91c3390b0b08399e168efe: Merge branches 'exynos-fix', 'for-rc', 'int3403-fix', 'misc', 'rcar-thermal' and 'sti-thermal' of .git into next (2014-07-22 10:13:00 +0800) are available in the git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git I suppose you mean http://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal.git next branch. And I've pulled those changes in your next branch. thanks, rui for you to fetch changes up to 3c94f17e72a7bcf689756da100b6051e535c45f4: Thermal: imx: add i.mx6sx thermal support (2014-08-09 10:29:30 -0400) Anson Huang (1): Thermal: imx: add i.mx6sx thermal support Laxman Dewangan (1): thermal: add support to disable thermal zone from DTS Punit Agrawal (3): thermal: trace: Trace temperature changes thermal: trace: Trace when a cooling device's state is updated thermal: trace: Trace when temperature is above a trip point .../devicetree/bindings/thermal/imx-thermal.txt| 5 +- drivers/thermal/fair_share.c | 12 +++ drivers/thermal/imx_thermal.c | 91 ++ drivers/thermal/of-thermal.c | 12 +++ drivers/thermal/step_wise.c| 5 +- drivers/thermal/thermal_core.c | 7 ++ include/trace/events/thermal.h | 83 7 files changed, 200 insertions(+), 15 deletions(-) create mode 100644 include/trace/events/thermal.h BR, Eduardo Valentin -- 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 4/6] acerhdf: Use bang-bang thermal governor
On Tue, 2014-07-22 at 17:37 +0200, Peter Feuerer wrote:
acerhdf has been doing an on-off fan control using hysteresis by
post-manipulating the outcome of thermal subsystem trip point handling.
This patch enables acerhdf to use the bang-bang governor, which is
intended for on-off controlled fans.
Cc: Andrew Morton a...@linux-foundation.org
CC: Zhang Rui rui.zh...@intel.com
Cc: Andreas Mohr a...@lisas.de
Cc: Javi Merino javi.mer...@arm.com
Acked-and-tested-by: Borislav Petkov b...@suse.de
Signed-off-by: Peter Feuerer pe...@piie.net
Peter,
will you take this patch, or do you want me to take this patch along
with Patch 3/6?
thanks,
rui
---
drivers/platform/x86/Kconfig | 3 ++-
drivers/platform/x86/acerhdf.c | 36 +++-
2 files changed, 33 insertions(+), 6 deletions(-)
diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index 172f26c..b5e80dc 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -38,7 +38,8 @@ config ACER_WMI
config ACERHDF
tristate Acer Aspire One temperature and fan driver
- depends on THERMAL ACPI
+ select THERMAL_GOV_BANG_BANG
+ depends on ACPI
---help---
This is a driver for Acer Aspire One netbooks. It allows to access
the temperature sensor and to control the fan.
diff --git a/drivers/platform/x86/acerhdf.c b/drivers/platform/x86/acerhdf.c
index f30767f..7fe7dbf 100644
--- a/drivers/platform/x86/acerhdf.c
+++ b/drivers/platform/x86/acerhdf.c
@@ -50,7 +50,7 @@
*/
#undef START_IN_KERNEL_MODE
-#define DRV_VER 0.5.30
+#define DRV_VER 0.7.0
/*
* According to the Atom N270 datasheet,
@@ -258,6 +258,14 @@ static const struct bios_settings_t bios_tbl[] = {
static const struct bios_settings_t *bios_cfg __read_mostly;
+/*
+ * this struct is used to instruct thermal layer to use bang_bang instead of
+ * default governor for acerhdf
+ */
+static struct thermal_zone_params acerhdf_zone_params = {
+ .governor_name = bang_bang,
+};
+
static int acerhdf_get_temp(int *temp)
{
u8 read_temp;
@@ -439,6 +447,17 @@ static int acerhdf_get_trip_type(struct
thermal_zone_device *thermal, int trip,
return 0;
}
+static int acerhdf_get_trip_hyst(struct thermal_zone_device *thermal, int
trip,
+ unsigned long *temp)
+{
+ if (trip != 0)
+ return -EINVAL;
+
+ *temp = fanon - fanoff;
+
+ return 0;
+}
+
static int acerhdf_get_trip_temp(struct thermal_zone_device *thermal, int
trip,
unsigned long *temp)
{
@@ -463,6 +482,7 @@ static struct thermal_zone_device_ops acerhdf_dev_ops = {
.get_mode = acerhdf_get_mode,
.set_mode = acerhdf_set_mode,
.get_trip_type = acerhdf_get_trip_type,
+ .get_trip_hyst = acerhdf_get_trip_hyst,
.get_trip_temp = acerhdf_get_trip_temp,
.get_crit_temp = acerhdf_get_crit_temp,
};
@@ -515,9 +535,7 @@ static int acerhdf_set_cur_state(struct
thermal_cooling_device *cdev,
}
if (state == 0) {
- /* turn fan off only if below fanoff temperature */
- if ((cur_state == ACERHDF_FAN_AUTO)
- (cur_temp fanoff))
+ if (cur_state == ACERHDF_FAN_AUTO)
acerhdf_change_fanstate(ACERHDF_FAN_OFF);
} else {
if (cur_state == ACERHDF_FAN_OFF)
@@ -696,11 +714,19 @@ static int acerhdf_register_thermal(void)
return -EINVAL;
thz_dev = thermal_zone_device_register(acerhdf, 1, 0, NULL,
- acerhdf_dev_ops, NULL, 0,
+ acerhdf_dev_ops,
+ acerhdf_zone_params, 0,
(kernelmode) ? interval*1000 : 0);
if (IS_ERR(thz_dev))
return -EINVAL;
+ if (strcmp(thz_dev-governor-name,
+ acerhdf_zone_params.governor_name)) {
+ pr_err(Didn't get thermal governor %s, perhaps not compiled
into thermal subsystem.\n,
+ acerhdf_zone_params.governor_name);
+ return -EINVAL;
+ }
+
return 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 v2] genirq: bug on inconstent flags and flow handler
On Tue, 26 Aug 2014, Florian Fainelli wrote: On 07/23/2014 12:14 PM, Florian Fainelli wrote: 2014-07-23 11:49 GMT-07:00 Thomas Gleixner t...@linutronix.de: On Wed, 23 Jul 2014, Florian Fainelli wrote: It is currently possible for a generic irq chip driver to set IRQ_LEVEL and have its irq flow handler be handle_edge_irq. Setting IRQ_LEVEL in such a case does not make sense, and will actually prevent e.g: the software resend logic from kicking, and potential other problems too. Signed-off-by: Florian Fainelli f.faine...@gmail.com --- Changes in v2: - replaced WARN_ON() with BUG_ON() since we really don't want to continue as suggested by Jason Cooper I disagree here. It's not a reason take the machine down. Its good enough to WARN. That keeps the machine alive and lets us debug that stuff. Works for me! Lemme find V1 Here it is: https://lkml.org/lkml/2014/7/1/468 Thomas, do you want me to resubmit that change so you get a clean submission in your inbox? Thanks Yes please -- 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: sync_set_bit() vs set_bit() -- what's the difference?
-Original Message- From: Jan Beulich Sent: Wednesday, August 27, 2014 15:39 PM On 27.08.14 at 09:30, de...@microsoft.com wrote: I'm curious about the difference. :-) sync_set_bit() is only used in drivers/hv/ and drivers/xen/ while set_bit() is used in all other places. What makes hv/xen special? I guess this would really want to be used by anything communicating with a hypervisor or a remote driver: set_bit() gets its LOCK prefix discarded when the local kernel determines it runs on a single CPU only. Obviously having knowledge of the CPU count inside a VM does not imply anything about the number of CPUs available to the host, i.e. stripping LOCK prefixes in that case would be unsafe. Jan Thank you, Juergen and Jan for your quick answers! I didn't realize LOCK_PREFIX is for UP. :-) Thanks, -- Dexuan -- 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 00/11] drm: add support for Atmel HLCDC Display Controller
Hi Laurent, On Tue, 26 Aug 2014 01:39:21 +0200 Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hi Boris, On Thursday 21 August 2014 19:26:33 Boris BREZILLON wrote: On Thu, 21 Aug 2014 19:08:53 +0200 Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: [...] While this could be acceptable when all drivers are statically linked in the kernel, it might be problematic when you're using modules, meaning that you won't be able to display anything on your LCD panel until your HDMI bridge module has been loaded. No. HDMI should be using proper hotplugging anyway, hence it should be always be loaded anyway. You're in for a world of pain if you think you can run DRM with a driver that's composed of separate kernel modules. I was talking about the external RGB to HDMI encoder, should the driver for this encoder (which is not on On Chip block) be compiled statically too ? Given the move to multiplatform kernels we need to aim for as few modules compiled in as possible. I'd say this includes HDMI encoders, panels and display controllers. Also if you don't want to use deferred probe, then you're in for the full hotplugging panel dance and that implies that you need to fix a bunch of things in DRM (one being the framebuffer console instantiation that I referred to in the other thread). For now, I wait until there is a device connected on the RGB connector (connector status set to connector_status_connected) before creating an fbdev. It might not be the cleanest way to solve this issue, but it works :-). Do you create a new drm_encoder at runtime for the HDMI encoder when it appears ? I thought the DRM core and API were not able to correctly cope with that. I haven't started to work on the HDMI encoder yet, and ATM I only have a single connector (which is true from an HW POV), which is then bound to an LCD panel (the only type of remote endpoint I currently support). BTW, I wonder how my use case should be represented in the DRM subsystem. As I said, from an HW POV I only have one RGB (or whatever name you choose for it) connector. But on such kind of connectors you can connect several output devices (panels, encoders, ...). And in my case I have 2 devices on the same RGB connector: a panel and an RGB to HDMI converter. The DRM connector object was initially meant to model a physical user- accessible connector on a board (VGA, DVI, HDMI, ...) and the properties of the monitor plugged into it. It has then been (ab)used to represent panels, as they're similar to monitors. In your case the VGA and HDMI connectors should be modeled as DRM connectors, the RGB to HDMI encoder as a DRM encoder, and the LCDC as a DRM CRTC. I don't have any VGA connector (or I'm missing something :-)), but I have an LCD panel and an RGB to HDMI encoder connected on the same RGB connector. As DRM hardcodes the pipeline model to CRTC - encoder - connector, you will also need a DRM encoder in the VGA path. I suppose your board has a VGA DAC, that's the component you should expose as a DRM encoder (even if it can't be controlled and doesn't limit the valid modes). Actually, my problem is that both devices are connected on the same RGB connector, and thus share the same display mode (resolution, HSYNC, VSYNC, RGB output mode, ...). This means that all remote devices have to agree on a specific mode if we want to mirror the display on several output devices, otherwise we must disable one of the output devices. You also can't be using the current device tree bindings because they all assume a dependency from the display controller/output to the panel. For hotplugging you'd need the dependency the other way around (the panel needs to refer to the output by phandle). Here [1] is a proposal for notification support in the drm_panel infrastructure (which is not that complicated), and here [2] is how I use it in my atmel-hlcdc driver to generate hotplug events. Is there a way we could use the component framework for that ? I know that partial notification isn't supported at the moment, but Russell agreed it was a real use case that should be implemented at some point. I'll give it a try. -- Boris Brezillon, Free Electrons Embedded Linux and Kernel 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/
[PATCH] usb: dwc3: exynos: remove usb_phy_generic support
dwc3 driver is using the new Exynos5 SoC series USB DRD PHY driver
(PHY_EXYNOS5_USBDRD which selects GENERIC_PHY) as can be seen by
looking at the following commits:
7a4cf0fde054 (ARM: dts: Update DWC3 usb controller to use new
phy driver for exynos5250)
f070267b5fc1 (ARM: dts: Enable support for DWC3 controller for
exynos5420)
Thus remove unused usb_phy_generic support from dwc3 Exynos glue
layer.
[ The code that is being removed is harmful in the context of
multi_v7_defconfig and enabling EHCI support for Samsung
S5P/EXYNOS SoC Series (USB_EHCI_EXYNOS) + OHCI support for
Samsung S5P/EXYNOS SoC Series (USB_OHCI_EXYNOS) because EHCI
support for OMAP3 and later chips (USB_EHCI_HCD_OMAP) selects
NOP USB Transceiver Driver (NOP_USB_XCEIV). NOP USB driver
attaches itself to usb_phy_generic platform devices created by
dwc3 Exynos glue layer and later causes Exynos EHCI driver to
fail probe and Exynos OHCI driver to hang on probe (as observed
on Exynos5250 Arndale board). ]
Cc: Olof Johansson o...@lixom.net
Cc: Kukjin Kim kgene@samsung.com
Cc: Vivek Gautam gautam.vi...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
---
drivers/usb/dwc3/dwc3-exynos.c | 68 -
1 file changed, 1 insertion(+), 67 deletions(-)
Index: b/drivers/usb/dwc3/dwc3-exynos.c
===
--- a/drivers/usb/dwc3/dwc3-exynos.c2014-08-25 14:57:04.991781925 +0200
+++ b/drivers/usb/dwc3/dwc3-exynos.c2014-08-27 09:16:38.312617727 +0200
@@ -23,15 +23,12 @@
#include linux/platform_data/dwc3-exynos.h
#include linux/dma-mapping.h
#include linux/clk.h
-#include linux/usb/otg.h
-#include linux/usb/usb_phy_generic.h
+#include linux/pm_runtime.h
#include linux/of.h
#include linux/of_platform.h
#include linux/regulator/consumer.h
struct dwc3_exynos {
- struct platform_device *usb2_phy;
- struct platform_device *usb3_phy;
struct device *dev;
struct clk *clk;
@@ -39,61 +36,6 @@ struct dwc3_exynos {
struct regulator*vdd10;
};
-static int dwc3_exynos_register_phys(struct dwc3_exynos *exynos)
-{
- struct usb_phy_generic_platform_data pdata;
- struct platform_device *pdev;
- int ret;
-
- memset(pdata, 0x00, sizeof(pdata));
-
- pdev = platform_device_alloc(usb_phy_generic, PLATFORM_DEVID_AUTO);
- if (!pdev)
- return -ENOMEM;
-
- exynos-usb2_phy = pdev;
- pdata.type = USB_PHY_TYPE_USB2;
- pdata.gpio_reset = -1;
-
- ret = platform_device_add_data(exynos-usb2_phy, pdata, sizeof(pdata));
- if (ret)
- goto err1;
-
- pdev = platform_device_alloc(usb_phy_generic, PLATFORM_DEVID_AUTO);
- if (!pdev) {
- ret = -ENOMEM;
- goto err1;
- }
-
- exynos-usb3_phy = pdev;
- pdata.type = USB_PHY_TYPE_USB3;
-
- ret = platform_device_add_data(exynos-usb3_phy, pdata, sizeof(pdata));
- if (ret)
- goto err2;
-
- ret = platform_device_add(exynos-usb2_phy);
- if (ret)
- goto err2;
-
- ret = platform_device_add(exynos-usb3_phy);
- if (ret)
- goto err3;
-
- return 0;
-
-err3:
- platform_device_del(exynos-usb2_phy);
-
-err2:
- platform_device_put(exynos-usb3_phy);
-
-err1:
- platform_device_put(exynos-usb2_phy);
-
- return ret;
-}
-
static int dwc3_exynos_remove_child(struct device *dev, void *unused)
{
struct platform_device *pdev = to_platform_device(dev);
@@ -127,12 +69,6 @@ static int dwc3_exynos_probe(struct plat
platform_set_drvdata(pdev, exynos);
- ret = dwc3_exynos_register_phys(exynos);
- if (ret) {
- dev_err(dev, couldn't register PHYs\n);
- return ret;
- }
-
clk = devm_clk_get(dev, usbdrd30);
if (IS_ERR(clk)) {
dev_err(dev, couldn't get clock\n);
@@ -194,8 +130,6 @@ static int dwc3_exynos_remove(struct pla
struct dwc3_exynos *exynos = platform_get_drvdata(pdev);
device_for_each_child(pdev-dev, NULL, dwc3_exynos_remove_child);
- platform_device_unregister(exynos-usb2_phy);
- platform_device_unregister(exynos-usb3_phy);
clk_disable_unprepare(exynos-clk);
--
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] mfd: Add Ricoh RN5T618 PMIC core driver
On Wed, 27 Aug 2014, Beniamino Galvani wrote:
Ricoh RN5T618 is a power management IC which integrates 3 step-down
DCDC converters, 7 low-dropout regulators, a Li-ion battery charger,
fuel gauge, ADC, GPIOs and a watchdog timer.
This commit adds a MFD core driver to support the I2C communication
with the device.
Signed-off-by: Beniamino Galvani b.galv...@gmail.com
---
drivers/mfd/Kconfig | 11 +++
drivers/mfd/Makefile|1 +
drivers/mfd/rn5t618.c | 129 ++
include/linux/mfd/rn5t618.h | 210
+++
4 files changed, 351 insertions(+)
create mode 100644 drivers/mfd/rn5t618.c
create mode 100644 include/linux/mfd/rn5t618.h
Really nicely done. We don't normally get many first submissions at
this quality level.
One question and a _really_ small nit though.
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 8d5fad2..fae8c5b 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -582,6 +582,17 @@ config MFD_RC5T583
Additional drivers must be enabled in order to use the
different functionality of the device.
+config MFD_RN5T618
+ bool Ricoh RN5T5618 PMIC
Shouldn't this be tristate?
+ depends on I2C=y
If so, this should be:
depends on I2C
+ select MFD_CORE
+ select REGMAP_I2C
+ help
+ Say yes here to add support for the Ricoh RN5T618 PMIC. This
+ driver provides common support for accessing the device,
+ additional drivers must be enabled in order to use the
+ functionality of the device.
[...]
+++ b/drivers/mfd/rn5t618.c
@@ -0,0 +1,129 @@
[...]
+static int rn5t618_i2c_probe(struct i2c_client *i2c,
+ const struct i2c_device_id *id)
+{
[...]
+ dev_info(i2c-dev, RN5T618 MFD driver loaded);
Can you remove this line? We normally only print things when
information is gathered from a chip i.e. version information and the
like.
+ return 0;
+}
[...]
--
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: [RFC Patch] irqdomain: Introduce new interfaces to support hierarchy irqdomains
Hi Thomas,
Thanks for your great comments! Please refer to
inline comments below.
Regards!
Gerry
On 2014/8/27 5:06, Thomas Gleixner wrote:
Jiang,
On Fri, 1 Aug 2014, Jiang Liu wrote:
First, architecture needs to define struct irq_map_info, which will be
used to pass architecture specific information to controller specific
callbacks.
We should not have another universal data structure which needs to
fit various levels of the hierarchy. See below.
Second, all new interfaces have parameter 'size' to support multiple
continous IRQs, which is needed by MSI when interrupt remapping is
enabled on x86.
Nitpick: nrirqs would be more intuitive.
Will use nrirqs in next version.
Third, a special value IRQDOMAIN_AUTO_ASSIGN_HWIRQ is defined out of
irq_hw_number_t, which indicates that irqdomain callbacks should
automatically hardware interrupt number for clients. This will be used
to support CPU vector allocation and interrupt remapping controller
on x86 platforms.
I can't see the point of this. If we have a hierarchy then this is a
property of the hierarchy itself not of an indiviual call.
When invoking irqdomain interfaces, we need to pass in an hwirq. For
IOAPIC, it's the pin number. But for remap and vector domains, caller
can't provide hwirq, it's assigned by remap and vector domains
themselves. So introduced IRQDOMAIN_AUTO_ASSIGN_HWIRQ to indicate
that irqdomain will assign hwirq for callers.
Fourth, the flag IRQDOMAIN_FLAG_HIERARCHY is used to indicate weather
irqdomain operations are hierarchy request. The irqdomain core uses
Why do we need that flag? If a domain has a parent domain, we already
know that this domain is part of a hierarchy.
This flag is passed into hierarchy irqdomain interfaces for two
purposes:
1) to protect irq_data-hwirq and irq_data-domain
2) to solve recursive lock issues in irqdomain core.
domain and hwirq fields in struct irq_data to save domain and hardware
interrupt number, but this causes trouble when enabling hierarchy
irqdomain. We solve this limitation by:
1) Still use domain and hwirq fields in struct irq_data to save
infomation about the out-most irqdomain.
2) For hierarchy irqdomains, the parent field in struct irq_domain is
used to save point to parent irqdomain.
3) For hierarchy irqdomains, it must implement a private method to save
hardware interrupt number (hwirq).
I'm not so fond of this design decision. Let's look at a hierarchy:
PCI-Device
MSI Interrupt
Remap Entry
CPU Vector
But your data representation is not hierarchical because only the
outmost domain map is stored in irq_data. For the parent domains you
offload the storage to the domain implementation itself.
One of my design rules is only to change x86 arch specific code when
possible, so used above solution. If we could make changes to public
data structures, we may find better solution as you have suggested:)
We should be more clever and make the storage hierarchical and
indivual itself.
What about adding a field:
struct irq_data *parent_data;
to struct irq_data and allocate it when we allocate an interrupt down
the hierarchy chain?
That allows to store hw_irq for each hierarchy level along with a
pointer to the interrupt chip and irq specific data. So the storage
would look like this:
irq
irq_desc
irq_data (hwirq, chip, chipdata, domain ...)
irq_data (hwirq, chip, chipdata, domain ...)
irq_data (hwirq, chip, chipdata, domain ...)
That allows us also to support scenarios where manipulation of the top
level interrupt irq requires to walk down the hierarchy without
consulting any irqdomain management code and without having specific
knowledge in the interrupt chip callbacks. Assume a two level
hierarchy which requires to mask/unmask both levels. In the current
mode we need to deal with this in the chip callback of the outermost
chip. But with a hierarchical data set, we can do:
mask(struct irqdata *d)
{
d-chip-irq_mask(d);
if (d-parent_data)
mask(d-parent_data);
}
and avoid magic conditionals in the chip callbacks.
That's a good suggestion. Should we reuse irq_data directly or
group some fields from irq_data into a new data structure?
Lets look at the current way of allocating a MSI interrupt with
remapping.
msi_capability_init()
arch_setup_msi_irqs()
irq_remapping_setup_msi_irqs()
irq_alloc_hwirq()
__assign_irq_vector()
intel_msi_alloc_irq()
alloc_irte()
In a proper domain hierarchy it would look like this:
msi_capability_init()
arch_setup_msi_irqs()
irq_domain_alloc(msi_domain)
irq_domain_alloc(remap_domain)
irq_domain_alloc(vector_domain)
In a non remapped scenario the msi_domain parent would be
vector_domain and the chain would look like this:
msi_capability_init()
arch_setup_msi_irqs()
Re: sync_set_bit() vs set_bit() -- what's the difference?
On 08/27/2014 09:50 AM, Dexuan Cui wrote: -Original Message- From: Jan Beulich Sent: Wednesday, August 27, 2014 15:39 PM On 27.08.14 at 09:30, de...@microsoft.com wrote: I'm curious about the difference. :-) sync_set_bit() is only used in drivers/hv/ and drivers/xen/ while set_bit() is used in all other places. What makes hv/xen special? I guess this would really want to be used by anything communicating with a hypervisor or a remote driver: set_bit() gets its LOCK prefix discarded when the local kernel determines it runs on a single CPU only. Obviously having knowledge of the CPU count inside a VM does not imply anything about the number of CPUs available to the host, i.e. stripping LOCK prefixes in that case would be unsafe. Jan Thank you, Juergen and Jan for your quick answers! I didn't realize LOCK_PREFIX is for UP. :-) Even worse: it is patched away dynamically when you disable all but one processor and activated again when a second processor is becoming active. Juergen -- 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/
Cufflinks factory
Good day , I am Ms.Joan Wong from Sonier Pins . we are metal gifts factory in China . Any metal item inquiry ,please feel free to ask us . thank you ! Best regards, Joan Wong Sales representative Sonier Pins Co.,Ltd Address : No.2, JiXi ShunCheng Center ,Xiaolan Town ,Zhongshan City 528415,Guangdong ,China . Tel：（86 -760）22123680 Fax：（86 -760）22122916 Email: j...@sonier-pins.com Website: sonier-pins.com
Re: [PATCH v5 4/6] acerhdf: Use bang-bang thermal governor
Zhang Rui writes:
On Tue, 2014-07-22 at 17:37 +0200, Peter Feuerer wrote:
acerhdf has been doing an on-off fan control using hysteresis by
post-manipulating the outcome of thermal subsystem trip point handling.
This patch enables acerhdf to use the bang-bang governor, which is
intended for on-off controlled fans.
Cc: Andrew Morton a...@linux-foundation.org
CC: Zhang Rui rui.zh...@intel.com
Cc: Andreas Mohr a...@lisas.de
Cc: Javi Merino javi.mer...@arm.com
Acked-and-tested-by: Borislav Petkov b...@suse.de
Signed-off-by: Peter Feuerer pe...@piie.net
Peter,
will you take this patch, or do you want me to take this patch along
with Patch 3/6?
Hi Rui,
please apply the whole series. I don't have a git repository where Linus
pulls from.
thanks and kind regards,
--peter;
thanks,
rui
---
drivers/platform/x86/Kconfig | 3 ++-
drivers/platform/x86/acerhdf.c | 36 +++-
2 files changed, 33 insertions(+), 6 deletions(-)
diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index 172f26c..b5e80dc 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -38,7 +38,8 @@ config ACER_WMI
config ACERHDF
tristate Acer Aspire One temperature and fan driver
- depends on THERMAL ACPI
+ select THERMAL_GOV_BANG_BANG
+ depends on ACPI
---help---
This is a driver for Acer Aspire One netbooks. It allows to access
the temperature sensor and to control the fan.
diff --git a/drivers/platform/x86/acerhdf.c b/drivers/platform/x86/acerhdf.c
index f30767f..7fe7dbf 100644
--- a/drivers/platform/x86/acerhdf.c
+++ b/drivers/platform/x86/acerhdf.c
@@ -50,7 +50,7 @@
*/
#undef START_IN_KERNEL_MODE
-#define DRV_VER 0.5.30
+#define DRV_VER 0.7.0
/*
* According to the Atom N270 datasheet,
@@ -258,6 +258,14 @@ static const struct bios_settings_t bios_tbl[] = {
static const struct bios_settings_t *bios_cfg __read_mostly;
+/*
+ * this struct is used to instruct thermal layer to use bang_bang instead of
+ * default governor for acerhdf
+ */
+static struct thermal_zone_params acerhdf_zone_params = {
+ .governor_name = bang_bang,
+};
+
static int acerhdf_get_temp(int *temp)
{
u8 read_temp;
@@ -439,6 +447,17 @@ static int acerhdf_get_trip_type(struct
thermal_zone_device *thermal, int trip,
return 0;
}
+static int acerhdf_get_trip_hyst(struct thermal_zone_device *thermal, int trip,
+unsigned long *temp)
+{
+ if (trip != 0)
+ return -EINVAL;
+
+ *temp = fanon - fanoff;
+
+ return 0;
+}
+
static int acerhdf_get_trip_temp(struct thermal_zone_device *thermal, int trip,
unsigned long *temp)
{
@@ -463,6 +482,7 @@ static struct thermal_zone_device_ops acerhdf_dev_ops = {
.get_mode = acerhdf_get_mode,
.set_mode = acerhdf_set_mode,
.get_trip_type = acerhdf_get_trip_type,
+ .get_trip_hyst = acerhdf_get_trip_hyst,
.get_trip_temp = acerhdf_get_trip_temp,
.get_crit_temp = acerhdf_get_crit_temp,
};
@@ -515,9 +535,7 @@ static int acerhdf_set_cur_state(struct
thermal_cooling_device *cdev,
}
if (state == 0) {
- /* turn fan off only if below fanoff temperature */
- if ((cur_state == ACERHDF_FAN_AUTO)
- (cur_temp fanoff))
+ if (cur_state == ACERHDF_FAN_AUTO)
acerhdf_change_fanstate(ACERHDF_FAN_OFF);
} else {
if (cur_state == ACERHDF_FAN_OFF)
@@ -696,11 +714,19 @@ static int acerhdf_register_thermal(void)
return -EINVAL;
thz_dev = thermal_zone_device_register(acerhdf, 1, 0, NULL,
- acerhdf_dev_ops, NULL, 0,
+ acerhdf_dev_ops,
+ acerhdf_zone_params, 0,
(kernelmode) ? interval*1000 : 0);
if (IS_ERR(thz_dev))
return -EINVAL;
+ if (strcmp(thz_dev-governor-name,
+ acerhdf_zone_params.governor_name)) {
+ pr_err(Didn't get thermal governor %s, perhaps not compiled into
thermal subsystem.\n,
+ acerhdf_zone_params.governor_name);
+ return -EINVAL;
+ }
+
return 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: [Xen-devel] Xen PV domain regression with KASLR enabled (kernel 3.16)
On 26.08.2014 18:01, Konrad Rzeszutek Wilk wrote: On Fri, Aug 22, 2014 at 11:20:50AM +0200, Stefan Bader wrote: On 21.08.2014 18:03, Kees Cook wrote: On Tue, Aug 12, 2014 at 2:07 PM, Konrad Rzeszutek Wilk konrad.w...@oracle.com wrote: On Tue, Aug 12, 2014 at 11:53:03AM -0700, Kees Cook wrote: On Tue, Aug 12, 2014 at 11:05 AM, Stefan Bader stefan.ba...@canonical.com wrote: On 12.08.2014 19:28, Kees Cook wrote: On Fri, Aug 8, 2014 at 7:35 AM, Stefan Bader stefan.ba...@canonical.com wrote: On 08.08.2014 14:43, David Vrabel wrote: On 08/08/14 12:20, Stefan Bader wrote: Unfortunately I have not yet figured out why this happens, but can confirm by compiling with or without CONFIG_RANDOMIZE_BASE being set that without KASLR all is ok, but with it enabled there are issues (actually a dom0 does not even boot as a follow up error). Details can be seen in [1] but basically this is always some portion of a vmalloc allocation failing after hitting a freshly allocated PTE space not being PTE_NONE (usually from a module load triggered by systemd-udevd). In the non-dom0 case this repeats many times but ends in a guest that allows login. In the dom0 case there is a more fatal error at some point causing a crash. I have not tried this for a normal PV guest but for dom0 it also does not help to add nokaslr to the kernel command-line. Maybe it's overlapping with regions of the virtual address space reserved for Xen? What the the VA that fails? David Yeah, there is some code to avoid some regions of memory (like initrd). Maybe missing p2m tables? I probably need to add debugging to find the failing VA (iow not sure whether it might be somewhere in the stacktraces in the report). The kernel-command line does not seem to be looked at. It should put something into dmesg and that never shows up. Also today's random feature is other PV guests crashing after a bit somewhere in the check_for_corruption area... Right now, the kaslr code just deals with initrd, cmdline, etc. If there are other reserved regions that aren't listed in the e820, it'll need to locate and skip them. -Kees Making my little steps towards more understanding I figured out that it isn't the code that does the relocation. Even with that completely disabled there were the vmalloc issues. What causes it seems to be the default of the upper limit and that this changes the split between kernel and modules to 1G+1G instead of 512M+1.5G. That is the reason why nokaslr has no effect. Oh! That's very interesting. There must be some assumption in Xen about the kernel VM layout then? No. I think most of the changes that look at PTE and PMDs are are all in arch/x86/xen/mmu.c. I wonder if this is xen_cleanhighmap being too aggressive (Sorry I had to cut our chat short at Kernel Summit!) I sounded like there was another region of memory that Xen was setting aside for page tables? But Stefan's investigation seems to show this isn't about layout at boot (since the kaslr=0 case means no relocation is done). Sounds more like the split between kernel and modules area, so I'm not sure how the memory area after the initrd would be part of this. What should next steps be, do you think? Maybe layout, but not about placement of the kernel. Basically leaving KASLR enabled but shrink the possible range back to the original kernel/module split is fine as well. I am bouncing between feeling close to understand to being confused. Konrad suggested xen_cleanhighmap being overly aggressive. But maybe its the other way round. The warning that occurs first indicates that PTE that was obtained for some vmalloc mapping is not unused (0) as it is expected. So it feels rather like some cleanup has *not* been done. Let me think aloud a bit... What seems to cause this, is the change of the kernel/module split from 512M:1.5G to 1G:1G (not exactly since there is 8M vsyscalls and 2M hole at the end). Which in vaddr terms means: Before: 8000 - 9fff (=512 MB) kernel text mapping, from phys 0 a000 - ff5f (=1526 MB) module mapping space After: 8000 - bfff (=1024 MB) kernel text mapping, from phys 0 c000 - ff5f (=1014 MB) module mapping space Now, *if* I got this right, this means the kernel starts on a vaddr that is pointed at by: PGD[510]-PUD[510]-PMD[0]-PTE[0] In the old layout the module vaddr area would start in the same PUD area, but with the change the kernel would cover PUD[510] and the module vaddr + vsyscalls and the hole would cover PUD[511]. I think there is a fixmap there too? Right, they forgot that in Documentation/x86/x86_64/mm... but head_64.S has it. So fixmap seems to be in the 2M space before the vsyscalls. Btw, apparently I got the PGD index wrong. It is of course 511, not 510.
Re: [Bugfix] x86, irq: Fix bug in setting IOAPIC pin attributes
On Wed, Aug 27, 2014 at 01:53:11PM +0800, Jiang Liu wrote: Commit 15a3c7cc9154321fc3 x86, irq: Introduce two helper functions to support irqdomain map operation breaks LPSS ACPI enumerated devices. On startup, IOAPIC driver preallocates IRQ descriptors and programs IOAPIC pins with default level and polarity attributes for all legacy IRQs. Later legacy IRQ users may fail to set IOAPIC pin attributes if the requested attributes conflicts with the default IOAPIC pin attributes. So change mp_irqdomain_map() to allow the first legacy IRQ user to reprogram IOAPIC pin with different attributes. Reported-by: Mika Westerberg mika.westerb...@linux.intel.com Signed-off-by: Jiang Liu jiang@linux.intel.com --- Hi Mika, We have a plan to kill function mp_set_gsi_attr() later, so I have slightly modified your changes. Could you please help to test it again? Works fine here, thanks! Tested-by: Mika Westerberg mika.westerb...@linux.intel.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/
[PATCHv5 1/2] parport: parport_pc: Introduce intel_bug_present function.
From: Matwey V. Kornilov mat...@sai.msu.ru
Put the code to check present of the Intel bug from parport_EPP_supported
into new intel_bug_present function. The later also return ECR register
to the state it has before function call.
Signed-off-by: Matwey V. Kornilov mat...@sai.msu.ru
---
drivers/parport/parport_pc.c | 38 ++
1 file changed, 26 insertions(+), 12 deletions(-)
diff --git a/drivers/parport/parport_pc.c b/drivers/parport/parport_pc.c
index 76ee775..fedc06b 100644
--- a/drivers/parport/parport_pc.c
+++ b/drivers/parport/parport_pc.c
@@ -1702,6 +1702,30 @@ static int parport_ECP_supported(struct parport *pb)
}
#endif
+static int intel_bug_present(struct parport *pb)
+{
+ const struct parport_pc_private *priv = pb-private_data;
+ int bug_present = 0;
+
+ if (priv-ecr) {
+ /* store value of ECR */
+ unsigned char ecr = inb(ECONTROL(pb));
+ unsigned char i;
+ for (i = 0x00; i 0x80; i += 0x20) {
+ ECR_WRITE(pb, i);
+ if (clear_epp_timeout(pb)) {
+ /* Phony EPP in ECP. */
+ bug_present = 1;
+ break;
+ }
+ }
+ /* return ECR into the inital state */
+ ECR_WRITE(pb, ecr);
+ }
+
+ return bug_present;
+}
+
static int parport_ECPPS2_supported(struct parport *pb)
{
const struct parport_pc_private *priv = pb-private_data;
@@ -1722,8 +1746,6 @@ static int parport_ECPPS2_supported(struct parport *pb)
static int parport_EPP_supported(struct parport *pb)
{
- const struct parport_pc_private *priv = pb-private_data;
-
/*
* Theory:
* Bit 0 of STR is the EPP timeout bit, this bit is 0
@@ -1742,16 +1764,8 @@ static int parport_EPP_supported(struct parport *pb)
return 0; /* No way to clear timeout */
/* Check for Intel bug. */
- if (priv-ecr) {
- unsigned char i;
- for (i = 0x00; i 0x80; i += 0x20) {
- ECR_WRITE(pb, i);
- if (clear_epp_timeout(pb)) {
- /* Phony EPP in ECP. */
- return 0;
- }
- }
- }
+ if (intel_bug_present(pb))
+ return 0;
pb-modes |= PARPORT_MODE_EPP;
--
1.8.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCHv5 2/2] parport: parport_pc: Implement architecture and device check to cut off false-positives
From: Matwey V. Kornilov mat...@sai.msu.ru
We definitely know that only x86 (32-bit) architecture is affected by the
issue, so implement a stub instead of the actual check for other architectures.
We also know that motherboard LPT chipset is affected, so the port is either
come from
parport_pc_init (when `io' module param is used) or
parport_pc_find_isa_ports (when default LPT ports are probbed: 0x378, 0x278,
0x3bc).
In both cases the port considered as 'legacy' and `dev' member of struct
parport is NULL. See also comments for `struct parport' in parport.h
Signed-off-by: Matwey V. Kornilov mat...@sai.msu.ru
---
drivers/parport/parport_pc.c | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/drivers/parport/parport_pc.c b/drivers/parport/parport_pc.c
index fedc06b..5b27747 100644
--- a/drivers/parport/parport_pc.c
+++ b/drivers/parport/parport_pc.c
@@ -1702,7 +1702,8 @@ static int parport_ECP_supported(struct parport *pb)
}
#endif
-static int intel_bug_present(struct parport *pb)
+#ifdef CONFIG_X86_32
+static int intel_bug_present_check_epp(struct parport *pb)
{
const struct parport_pc_private *priv = pb-private_data;
int bug_present = 0;
@@ -1725,6 +1726,21 @@ static int intel_bug_present(struct parport *pb)
return bug_present;
}
+static int intel_bug_present(struct parport *pb)
+{
+/* Check whether the device is legacy, not PCI or PCMCIA. Only legacy is known
to be affected. */
+ if (pb-dev != NULL) {
+ return 0;
+ }
+
+ return intel_bug_present_check_epp(pb);
+}
+#else
+static int intel_bug_present(struct parport *pb)
+{
+ return 0;
+}
+#endif /* CONFIG_X86_32 */
static int parport_ECPPS2_supported(struct parport *pb)
{
--
1.8.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCHv5 0/2] parport: parport_pc: Fix false-positives at checking for Intel bug
From: Matwey V. Kornilov mat...@sai.msu.ru Hi, The following patch series is to deal with the issue on false-positives of Intel EPP bug check [1]. More than a decade ago, the check was introduced in order to prevent EPP operation on the some Intel LPT chipsets. The main issue to defence from was CPU hang at EPP operation on broken chipsets. It is mentioned that affected chipsets are Intel 82091. However, it is not known whether there are others. The check was implemented in strange manner. Now, there is no explanations why. The check itself now leads to the false-positives, disabling EPP on many PC-s (Dell OptiPlex series for instance). The latter is an issue. Here is new version of the patches supposed to shrink the set of the false-positives. We know that the initial problem arises on x86 with motherboard LPT controller. The patches following are to enable initial check only for x86 and non-PCI based devices. It is hard to correctly determine which CPUs could be installed into PentiumPro-compatible socket, so I postponed initial Alan's suggestion. For those who want to check theirs hardware, there's prebuilt usb-stick image available: https://susestudio.com/a/OdbKqm/opensuse-13-1-parport_pc The patches organized as following: 1. Introduce-intel_bug_present-function The transparent refactoring of the check is performed. Make the check be immutable regarding to ECR register. 2. Implement architecture and device check to cut off false-positives Run the initial check only for x86, and for 'legacy' devices. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=630593 Signed-off-by: Matwey V. Kornilov mat...@sai.msu.ru --- Changes from v4: - Revert to v1 and implement different checks: arch and PCI-based. Changes from v3: - Do not introduce the additional option, rely on CPU model instead. Changes from v2: - The module option has more clear description Changes from v1: - Patch 1 fetched from right branch and now compiled -- 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] HID: picolcd: sanity check report size in raw_event() callback
On Wed, 27 Aug 2014 09:13:15 +0200 (CEST) Jiri Kosina wrote:
The report passed to us from transport driver could potentially be
arbitrarily large, therefore we better sanity-check it so that raw_data
that we hold in picolcd_pending structure are always kept within proper
bounds.
Cc: sta...@vger.kernel.org
Reported-by: Steven Vittitoe scvi...@google.com
Signed-off-by: Jiri Kosina jkos...@suse.cz
Acked-by: Bruno Prémont bonb...@linux-vserver.org
---
drivers/hid/hid-picolcd_core.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/hid/hid-picolcd_core.c b/drivers/hid/hid-picolcd_core.c
index acbb0210..020df3c 100644
--- a/drivers/hid/hid-picolcd_core.c
+++ b/drivers/hid/hid-picolcd_core.c
@@ -350,6 +350,12 @@ static int picolcd_raw_event(struct hid_device *hdev,
if (!data)
return 1;
+ if (size 64) {
+ hid_warn(hdev, invalid size value (%d) for picolcd raw
event\n,
+ size);
Is it worth adding report-id to this hid_warn()?
A valid device is not expected to ever send 64 bytes reports but in
case a firmware update would do so it would help to know for which
report it was.
+ return 0;
+ }
+
if (report-id == REPORT_KEY_STATE) {
if (data-input_keys)
ret = picolcd_raw_keypad(data, report, raw_data+1,
size-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: [alsa-devel] [PATCH 1/2] regmap: cache: Fix regcache_sync_block for non-autoincrementing devices
On Wed, Aug 27, 2014 at 08:52:16AM +0300, Jarkko Nikula wrote: I don't know. I was thinking that also but was unsure about it since regcache_sync_block_raw() and regcache_sync_block_single() code paths use different regmap write functions. regcache_sync_block_raw() ends up calling _regmap_raw_write() which takes care of page select operation when needed and regcache_sync_block_single() uses _regmap_write() which doesn't. Which makes me thinking should the regcache_sync_block_single() also use _regmap_raw_write() in order to take care of page selects? We can't use raw_write() for everything since not every bus can do a raw write. We probably need to push the select_page() operation into the _regmap_write() path though, it looks like it's getting missed at the minute. I ought to redo a lot of that code to simplify it, it's got too many tentacles at the minute. signature.asc Description: Digital signature
Re: [PATCH 2/2] HID: picolcd: sanity check report size in raw_event() callback
On Wed, 27 Aug 2014, Bruno Prémont wrote:
The report passed to us from transport driver could potentially be
arbitrarily large, therefore we better sanity-check it so that raw_data
that we hold in picolcd_pending structure are always kept within proper
bounds.
Cc: sta...@vger.kernel.org
Reported-by: Steven Vittitoe scvi...@google.com
Signed-off-by: Jiri Kosina jkos...@suse.cz
Acked-by: Bruno Prémont bonb...@linux-vserver.org
Thanks.
---
drivers/hid/hid-picolcd_core.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/hid/hid-picolcd_core.c b/drivers/hid/hid-picolcd_core.c
index acbb0210..020df3c 100644
--- a/drivers/hid/hid-picolcd_core.c
+++ b/drivers/hid/hid-picolcd_core.c
@@ -350,6 +350,12 @@ static int picolcd_raw_event(struct hid_device *hdev,
if (!data)
return 1;
+ if (size 64) {
+ hid_warn(hdev, invalid size value (%d) for picolcd raw
event\n,
+ size);
Is it worth adding report-id to this hid_warn()?
A valid device is not expected to ever send 64 bytes reports but in
case a firmware update would do so it would help to know for which
report it was.
It definitely wouldn't hurt. Pull request with the original patch is now
on its way to Linus though, so let's do this as a followup patch on top
once this is merged.
--
Jiri Kosina
SUSE Labs
--
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] iio: adc: at91: make the function handle_adc_eoc_trigger() static
On 27/08/2014 10:31, Josh Wu :
The handle_adc_eoc_trigger() in only used in at91_adc.c. So make it
static.
Signed-off-by: Josh Wu josh...@atmel.com
Absolutely.
Acked-by: Nicolas Ferre nicolas.fe...@atmel.com
Thanks, bye.
---
drivers/iio/adc/at91_adc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iio/adc/at91_adc.c b/drivers/iio/adc/at91_adc.c
index 772e869..7807e0e 100644
--- a/drivers/iio/adc/at91_adc.c
+++ b/drivers/iio/adc/at91_adc.c
@@ -266,7 +266,7 @@ static irqreturn_t at91_adc_trigger_handler(int irq, void
*p)
}
/* Handler for classic adc channel eoc trigger */
-void handle_adc_eoc_trigger(int irq, struct iio_dev *idev)
+static void handle_adc_eoc_trigger(int irq, struct iio_dev *idev)
{
struct at91_adc_state *st = iio_priv(idev);
--
Nicolas Ferre
--
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] iio: adc: at91: make the function handle_adc_eoc_trigger() static
The handle_adc_eoc_trigger() in only used in at91_adc.c. So make it
static.
Signed-off-by: Josh Wu josh...@atmel.com
---
drivers/iio/adc/at91_adc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iio/adc/at91_adc.c b/drivers/iio/adc/at91_adc.c
index 772e869..7807e0e 100644
--- a/drivers/iio/adc/at91_adc.c
+++ b/drivers/iio/adc/at91_adc.c
@@ -266,7 +266,7 @@ static irqreturn_t at91_adc_trigger_handler(int irq, void
*p)
}
/* Handler for classic adc channel eoc trigger */
-void handle_adc_eoc_trigger(int irq, struct iio_dev *idev)
+static void handle_adc_eoc_trigger(int irq, struct iio_dev *idev)
{
struct at91_adc_state *st = iio_priv(idev);
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] Adding Skyworks SKY81452 MFD driver
On Wed, 27 Aug 2014, Gyungoh Yoo wrote:
On Tue, Aug 26, 2014 at 09:22:58AM +0100, Lee Jones wrote:
On Mon, 25 Aug 2014, Gyungoh Yoo wrote:
On Thu, Aug 21, 2014 at 10:45:02AM +0100, Lee Jones wrote:
When you send patch-sets, you should send them connected to one
another AKA threaded. That way, when we're reviewing we can look at
the other patches in the set for reference. See the man page for `git
send-email` for details.
commit log
Signed-off-by: Gyungoh Yoo jack@skyworksinc.com
---
[...]
+static int sky81452_register_devices(struct device *dev,
+ const struct sky81452_platform_data *pdata)
+{
+ struct mfd_cell cells[] = {
+ {
+ .name = sky81452-bl,
+ .platform_data = pdata-bl_pdata,
+ .pdata_size = sizeof(*pdata-bl_pdata),
Have you tested this with DT?
You're not passing the compatible string and not using
of_platform_populate() so I'm struggling to see how it would work
properly.
sky81452-bl and regulator-sky81452 is parsing the information
in regulator node of its parent node. So I thought these 2 drivers
don't need compatible attribute. That is what it didn't have
compatible string.
Is is mandatory that all drivers should have compatible attribute?
How do they obtain their DT nodes?
The backlight driver which is one of the child driver is obtain its DT node
like this
np = of_get_child_by_name(dev-parent-of_node, backlight);
The MFD core provides infrastructure so you don't have to do this.
Just place the compatible string in 'struct mfd_cell cells[]' and the
core will match and populate dev-of_node for you.
[...]
+ return mfd_add_devices(dev, -1, cells, ARRAY_SIZE(cells),
+ NULL, 0, NULL);
This doesn't really need to be in a function of its own. Please put
it in .probe(). Also check for the return value and present the user
with an error message if it fails.
I think this need to be, in case of !CONFIG_OF.
Can you please explain more in details?
Then how to you obtain the shared register map you created?
regmap is stored in driver data in MFD.
i2c_set_clientdata(client, regmap);
The child drivers obain the regmap from the parent.
struct regmap *regmap = dev_get_drvdata(dev-parent);
Ah yes, of course you do. Silly of me to miss this.
I also just noticed that you're also manually populating the
chlidren's platform data. It's easier if you do this from the child
device drivers:
const struct sky81452_platform_data ppdata = dev_get_platdata(dev-parent);
const struct sky81452_bl_platform_data = pdata = ppdata-bl_pdata;
--
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: Buffer I/O error after s2ram with usb storage
Ping I have got also a problem with a usb sdcard reader (without power cut during suspend) [ 1073.606668] PM: Entering mem sleep [ 1073.606742] Suspending console(s) (use no_console_suspend to debug) [ 1073.607146] sd 1:0:0:0: [sda] Synchronizing SCSI cache [ 1073.639076] sd 1:0:0:0: [sda] Stopping disk [ 1074.186688] PM: suspend of devices complete after 580.127 msecs [...] [ 1075.265183] PM: resume of devices complete after 615.990 msecs [ 1075.265627] PM: Finishing wakeup. [ 1075.265630] Restarting tasks ... [...] [ 1203.404593] EXT4-fs error (device sdb6): ext4_mb_generate_buddy:756: group 6, 29065 clusters in bitmap, 32768 in gd; block bitmap corrupt. [ 1203.404628] EXT4-fs error (device sdb6): ext4_mb_generate_buddy:756: group 5, 1601 clusters in bitmap, 32321 in gd; block bitmap corrupt. [ 1203.404648] EXT4-fs error (device sdb6): ext4_mb_generate_buddy:756: group 4, 0 clusters in bitmap, 32768 in gd; block bitmap corrupt. [ 1203.404667] EXT4-fs error (device sdb6): ext4_mb_generate_buddy:756: group 3, 1601 clusters in bitmap, 32321 in gd; block bitmap corrupt. [ 1203.404686] EXT4-fs error (device sdb6): ext4_mb_generate_buddy:756: group 2, 0 clusters in bitmap, 32768 in gd; block bitmap corrupt. [ 1203.404705] EXT4-fs error (device sdb6): ext4_mb_generate_buddy:756: group 1, 1600 clusters in bitmap, 32321 in gd; block bitmap corrupt. [ 1203.404726] JBD2: Spotted dirty metadata buffer (dev = sdb6, blocknr = 0). There's a risk of filesystem corruption in case of system crash. [ 1204.141482] sd 8:0:0:0: [sdb] Media Changed [ 1204.141490] sd 8:0:0:0: [sdb] [ 1204.141494] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [ 1204.141497] sd 8:0:0:0: [sdb] [ 1204.141499] Sense Key : Unit Attention [current] [ 1204.141504] Info fld=0x0 [ 1204.141506] sd 8:0:0:0: [sdb] [ 1204.141510] Add. Sense: Not ready to ready change, medium may have changed [ 1204.141514] sd 8:0:0:0: [sdb] CDB: [ 1204.141516] Read(10): 28 00 00 0a 75 f8 00 00 08 00 [ 1204.141526] end_request: I/O error, dev sdb, sector 685560 Le Mon, 28 Apr 2014 15:01:39 +0200, Matthieu CASTET matthieu.cas...@parrot.com a écrit : Hi, any news on this. Matthieu CASTET Le Tue, 22 Apr 2014 16:01:15 +0200, Matthieu CASTET matthieu.cas...@parrot.com a écrit : Hi, while playing with suspend to ram I found a strange behavior with usb key. This can be easily reproduced by doing : - plug a usb key - start to read the usb key : cat /dev/sdx /dev/null - go to suspend : echo mem /sys/power/state - while in suspend, unplug and replug the usb key (simulate usb power loss for computer that keep power) - exit suspend - there is read error on the usb key Because the power was cut during s2ram, the usb stack reset the device 1. When new data transfer are done, we got a UNIT_ATTENTION from the device 2 and IO error are returned to user space application. After some investigation it seems some (all on the 3 I tested) usb key report as removable, and scsi layer abort the transfer in case of UNIT_ATTENTION 3. The usb storage driver call scsi_report_bus_reset after device reset, but because of commit dfcf7775 4, we don't ignore unit attention if sshdr.asc == 0x28 sshdr.ascq == 0x00 (Not-ready to ready). If dfcf7775 is reverted there is no more Buffer I/O error. Is that possible to find a way to restore the behavior before dfcf7775 commit (no Buffer I/O error after device reset) after a suspend to ram ? Matthieu CASTET PS : the same error happen if sg_reset -b /dev/sdx is used on the device. 1 [ 117.070255] usb 2-1.4: reset high-speed USB device number 3 using ehci-pci [...] [ 117.543922] Restarting tasks ... done. [ 117.548390] video LNXVIDEO:01: Restoring backlight state 2 [ 117.549179] sd 6:0:0:0: [sdb] Media Changed [ 117.549184] sd 6:0:0:0: [sdb] [ 117.549187] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [ 117.549189] sd 6:0:0:0: [sdb] [ 117.549191] Sense Key : Unit Attention [current] [ 117.549195] Info fld=0x0 [ 117.549197] sd 6:0:0:0: [sdb] [ 117.549201] Add. Sense: Not ready to ready change, medium may have changed [ 117.549203] sd 6:0:0:0: [sdb] CDB: [ 117.549205] Read(10): 28 00 00 02 c9 00 00 00 f0 00 [ 117.549212] end_request: I/O error, dev sdb, sector 182528 [ 117.549218] Buffer I/O error on device sdb1, logical block 22560 [ 117.549225] Buffer I/O error on device sdb1, logical block 22561 [ 117.549228] Buffer I/O error on device sdb1, logical block 22562 [ 117.549231] Buffer I/O error on device sdb1, logical block 22563 [ 117.549233] Buffer I/O error on device sdb1, logical block 22564 [ 117.549235] Buffer I/O error on device sdb1, logical block 22565 [ 117.549238] Buffer I/O error on device sdb1, logical block 22566 [ 117.549240] Buffer I/O error on device sdb1, logical block 22567 [ 117.549243] Buffer I/O error on device sdb1, logical block 22568 [
Re: [PATCH][v5] therm_windtunnel does not work properly on PowerMac G4
Hi Benjamin, do you have any feedback about this ? Do you think that it would be possible to include these patches in a next pull-for-linus ? Let me know, if you want other changes. BR G.Baroncelli On 08/09/2014 08:49 AM, Goffredo Baroncelli wrote: Hi All, On a PowerMac G4 I noticed that between the kernel v3.2 and v3.14 I lost the fan management. I found on internet other references to this kind of problem [2] **How reproduce: - booting with the kernel 3.2, the fan is quite silent. The module therm_windtunnel is loaded and in the log there are lines like: [ 1342.614956] CPU-temp: 58.7 C, Case: 33.7 C, Fan: 5 (tuned +0) [ 1390.637793] CPU-temp: 58.6 C, Case: 33.6 C, Fan: 5 I had also access to the temperature via the sysfs files: /sys/devices/temperature/case_temperature /sys/devices/temperature/cpu_temperature - booting with the kernel 3.14, the fan is very loud. The module therm_windtunnel is not loaded. In the log there aren't any message related to the temperature. The sysfs entries don't exist. ** Analysis In these Apple machines the module i2c-powermac requires the i2c drivers provided by the module therm_windtunnel. Between the kernel v3.2 and v3.14 [1] some patches changed the driver name requested by the i2c-powermac module, so the therm_windtunnel modules is not instantiated anymore. ** Proposed solution In the following emails I sent you 5 patches to solve this problem (tested on my PowerMac G4). Only the first two are strictly related to the problem, the others three may be skipped. 1) change the driver name therm_ds1775 - MAC,ds1775 therm_adm1030 - MAC,adm1030 so the i2c driver are instantiated by i2c-powermac 2) remove the (unused) method do_attach from the i2c-driver 3) add a parameter to the therm_windtunnel module to control the kernel log message 4) export the fan speed via sysfs 5) export the temperature via the hwmon subsistem The patch 1) solve the problem. The patch 2) is a small cleanup. The patch 3) allow a better control of the log in dmesg. The patch 4) is copyied from the Bryan Christianson's patch (see debian bug #741663) The patch 5) export the temperatures via hwmon, a more standard interface. I also added the internal sensor of the adm1030, which I called Case2, because it measure the same temperature /+/- 1C) of the Case sensor. I have to highlight that I tried to export also the fan speed, but I was unable to get it, without affecting the fan speed: when I set the bit 2 (TACH 1 En) of the register 0x1 (Configuration 2), it seemed that the speed every 4/5s dropped, then it raised quickly I didn't perform other test to avoid damages. Could you be so kindly to apply these patches ? PS: I am not LKML subscriber, so please put me in CC in case of reply. BR G.Baroncelli Changelog: v1: 2014/07/30 - first issue v2: 2014/08/01 - protect with a mutex the check before starting the fan daemon (to protect from parallel drivers instantation) - reduce the number of module parameters to 1 as suggested by Jean Delvare - export the fan speed via sysfs v3: 2014/08/06 - export the temperatures via hwmon - export the internal temperature sensor of the adm1030 - little cleanup due to the suggestion of checkpatch.pl ( and Jean Delvare) - removed the (tune +0) in the log. v4: 2014/08/07 - accepted some small cleanup suggestions from Jean Delvare - replaced SENSOR_DEVICE_ATTR with DEVICE_ATTR, and added ATTRIBUTE_GROUPS() use v5: 2014/08/09 - hanlde the return error of hwmon_device_register_with_groups() with IS_ERR() macro - better explanation about the source of patch #4 [1] I think that the guilty commit is commit 81e5d8646ff6bf323dddcf172aa3cef84468fa12 Author: Benjamin Herrenschmidt b...@kernel.crashing.org Date: Wed Apr 18 22:16:42 2012 + i2c/powermac: Register i2c devices from device-tree This causes i2c-powermac to register i2c devices exposed in the device-tree, enabling new-style probing of devices. Note that we prefix the IDs with MAC, in order to prevent the generic drivers from matching. This is done on purpose as we only want drivers specifically tested/designed to operate on powermacs to match. This removes the special case we had for the AMS driver, and updates the driver's match table instead. Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org [2] There is the debian bug #741663 which highlight the same problem. In the bug discussion there is a patch like the my ones. See also https://lists.ozlabs.org/pipermail/linuxppc-dev/2012-July/099561.html -- gpg @keyserver.linux.it: Goffredo Baroncelli (kreijackATinwind.it Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5 -- To
Re: [PATCH v3] iio: Add Dyna-Image AL3320A ambient light sensor driver
Daniel Baluta schrieb:
Minimal implementation. This driver provides raw illuminance readings.
This is based on drivers/hwmon/al3320.c (*) driver from msm tree written
by Tsechih Lin tsechih_...@asus.com
* https://android.googlesource.com/kernel/msm.git
Signed-off-by: Daniel Baluta daniel.bal...@intel.com
Hi, I think you should protect your write_raw with a mutex. Other minor
comments inline.
---
Changes since v2: (reported by Peter Meerwald)
* removed definition of DATA_HIGH and SW_RESET as they are not used
* added a comment to al3320a_get_adc_value() function
* added thresholds on TODO list
* small stye fixes
Changes since v1: (reported by Peter Meerwald)
* used u8 instead of int for passing gain and mean_time
* used i2c_smbus_read_word_swapped instead of 2 x
i2c_smbus_read_byte_data
* used devm_iio_device_register instead of iio_device_register
* small style fixes
drivers/iio/light/Kconfig | 10 ++
drivers/iio/light/Makefile | 1 +
drivers/iio/light/al3320a.c | 255
3 files changed, 266 insertions(+)
create mode 100644 drivers/iio/light/al3320a.c
diff --git a/drivers/iio/light/Kconfig b/drivers/iio/light/Kconfig
index bf05ca5..5bea821 100644
--- a/drivers/iio/light/Kconfig
+++ b/drivers/iio/light/Kconfig
@@ -17,6 +17,16 @@ config ADJD_S311
This driver can also be built as a module. If so, the module
will be called adjd_s311.
+config AL3320A
+ tristate AL3320A ambient light sensor
+ depends on I2C
+ help
+ Say Y here if you want to build a driver for the Dyna Image AL3320A
+ ambient light sensor.
+
+ To compile this driver as a module, choose M here: the
+ module will be called al3320a.
+
config APDS9300
tristate APDS9300 ambient light sensor
depends on I2C
diff --git a/drivers/iio/light/Makefile b/drivers/iio/light/Makefile
index 8b8c09f..47877a3 100644
--- a/drivers/iio/light/Makefile
+++ b/drivers/iio/light/Makefile
@@ -4,6 +4,7 @@
# When adding new entries keep the list in alphabetical order
obj-$(CONFIG_ADJD_S311) += adjd_s311.o
+obj-$(CONFIG_AL3320A)+= al3320a.o
obj-$(CONFIG_APDS9300) += apds9300.o
obj-$(CONFIG_CM32181)+= cm32181.o
obj-$(CONFIG_CM36651)+= cm36651.o
diff --git a/drivers/iio/light/al3320a.c b/drivers/iio/light/al3320a.c
new file mode 100644
index 000..28fc8b0
--- /dev/null
+++ b/drivers/iio/light/al3320a.c
@@ -0,0 +1,255 @@
+/*
+ * AL3320A - Dyna Image Ambient Light Sensor
+ *
+ * Copyright (c) 2014, Intel Corporation.
+ *
+ * This file is subject to the terms and conditions of version 2 of
+ * the GNU General Public License. See the file COPYING in the main
+ * directory of this archive for more details.
+ *
+ * IIO driver for AL3320A (7-bit I2C slave address 0x1C).
+ *
+ * TODO: interrupt support, thresholds
+ *
+ */
+
+#include linux/module.h
+#include linux/init.h
+#include linux/i2c.h
+
+#include linux/iio/iio.h
+#include linux/iio/sysfs.h
+
+#define AL3320A_DRV_NAME al3320a
+
+#define AL3320A_REG_CONFIG 0x00
+#define AL3320A_REG_STATUS 0x01
+#define AL3320A_REG_INT 0x02
+#define AL3320A_REG_WAIT 0x06
+#define AL3320A_REG_CONFIG_RANGE 0x07
+#define AL3320A_REG_PERSIST 0x08
+#define AL3320A_REG_MEAN_TIME0x09
+#define AL3320A_REG_ADUMMY 0x0A
+#define AL3320A_REG_DATA_LOW 0x22
+
+#define AL3320A_REG_LOW_THRESH_LOW 0x30
+#define AL3320A_REG_LOW_THRESH_HIGH 0x31
+#define AL3320A_REG_HIGH_THRESH_LOW 0x32
+#define AL3320A_REG_HIGH_THRESH_HIGH 0x33
+
+#define AL3320A_CONFIG_DISABLE 0x00
+#define AL3320A_CONFIG_ENABLEBIT(0)
+
+#define AL3320A_GAIN_SHIFT 1
+
+/* chip params default values */
+#define AL3320A_DEFAULT_MEAN_TIME4
+#define AL3320A_DEFAULT_WAIT_TIME0 /* no waiting */
+
+enum al3320a_range {
+ AL3320A_RANGE_1, /* 33.28K lux */
+ AL3320A_RANGE_2, /* 8.32K lux */
+ AL3320A_RANGE_3, /* 2.08K lux */
+ AL3320A_RANGE_4 /* 0.65K lux */
+};
+
+static const int al3320a_scales[][2] = {
+ {0, 512000}, {0, 128000}, {0, 32000}, {0, 1}
+};
+
+struct al3320a_data {
+ struct i2c_client *client;
+ u8 range;
+};
+
+static const struct iio_chan_spec al3320a_channels[] = {
+ {
+ .type = IIO_LIGHT,
+ .info_mask_separate =
+ BIT(IIO_CHAN_INFO_RAW) |
+ BIT(IIO_CHAN_INFO_SCALE),
I would indent it like this:
+ .type = IIO_LIGHT,
+ .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |
+ BIT(IIO_CHAN_INFO_SCALE),
+ }
+};
+
+static int al3320a_enable(struct al3320a_data *data)
+{
+ return
tracing: horrible read performance on host with many CPUs
I have tried to use tracing on host with 32cpus, but it is appeared that performance is horrible. dd if=/sys/kernel/debug/tracing/trace_pipe of=tmpfs/t3.log bs=1M 0+21268 records in 0+21267 records out 85701248 bytes (86 MB) copied, 26.1424 s, 3.3 MB/s 0+25706 records in 0+25705 records out 103600749 bytes (104 MB) copied, 31.6595 s, 3.3 MB/s 0+59204 records in 0+59203 records out 238746128 bytes (239 MB) copied, 73.4347 s, 3.3 MB/s Since I've collected ~3Gb of data this takes a lot of time to simply copy from kernel to tmpfs. AFAIU this happen due to sub-optimal sorting procedure __find_next_entry Each time it walks each cpu and pick the one with smallest timestamp. This can be optimized simply by fetching N-entries at the time. Are there any plans to implement that? BTW:What is the most convenient way fetch big data from traces? One of possible way is to dump per-cpu traces(20Mb/s in my case) and then merge files according to timestamp -- 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: [3.16 stable PATCH v2 1/2] virtio: rng: delay hwrng_register() till driver is ready
Hey Greg,
Can you add these two patches to the 3.16 queue?
Thanks,
On (Tue) 12 Aug 2014 [13:23:45], Amit Shah wrote:
Instead of calling hwrng_register() in the probe routing, call it in the
scan routine. This ensures that when hwrng_register() is successful,
and it requests a few random bytes to seed the kernel's pool at init,
we're ready to service that request.
This will also enable us to remove the workaround added previously to
check whether probe was completed, and only then ask for data from the
host. The revert follows in the next commit.
There's a slight behaviour change here on unsuccessful hwrng_register().
Previously, when hwrng_register() failed, the probe() routine would
fail, and the vqs would be torn down, and driver would be marked not
initialized. Now, the vqs will remain initialized, driver would be
marked initialized as well, but won't be available in the list of RNGs
available to hwrng core. To fix the failures, the procedure remains the
same, i.e. unload and re-load the module, and hope things succeed the
next time around.
Signed-off-by: Amit Shah amit.s...@redhat.com
Signed-off-by: Rusty Russell ru...@rustcorp.com.au
(cherry picked from commit 5c06273401f2eb7b290cadbae18ee00f8f65e893)
Signed-off-by: Amit Shah amit.s...@redhat.com
---
drivers/char/hw_random/virtio-rng.c | 25 +++--
1 file changed, 15 insertions(+), 10 deletions(-)
diff --git a/drivers/char/hw_random/virtio-rng.c
b/drivers/char/hw_random/virtio-rng.c
index e9b15bc..f4e04f3 100644
--- a/drivers/char/hw_random/virtio-rng.c
+++ b/drivers/char/hw_random/virtio-rng.c
@@ -36,6 +36,7 @@ struct virtrng_info {
bool busy;
char name[25];
int index;
+ bool hwrng_register_done;
};
static bool probe_done;
@@ -137,15 +138,6 @@ static int probe_common(struct virtio_device *vdev)
return err;
}
- err = hwrng_register(vi-hwrng);
- if (err) {
- vdev-config-del_vqs(vdev);
- vi-vq = NULL;
- kfree(vi);
- ida_simple_remove(rng_index_ida, index);
- return err;
- }
-
probe_done = true;
return 0;
}
@@ -153,9 +145,11 @@ static int probe_common(struct virtio_device *vdev)
static void remove_common(struct virtio_device *vdev)
{
struct virtrng_info *vi = vdev-priv;
+
vdev-config-reset(vdev);
vi-busy = false;
- hwrng_unregister(vi-hwrng);
+ if (vi-hwrng_register_done)
+ hwrng_unregister(vi-hwrng);
vdev-config-del_vqs(vdev);
ida_simple_remove(rng_index_ida, vi-index);
kfree(vi);
@@ -171,6 +165,16 @@ static void virtrng_remove(struct virtio_device *vdev)
remove_common(vdev);
}
+static void virtrng_scan(struct virtio_device *vdev)
+{
+ struct virtrng_info *vi = vdev-priv;
+ int err;
+
+ err = hwrng_register(vi-hwrng);
+ if (!err)
+ vi-hwrng_register_done = true;
+}
+
#ifdef CONFIG_PM_SLEEP
static int virtrng_freeze(struct virtio_device *vdev)
{
@@ -195,6 +199,7 @@ static struct virtio_driver virtio_rng_driver = {
.id_table = id_table,
.probe =virtrng_probe,
.remove = virtrng_remove,
+ .scan = virtrng_scan,
#ifdef CONFIG_PM_SLEEP
.freeze = virtrng_freeze,
.restore = virtrng_restore,
--
1.9.3
Amit
--
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] irqdomain: Introduce new interfaces to support hierarchy irqdomains
Jiang, On Wed, 27 Aug 2014, Jiang Liu wrote: Third, a special value IRQDOMAIN_AUTO_ASSIGN_HWIRQ is defined out of irq_hw_number_t, which indicates that irqdomain callbacks should automatically hardware interrupt number for clients. This will be used to support CPU vector allocation and interrupt remapping controller on x86 platforms. I can't see the point of this. If we have a hierarchy then this is a property of the hierarchy itself not of an indiviual call. When invoking irqdomain interfaces, we need to pass in an hwirq. For IOAPIC, it's the pin number. But for remap and vector domains, caller can't provide hwirq, it's assigned by remap and vector domains themselves. So introduced IRQDOMAIN_AUTO_ASSIGN_HWIRQ to indicate that irqdomain will assign hwirq for callers. I don't think it's an issue. You don't have to worry about the existing irqdomain semantics and functionality. By introducing hierarchy some of the existing rules are going to change no matter what. So we should not try to make the interfaces which are required for the hierarchical domains follow the semantics of the existing plain interfaces. If we decide to have the allocation scheme which I outlined, then this becomes completely moot, simply because the allocation will take care of this. Lets look at the MSI example again. MSI does not have a hwirq number, the MSI domain manages the MSI msg and that is composed from the information which is created/managed by the remap and vector domains. Fourth, the flag IRQDOMAIN_FLAG_HIERARCHY is used to indicate weather irqdomain operations are hierarchy request. The irqdomain core uses Why do we need that flag? If a domain has a parent domain, we already know that this domain is part of a hierarchy. This flag is passed into hierarchy irqdomain interfaces for two purposes: 1) to protect irq_data-hwirq and irq_data-domain Again, you try to bolt the hierarchy into the existing design rather than doing a hierarchy design for irq domains and either map the existing flat domain functionality into it or just leave it alone. But your data representation is not hierarchical because only the outmost domain map is stored in irq_data. For the parent domains you offload the storage to the domain implementation itself. One of my design rules is only to change x86 arch specific code when possible, so used above solution. This design rule is wrong to begin with. You need to touch core code anyway to support the hierarchy mechanisms. So you better have a proper support for all of this in the core than having half baken infrastructure plus ugly workarounds in the architecture code. If we could make changes to public data structures, we may find better solution as you have suggested:) Of course we can do that and we should do it. and avoid magic conditionals in the chip callbacks. That's a good suggestion. Should we reuse irq_data directly or group some fields from irq_data into a new data structure? If we keep irq_data, then all nested chip callbacks and other things just work. So creating a new sub structure is probably counterproductive. Now you might ask the question how #2 makes use of #1 (cfg-vector/cfg-domain) and #3 makes use of #2 (msi msg). That's rather simple. Currently we solve this issue by packing all data into irq_cfg, we remap and ioapic level could access apic id and vector in vector domain. Well, that's how it was hacked into the code in the first place, but that's not something we want to keep. Clear separation of storage is definitely a goal of doing the whole hierarchy change. I plan to build one irqdomain to support MSI/MSIx, but system may have multiple interrupt remapping units. It's a little tricky to maintain hierarchy relationship between MSI irqdomain and remapping irqdomain. It's hard to maintain N:N relationship for MSI and remapping irqdomains. So should we maintain 1:N or 1:1 relationships? In other words, should we build one irqdomain for each remapping unit or only build one irqdomain for all remapping units? If you have several remapping domains, then you might consider to have several corresponding MSI[X] domains as well. That's how the hardware is structured. On the other hand, it's a good news that we almost have the same goals, and just have different ways to achieve our goals. I tried to change x86 arch code only, and you suggest to touch the irq public code. To be honest, I have no enough confidence to touch irq public code at the first step:( Don't worry about touching generic code. It's not different from x86 code and having a proper core infrastructure makes the architecture side clean and simple rather than stuffed with obscure workarounds. I'm happy to guide you through if there are questions or design decisions to make. Thanks, tglx -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More
Re: [PATCH v6 5/5] regulator: RK808: remove redundant code
On Tue, Aug 26, 2014 at 10:18:57PM +0800, Chris Zhong wrote: remove the redundant code, since pdata has been removed from stuct rk808 I've applied this but if there's further changes needed please wait until the MFD changes they depend on have been accepted before resending. This will be less work all round. signature.asc Description: Digital signature
Re: [PATCH/RFC 2/2] lib: string: Make all calls to strnicmp into calls to strncasecmp
On Wed, Aug 27, 2014 at 09:36:02AM +0200, Rasmus Villemoes wrote: The previous patch made strnicmp into a wrapper for strncasecmp. This patch makes all in-tree users of strnicmp call strncasecmp directly, while still making sure that the strnicmp symbol can be used by out-of-tree modules. It should be considered a temporary hack until all in-tree callers have been converted. Signed-off-by: Rasmus Villemoes li...@rasmusvillemoes.dk Won't GCC just do the right thing without this second patch? regards, dan carpenter -- 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 2/2] lib: string: Make all calls to strnicmp into calls to strncasecmp
On Wed, Aug 27 2014, Dan Carpenter dan.carpen...@oracle.com wrote: On Wed, Aug 27, 2014 at 09:36:02AM +0200, Rasmus Villemoes wrote: The previous patch made strnicmp into a wrapper for strncasecmp. This patch makes all in-tree users of strnicmp call strncasecmp directly, while still making sure that the strnicmp symbol can be used by out-of-tree modules. It should be considered a temporary hack until all in-tree callers have been converted. Signed-off-by: Rasmus Villemoes li...@rasmusvillemoes.dk Won't GCC just do the right thing without this second patch? Not without LTO, I think. gcc can't really know how strnicmp is implemented, so it has to emit a call to it. Anyway, I was also planning on sending tree-wide patches doing s/strnicmp/strncasecmp/, and then removing the hack from string.h, but I first wanted to get feedback on the first patch and maybe some guidance on how to properly deal with the module issue (e.g., does the kernel need to export a strnicmp symbol forever?). Rasmus -- 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/
[tip:x86/urgent] x86: irq: Fix bug in setting IOAPIC pin attributes
Commit-ID: f395dcae7a68497751869cf0031fd8ce5e115f0a
Gitweb: http://git.kernel.org/tip/f395dcae7a68497751869cf0031fd8ce5e115f0a
Author: Jiang Liu jiang@linux.intel.com
AuthorDate: Wed, 27 Aug 2014 13:53:11 +0800
Committer: Thomas Gleixner t...@linutronix.de
CommitDate: Wed, 27 Aug 2014 11:02:16 +0200
x86: irq: Fix bug in setting IOAPIC pin attributes
Commit 15a3c7cc9154321fc3 x86, irq: Introduce two helper functions
to support irqdomain map operation breaks LPSS ACPI enumerated
devices.
On startup, IOAPIC driver preallocates IRQ descriptors and programs
IOAPIC pins with default level and polarity attributes for all legacy
IRQs. Later legacy IRQ users may fail to set IOAPIC pin attributes
if the requested attributes conflicts with the default IOAPIC pin
attributes. So change mp_irqdomain_map() to allow the first legacy IRQ
user to reprogram IOAPIC pin with different attributes.
Reported-and-tested-by: Mika Westerberg mika.westerb...@linux.intel.com
Signed-off-by: Jiang Liu jiang@linux.intel.com
Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Cc: Tony Luck tony.l...@intel.com
Cc: Joerg Roedel j...@8bytes.org
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Cc: Rafael J. Wysocki r...@rjwysocki.net
Cc: Bjorn Helgaas bhelg...@google.com
Cc: Randy Dunlap rdun...@infradead.org
Cc: Yinghai Lu ying...@kernel.org
Cc: Borislav Petkov b...@alien8.de
Cc: Grant Likely grant.lik...@linaro.org
Cc: Prarit Bhargava pra...@redhat.com
Link:
http://lkml.kernel.org/r/1409118795-17046-1-git-send-email-jiang@linux.intel.com
Signed-off-by: Thomas Gleixner t...@linutronix.de
---
arch/x86/kernel/apic/io_apic.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index 29290f5..40a4aa3 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -1070,6 +1070,11 @@ static int mp_map_pin_to_irq(u32 gsi, int idx, int
ioapic, int pin,
}
if (flags IOAPIC_MAP_ALLOC) {
+ /* special handling for legacy IRQs */
+ if (irq nr_legacy_irqs() info-count == 1
+ mp_irqdomain_map(domain, irq, pin) != 0)
+ irq = -1;
+
if (irq 0)
info-count++;
else if (info-count == 0)
@@ -3896,7 +3901,15 @@ int mp_irqdomain_map(struct irq_domain *domain, unsigned
int virq,
info-polarity = 1;
}
info-node = NUMA_NO_NODE;
- info-set = 1;
+
+ /*
+* setup_IO_APIC_irqs() programs all legacy IRQs with default
+* trigger and polarity attributes. Don't set the flag for that
+* case so the first legacy IRQ user could reprogram the pin
+* with real trigger and polarity attributes.
+*/
+ if (virq = nr_legacy_irqs() || info-count)
+ info-set = 1;
}
set_io_apic_irq_attr(attr, ioapic, hwirq, info-trigger,
info-polarity);
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/4] Drivers: hv: vmbus: Eliminate calls to BUG_ON()
On Tue, Aug 26, 2014 at 12:05:22PM -0700, K. Y. Srinivasan wrote: Cleanup the channel management code and eliminate calls to BUG_ON() K. Y. Srinivasan (4): Drivers: hv: vmbus: Cleanup vmbus_post_msg() Drivers: hv: vmbus: Cleanup vmbus_teardown_gpadl() Drivers: hv: vmbus: Cleanup vmbus_close_internal() Drivers: hv: vmbus: Cleanup vmbus_establish_gpadl() I've applied these on top of 3.17-rc1 and my Hyper-V guest with most verification on bar DEBUG_PAGEALLOC boots without issue so long as I have more than one CPU assigned (that issue is being investigated in https://lkml.org/lkml/2014/8/26/271, [PANIC, hyperv] BUG: unable to handle kernel paging request at 88007784 (hv_ringbuffer_write)). With DEBUG_PAGEALLOC on I hit https://lkml.org/lkml/2014/8/19/227 (BUG: unable to handle kernel paging request at 8801f3febe63 (netvsc_select_queue)) but that's different to the above BUG_ONs. -- Sitsofe | http://sucs.org/~sits/ -- 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/
[tip:timers/core] timerfd: Remove an always true check
Commit-ID: 88299c9bdb109e0d95abdca648065631ff91b2cb
Gitweb: http://git.kernel.org/tip/88299c9bdb109e0d95abdca648065631ff91b2cb
Author: Dan Carpenter dan.carpen...@oracle.com
AuthorDate: Fri, 1 Aug 2014 11:28:48 +0300
Committer: Thomas Gleixner t...@linutronix.de
CommitDate: Wed, 27 Aug 2014 11:17:48 +0200
timerfd: Remove an always true check
We would have returned -EINVAL earlier if ticks wasn't set.
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
Cc: Alexander Viro v...@zeniv.linux.org.uk
Cc: Cyrill Gorcunov gorcu...@openvz.org
Link: http://lkml.kernel.org/r/20140801082848.GF28869@mwanda
Signed-off-by: Thomas Gleixner t...@linutronix.de
---
fs/timerfd.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/fs/timerfd.c b/fs/timerfd.c
index 80c3502..b46ffa9 100644
--- a/fs/timerfd.c
+++ b/fs/timerfd.c
@@ -333,8 +333,7 @@ static long timerfd_ioctl(struct file *file, unsigned int
cmd, unsigned long arg
spin_lock_irq(ctx-wqh.lock);
if (!timerfd_canceled(ctx)) {
ctx-ticks = ticks;
- if (ticks)
- wake_up_locked(ctx-wqh);
+ wake_up_locked(ctx-wqh);
} else
ret = -ECANCELED;
spin_unlock_irq(ctx-wqh.lock);
--
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: tracing: horrible read performance on host with many CPUs
Use trace-cmd. It reads the per cpu files and sorts later -- Steve On August 27, 2014 4:50:38 AM GMT-04:00, Dmitry Monakhov dmonak...@openvz.org wrote: I have tried to use tracing on host with 32cpus, but it is appeared that performance is horrible. dd if=/sys/kernel/debug/tracing/trace_pipe of=tmpfs/t3.log bs=1M 0+21268 records in 0+21267 records out 85701248 bytes (86 MB) copied, 26.1424 s, 3.3 MB/s 0+25706 records in 0+25705 records out 103600749 bytes (104 MB) copied, 31.6595 s, 3.3 MB/s 0+59204 records in 0+59203 records out 238746128 bytes (239 MB) copied, 73.4347 s, 3.3 MB/s Since I've collected ~3Gb of data this takes a lot of time to simply copy from kernel to tmpfs. AFAIU this happen due to sub-optimal sorting procedure __find_next_entry Each time it walks each cpu and pick the one with smallest timestamp. This can be optimized simply by fetching N-entries at the time. Are there any plans to implement that? BTW:What is the most convenient way fetch big data from traces? One of possible way is to dump per-cpu traces(20Mb/s in my case) and then merge files according to timestamp -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- 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 0/9] dt: dependencies (for deterministic driver initialization order based on the DT)
Am 27.08.2014 09:16, schrieb Alexander Holler: Why should I? I've posted patches along with a lot of comments and explanations, and e.g. you are just talking that it should be made like my patches already did. And others do talk too like my patches and the accompanying comments from me which explain most stuff never have existed and just repeat what the patches already do without refering to them. Just to repeat myself: These patches which started this thread are not just some ideas without any sense for the amount of work necessary to implement them (as seen so often). These patches are real working code everyone can apply to the mentioned kernel version and see what happens with his board. They are even checkpatched to avoid bean counting discussion. (Don't forget to use patch 10/9 too) Regards, Alexander Holler -- 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: [PATCHv7 3/5] common: dma-mapping: Introduce common remapping functions
On 26/08/14 17:58, Laura Abbott wrote:
On 8/26/2014 3:05 AM, James Hogan wrote:
On 12 August 2014 00:40, Laura Abbott lau...@codeaurora.org wrote:
For architectures without coherent DMA, memory for DMA may
need to be remapped with coherent attributes. Factor out
the the remapping code from arm and put it in a
common location to reduce code duplication.
As part of this, the arm APIs are now migrated away from
ioremap_page_range to the common APIs which use map_vm_area for remapping.
This should be an equivalent change and using map_vm_area is more
correct as ioremap_page_range is intended to bring in io addresses
into the cpu space and not regular kernel managed memory.
Reviewed-by: Catalin Marinas catalin.mari...@arm.com
Signed-off-by: Laura Abbott lau...@codeaurora.org
This commit in linux-next () breaks the build for metag:
drivers/base/dma-mapping.c: In function ‘dma_common_contiguous_remap’:
drivers/base/dma-mapping.c:294: error: implicit declaration of
function ‘dma_common_pages_remap’
drivers/base/dma-mapping.c:294: warning: assignment makes pointer from
integer without a cast
drivers/base/dma-mapping.c: At top level:
drivers/base/dma-mapping.c:308: error: conflicting types for
‘dma_common_pages_remap’
drivers/base/dma-mapping.c:294: error: previous implicit declaration
of ‘dma_common_pages_remap’ was here
Looks like metag isn't alone either:
$ git grep -L dma-mapping-common arch/*/include/asm/dma-mapping.h
arch/arc/include/asm/dma-mapping.h
arch/avr32/include/asm/dma-mapping.h
arch/blackfin/include/asm/dma-mapping.h
arch/c6x/include/asm/dma-mapping.h
arch/cris/include/asm/dma-mapping.h
arch/frv/include/asm/dma-mapping.h
arch/m68k/include/asm/dma-mapping.h
arch/metag/include/asm/dma-mapping.h
arch/mn10300/include/asm/dma-mapping.h
arch/parisc/include/asm/dma-mapping.h
arch/xtensa/include/asm/dma-mapping.h
I've checked a couple of these arches (blackfin, xtensa) which don't
include dma-mapping-common.h and their builds seem to be broken too.
Cheers
James
Thanks for the report. Would you mind giving the following patch
a test (this is theoretical only but I think it should work)
It certainly fixes the build for metag.
Thanks
James
-8--
From 81c9a5504cbc1d72ff1df084d48502b248cd79d0 Mon Sep 17 00:00:00 2001
From: Laura Abbott lau...@codeaurora.org
Date: Tue, 26 Aug 2014 09:50:49 -0700
Subject: [PATCH] common: dma-mapping: Swap function order
Fix the order of dma_common_contiguous_remap and
dma_common_pages_remap to avoid function declaration errors:
drivers/base/dma-mapping.c: In function 'dma_common_contiguous_remap':
drivers/base/dma-mapping.c:294: error: implicit declaration of
function 'dma_common_pages_remap'
drivers/base/dma-mapping.c:294: warning: assignment makes pointer from
integer without a cast
drivers/base/dma-mapping.c: At top level:
drivers/base/dma-mapping.c:308: error: conflicting types for
'dma_common_pages_remap'
drivers/base/dma-mapping.c:294: error: previous implicit declaration
of 'dma_common_pages_remap' was here
Change-Id: I65db739114e8f5816a24a279a2ff1a6dc92e2b83
Reported-by: James Hogan james.ho...@imgtec.com
Reported-by: kbuild test robot fengguang...@intel.com
Signed-off-by: Laura Abbott lau...@codeaurora.org
---
drivers/base/dma-mapping.c | 44 ++--
1 file changed, 22 insertions(+), 22 deletions(-)
diff --git a/drivers/base/dma-mapping.c b/drivers/base/dma-mapping.c
index 1bc46df..056fd46 100644
--- a/drivers/base/dma-mapping.c
+++ b/drivers/base/dma-mapping.c
@@ -271,6 +271,28 @@ int dma_common_mmap(struct device *dev, struct
vm_area_struct *vma,
EXPORT_SYMBOL(dma_common_mmap);
/*
+ * remaps an array of PAGE_SIZE pages into another vm_area
+ * Cannot be used in non-sleeping contexts
+ */
+void *dma_common_pages_remap(struct page **pages, size_t size,
+ unsigned long vm_flags, pgprot_t prot,
+ const void *caller)
+{
+ struct vm_struct *area;
+
+ area = get_vm_area_caller(size, vm_flags, caller);
+ if (!area)
+ return NULL;
+
+ if (map_vm_area(area, prot, pages)) {
+ vunmap(area-addr);
+ return NULL;
+ }
+
+ return area-addr;
+}
+
+/*
* remaps an allocated contiguous region into another vm_area.
* Cannot be used in non-sleeping contexts
*/
@@ -299,28 +321,6 @@ void *dma_common_contiguous_remap(struct page *page,
size_t size,
}
/*
- * remaps an array of PAGE_SIZE pages into another vm_area
- * Cannot be used in non-sleeping contexts
- */
-void *dma_common_pages_remap(struct page **pages, size_t size,
- unsigned long vm_flags, pgprot_t prot,
- const void *caller)
-{
- struct vm_struct *area;
-
- area = get_vm_area_caller(size, vm_flags, caller);
- if (!area)
- return NULL;
-
- if (map_vm_area(area, prot,
[PATCH 1/2] Revert arm64: use cpu_online_mask when using forced irq_set_affinity
From: Byungchul Park byungchul.p...@lge.com
This reverts commit 601c942176d8ad8334118bddb747e3720bed24f8.
This patch is designed to ensure that the cpu being offlined is not
present in the affinity mask. But it is a bad idea to overwrite the
affinity variable with cpu_online_mask, even in case that the current
affinity already includes onlined cpus.
So revert this patch to replace it with another one doing exactly
what it intends.
Signed-off-by: Byungchul Park byungchul.p...@lge.com
---
arch/arm64/kernel/irq.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/arch/arm64/kernel/irq.c b/arch/arm64/kernel/irq.c
index 0f08dfd..473e5db 100644
--- a/arch/arm64/kernel/irq.c
+++ b/arch/arm64/kernel/irq.c
@@ -97,15 +97,11 @@ static bool migrate_one_irq(struct irq_desc *desc)
if (irqd_is_per_cpu(d) || !cpumask_test_cpu(smp_processor_id(),
affinity))
return false;
- if (cpumask_any_and(affinity, cpu_online_mask) = nr_cpu_ids)
+ if (cpumask_any_and(affinity, cpu_online_mask) = nr_cpu_ids) {
+ affinity = cpu_online_mask;
ret = true;
+ }
- /*
-* when using forced irq_set_affinity we must ensure that the cpu
-* being offlined is not present in the affinity mask, it may be
-* selected as the target CPU otherwise
-*/
- affinity = cpu_online_mask;
c = irq_data_get_irq_chip(d);
if (!c-irq_set_affinity)
pr_debug(IRQ%u: unable to set affinity\n, d-irq);
--
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 2/2] arm64: take onlined cpus into account when setting irq affinity in migrate_one_irq
From: Byungchul Park byungchul.p...@lge.com
This patch ensures that the cpu being offlined is not present in the affinity
mask.
Signed-off-by: Byungchul Park byungchul.p...@lge.com
---
arch/arm64/kernel/irq.c |9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm64/kernel/irq.c b/arch/arm64/kernel/irq.c
index 473e5db..0c7b79e 100644
--- a/arch/arm64/kernel/irq.c
+++ b/arch/arm64/kernel/irq.c
@@ -87,6 +87,7 @@ static bool migrate_one_irq(struct irq_desc *desc)
{
struct irq_data *d = irq_desc_get_irq_data(desc);
const struct cpumask *affinity = d-affinity;
+ struct cpumask tmp_affinity;
struct irq_chip *c;
bool ret = false;
@@ -100,6 +101,14 @@ static bool migrate_one_irq(struct irq_desc *desc)
if (cpumask_any_and(affinity, cpu_online_mask) = nr_cpu_ids) {
affinity = cpu_online_mask;
ret = true;
+ } else {
+ /*
+* when using forced irq_set_affinity we must ensure that the
cpu
+* being offlined is not present in the affinity mask, it may be
+* selected as the target CPU otherwise
+*/
+ cpumask_and(tmp_affinity, affinity, cpu_online_mask);
+ affinity = tmp_affinity;
}
c = irq_data_get_irq_chip(d);
--
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/
Re: [hyperv] BUG at drivers/hv/channel.c:462 while changing MTU
On Mon, Aug 25, 2014 at 09:48:31PM +, KY Srinivasan wrote: There is also a case of the BUG_ON at line 460 being hit (from https://lkml.org/lkml/2014/8/19/708 ): 457ret = vmbus_post_msg(msg, 458 sizeof(struct vmbus_channel_gpadl_teardown)); 459 460BUG_ON(ret != 0); I will take care of all BUG_ON() instances in channel.c Running a kernel patched with Drivers: hv: vmbus: Eliminate calls to BUG_ON() boots but repeatedly changing the MTU with the following script now results in a GPF in netvsc_open: dev=eth1; while true; do ifconfig eth1 down; ifconfig eth1 mtu 1500; ifconfig eth1 up; ifconfig eth1 mtu 9000; done [ 58.031328] hv_netvsc vmbus_0_15: net device safe to remove [ 58.083975] hv_netvsc: hv_netvsc channel opened successfully [ 58.973625] hv_netvsc vmbus_0_15: Send section size: 6144, Section count:2560 [ 59.030456] hv_netvsc vmbus_0_15: Device MAC 00:15:5d:6f:02:a5 link state up [ 59.142723] hv_netvsc vmbus_0_15: net device safe to remove [ 59.184701] hv_netvsc: hv_netvsc channel opened successfully [ 59.867690] hv_netvsc vmbus_0_15: Send section size: 6144, Section count:2560 [ 59.919317] hv_netvsc vmbus_0_15: Device MAC 00:15:5d:6f:02:a5 link state up [ 59.988054] hv_netvsc vmbus_0_15 eth1: unable to teardown receive buffer's gpadl [ 60.038752] hv_netvsc vmbus_0_15: net device safe to remove [ 60.070163] hv_vmbus: Close failed: close post msg return is 4 [ 60.121381] hv_vmbus: Close failed: close post msg return is 4 [ 60.157974] hv_vmbus: Close failed: close post msg return is 4 [ 60.190205] hv_vmbus: Close failed: close post msg return is 4 [ 60.232070] hv_vmbus: Close failed: close post msg return is 4 [ 65.275820] hv_netvsc vmbus_0_15 eth1: unable to open channel: -110 [ 65.325009] general protection fault: [#1] SMP [ 65.356804] CPU: 7 PID: 852 Comm: ifconfig Not tainted 3.17.0-rc1.x86_64-dirty #127 [ 65.356804] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS 090006 05/23/2012 [ 65.356804] task: 8800f268b9f0 ti: 8800eed38000 task.ti: 8800eed38000 [ 65.356804] RIP: 0010:[814e9fff] [814e9fff] rndis_filter_open+0x1f/0x60 [ 65.356804] RSP: 0018:8800eed3bd28 EFLAGS: 00010246 [ 65.356804] RAX: RBX: 6b6b6b6b6b6b6b6b RCX: 0006 [ 65.356804] RDX: 0006 RSI: 8800f268c130 RDI: 8801fbb8d480 [ 65.356804] RBP: 8800eed3bd30 R08: R09: [ 65.356804] R10: 0001 R11: 0001 R12: 8801fbb8d480 [ 65.356804] R13: R14: R15: 0001 [ 65.356804] FS: 7fdfdbf94740() GS:880207ce() knlGS: [ 65.356804] CS: 0010 DS: ES: CR0: 80050033 [ 65.356804] CR2: 7fdfdc1b51c4 CR3: ec53b000 CR4: 000406e0 [ 65.356804] Stack: [ 65.356804] 8800f1021160 8800eed3bd58 814e6515 8800f1021160 [ 65.356804] 8188f980 8800eed3bd80 815d0998 [ 65.356804] 8800f1021160 8800f1021160 1043 8800eed3bdb8 [ 65.356804] Call Trace: [ 65.356804] [814e6515] netvsc_open+0x25/0xb0 [ 65.356804] [815d0998] __dev_open+0x98/0x110 [ 65.356804] [815d0c99] __dev_change_flags+0xb9/0x160 [ 65.356804] [815d0d69] dev_change_flags+0x29/0x60 [ 65.356804] [81641b6b] devinet_ioctl+0x31b/0x6f0 [ 65.356804] [81642c4d] inet_ioctl+0x6d/0xa0 [ 65.356804] [815b27c0] sock_ioctl+0x1e0/0x210 [ 65.356804] [811d4dc0] do_vfs_ioctl+0x4d0/0x510 [ 65.356804] [816a2d55] ? sysret_check+0x22/0x5d [ 65.356804] [810b976d] ? trace_hardirqs_on_caller+0x17d/0x210 [ 65.356804] [811d4e53] SyS_ioctl+0x53/0x90 [ 65.356804] [816a2d29] system_call_fastpath+0x16/0x1b [ 65.356804] Code: 41 5e 41 5f 5d c3 66 0f 1f 44 00 00 66 66 66 66 90 48 8b 87 20 01 00 00 48 85 c0 74 2f 55 48 89 e5 53 48 8b 98 40 02 00 00 31 c0 83 7b 08 02 75 2b be 0d 00 00 00 48 89 df e8 9e f9 ff ff 85 c0 [ 65.356804] RIP [814e9fff] rndis_filter_open+0x1f/0x60 [ 65.356804] RSP 8800eed3bd28 [ 66.789324] ---[ end trace 1b6075f9340eb5bc ]--- -- Sitsofe | http://sucs.org/~sits/ -- 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: [HELP (not patch)] Re: Resume from hibernation fails 40% of time, kernel 3.16.0 (64GB of RAM, 32 Xeon E5-2687W cores)
On Mon 2014-08-04 23:24:47, Janek Kozicki wrote: I see that this list is extremely busy, I thought this is the place to go asking for help in debugging hibernation. If that's not the right place, please tell me where should I go. If that's the right place, please get me started. First - how can I retrieve some useful logs from failed resume attempts? You want to cc rjw. The failure was always a reboot after resume had almost succeeded. In cases when there was a success there was a ---[cut here]--- part which is in the attachment. All of my successes are included in the attachments (please note that method had 0 success rate, so no success logs are attached for it). Usually trying with minimum set of drivers loaded is useful debug technique. Plus there are some debugging hints in Documentation/. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 00/26] genirq: fix use of irq_find_mapping outside of legal RCU context
Hi Thomas,
On Tue, Aug 26 2014 at 10:34:51 pm BST, Thomas Gleixner t...@linutronix.de
wrote:
On Tue, 26 Aug 2014, Marc Zyngier wrote:
A number of irqchip drivers are directly calling irq_find_mapping,
which may use a rcu_read_lock call when walking the radix tree.
Turns out that if you hit that point with CONFIG_PROVE_RCU enabled,
the kernel will shout at you, as using RCU in this context may be
illegal (specially if coming from the idle state, where RCU would be
in a quiescent state).
A possible fix would be to wrap calls to irq_find_mapping into a
RCU_NONIDLE macro, but that really looks ugly.
This patch series introduce another generic IRQ entry point
(handle_domain_irq), which has the exact same behaviour as handle_IRQ
(as defined on arm, arm64 and openrisc), except that it also takes a
irq_domain pointer. This allows the logical IRQ lookup to be done
inside the irq_{enter,exit} section, which contains a
rcu_irq_{enter,exit}, making it safe.
Looks good. Should this be routed to the genirq tree?
I'm happy for you to take this series, provided the architecture
maintainers agree on it (I'm still to hear from the openrisc guys, and
their mailing-list seems to positively hate my guts).
Thanks,
M.
--
Jazz is not dead. It just smells funny.
--
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 part1 0/4] Fix SG_IO ambiguity between READ SUBCHANNEL and UNMAP (and other similar cases)
On Thu, May 23, 2013 at 03:58:19PM +0200, Paolo Bonzini wrote: The SG_IO ioctl's command whitelist is designed for MMC devices (roughly, play/burn CDs without requiring root) but some opcodes overlap across SCSI device classes and have different meanings for different classes. To fix this, use different bitmaps for the various device classes. This is CVE-2012-4542. Sorry for bringing this old issue again, but I was wondering what happen to this fix. Cheers, -- Luís v2-v3: patches are now split differently, according to Tejun's indications; added conflict on operation code A4h. Paolo Bonzini (4): sg_io: pass request_queue to blk_verify_command sg_io: prepare to introduce per-class command filters sg_io: use different default filters for each device class sg_io: resolve conflicts between commands assigned to multiple classes (CVE-2012-4542) block/bsg.c | 2 +- block/scsi_ioctl.c | 193 +++ drivers/scsi/scsi_scan.c | 2 + drivers/scsi/sg.c| 3 +- include/linux/blkdev.h | 5 +- 5 files changed, 118 insertions(+), 87 deletions(-) -- 1.8.1.4 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: dts: make arch-timer always on in rk3288 soc
Hi,
On Wed, Aug 27, 2014 at 02:47:40AM +0100, Kever Yang wrote:
We need use the hrtimer, which need the arch-timer to be 'always-on'
Just to check: it isn't possible to place CPUs in the rk3288 SoC into
low power states where their timers lose state and/or might not fire?
Mark.
Signed-off-by: Kever Yang kever.y...@rock-chips.com
---
arch/arm/boot/dts/rk3288.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index 5950b0a..698e6ea 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -76,6 +76,7 @@
GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(4) |
IRQ_TYPE_LEVEL_HIGH),
GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(4) |
IRQ_TYPE_LEVEL_HIGH);
clock-frequency = 2400;
+ always-on;
};
i2c1: i2c@ff14 {
--
1.9.1
--
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
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/4] ARM: DT: APQ8064: Add node for ps_hold function in pinctrl
This patch adds DT support to configure GPIO_78 as function ps_hold
on apq8064.
CC: Rob Herring robh...@kernel.org
CC: Pawel Moll pawel.m...@arm.com
CC: Mark Rutland mark.rutl...@arm.com
CC: Ian Campbell ijc+devicet...@hellion.org.uk
CC: Kumar Gala ga...@codeaurora.org
CC: devicet...@vger.kernel.org
CC: linux-arm-ker...@lists.infradead.org
Signed-off-by: Pramod Gurav pramod.gu...@smartplayin.com
---
arch/arm/boot/dts/qcom-apq8064.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-apq8064.dtsi
b/arch/arm/boot/dts/qcom-apq8064.dtsi
index 681e194..0873b24 100644
--- a/arch/arm/boot/dts/qcom-apq8064.dtsi
+++ b/arch/arm/boot/dts/qcom-apq8064.dtsi
@@ -82,6 +82,16 @@
interrupt-controller;
#interrupt-cells = 2;
interrupts = 0 32 0x4;
+
+ pinctrl-names = default;
+ pinctrl-0 = ps_hold;
+
+ ps_hold: ps_hold {
+ mux {
+ pins = gpio78;
+ function = ps_hold;
+ };
+ };
};
intc: interrupt-controller@200 {
--
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 3/4] pinctrl: msm: Add ps_hold function in pinctrl-apq8064 binding documentation
This adds a function ps_hold (Power Suppy Hold Signal) in pinctrl-ap8064 documentation which was missing. This function is used to reset the targets with apq8064 soc. CC: Linus Walleij linus.wall...@linaro.org CC: Bjorn Andersson bjorn.anders...@sonymobile.com CC: Ivan T. Ivanov iiva...@mm-sol.com CC: Stephen Boyd sb...@codeaurora.org CC: Andy Gross agr...@codeaurora.org Signed-off-by: Pramod Gurav pramod.gu...@smartplayin.com --- .../bindings/pinctrl/qcom,apq8064-pinctrl.txt |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,apq8064-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/qcom,apq8064-pinctrl.txt index 0211c6d..ca5bfa5 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,apq8064-pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/qcom,apq8064-pinctrl.txt @@ -50,7 +50,7 @@ Valid values for function are: gsbi4_cam_i2c, gsbi5, gsbi5_spi_cs1, gsbi5_spi_cs2, gsbi5_spi_cs3, gsbi6, gsbi6_spi_cs1, gsbi6_spi_cs2, gsbi6_spi_cs3, gsbi7, gsbi7_spi_cs1, gsbi7_spi_cs2, gsbi7_spi_cs3, gsbi_cam_i2c, hdmi, mi2s, riva_bt, riva_fm, - riva_wlan, sdc2, sdc4, slimbus, spkr_i2s, tsif1, tsif2, usb2_hsic, + riva_wlan, sdc2, sdc4, slimbus, spkr_i2s, tsif1, tsif2, usb2_hsic, ps_hold Example: -- 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/
Re: [PATCH v5 1/4] drivers/mfd/menf21bmc: introduce MEN 14F021P00 BMC MFD Core driver
On Wed, Aug 27, 2014 at 08:26:33AM +0100, Lee Jones wrote:
On Tue, 26 Aug 2014, Andreas Werner wrote:
The MEN 14F021P00 Board Management Controller provides an
I2C interface to the host to access the feature implemented in the BMC.
The BMC is a PIC Microntroller assembled on CPCI Card from MEN
Mikroelektronik
and on a few Box/Display Computer.
Added MFD Core driver, supporting the I2C communication to the device.
The MFD driver currently supports the following features:
- Watchdog
- LEDs
- Hwmon (voltage monitoring)
Signed-off-by: Andreas Werner andreas.wer...@men.de
Acked-by: Lee Jones lee.jo...@linaro.org
---
drivers/mfd/Kconfig | 12 +
drivers/mfd/Makefile| 1 +
drivers/mfd/menf21bmc.c | 132
3 files changed, 145 insertions(+)
create mode 100644 drivers/mfd/menf21bmc.c
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index b8d9ca0..6a9f101 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -453,6 +453,18 @@ config MFD_MAX8998
additional drivers must be enabled in order to use the functionality
of the device.
+config MFD_MENF21BMC
+ tristate MEN 14F021P00 Board Management Controller Support
+ depends on I2C
+ select MFD_CORE
+ help
+ Say yes here to add support for the MEN 14F021P00 BMC
+ which is a Board Management Controller connected to the I2C bus.
+ The device supports multiple sub-devices like LED, HWMON and WDT.
Nit: Whitespace error.
Forgot to run checkpatch on Kconfig since the last change. Will fix it.
+ This driver provides common support for accessing the devices;
+ additional drivers must be enabled in order to use the
+ functionality of the BMC device.
+
config EZX_PCAP
bool Motorola EZXPCAP Support
depends on SPI_MASTER
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 4e2bc25..37bf336 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -169,6 +169,7 @@ obj-$(CONFIG_MFD_AS3711)+= as3711.o
obj-$(CONFIG_MFD_AS3722) += as3722.o
obj-$(CONFIG_MFD_STW481X) += stw481x.o
obj-$(CONFIG_MFD_IPAQ_MICRO) += ipaq-micro.o
+obj-$(CONFIG_MFD_MENF21BMC)+= menf21bmc.o
intel-soc-pmic-objs:= intel_soc_pmic_core.o
intel_soc_pmic_crc.o
obj-$(CONFIG_INTEL_SOC_PMIC) += intel-soc-pmic.o
diff --git a/drivers/mfd/menf21bmc.c b/drivers/mfd/menf21bmc.c
new file mode 100644
index 000..a6eb03f
--- /dev/null
+++ b/drivers/mfd/menf21bmc.c
@@ -0,0 +1,132 @@
+/*
+ * MEN 14F021P00 Board Management Controller (BMC) MFD Core Driver.
+ *
+ * Copyright (C) 2014 MEN Mikro Elektronik Nuernberg GmbH
+ *
+ * This program is free software; you can redistribute it and/or modify
it
+ * under the terms of the GNU General Public License as published by
the
+ * Free Software Foundation; either version 2 of the License, or (at
your
+ * option) any later version.
+ */
+
+#include linux/kernel.h
+#include linux/device.h
+#include linux/module.h
+#include linux/i2c.h
+#include linux/mfd/core.h
+
+#define BMC_CMD_WDT_EXIT_PROD 0x18
+#define BMC_CMD_WDT_PROD_STAT 0x19
+#define BMC_CMD_REV_MAJOR 0x80
+#define BMC_CMD_REV_MINOR 0x81
+#define BMC_CMD_REV_MAIN 0x82
+
+static struct mfd_cell menf21bmc_cell[] = {
+ { .name = menf21bmc_wdt, },
+ { .name = menf21bmc_led, },
+ { .name = menf21bmc_hwmon, }
+};
+
+static int menf21bmc_wdt_exit_prod_mode(struct i2c_client *client)
+{
+ int val, ret;
+
+ val = i2c_smbus_read_byte_data(client, BMC_CMD_WDT_PROD_STAT);
+ if (val 0)
+ return val;
+
+ /*
+* Production mode should be not active after delivery of the Board.
+* To be sure we check it, inform the user and exit the mode
+* if active.
+*/
+ if (val == 0x00) {
+ dev_info(client-dev,
+ BMC in production mode. Exit production mode\n);
+
+ ret = i2c_smbus_write_byte(client, BMC_CMD_WDT_EXIT_PROD);
+ if (ret 0)
+ return ret;
+ }
+
+ return 0;
+}
+
+static int
+menf21bmc_probe(struct i2c_client *client, const struct i2c_device_id *ids)
+{
+ int ret;
+ int rev_major, rev_minor, rev_main;
Really small nit (as you have to fix the whitespace err anyway):
Can you change the order of the two lines above please?
No problem.
+ ret = i2c_check_functionality(client-adapter,
+ I2C_FUNC_SMBUS_BYTE_DATA |
+ I2C_FUNC_SMBUS_WORD_DATA |
+ I2C_FUNC_SMBUS_BYTE);
+ if (!ret)
+ return -ENODEV;
+
+ rev_major = i2c_smbus_read_word_data(client, BMC_CMD_REV_MAJOR);
+ if (rev_major 0) {
+
[PATCH 1/3] GPIO: gpio-dwapb: Enable platform driver binding to MFD driver
The Synopsys DesignWare APB GPIO driver only supports open firmware devices.
But, like Intel Quark X1000 SOC, which has a single PCI function exporting
a GPIO and an I2C controller, it is a Multifunction device. This patch is
to enable the current Synopsys DesignWare APB GPIO driver to support the
Multifunction device which exports the designware GPIO controller.
Reviewed-by: Hock Leong Kweh hock.leong.k...@intel.com
Reviewed-by: Shevchenko, Andriy andriy.shevche...@intel.com
Signed-off-by: Weike Chen alvin.c...@intel.com
---
drivers/gpio/Kconfig |1 -
drivers/gpio/gpio-dwapb.c| 187 ++
include/linux/platform_data/gpio-dwapb.h | 32 +
3 files changed, 171 insertions(+), 49 deletions(-)
create mode 100644 include/linux/platform_data/gpio-dwapb.h
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 9de1515..8250a44 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -136,7 +136,6 @@ config GPIO_DWAPB
tristate Synopsys DesignWare APB GPIO driver
select GPIO_GENERIC
select GENERIC_IRQ_CHIP
- depends on OF_GPIO
help
Say Y or M here to build support for the Synopsys DesignWare APB
GPIO block.
diff --git a/drivers/gpio/gpio-dwapb.c b/drivers/gpio/gpio-dwapb.c
index d6618a6..155a64b 100644
--- a/drivers/gpio/gpio-dwapb.c
+++ b/drivers/gpio/gpio-dwapb.c
@@ -21,6 +21,7 @@
#include linux/of_irq.h
#include linux/platform_device.h
#include linux/spinlock.h
+#include linux/platform_data/gpio-dwapb.h
#define GPIO_SWPORTA_DR0x00
#define GPIO_SWPORTA_DDR 0x04
@@ -52,14 +53,15 @@ struct dwapb_gpio_port {
struct bgpio_chip bgc;
boolis_registered;
struct dwapb_gpio *gpio;
+ struct dwapb_gpio_port_property *pp;
};
struct dwapb_gpio {
struct device *dev;
void __iomem*regs;
struct dwapb_gpio_port *ports;
- unsigned intnr_ports;
struct irq_domain *domain;
+ const struct dwapb_gpio_platform_data *pdata;
};
static int dwapb_gpio_to_irq(struct gpio_chip *gc, unsigned offset)
@@ -207,22 +209,24 @@ static int dwapb_irq_set_type(struct irq_data *d, u32
type)
return 0;
}
+static irqreturn_t dwapb_irq_handler_mfd(int irq, void *dev_id)
+{
+ struct irq_desc *desc = irq_to_desc(irq);
+
+ dwapb_irq_handler(irq, desc);
+
+ return IRQ_HANDLED;
+}
+
static void dwapb_configure_irqs(struct dwapb_gpio *gpio,
struct dwapb_gpio_port *port)
{
struct gpio_chip *gc = port-bgc.gc;
- struct device_node *node = gc-of_node;
- struct irq_chip_generic *irq_gc;
+ struct device_node *node = port-pp-node;
+ struct irq_chip_generic *irq_gc = NULL;
unsigned int hwirq, ngpio = gc-ngpio;
struct irq_chip_type *ct;
- int err, irq, i;
-
- irq = irq_of_parse_and_map(node, 0);
- if (!irq) {
- dev_warn(gpio-dev, no irq for bank %s\n,
- port-bgc.gc.of_node-full_name);
- return;
- }
+ int err, i;
gpio-domain = irq_domain_add_linear(node, ngpio,
irq_generic_chip_ops, gpio);
@@ -269,8 +273,24 @@ static void dwapb_configure_irqs(struct dwapb_gpio *gpio,
irq_gc-chip_types[1].type = IRQ_TYPE_EDGE_BOTH;
irq_gc-chip_types[1].handler = handle_edge_irq;
- irq_set_chained_handler(irq, dwapb_irq_handler);
- irq_set_handler_data(irq, gpio);
+ if (!port-pp-irq_shared) {
+ irq_set_chained_handler(port-pp-irq, dwapb_irq_handler);
+ } else {
+ /*
+* Request a shared IRQ since where MFD would have devices
+* using the same irq pin
+*/
+ err = devm_request_irq(gpio-dev, port-pp-irq,
+ dwapb_irq_handler_mfd,
+ IRQF_SHARED, gpio-dwapb-mfd, gpio);
+ if (err) {
+ dev_err(gpio-dev, error requesting IRQ\n);
+ irq_domain_remove(gpio-domain);
+ gpio-domain = NULL;
+ return;
+ }
+ }
+ irq_set_handler_data(port-pp-irq, gpio);
for (hwirq = 0 ; hwirq ngpio ; hwirq++)
irq_create_mapping(gpio-domain, hwirq);
@@ -296,57 +316,43 @@ static void dwapb_irq_teardown(struct dwapb_gpio *gpio)
}
static int dwapb_gpio_add_port(struct dwapb_gpio *gpio,
- struct device_node *port_np,
+ struct dwapb_gpio_port_property *pp,
unsigned int offs)
{
struct dwapb_gpio_port *port;
- u32 port_idx, ngpio;
void __iomem *dat, *set, *dirout;
int err;
- if
Re: [PATCH 1/5] perf, x86: Remove incorrect model number from Haswell perf
On Wed, 27 Aug 2014, Thomas Gleixner wrote: On Tue, 26 Aug 2014, Andi Kleen wrote: So what's the point of making the obvious onliner patch - case 71: into something which reorders the sorted case numbers? This was a merging mistake. I'll fix it to be a one liner. And of course, this patch is missing any explanation WHY 71 is incorrect and how it got there in the first place. 71 is a Broadwell, as you would know if you had read the next patch. And why on earth do I need to read the next patch to figure out what the heck this patch is doing? Just because it's written by someone who gives a shit? Your unwillingness to cooperate and your advisory resistance are slowly approaching the Krause level... And after reading the next patch I still can't see that 71 is a broadwell, because the next patch merily adds haswell names to the numbers. Neither of the following patches has the magic 71 incorporated. The only model number related to broadwell is 61 in patch 3/5. Try again when you figured yourself out what number means what and why 71 is bogus. Thanks, tglx -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/3] The Designware GPIO Supporting
Hi, These patches are for Intel Quark X1000 designware GPIO supporting. The first patch enables the Synopsys DesignWare APB GPIO driver to support the MFD device. And the Quark designware GPIO controller is registered as MFD device, because Quark exports a single PCI device with both GPIO and I2C functions. It is about reviewing the GPIO changes in gpio-dwapb, and in near future, the Quark I2C driver and the MFD driver that binds these GPIO I2C functions will be sent subsequently. The second patch enables the gpio 'debounce' feature. And the third patch enables the power management. Weike Chen (3): GPIO: gpio-dwapb: Enable platform driver binding to MFD driver GPIO: gpio-dwapb: Support Debounce GPIO: gpio-dwapb: Suspend Resume PM enabling drivers/gpio/Kconfig |1 - drivers/gpio/gpio-dwapb.c| 296 +- include/linux/platform_data/gpio-dwapb.h | 32 3 files changed, 280 insertions(+), 49 deletions(-) create mode 100644 include/linux/platform_data/gpio-dwapb.h -- 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 3/3] GPIO: gpio-dwapb: Suspend Resume PM enabling
This patch enables suspend and resume mode for the power management, and
it is based on Josef Ahmad's previous work.
Reviewed-by: Hock Leong Kweh hock.leong.k...@intel.com
Reviewed-by: Shevchenko, Andriy andriy.shevche...@intel.com
Signed-off-by: Weike Chen alvin.c...@intel.com
---
drivers/gpio/gpio-dwapb.c | 67 +
1 file changed, 67 insertions(+)
diff --git a/drivers/gpio/gpio-dwapb.c b/drivers/gpio/gpio-dwapb.c
index e0ab988..1055cb3 100644
--- a/drivers/gpio/gpio-dwapb.c
+++ b/drivers/gpio/gpio-dwapb.c
@@ -560,10 +560,77 @@ static const struct of_device_id dwapb_of_match[] = {
};
MODULE_DEVICE_TABLE(of, dwapb_of_match);
+#if defined CONFIG_PM_SLEEP
+/* Store GPIO context across system-wide suspend/resume transitions */
+static struct gpio_saved_regs {
+ unsigned long data;
+ unsigned long dir;
+ unsigned long int_en;
+ unsigned long int_mask;
+ unsigned long int_type;
+ unsigned long int_pol;
+ unsigned long int_deb;
+} saved_regs;
+
+static int dwapb_gpio_suspend(struct device *dev)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ struct dwapb_gpio *gpio = platform_get_drvdata(pdev);
+ struct bgpio_chip *bgc = gpio-ports[0].bgc;
+ unsigned long flags;
+
+ spin_lock_irqsave(bgc-lock, flags);
+
+ saved_regs.int_mask = dwapb_read(gpio, GPIO_INTMASK);
+ saved_regs.int_en = dwapb_read(gpio, GPIO_INTEN);
+ saved_regs.int_deb = dwapb_read(gpio, GPIO_PORTA_DEBOUNCE);
+ saved_regs.int_pol = dwapb_read(gpio, GPIO_INT_POLARITY);
+ saved_regs.int_type = dwapb_read(gpio, GPIO_INTTYPE_LEVEL);
+ saved_regs.dir = dwapb_read(gpio, GPIO_SWPORTA_DDR);
+ saved_regs.data = dwapb_read(gpio, GPIO_SWPORTA_DR);
+
+ /* Mask out interrupts */
+ dwapb_write(gpio, GPIO_INTMASK, 0x);
+
+ spin_unlock_irqrestore(bgc-lock, flags);
+
+ return 0;
+}
+
+static int dwapb_gpio_resume(struct device *dev)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ struct dwapb_gpio *gpio = platform_get_drvdata(pdev);
+ struct bgpio_chip *bgc = gpio-ports[0].bgc;
+ unsigned long flags;
+
+ spin_lock_irqsave(bgc-lock, flags);
+
+ dwapb_write(gpio, GPIO_SWPORTA_DR, saved_regs.data);
+ dwapb_write(gpio, GPIO_SWPORTA_DDR, saved_regs.dir);
+ dwapb_write(gpio, GPIO_INTTYPE_LEVEL, saved_regs.int_type);
+ dwapb_write(gpio, GPIO_INT_POLARITY, saved_regs.int_pol);
+ dwapb_write(gpio, GPIO_PORTA_DEBOUNCE, saved_regs.int_deb);
+ dwapb_write(gpio, GPIO_INTEN, saved_regs.int_en);
+ dwapb_write(gpio, GPIO_INTMASK, saved_regs.int_mask);
+
+ /* Clear out spurious interrupts */
+ dwapb_write(gpio, GPIO_PORTA_EOI, 0x);
+
+ spin_unlock_irqrestore(bgc-lock, flags);
+
+ return 0;
+}
+#endif
+
+static SIMPLE_DEV_PM_OPS(dwapb_gpio_pm_ops, dwapb_gpio_suspend,
+dwapb_gpio_resume);
+
static struct platform_driver dwapb_gpio_driver = {
.driver = {
.name = gpio-dwapb,
.owner = THIS_MODULE,
+ .pm = dwapb_gpio_pm_ops,
.of_match_table = of_match_ptr(dwapb_of_match),
},
.probe = dwapb_gpio_probe,
--
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 2/3] GPIO: gpio-dwapb: Support Debounce
This patch enables 'debounce' for the designware GPIO, and
it is based on Josef Ahmad's previous work.
Reviewed-by: Hock Leong Kweh hock.leong.k...@intel.com
Reviewed-by: Shevchenko, Andriy andriy.shevche...@intel.com
Signed-off-by: Weike Chen alvin.c...@intel.com
---
drivers/gpio/gpio-dwapb.c | 42 ++
1 file changed, 42 insertions(+)
diff --git a/drivers/gpio/gpio-dwapb.c b/drivers/gpio/gpio-dwapb.c
index 155a64b..e0ab988 100644
--- a/drivers/gpio/gpio-dwapb.c
+++ b/drivers/gpio/gpio-dwapb.c
@@ -36,6 +36,7 @@
#define GPIO_INTTYPE_LEVEL 0x38
#define GPIO_INT_POLARITY 0x3c
#define GPIO_INTSTATUS 0x40
+#define GPIO_PORTA_DEBOUNCE0x48
#define GPIO_PORTA_EOI 0x4c
#define GPIO_EXT_PORTA 0x50
#define GPIO_EXT_PORTB 0x54
@@ -64,6 +65,23 @@ struct dwapb_gpio {
const struct dwapb_gpio_platform_data *pdata;
};
+static inline u32 dwapb_read(struct dwapb_gpio *gpio, unsigned int offset)
+{
+ struct bgpio_chip *bgc = gpio-ports[0].bgc;
+ void __iomem *reg_base = gpio-regs;
+
+ return bgc-read_reg(reg_base + offset);
+}
+
+static inline void dwapb_write(struct dwapb_gpio *gpio, unsigned int offset,
+ u32 val)
+{
+ struct bgpio_chip *bgc = gpio-ports[0].bgc;
+ void __iomem *reg_base = gpio-regs;
+
+ bgc-write_reg(reg_base + offset, val);
+}
+
static int dwapb_gpio_to_irq(struct gpio_chip *gc, unsigned offset)
{
struct bgpio_chip *bgc = to_bgpio_chip(gc);
@@ -209,6 +227,29 @@ static int dwapb_irq_set_type(struct irq_data *d, u32 type)
return 0;
}
+static int dwapb_gpio_set_debounce(struct gpio_chip *gc,
+ unsigned offset, unsigned debounce)
+{
+ struct bgpio_chip *bgc = to_bgpio_chip(gc);
+ struct dwapb_gpio_port *port =
+ container_of(bgc, struct dwapb_gpio_port, bgc);
+ struct dwapb_gpio *gpio = port-gpio;
+ unsigned long flags, val_deb;
+ unsigned long mask = bgc-pin2mask(bgc, offset);
+
+ spin_lock_irqsave(bgc-lock, flags);
+
+ val_deb = dwapb_read(gpio, GPIO_PORTA_DEBOUNCE);
+ if (debounce)
+ dwapb_write(gpio, GPIO_PORTA_DEBOUNCE, mask | val_deb);
+ else
+ dwapb_write(gpio, GPIO_PORTA_DEBOUNCE, ~mask val_deb);
+
+ spin_unlock_irqrestore(bgc-lock, flags);
+
+ return 0;
+}
+
static irqreturn_t dwapb_irq_handler_mfd(int irq, void *dev_id)
{
struct irq_desc *desc = irq_to_desc(irq);
@@ -342,6 +383,7 @@ static int dwapb_gpio_add_port(struct dwapb_gpio *gpio,
port-bgc.gc.ngpio = pp-ngpio;
port-bgc.gc.base = pp-gpio_base;
+ port-bgc.gc.set_debounce = dwapb_gpio_set_debounce;
/*
* Only port A can provide interrupts in all configurations of the IP.
--
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/
Re: [RESEND PATCH v2 1/4] irqchip: gic: Change irq type check when extension is present
Marc, On Fri, 2014-08-22 at 12:09 +0100, Marc Zyngier wrote: Here, you're using it to program something that sits between the device and the GIC. This is a separate block, with its own hardware configuration, that modifies the interrupt signal. This should be reflected in the device-tree and the code paths. You can probably model this as a separate irqchip for the few interrupts that require this, or have it configured at boot time (assuming the configuration never changes). It seems to me that using a separate irqchip for a simple inverter would add the run-time overhead of passing through wrapper functions on every IRQ. Do you have an idea how this could be avoided without using the gic_arch_extn feature? As in the DT the actual IRQ polarity should be used, simply configuring the HW IRQ polarity in the bootloader is not enough without telling the GIC driver which polarity is supported on which IRQ, right? Regards, Jan -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] dtb: at91: sam9n12ek: ohci: add port and vbus property
Add the port number and vbus property for ohci port, or else if
bootloader won't configure the vbus pin, the 5v supply is not
power on, so can not work with usb devices.
Signed-off-by: Bo Shen voice.s...@atmel.com
---
arch/arm/boot/dts/at91sam9n12ek.dts | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/at91sam9n12ek.dts
b/arch/arm/boot/dts/at91sam9n12ek.dts
index 83d7237..13bb24e 100644
--- a/arch/arm/boot/dts/at91sam9n12ek.dts
+++ b/arch/arm/boot/dts/at91sam9n12ek.dts
@@ -136,6 +136,8 @@
};
usb0: ohci@0050 {
+ num-ports = 1;
+ atmel,vbus-gpio = pioB 7 GPIO_ACTIVE_LOW;
status = okay;
};
};
--
1.8.5.2
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2] video : remove redundant error check
Hi,
2014-08-26 19:34 GMT+09:00 Tomi Valkeinen tomi.valkei...@ti.com:
On 16/05/14 12:31, Daeseok Youn wrote:
It doesn't need to check err for printing info.
And also use pr_info instead of printk.
Signed-off-by: Daeseok Youn daeseok.y...@gmail.com
---
V2: removes unneeded lines for sending a patch
drivers/video/fbdev/i810/i810_main.c |7 +++
1 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/video/fbdev/i810/i810_main.c
b/drivers/video/fbdev/i810/i810_main.c
index bb674e4..15cb397 100644
--- a/drivers/video/fbdev/i810/i810_main.c
+++ b/drivers/video/fbdev/i810/i810_main.c
@@ -1910,13 +1910,12 @@ static void i810fb_find_init_mode(struct fb_info
*info)
for (i = 0; i par-ddc_num + 1; i++) {
err = i810_probe_i2c_connector(info, par-edid, i);
- if (!err)
+ if (!err) {
+ pr_info(i810fb_init_pci: DDC probe successful\n);
break;
+ }
}
- if (!err)
- printk(i810fb_init_pci: DDC probe successful\n);
-
fb_edid_to_monspecs(par-edid, specs);
if (specs-modedb == NULL)
I don't know... I think I personally like more the original version. In
fact, the whole print looks quite useless to me, or at least it should
be a debug print.
Yes. this patch doesn't need.
Thanks for review.
regards,
Daeseok Youn.
Tomi
--
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/4] drivers/mfd/menf21bmc: introduce MEN 14F021P00 BMC MFD Core driver
On Wed, Aug 27, 2014 at 08:26:33AM +0100, Lee Jones wrote:
On Tue, 26 Aug 2014, Andreas Werner wrote:
The MEN 14F021P00 Board Management Controller provides an
I2C interface to the host to access the feature implemented in the BMC.
The BMC is a PIC Microntroller assembled on CPCI Card from MEN
Mikroelektronik
and on a few Box/Display Computer.
Added MFD Core driver, supporting the I2C communication to the device.
The MFD driver currently supports the following features:
- Watchdog
- LEDs
- Hwmon (voltage monitoring)
Signed-off-by: Andreas Werner andreas.wer...@men.de
Acked-by: Lee Jones lee.jo...@linaro.org
---
drivers/mfd/Kconfig | 12 +
drivers/mfd/Makefile| 1 +
drivers/mfd/menf21bmc.c | 132
3 files changed, 145 insertions(+)
create mode 100644 drivers/mfd/menf21bmc.c
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index b8d9ca0..6a9f101 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -453,6 +453,18 @@ config MFD_MAX8998
additional drivers must be enabled in order to use the functionality
of the device.
+config MFD_MENF21BMC
+ tristate MEN 14F021P00 Board Management Controller Support
+ depends on I2C
+ select MFD_CORE
+ help
+ Say yes here to add support for the MEN 14F021P00 BMC
+ which is a Board Management Controller connected to the I2C bus.
+ The device supports multiple sub-devices like LED, HWMON and WDT.
Nit: Whitespace error.
I run checkpatch but did not find any whitespace error.
Where is it?
...
+MODULE_DEVICE_TABLE(i2c, menf21bmc_id_table);
+
+static struct i2c_driver menf21bmc_driver = {
+ .driver.name= menf21bmc,
+ .id_table = menf21bmc_id_table,
+ .probe = menf21bmc_probe,
+ .remove = menf21bmc_remove,
+};
No DT support?
No not at the moment because it is used only on x86 system.
+module_i2c_driver(menf21bmc_driver);
+
+MODULE_DESCRIPTION(MEN 14F021P00 BMC mfd core driver);
s/mfd/MFD
+MODULE_AUTHOR(Andreas Werner andreas.wer...@men.de);
+MODULE_LICENSE(GPL v2);
--
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 3/4] Drivers: hv: vmbus: Cleanup vmbus_close_internal()
On Tue, Aug 26, 2014 at 12:05:51PM -0700, K. Y. Srinivasan wrote:
-static void vmbus_close_internal(struct vmbus_channel *channel)
+static int vmbus_close_internal(struct vmbus_channel *channel)
{
struct vmbus_channel_close_channel *msg;
- int ret;
+ int ret = 0;
GCC has a feature which warns about uninitialized variables. Those
features are there to help prevent bugs. You are turning the feature
off here by initializing it with a bogus value. Don't do that.
channel-state = CHANNEL_OPEN_STATE;
channel-sc_creation_callback = NULL;
@@ -502,11 +502,28 @@ static void vmbus_close_internal(struct vmbus_channel
*channel)
ret = vmbus_post_msg(msg, sizeof(struct vmbus_channel_close_channel));
- BUG_ON(ret != 0);
+ if (ret) {
+ pr_err(Close failed: close post msg return is %d\n, ret);
+ /*
+ * If we failed to post the close msg,
+ * it is perhaps better to leak memory.
+ */
+ goto close_err;
Just return directly. Don't introduce do-nothing gotos to lead the
reader through a series of pointless goto hops.
The goto label is poorly chosen. Label names should be based on the
thing which they do. close_err implies that something is closed but
that's not the case, the label doesn't do anything.
regards,
dan carpenter
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] drivers/xen/grant-table.c: Be sure of unsigned value never comparing with 0
On 26/08/14 20:42, Chen Gang wrote: On 08/27/2014 01:03 AM, David Vrabel wrote: On 26/08/14 16:38, Chen Gang wrote: In grow_gnttab_list(), 'i' is 'unsigned int', and 'nr_glist_frames' may be 0 because 'nr_grant_frames' may be 0. So 'i' may never be less than 'nr_glist_frames' in failure processing, which cause infinite looping. nr_grant_frames is at least 1. See gnttab_init(). OK, thanks, that sounds reasonable to me, it is not a real wold bug, it is my fault. :-) --- a/drivers/xen/grant-table.c +++ b/drivers/xen/grant-table.c @@ -592,8 +592,8 @@ static int grow_gnttab_list(unsigned int more_frames) return 0; grow_nomem: - for ( ; i = nr_glist_frames; i--) - free_page((unsigned long) gnttab_list[i]); + while (i nr_glist_frames) + free_page((unsigned long) gnttab_list[--i]); while (i-- nr_glist_frames) ... Would have been better. OK, thanks, that sounds reasonable to me. If necessary to send patch v2 (change comments and contents), please let me know, and I shall send. Applied to devel/for-linus-3.18 with this description: xen/grant-table: refactor error cleanup in grow_gnttab_list() The cleanup loop in grow_gnttab_list() is safe from the underflow of the unsigned 'i' since nr_glist_frames is = 1, but refactor it anyway. Thanks. David -- 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] power_supply: Add boot and calibration attributes
Usually PMIC's come with coulomb counting mechanism which can be
used to implement a Fuel Gauginig solution in Software itself.
One of key input to these SW Fuel Gauge solutioons is the boot up
parameters like boot voltage and boot current.
This patch adds the VOLTAGE_BOOT and CURRENT_BOOT power supply attributes
to report bootup voltage and current.
This patch also adds CALIBRATE power supply attribute which useful is
for calibrating the battery/coulomb counter.
Signed-off-by: Ramakrishna Pallala ramakrishna.pall...@intel.com
---
Documentation/power/power_supply_class.txt |6 ++
drivers/power/power_supply_sysfs.c |3 +++
include/linux/power_supply.h |5 +
3 files changed, 14 insertions(+)
diff --git a/Documentation/power/power_supply_class.txt
b/Documentation/power/power_supply_class.txt
index 48cff88..82dacc0 100644
--- a/Documentation/power/power_supply_class.txt
+++ b/Documentation/power/power_supply_class.txt
@@ -101,6 +101,10 @@ VOLTAGE_MAX, VOLTAGE_MIN - same as _DESIGN voltage values
except that
these ones should be used if hardware could only guess (measure and
retain) the thresholds of a given power supply.
+VOLTAGE_BOOT - Reports the voltage measured during boot
+
+CURRENT_BOOT - Reports the current measured during boot
+
CHARGE_FULL_DESIGN, CHARGE_EMPTY_DESIGN - design charge values, when
battery considered full/empty.
@@ -123,6 +127,8 @@ the current drawn from a charging source.
CHARGE_TERM_CURRENT - Charge termination current used to detect the end of
charge
condition.
+CALIBRATE - battery or coulomb counter calibration status
+
CONSTANT_CHARGE_VOLTAGE - constant charge voltage programmed by charger.
CONSTANT_CHARGE_VOLTAGE_MAX - maximum charge voltage supported by the
power supply object.
diff --git a/drivers/power/power_supply_sysfs.c
b/drivers/power/power_supply_sysfs.c
index 750a202..7e4726d 100644
--- a/drivers/power/power_supply_sysfs.c
+++ b/drivers/power/power_supply_sysfs.c
@@ -149,9 +149,11 @@ static struct device_attribute power_supply_attrs[] = {
POWER_SUPPLY_ATTR(voltage_now),
POWER_SUPPLY_ATTR(voltage_avg),
POWER_SUPPLY_ATTR(voltage_ocv),
+ POWER_SUPPLY_ATTR(voltage_boot),
POWER_SUPPLY_ATTR(current_max),
POWER_SUPPLY_ATTR(current_now),
POWER_SUPPLY_ATTR(current_avg),
+ POWER_SUPPLY_ATTR(current_boot),
POWER_SUPPLY_ATTR(power_now),
POWER_SUPPLY_ATTR(power_avg),
POWER_SUPPLY_ATTR(charge_full_design),
@@ -193,6 +195,7 @@ static struct device_attribute power_supply_attrs[] = {
POWER_SUPPLY_ATTR(type),
POWER_SUPPLY_ATTR(scope),
POWER_SUPPLY_ATTR(charge_term_current),
+ POWER_SUPPLY_ATTR(calibrate),
/* Properties of type `const char *' */
POWER_SUPPLY_ATTR(model_name),
POWER_SUPPLY_ATTR(manufacturer),
diff --git a/include/linux/power_supply.h b/include/linux/power_supply.h
index f3dea41..de59a28 100644
--- a/include/linux/power_supply.h
+++ b/include/linux/power_supply.h
@@ -102,9 +102,11 @@ enum power_supply_property {
POWER_SUPPLY_PROP_VOLTAGE_NOW,
POWER_SUPPLY_PROP_VOLTAGE_AVG,
POWER_SUPPLY_PROP_VOLTAGE_OCV,
+ POWER_SUPPLY_PROP_VOLTAGE_BOOT,
POWER_SUPPLY_PROP_CURRENT_MAX,
POWER_SUPPLY_PROP_CURRENT_NOW,
POWER_SUPPLY_PROP_CURRENT_AVG,
+ POWER_SUPPLY_PROP_CURRENT_BOOT,
POWER_SUPPLY_PROP_POWER_NOW,
POWER_SUPPLY_PROP_POWER_AVG,
POWER_SUPPLY_PROP_CHARGE_FULL_DESIGN,
@@ -146,6 +148,7 @@ enum power_supply_property {
POWER_SUPPLY_PROP_TYPE, /* use power_supply.type instead */
POWER_SUPPLY_PROP_SCOPE,
POWER_SUPPLY_PROP_CHARGE_TERM_CURRENT,
+ POWER_SUPPLY_PROP_CALIBRATE,
/* Properties of type `const char *' */
POWER_SUPPLY_PROP_MODEL_NAME,
POWER_SUPPLY_PROP_MANUFACTURER,
@@ -291,6 +294,7 @@ static inline bool power_supply_is_amp_property(enum
power_supply_property psp)
case POWER_SUPPLY_PROP_CURRENT_MAX:
case POWER_SUPPLY_PROP_CURRENT_NOW:
case POWER_SUPPLY_PROP_CURRENT_AVG:
+ case POWER_SUPPLY_PROP_CURRENT_BOOT:
return 1;
default:
break;
@@ -315,6 +319,7 @@ static inline bool power_supply_is_watt_property(enum
power_supply_property psp)
case POWER_SUPPLY_PROP_VOLTAGE_NOW:
case POWER_SUPPLY_PROP_VOLTAGE_AVG:
case POWER_SUPPLY_PROP_VOLTAGE_OCV:
+ case POWER_SUPPLY_PROP_VOLTAGE_BOOT:
case POWER_SUPPLY_PROP_CONSTANT_CHARGE_VOLTAGE:
case POWER_SUPPLY_PROP_CONSTANT_CHARGE_VOLTAGE_MAX:
case POWER_SUPPLY_PROP_POWER_NOW:
--
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/
