[PATCH v6 2/3] gpio: Cygnus: add GPIO driver
This GPIO driver supports all 3 GPIO controllers in the Broadcom Cygnus
SoC. The 3 GPIO controllers are 1) the ASIU GPIO controller, 2) the
chipCommonG GPIO controller, and 3) the ALWAYS-ON GPIO controller
Signed-off-by: Ray Jui
Reviewed-by: Scott Branden
---
drivers/gpio/Kconfig | 12 +
drivers/gpio/Makefile |1 +
drivers/gpio/gpio-bcm-cygnus.c | 607
3 files changed, 620 insertions(+)
create mode 100644 drivers/gpio/gpio-bcm-cygnus.c
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 633ec21..1790ffd 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -126,6 +126,18 @@ config GPIO_74XX_MMIO
8 bits: 74244 (Input), 74273 (Output)
16 bits:741624 (Input), 7416374 (Output)
+config GPIO_BCM_CYGNUS
+ bool "Broadcom Cygnus GPIO support"
+ depends on ARCH_BCM_CYGNUS && OF_GPIO
+ default y
+ help
+ Say yes here to turn on GPIO support for Broadcom Cygnus SoC
+
+ The Broadcom Cygnus SoC has 3 GPIO controllers including the ASIU
+ GPIO controller (ASIU), the chipCommonG GPIO controller (CCM), and
+ the always-ON GPIO controller (CRMU). All 3 GPIO controllers are
+ supported by this driver
+
config GPIO_CLPS711X
tristate "CLPS711X GPIO support"
depends on ARCH_CLPS711X || COMPILE_TEST
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 81755f1..31eb7e0 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -19,6 +19,7 @@ obj-$(CONFIG_GPIO_ADP5520)+= gpio-adp5520.o
obj-$(CONFIG_GPIO_ADP5588) += gpio-adp5588.o
obj-$(CONFIG_GPIO_AMD8111) += gpio-amd8111.o
obj-$(CONFIG_GPIO_ARIZONA) += gpio-arizona.o
+obj-$(CONFIG_GPIO_BCM_CYGNUS) += gpio-bcm-cygnus.o
obj-$(CONFIG_GPIO_BCM_KONA)+= gpio-bcm-kona.o
obj-$(CONFIG_GPIO_BT8XX) += gpio-bt8xx.o
obj-$(CONFIG_GPIO_CLPS711X)+= gpio-clps711x.o
diff --git a/drivers/gpio/gpio-bcm-cygnus.c b/drivers/gpio/gpio-bcm-cygnus.c
new file mode 100644
index 000..817bc9a
--- /dev/null
+++ b/drivers/gpio/gpio-bcm-cygnus.c
@@ -0,0 +1,607 @@
+/*
+ * Copyright (C) 2014 Broadcom Corporation
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define CYGNUS_GPIO_DATA_IN_OFFSET 0x00
+#define CYGNUS_GPIO_DATA_OUT_OFFSET 0x04
+#define CYGNUS_GPIO_OUT_EN_OFFSET0x08
+#define CYGNUS_GPIO_IN_TYPE_OFFSET 0x0c
+#define CYGNUS_GPIO_INT_DE_OFFSET0x10
+#define CYGNUS_GPIO_INT_EDGE_OFFSET 0x14
+#define CYGNUS_GPIO_INT_MSK_OFFSET 0x18
+#define CYGNUS_GPIO_INT_STAT_OFFSET 0x1c
+#define CYGNUS_GPIO_INT_MSTAT_OFFSET 0x20
+#define CYGNUS_GPIO_INT_CLR_OFFSET 0x24
+#define CYGNUS_GPIO_PAD_RES_OFFSET 0x34
+#define CYGNUS_GPIO_RES_EN_OFFSET0x38
+
+/* drive strength control for ASIU GPIO */
+#define CYGNUS_GPIO_ASIU_DRV0_CTRL_OFFSET 0x58
+
+/* drive strength control for CCM GPIO */
+#define CYGNUS_GPIO_CCM_DRV0_CTRL_OFFSET 0x00
+
+#define GPIO_BANK_SIZE 0x200
+#define NGPIOS_PER_BANK 32
+#define GPIO_BANK(pin) ((pin) / NGPIOS_PER_BANK)
+
+#define CYGNUS_GPIO_REG(pin, reg) (GPIO_BANK(pin) * GPIO_BANK_SIZE + (reg))
+#define CYGNUS_GPIO_SHIFT(pin) ((pin) % NGPIOS_PER_BANK)
+
+#define GPIO_FLAG_BIT_MASK 0x
+#define GPIO_PULL_BIT_SHIFT 16
+#define GPIO_PULL_BIT_MASK 0x3
+
+#define GPIO_DRV_STRENGTH_BIT_SHIFT 20
+#define GPIO_DRV_STRENGTH_BITS 3
+#define GPIO_DRV_STRENGTH_BIT_MASK ((1 << GPIO_DRV_STRENGTH_BITS) - 1)
+
+/*
+ * For GPIO internal pull up/down registers
+ */
+enum gpio_pull {
+ GPIO_PULL_NONE = 0,
+ GPIO_PULL_UP,
+ GPIO_PULL_DOWN,
+ GPIO_PULL_INVALID,
+};
+
+/*
+ * GPIO drive strength
+ */
+enum gpio_drv_strength {
+ GPIO_DRV_STRENGTH_2MA = 0,
+ GPIO_DRV_STRENGTH_4MA,
+ GPIO_DRV_STRENGTH_6MA,
+ GPIO_DRV_STRENGTH_8MA,
+ GPIO_DRV_STRENGTH_10MA,
+ GPIO_DRV_STRENGTH_12MA,
+ GPIO_DRV_STRENGTH_14MA,
+ GPIO_DRV_STRENGTH_16MA,
+ GPIO_DRV_STRENGTH_INVALID,
+};
+
+struct cygnus_gpio {
+ struct device *dev;
+ void __iomem *base;
+ void __iomem *io_ctrl;
+ spinlock_t lock;
+ struct gpio_chip gc;
+ unsigned num_banks;
+ int irq;
+ struct irq_domain *irq_domain;
+};
+
+static struct cygnus_gpio *to_cygnus_gpio(struct gpio_chip *gc)
+{
+ return container_of(gc, struct cygnus_gpio, gc);
+}
+
+static u32 cygnus_readl(struct cygnus_gpio
[PATCH v6 0/3] Add gpio support to Broadcom Cygnus SoC
This patchset contains the initial GPIO support for the Broadcom Cygnus SoC. Cygnus has 3 GPIO controllers: 1) the ASIU GPIO; 2) the chipCommonG GPIO; and 3) the ALWAYS-ON GPIO. All 3 types of GPIO controllers are supported by the same Cygnus GPIO driver Changes from v5: - Get rid of DT property "linux,gpio-base". Use dynamic allocation for GPIO base number Changes from v4: - Use DT property "linux,gpio-base" to define GPIO base number - factorize common code to improve code readability and reduce code size - remove "bcm_" prefix on function and struct names - improve debugging prints - default GPIO_BCM_CYGNUS to y in Kconfig (it still depends on ARCH_BCM_CYGNUS). This way we do not need to select it from the arch/arm/mach-bcm/Kconfig - Get rid of redundant MAINTAINER entry for this driver. It will be maintained by Broadcom iProc/Cygnus maintainers - Update device tree document based on driver changes Changes from v3: - Fix dt property tpyo - Fix incorrect GPIO compatible ID in device tree binding document example Changes from v2: - Consolidate different compatible IDs into "brcm,cygnus-gpio" - Get rid of redundant "no-interrupt" property Changes from v1: - Get rid of inline qualifier - Get rid of redundant check in the ISR - Other minor fixes to imrove code readability Ray Jui (3): gpio: Cygnus: define Broadcom Cygnus GPIO binding gpio: Cygnus: add GPIO driver ARM: dts: enable GPIO for Broadcom Cygnus .../devicetree/bindings/gpio/brcm,cygnus-gpio.txt | 82 +++ arch/arm/boot/dts/bcm-cygnus.dtsi | 30 + drivers/gpio/Kconfig | 12 + drivers/gpio/Makefile |1 + drivers/gpio/gpio-bcm-cygnus.c | 607 5 files changed, 732 insertions(+) create mode 100644 Documentation/devicetree/bindings/gpio/brcm,cygnus-gpio.txt create mode 100644 drivers/gpio/gpio-bcm-cygnus.c -- 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: [RFC PATCH 2/2] iommu: rockchip: Handle system-wide and runtime PM
On Tue, Dec 16, 2014 at 4:53 AM, Laurent Pinchart wrote: > Hi Tomasz, > > On Monday 15 December 2014 11:39:01 Tomasz Figa wrote: >> On Sat, Dec 13, 2014 at 5:47 AM, Laurent Pinchart wrote: >> > On Friday 12 December 2014 13:15:51 Tomasz Figa wrote: >> >> On Fri, Dec 12, 2014 at 5:48 AM, Rafael J. Wysocki wrote: >> >>> On Thursday, December 11, 2014 04:51:37 PM Ulf Hansson wrote: >> On 11 December 2014 at 16:31, Kevin Hilman wrote: >> > [+ Laurent Pinchart] >> > >> > Tomasz Figa writes: >> >> On Thu, Dec 11, 2014 at 8:58 PM, Ulf Hansson wrote: >> > [...] >> > >> @@ -988,11 +1107,28 @@ static int rk_iommu_probe(struct >> platform_device *pdev) >> return -ENXIO; >> } >> >> + pm_runtime_no_callbacks(dev); >> + pm_runtime_enable(dev); >> + >> + /* Synchronize state of the domain with driver data. */ >> + pm_runtime_get_sync(dev); >> + iommu->is_powered = true; >> >>> >> >>> Doesn't the runtime PM status reflect the value of "is_powered", >> >>> thus why do you need to have a copy of it? Could it perpahps be >> >>> that you try to cope with the case when CONFIG_PM is unset? >> >> >> >> It's worth noting that this driver fully relies on status of other >> >> devices in the power domain the IOMMU is in and does not enforce >> >> the status on its own. So in general, as far as my understanding of >> >> PM runtime subsystem, the status of the IOMMU device will be always >> >> suspended, because nobody will call pm_runtime_get() on it (except >> >> the get and put pair in probe). So is_powered is here to track >> >> status of the domain, not the device. Feel free to suggest a better >> >> way, though. >> > >> > I still don't like these notifiers. I think they add ways to bypass >> > having proper runtime PM implemented for devices/subsystems. >> >> I do agree, but I haven't found another good solution to the problem. >> >>> >> >>> For the record, I'm not liking this mostly because it "fixes" a generic >> >>> problem in a way that's hidden in the genpd code and very indirect. >> >> >> >> Well, that's true. This is indeed a generic problem of PM dependencies >> >> between devices (other than those represented by parent-child >> >> relation), which in fact doesn't have much to do with genpd, but >> >> rather with those devices directly. It is just that genpd is the most >> >> convenient location to solve this in current code and in a simple way. >> >> In other words, I see this solution as a reasonable way to get the >> >> problem solved quickly for now, so that we can start thinking about a >> >> more elegant solution. >> >> >> >> >> > From a high-level, the IOMMU is just another device inside the PM >> >> >> > domain, so ideally it should be doing it's own _get() and _put() >> >> >> > calls so the PM domain code would just do the right thing without >> >> >> > the need for notifiers. >> >> >> >> >> >> As I understand it, the IOMMU (or for other similar cases) shouldn't >> >> >> be doing any get() and put() at all because there are no IO API to >> >> >> serve request from. >> > >> > Speaking purely from an IOMMU point of view that's not entirely tree. >> > IOMMU drivers expose map and unmap operations, so they can track whether >> > any memory is mapped. From a bus master point of view the IOMMU map and >> > unmap operations are hidden by the DMA mapping API. The IOMMU can thus >> > track the existence of mappings without any IOMMU awareness in the bus >> > master driver. >> > >> > If no mapping exist the IOMMU shouldn't receive any translation request. >> > An IOMMU driver could thus call pm_runtime_get_sync() in the map handler >> > when creating the first mapping, and pm_runtime_put() in the unmap handler >> > when tearing the last mapping down. >> > >> > One could argue that the IOMMU would end up being powered more often than >> > strictly needed, as bus masters drivers, even when written properly, could >> > keep mappings around at times they don't perform bus access. This is true, >> > and that's an argument I've raised during the last kernel summit. The >> > general response (including Linus Torvald's) was that micro-optimizing >> > power management might not be worth it, and that measurements proving >> > that the gain is worth it are required before introducing new APIs to >> > solve the problem. I can't disagree with that argument. >> >> This would be a micro optimization if the IOMMU was located in its own >> power domain. Unfortunately in most cases it is not, so keeping all >> the devices in the domain powered on, because one of them have a >> mapping created doesn't sound like a good idea. >> >> Moreover, most of the drivers will keep the mapping for much longer >> than one run cycle. Please take a look at V4L2's videobuf2 subsystem >> (which I
Re: [git pull] drm for 3.19-rc1
On Mon, Dec 15, 2014 at 5:50 PM, Dave Airlie wrote: > > Now you might complain that printing anything in this case is bad, I don't mind it if it's *one* line, and if people realize that the commentary in the commit in question was pure and utter shit. Because talking about how it's going to become an error is pretty damn premature, if Xorg uses it today. That's part of what just made me really frigging upset. People applied this patch, didn't test it AT ALL, and the commit message is completely inappropriate crap. Having a quiet deprecation warning with the understanding that things will stay around for *years* is fine. Although it makes me wonder how much value the deprecation message really adds. I mean, why the hell print a message, when the only correct thing to do is to just look at and fix Xorg? And if you can't get Xorg fixed, then the message is kind of pointless too? So really, I don't see the point of even a oneliner message. You guys know who the user is. There's no value in the message. Either you fix the user or you don't. It's not like "oh, it's Xorg that uses our drm interfaces" is a big surprise, is it? Linus -- 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] perf tool: Fix use after free in filename__read_build_id
In filename__read_build_id, phdr points to memory in buf, which gets realloced
before a call to fseek that uses phdr->p_offset. This change stores the value
of p_offset before buf is realloced, so the fseek can use the value safely.
Signed-off-by: Mitchell Krome
---
tools/perf/util/symbol-minimal.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/tools/perf/util/symbol-minimal.c b/tools/perf/util/symbol-minimal.c
index fa585c6..d7efb03 100644
--- a/tools/perf/util/symbol-minimal.c
+++ b/tools/perf/util/symbol-minimal.c
@@ -129,6 +129,7 @@ int filename__read_build_id(const char *filename, void *bf,
size_t size)
for (i = 0, phdr = buf; i < ehdr.e_phnum; i++, phdr++) {
void *tmp;
+ long offset;
if (need_swap) {
phdr->p_type = bswap_32(phdr->p_type);
@@ -140,12 +141,13 @@ int filename__read_build_id(const char *filename, void
*bf, size_t size)
continue;
buf_size = phdr->p_filesz;
+ offset = phdr->p_offset;
tmp = realloc(buf, buf_size);
if (tmp == NULL)
goto out_free;
buf = tmp;
- fseek(fp, phdr->p_offset, SEEK_SET);
+ fseek(fp, offset, SEEK_SET);
if (fread(buf, buf_size, 1, fp) != 1)
goto out_free;
@@ -178,6 +180,7 @@ int filename__read_build_id(const char *filename, void *bf,
size_t size)
for (i = 0, phdr = buf; i < ehdr.e_phnum; i++, phdr++) {
void *tmp;
+ long offset;
if (need_swap) {
phdr->p_type = bswap_32(phdr->p_type);
@@ -189,12 +192,13 @@ int filename__read_build_id(const char *filename, void
*bf, size_t size)
continue;
buf_size = phdr->p_filesz;
+ offset = phdr->p_offset;
tmp = realloc(buf, buf_size);
if (tmp == NULL)
goto out_free;
buf = tmp;
- fseek(fp, phdr->p_offset, SEEK_SET);
+ fseek(fp, offset, SEEK_SET);
if (fread(buf, buf_size, 1, fp) != 1)
goto out_free;
--
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 3.17 000/122] 3.17.5-stable review
On 12/05/2014 07:44 PM, Greg Kroah-Hartman wrote:
On Fri, Dec 05, 2014 at 07:30:48PM -0800, Guenter Roeck wrote:
On 12/05/2014 02:42 PM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 3.17.5 release.
There are 122 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Sun Dec 7 22:32:17 UTC 2014.
Anything received after that time might be too late.
Build results:
total: 133 pass: 132 fail: 1
Failed builds:
avr32:atngw100mkii_evklcd101_defconfig
Bah, it looks like no one cares about avr32 anymore :(
Hi Greg,
Just in case you do care, the following patch makes it compile again.
cd514e727b18 ("lib/string.c: remove duplicated function")
Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/6] dt-bindings: Add documentation for Rockchip hdmi-audio
Hi Mark :
Got it, it will be good to use simple-card. i will try it in next version.
Best Regards.
在 2014年12月16日 00:18, Mark Brown 写道:
On Mon, Dec 15, 2014 at 09:10:26PM +0800, Kuankuan.Yang wrote:
Hi Mark & Russell:
Please don't top post, that way people have some context for what you're
saying - look at how people normally format their mails on thelist.
In that way, dt will only need compatible for creating sound device. is it
ok ?
sound {
compatible = "rockchip,rk3288-hdmi-audio";
status = "okay";
}
could you give me some advises.
That'd be good, though the other question is if this can be made to use
simple-card so we can avoid having a custom driver for this.
--
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] perf: fix building warning on ARM 32.
Commit 85c116a6c introduces asprintf() call and matches '%ld' to a u64
argument, which is incorrect on ARM.
CC /home/wn/util/srcline.o
util/srcline.c: In function 'get_srcline':
util/srcline.c:297:6: error: format '%ld' expects argument of type 'long int',
but argument 4 has type 'u64' [-Werror=format]
cc1: all warnings being treated as errors
make[1]: *** [/home/wn/util/srcline.o] Error 1
Signed-off-by: Wang Nan
---
tools/perf/util/srcline.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/perf/util/srcline.c b/tools/perf/util/srcline.c
index e73b6a5..42cb642 100644
--- a/tools/perf/util/srcline.c
+++ b/tools/perf/util/srcline.c
@@ -294,7 +294,7 @@ out:
}
if (sym) {
if (asprintf(, "%s+%ld", show_sym ? sym->name : "",
- addr - sym->start) < 0)
+ (long int)(addr - sym->start)) < 0)
return SRCLINE_UNKNOWN;
} else if (asprintf(, "%s[%lx]", dso->short_name, addr) < 0)
return SRCLINE_UNKNOWN;
--
1.8.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] scsi:storvsc enable reading from VPD pages on SPC-2
Thanks Martin for the explanation. I'll send out another patch. > -Original Message- > From: Martin K. Petersen [mailto:martin.peter...@oracle.com] > Sent: Thursday, December 11, 2014 7:04 PM > To: Long Li > Cc: Martin K. Petersen; KY Srinivasan; Haiyang Zhang; > jbottom...@parallels.com; linux-s...@vger.kernel.org; > de...@linuxdriverproject.org; linux-kernel@vger.kernel.org > Subject: Re: [PATCH] scsi:storvsc enable reading from VPD pages on SPC-2 > > > "Long" == Long Li writes: > > >> Handle the issues or handle WRITE SAME(10/16)? > > Long> With this patch, the SCSI layer will be able to correctly send > Long> WRITE_SAME_16 to the Hyper-V host. It will not send WRITE_SAME_10: > Long> it has been disabled in the driver template. Do you want me to > Long> send another patch with these details? > > no_write_same prevents us from attempting to use WRITE SAME(10/16) to zero > block ranges. > > This is completely orthogonal to using the WRITE SAME(10/16) commands with > the UNMAP bit set to discard block ranges. The latter is controlled by the > logical > block provisioning heuristics and is not affected by no_write_same at all. > > -- > Martin K. PetersenOracle Linux Engineering -- 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/3] usb: host: f_usb20ho: add support for Fujitsu ehci/ohci USB 2.0 host controller
This patch adds support for EHCI compliant Host controller found
on Fujitsu Socs.
Signed-off-by: Sneeker Yeh
---
.../devicetree/bindings/usb/fujitsu-ehci.txt | 22 ++
drivers/usb/host/Kconfig | 11 +
drivers/usb/host/Makefile |1 +
drivers/usb/host/f_usb20ho_hcd.c | 306
drivers/usb/host/f_usb20ho_hcd.h | 35 +++
5 files changed, 375 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/fujitsu-ehci.txt
create mode 100644 drivers/usb/host/f_usb20ho_hcd.c
create mode 100644 drivers/usb/host/f_usb20ho_hcd.h
diff --git a/Documentation/devicetree/bindings/usb/fujitsu-ehci.txt
b/Documentation/devicetree/bindings/usb/fujitsu-ehci.txt
new file mode 100644
index 000..e180860
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/fujitsu-ehci.txt
@@ -0,0 +1,22 @@
+FUJITSU GLUE COMPONENTS
+
+MB86S7x EHCI GLUE
+ - compatible : Should be "fujitsu,f_usb20ho_hcd"
+ - reg : Address and length of the register set for the device.
+ - interrupts : The irq number of this device that is used to interrupt the
+ CPU
+ - clocks: from common clock binding, handle to usb clock.
+ - clock-names: from common clock binding.
+ - #stream-id-cells : handle to use "arm,mmu-400" ARM IOMMU driver
+ - fujitsu,power-domain : pd_usb2h node has to be builded, details can be
+ found in:
+ Documentation/devicetree/bindings/
+
+hcd21: f_usb20ho_hcd {
+ compatible = "fujitsu,f_usb20ho_hcd";
+ reg = <0 0x3420 0x8>;
+ interrupts = <0 419 0x4>;
+ clocks = <_main_2_4>, <_main_4_5>, <_usb_0_0>;
+ clock-names = "h_clk", "p_clk", "p_cryclk";
+ #stream-id-cells = <0>;
+};
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index fafc628..9482140 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -786,6 +786,17 @@ config USB_HCD_SSB
If unsure, say N.
+config USB_F_USB20HO_HCD
+ tristate "F_USB20HO USB Host Controller"
+ depends on USB && ARCH_MB86S7X
+ default y
+ help
+ This driver enables support for USB20HO USB Host Controller,
+ the driver supports High, Full and Low Speed USB.
+
+ To compile this driver a module, choose M here: the module
+ will be called "f_usb20ho-hcd".
+
config USB_HCD_TEST_MODE
bool "HCD test mode support"
---help---
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index d6216a4..b89e536 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -78,3 +78,4 @@ obj-$(CONFIG_USB_HCD_SSB) += ssb-hcd.o
obj-$(CONFIG_USB_FUSBH200_HCD) += fusbh200-hcd.o
obj-$(CONFIG_USB_FOTG210_HCD) += fotg210-hcd.o
obj-$(CONFIG_USB_MAX3421_HCD) += max3421-hcd.o
+obj-$(CONFIG_USB_F_USB20HO_HCD)+= f_usb20ho_hcd.o
diff --git a/drivers/usb/host/f_usb20ho_hcd.c b/drivers/usb/host/f_usb20ho_hcd.c
new file mode 100644
index 000..d665487
--- /dev/null
+++ b/drivers/usb/host/f_usb20ho_hcd.c
@@ -0,0 +1,306 @@
+/**
+ * f_usb20ho_hcd.c - Fujitsu EHCI platform driver
+ *
+ * Copyright (c) 2013 - 2014 FUJITSU SEMICONDUCTOR LIMITED
+ * http://jp.fujitsu.com/group/fsl
+ *
+ * based on bcma-hcd.c
+ *
+ * Author: Sneeker Yeh
+ *
+ * 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
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "f_usb20ho_hcd.h"
+
+static int f_usb20ho_clk_control(struct device *dev, bool on)
+{
+ int ret, i;
+ struct clk *clk;
+
+ if (!on)
+ goto clock_off;
+
+ for (i = 0;; i++) {
+ clk = of_clk_get(dev->of_node, i);
+ if (IS_ERR(clk))
+ break;
+
+ ret = clk_prepare_enable(clk);
+ if (ret) {
+ dev_err(dev, "failed to enable clock[%d]\n", i);
+ goto clock_off;
+ }
+ }
+
+ return 0;
+
+clock_off:
+ for (i = 0;; i++) {
+ clk = of_clk_get(dev->of_node, i);
+ if (IS_ERR(clk))
+ break;
+
+ clk_disable_unprepare(clk);
+ }
+
+ return on;
+}
+
+static struct platform_device *f_usb20ho_hcd_create_pdev(
+ struct platform_device *pdev, bool ohci)
+{
+ struct resource *resource;
+ struct platform_device *hci_dev;
+ struct resource hci_res[2];
+ int ret = -ENOMEM;
+ int irq;
+ resource_size_t resource_size;
+
+ memset(hci_res, 0, sizeof(hci_res));
+
+ resource = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if
[PATCH 3/3] usb: dwc3: add a quirk for device disconnection issue in Synopsis dwc3 core
Synopsis DesignWare USB3 IP Core integrated with a config-free
phy needs special handling during device disconnection to avoid
the host controller dying.
This quirk makes sure PORT_CSC is cleared after the disable slot
command when usb device is disconnected from internal root hub,
otherwise, Synopsis core would fall into a state that cannot use
any endpoint command. Consequently, device disconnection procedure
might not be finished because sometimes endpoint need to be stop
by endpoint stop command issuing.
Symptom usually happens when disconnected device is keyboard,
mouse, and hub.
Signed-off-by: Sneeker Yeh
---
drivers/usb/host/xhci-hub.c |4
drivers/usb/host/xhci-plat.c |5 +
drivers/usb/host/xhci.c | 29 +
drivers/usb/host/xhci.h |7 +++
4 files changed, 45 insertions(+)
diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
index a7865c4..3b8f7fc 100644
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -368,6 +368,10 @@ static void xhci_clear_port_change_bit(struct xhci_hcd
*xhci, u16 wValue,
port_change_bit = "warm(BH) reset";
break;
case USB_PORT_FEAT_C_CONNECTION:
+ if ((xhci->quirks & XHCI_DISCONNECT_QUIRK) &&
+ !(readl(addr) & PORT_CONNECT))
+ return;
+
status = PORT_CSC;
port_change_bit = "connect";
break;
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 08d402b..3ede6b4 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -33,6 +33,11 @@ static void xhci_plat_quirks(struct device *dev, struct
xhci_hcd *xhci)
* dev struct in order to setup MSI
*/
xhci->quirks |= XHCI_PLAT;
+
+ if (dev->parent && dev->parent->parent &&
+ of_device_is_compatible(dev->parent->parent->of_node,
+ "fujitsu,mb86s70-dwc3"))
+ xhci->quirks |= XHCI_DISCONNECT_QUIRK;
}
/* called during probe() after chip reset completes */
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 01fcbb5..50d757b 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -3584,6 +3584,33 @@ command_cleanup:
return ret;
}
+static void xhci_try_to_clear_csc(struct usb_hcd *hcd, int dev_port_num)
+{
+ int max_ports;
+ struct xhci_hcd *xhci = hcd_to_xhci(hcd);
+ __le32 __iomem **port_array;
+ u32 status;
+
+ /* print debug info */
+ if (hcd->speed == HCD_USB3) {
+ max_ports = xhci->num_usb3_ports;
+ port_array = xhci->usb3_ports;
+ } else {
+ max_ports = xhci->num_usb2_ports;
+ port_array = xhci->usb2_ports;
+ }
+
+ if (dev_port_num > max_ports) {
+ xhci_err(xhci, "%s() port number invalid", __func__);
+ return;
+ }
+ status = readl(port_array[dev_port_num - 1]);
+
+ /* write 1 to clear */
+ if (!(status & PORT_CONNECT) && (status & PORT_CSC))
+ writel(status & PORT_CSC, port_array[0]);
+}
+
/*
* At this point, the struct usb_device is about to go away, the device has
* disconnected, and all traffic has been stopped and the endpoints have been
@@ -3649,6 +3676,8 @@ void xhci_free_dev(struct usb_hcd *hcd, struct usb_device
*udev)
xhci_ring_cmd_db(xhci);
spin_unlock_irqrestore(>lock, flags);
+ if (xhci->quirks & XHCI_DISCONNECT_QUIRK)
+ xhci_try_to_clear_csc(hcd, udev->portnum);
/*
* Event command completion handler will free any data structures
* associated with the slot. XXX Can free sleep?
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index cc7c5bb..e6c820c 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -1560,6 +1560,13 @@ struct xhci_hcd {
#define XHCI_SPURIOUS_WAKEUP (1 << 18)
/* For controllers with a broken beyond repair streams implementation */
#define XHCI_BROKEN_STREAMS(1 << 19)
+/*
+ * Synopsis dwc3 core integrated with a config-free phy needs special
+ * handling during device disconnection to avoid the host controller
+ * dying. This quirk makes sure PORT_CSC is cleared after the disable
+ * slot command.
+ */
+#define XHCI_DISCONNECT_QUIRK (1 << 20)
unsigned intnum_active_eps;
unsigned intlimit_active_eps;
/* There are two roothubs to keep track of bus suspend info for */
--
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] usb: dwc3: add Fujitsu Specific Glue layer
This patch adds support for Synopsis DesignWare USB3 IP Core found
on Fujitsu Socs.
Signed-off-by: Sneeker Yeh
---
.../devicetree/bindings/usb/fujitsu-dwc3.txt | 25 +++
drivers/usb/dwc3/Kconfig | 11 ++
drivers/usb/dwc3/Makefile |1 +
drivers/usb/dwc3/dwc3-mb86s70.c| 194
4 files changed, 231 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/fujitsu-dwc3.txt
create mode 100644 drivers/usb/dwc3/dwc3-mb86s70.c
diff --git a/Documentation/devicetree/bindings/usb/fujitsu-dwc3.txt
b/Documentation/devicetree/bindings/usb/fujitsu-dwc3.txt
new file mode 100644
index 000..df77f91
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/fujitsu-dwc3.txt
@@ -0,0 +1,25 @@
+FUJITSU GLUE COMPONENTS
+
+MB86S7x DWC3 GLUE
+ - compatible : Should be "fujitsu,mb86s70-dwc3"
+ - clocks: from common clock binding, handle to usb clock.
+ - clock-names: from common clock binding.
+ - #address-cells, #size-cells : Must be present if the device has sub-nodes
+ - ranges: the child address space are mapped 1:1 onto the parent address space
+ - #stream-id-cells : handle to use "arm,mmu-400" ARM IOMMU driver
+
+Sub-nodes:
+The dwc3 core should be added as subnode to MB86S7x dwc3 glue.
+- dwc3 :
+ The binding details of dwc3 can be found in:
+ Documentation/devicetree/bindings/usb/dwc3.txt
+
+usb3host: mb86s70_usb3host {
+ compatible = "fujitsu,mb86s70-dwc3";
+ clocks = <_alw_1_1>;
+ clock-names = "bus_clk";
+ #address-cells = <2>;
+ #size-cells = <1>;
+ ranges;
+ #stream-id-cells = <0>;
+};
diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
index 58b5b2c..3390d42 100644
--- a/drivers/usb/dwc3/Kconfig
+++ b/drivers/usb/dwc3/Kconfig
@@ -61,6 +61,17 @@ config USB_DWC3_EXYNOS
Recent Exynos5 SoCs ship with one DesignWare Core USB3 IP inside,
say 'Y' or 'M' if you have one such device.
+config USB_DWC3_MB86S70
+ tristate "MB86S70 Designware USB3 Platform code"
+ default USB_DWC3
+ help
+ MB86S7X SOC ship with DesignWare Core USB3 IP inside,
+ this implementation also integrated Fujitsu USB PHY inside
+ this Core USB3 IP.
+
+ say 'Y' or 'M' if you have one such device.
+
+
config USB_DWC3_PCI
tristate "PCIe-based Platforms"
depends on PCI
diff --git a/drivers/usb/dwc3/Makefile b/drivers/usb/dwc3/Makefile
index bb34fbc..05d1de2 100644
--- a/drivers/usb/dwc3/Makefile
+++ b/drivers/usb/dwc3/Makefile
@@ -38,3 +38,4 @@ obj-$(CONFIG_USB_DWC3_PCI)+= dwc3-pci.o
obj-$(CONFIG_USB_DWC3_KEYSTONE)+= dwc3-keystone.o
obj-$(CONFIG_USB_DWC3_QCOM)+= dwc3-qcom.o
obj-$(CONFIG_USB_DWC3_ST) += dwc3-st.o
+obj-$(CONFIG_USB_DWC3_MB86S70) += dwc3-mb86s70.o
diff --git a/drivers/usb/dwc3/dwc3-mb86s70.c b/drivers/usb/dwc3/dwc3-mb86s70.c
new file mode 100644
index 000..241c5bd
--- /dev/null
+++ b/drivers/usb/dwc3/dwc3-mb86s70.c
@@ -0,0 +1,194 @@
+/**
+ * dwc3-mb86s70.c - Fujitsu mb86s70 DWC3 Specific Glue layer
+ *
+ * Copyright (c) 2013 - 2014 FUJITSU SEMICONDUCTOR LIMITED
+ * http://jp.fujitsu.com/group/fsl
+ *
+ * Author: Alice Chan
+ * based on dwc3-exynos.c
+ *
+ * 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
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct dwc3_mb86s70 {
+ struct device *dev;
+ struct clk **clk_table;
+};
+
+/* return 0 means successful */
+static int dwc3_mb86s70_clk_control(struct device *dev, bool on)
+{
+ int ret, i;
+ struct clk *clk;
+
+ if (!on)
+ goto clock_off;
+
+ for (i = 0;; i++) {
+ clk = of_clk_get(dev->of_node, i);
+ if (IS_ERR(clk))
+ break;
+
+ ret = clk_prepare_enable(clk);
+ if (ret) {
+ dev_err(dev, "failed to enable clock[%d]\n", i);
+ goto clock_off;
+ }
+ }
+
+ return 0;
+
+clock_off:
+ for (i = 0;; i++) {
+ clk = of_clk_get(dev->of_node, i);
+ if (IS_ERR(clk))
+ break;
+
+ clk_disable_unprepare(clk);
+ }
+
+ return on;
+}
+
+static int dwc3_mb86s70_remove_child(struct device *dev, void *unused)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+
+ of_device_unregister(pdev);
+
+ return 0;
+}
+
+static u64 dwc3_mb86s70_dma_mask = DMA_BIT_MASK(32);
+
+static int dwc3_mb86s70_probe(struct platform_device *pdev)
+{
+ struct dwc3_mb86s70 *mb86s70;
+
[PATCH 0/3] Add support for Fujitsu USB host controller
These patches add support for EHCI and XHCI compliant Host controller found on Fujitsu Socs, and are based on http://www.spinics.net/lists/arm-kernel/msg385573.html First patch is EHCI platform glue driver. Patch 2 introduces Fujitsu Specific Glue layer in Synopsis DesignWare USB3 IP driver. Patch 3 introduces a quirk with device disconnection management necessary for IPs using the Synopsys Designware dwc3 core. It solves a problem where without the quirk, that host controller will die after a usb device is disconnected from port of root hub, which happened in Synopsis core with Fujitsu config-free usb phy integrated. Successfully tested on Fujitsu mb86s7x board. Sneeker Yeh (3): usb: host: f_usb20ho: add support for Fujitsu ehci/ohci USB 2.0 host controller usb: dwc3: add Fujitsu Specific Glue layer usb: dwc3: add a quirk for device disconnection issue in Synopsis dwc3 core .../devicetree/bindings/usb/fujitsu-dwc3.txt | 25 ++ .../devicetree/bindings/usb/fujitsu-ehci.txt | 22 ++ drivers/usb/dwc3/Kconfig | 11 + drivers/usb/dwc3/Makefile |1 + drivers/usb/dwc3/dwc3-mb86s70.c| 194 + drivers/usb/host/Kconfig | 11 + drivers/usb/host/Makefile |1 + drivers/usb/host/f_usb20ho_hcd.c | 306 drivers/usb/host/f_usb20ho_hcd.h | 35 +++ drivers/usb/host/xhci-hub.c|4 + drivers/usb/host/xhci-plat.c |5 + drivers/usb/host/xhci.c| 29 ++ drivers/usb/host/xhci.h|7 + 13 files changed, 651 insertions(+) create mode 100644 Documentation/devicetree/bindings/usb/fujitsu-dwc3.txt create mode 100644 Documentation/devicetree/bindings/usb/fujitsu-ehci.txt create mode 100644 drivers/usb/dwc3/dwc3-mb86s70.c create mode 100644 drivers/usb/host/f_usb20ho_hcd.c create mode 100644 drivers/usb/host/f_usb20ho_hcd.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/
Re: [CFT] Can I get some Tested-By's on this series?
On Wed, Dec 10, 2014 at 8:39 AM, Eric W. Biederman wrote: > > Will people please test these patches with their container project? > > These changes break container userspace (hopefully in a minimal way) if > I could have that confirmed by testing I would really appreciate it. I > really don't want to send out a bug fix that accidentally breaks > userspace again. > > The only issue sort of under discussion is if there is a better name for > /proc//setgroups, and the name of the file will not affect the > functionality of the patchset. > > With the code reviewed and written in simple obviously correct, easily > reviewable ways I am hoping/planning to send this to Linus ASAP. I tested this with Sandstorm. It breaks as is and it works if I add the setgroups thing. Tested-by: Andy Lutomirski # breaks things as designed :( I still don't like the name "setgroups". --Andy > > Eric -- Andy Lutomirski AMA Capital Management, LLC -- 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 (resend)] mailbox: Add Altera mailbox driver
On Mon, Dec 15, 2014 at 10:22 PM, Dinh Nguyen wrote:
>
>
> On 12/15/14, 12:22 AM, Ley Foon Tan wrote:
>> On Fri, Dec 12, 2014 at 10:38 PM, Dinh Nguyen wrote:
>>
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
>>>
>>> Alphabetize the headers.
>> Okay.
>>
>>
+static int altera_mbox_startup_sender(struct mbox_chan *chan)
+{
+ int ret;
+ struct altera_mbox *mbox = to_altera_mbox(chan);
+
+ if (mbox->intr_mode) {
+ ret = request_irq(mbox->irq, altera_mbox_tx_interrupt, 0,
>>>
>>> Use devm_request_irq, since you didn't have and don't need use free_irq
>>> in the shutdown function.
>> We want to free_irq when it shutdown. That means nobody requests for
>> that mailbox (or channel) and request_irq() again if someone requests
>> for a mailbox.
>>
>
> But you didn't have any free_irq in the shutdown function. Use
> devm_request_irq here, so you don't have to add them.
Hi Dinh
free_irq() is in altera_mbox_shutdown(). This function will be called
when user free/release the mailbox (channel).
But, devm_free_irq() only will be called when unload the module.
+static void altera_mbox_shutdown(struct mbox_chan *chan)
+{
+ struct altera_mbox *mbox = to_altera_mbox(chan);
+
+ if (WARN_ON(!mbox))
+ return;
+
+ if (mbox->intr_mode) {
+ /* Unmask all interrupt masks */
+ __raw_writel(~0, mbox->mbox_base + MAILBOX_INTMASK_REG);
+ free_irq(mbox->irq, chan);
--
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 v6] Thermal: introduce INT3406 thermal driver
On 13/12/14 02:18, Olof Johansson wrote: > Hi, > > > > On Thu, Dec 11, 2014 at 12:38 AM, Aaron Lu wrote: >> INT3406 ACPI device object resembles an ACPI video output device, but its >> _BCM is said to be deprecated and should not be used. So we will make >> use of the raw interface to do the actual cooling. Due to this, the >> backlight core has some modifications. Also, to re-use some of the ACPI >> video module's code, one function has been exported. >> >> Signed-off-by: Aaron Lu >> --- >> v6: Fix an issue that wrongly set error path return value as reported >> by Olof Johansson. > > Last night's -next was still broken. I take it this wasn't applied > yet? Please at least revert the original patch. Indeed, not yet. I believe Rui is waiting for you to confirm that the patch indeed fix your problem, so can you please kindly give it a test? Thanks. -Aaron > > > -Olof > -- 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 RESEND v2] mfd: syscon: add child device support
Hi,
The patch set is used to implement reset controller in
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-November/299141.html
Tested-by: Flora Fu
Thanks,
Flora
On Mon, 2014-12-15 at 09:58 +, Lee Jones wrote:
> On Mon, 15 Dec 2014, Philipp Zabel wrote:
> > Am Montag, den 01.12.2014, 17:25 +0100 schrieb Philipp Zabel:
> > > For devices which have a complete register for themselves, it is possible
> > > to
> > > place them next to the syscon device with overlapping reg ranges. The
> > > same is
> > > not possible for devices which only occupy bitfields in registers shared
> > > with
> > > other users.
> > > For devices that are completely controlled by bitfields in the syscon
> > > address
> > > range, such as multiplexers or voltage regulators, allow to put child
> > > devices
> > > into the syscon device node.
> >
> > What is the status of this patch?
> > Is this ok to be applied after the merge window closes?
> >
> > For reference, these are the previous threads:
> > https://lkml.org/lkml/2014/5/27/422
> > https://lkml.org/lkml/2014/11/3/134
>
> As this is such an important driver I need more Acks for users/testers
> and senior reviewers before applying.
>
> > > Signed-off-by: Philipp Zabel
> > > ---
> > > Changes since v1:
> > > - Reworded binding documentation to allow #size-cells = <1>, which is
> > > useful
> > >for syscon children that are controlled through a (possibly shared)
> > > register
> > >range.
> > > ---
> > > Documentation/devicetree/bindings/mfd/syscon.txt | 13 +
> > > drivers/mfd/syscon.c | 3 +++
> > > 2 files changed, 16 insertions(+)
> > >
> > > diff --git a/Documentation/devicetree/bindings/mfd/syscon.txt
> > > b/Documentation/devicetree/bindings/mfd/syscon.txt
> > > index fe8150b..0c6b497 100644
> > > --- a/Documentation/devicetree/bindings/mfd/syscon.txt
> > > +++ b/Documentation/devicetree/bindings/mfd/syscon.txt
> > > @@ -9,12 +9,25 @@ using a specific compatible value), interrogate the
> > > node (or associated
> > > OS driver) to determine the location of the registers, and access the
> > > registers directly.
> > >
> > > +Optionally, devices that are controlled exclusively through syscon
> > > registers,
> > > +or even bitfields in shared syscon registers, can also be added as child
> > > nodes
> > > +to the syscon device node. These devices can implicitly assume their
> > > parent
> > > +node is a syscon provider without referencing it explicitly via phandle.
> > > +In this case, the syscon node should have #address-cells = <1> and
> > > +#size-cells = <0> or <1> and no ranges property.
> > > +
> > > Required properties:
> > > - compatible: Should contain "syscon".
> > > - reg: the register region can be accessed from syscon
> > >
> > > +Optional properties:
> > > +- #address-cells: Should be 1.
> > > +- #size-cells: Should be 0 or 1.
> > > +
> > > Examples:
> > > gpr: iomuxc-gpr@020e {
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > compatible = "fsl,imx6q-iomuxc-gpr", "syscon";
> > > reg = <0x020e 0x38>;
> > > };
> > > diff --git a/drivers/mfd/syscon.c b/drivers/mfd/syscon.c
> > > index ca15878..38da178 100644
> > > --- a/drivers/mfd/syscon.c
> > > +++ b/drivers/mfd/syscon.c
> > > @@ -155,6 +155,9 @@ static int syscon_probe(struct platform_device *pdev)
> > >
> > > dev_dbg(dev, "regmap %pR registered\n", res);
> > >
> > > + if (!of_device_is_compatible(pdev->dev.of_node, "simple-bus"))
> > > + of_platform_populate(pdev->dev.of_node, NULL, NULL, >dev);
> > > +
> > > 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: linux-next: build failure after merge of the infiniband tree
On Mon, Dec 15, 2014 at 5:47 PM, Stephen Rothwell wrote: > Hi all, > > After merging the infiniband tree, today's linux-next build (x86_64 > allmodconfig) failed like this: > > drivers/infiniband/hw/mlx5/main.c: In function 'mlx5_ib_query_device': > drivers/infiniband/hw/mlx5/main.c:248:34: error: > 'MLX5_DEV_CAP_FLAG_ON_DMND_PG' undeclared (first use in this function) > if (dev->mdev->caps.gen.flags & MLX5_DEV_CAP_FLAG_ON_DMND_PG) > ^ > drivers/net/ethernet/mellanox/mlx5/core/fw.c: In function > 'mlx5_query_odp_caps': > drivers/net/ethernet/mellanox/mlx5/core/fw.c:79:30: error: > 'MLX5_DEV_CAP_FLAG_ON_DMND_PG' undeclared (first use in this function) > if (!(dev->caps.gen.flags & MLX5_DEV_CAP_FLAG_ON_DMND_PG)) > ^ > drivers/net/ethernet/mellanox/mlx5/core/eq.c: In function 'mlx5_start_eqs': > drivers/net/ethernet/mellanox/mlx5/core/eq.c:459:28: error: > 'MLX5_DEV_CAP_FLAG_ON_DMND_PG' undeclared (first use in this function) > if (dev->caps.gen.flags & MLX5_DEV_CAP_FLAG_ON_DMND_PG) > ^ > > Really? Code added half way though the merge window not even build > tested? It's not quite as bad as it seems. The infiniband tree itself builds, the problem is the merged tree. The Mellanox guys merged the "cleanup" commit 0c7aac854f52 Author: Eli Cohen Date: Tue Dec 2 02:26:14 2014 net/mlx5_core: Remove unused dev cap enum fields These enumerations are not used so remove them. Signed-off-by: Eli Cohen Signed-off-by: David S. Miller through davem's tree, and then went ahead and used at least MLX5_DEV_CAP_FLAG_ON_DMND_PG (which that patch removes) in patches they merged through my tree. I'll add a partial revert of that patch to my tree to get back the now-used enum values. - R. -- 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] drm for 3.19-rc1
On 16 December 2014 at 11:03, Linus Torvalds wrote: > On Mon, Dec 15, 2014 at 4:48 PM, Dave Airlie wrote: >> >> I'd be inclined to just revert this for now, it is annoying we let >> userspace away with this, but we probably need to find a better >> way to enforce it, since the cat is out of the bag. > > .. why did that commit ever even get far enough to get to me? > > It seems to happen on any reasonably modern Intel graphics - at least > it happens on both my laptop and my desktop. And I'm running > bog-standard F20, so either nobody ever even tested that broken thing, > or nobody bothered to look at the messages to notice it was broken. > Either way, it shows a rather distinct lack of actual testing, > wouldn't you say? > > I really see no excuse for crap like this. If I find obvious bugs > immediately, on my very normal hardware and very normal distribution, > that means that there is something wrong in the development process. > If I was some subtle timing-dependent thing, or I were to be using > eally odd hardware, or I had to do something special to trigger it, > that would be one thing. But that's definitely not the case here. Its a rather straightforward revert, patch should have used an DRM_INFO rather than WARN at this point, people like WARN because automatic tools find them on the Internet and make it easier to track down, but it also freaks everyone out when they see a backtrace, and there are ongoing discussion with the WARN fans to tone them down. especially where things continue fine after them. I think a few people have become immune to i915 WARNs in logs, and we are trying to bring that back a bit. Now you might complain that printing anything in this case is bad, but I've got machines with buckets of deprecated sysctl warnings etc, so the precedent has well been set for at least trying to track down bad userspace behaviour. e.g. I see WARNING! power/level is deprecated; use power/control instead This patch was just over zealous in picking it reporting method. I'd have to ask the i915 folks why it didn't get seen there, I haven't had the bandwidth to test -next on the haswell laptop I have here and I expect this would happen on it fine, but I've been running it on a few amd/nvidia laptops to diversify testing a bit. The patch came from VMware developers and maybe it didn't get into the Intel developers test cycle early enough for them to notice it. Its main job was to find out early if userspace things were breaking the rules, and it looks like yes they were, and its a pity nobody noticed earlier. Dave. -- 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] drm for 3.19-rc1
On Mon, Dec 15, 2014 at 7:48 PM, Dave Airlie wrote:
> On 16 December 2014 at 10:35, Linus Torvalds
> wrote:
>> On Sun, Dec 14, 2014 at 11:17 PM, Dave Airlie wrote:
>>>
>>> i915:
>>> Initial Skylake (SKL) support
>>> gen3/4 reset work
>>> start of dri1/ums removal
>>> infoframe tracking
>>> fixes for lots of things.
>>
>> So I'm not sure how happy I am about this. It seems to work, but on
>> the very first boot I get this:
>>
>> [ cut here ]
>> WARNING: CPU: 1 PID: 1292 at
>> drivers/gpu/drm/i915/i915_gem_execbuffer.c:125
>> eb_lookup_vmas.isra.18+0x333/0x3d0 [i915]()
>> GPU use of dumb buffer is illegal.
>> Modules linked in: ip6t_rpfilter bnep ip6t_REJECT nf_reject_ipv6
>> bluetooth nf_conntrack_ipv6 ...
>>video
>> CPU: 1 PID: 1292 Comm: Xorg Not tainted 3.18.0-09423-g988adfdffdd4 #1
>> Hardware name: /DH87RL, BIOS
>> RLH8710H.86A.0327.2014.0924.1645 09/24/2014
>> Call Trace:
>> dump_stack+0x45/0x57
>> warn_slowpath_common+0x80/0xc0
>> warn_slowpath_fmt+0x41/0x50
>> ? sg_kfree+0x30/0x30
>> eb_lookup_vmas.isra.18+0x333/0x3d0 [i915]
>> i915_gem_do_execbuffer.isra.25+0x50d/0xd80 [i915]
>> ? unlock_page+0x6d/0x80
>> i915_gem_execbuffer2+0xb1/0x2c0 [i915]
>> drm_ioctl+0x19c/0x630 [drm]
>> do_vfs_ioctl+0x2e0/0x4e0
>> ? file_has_perm+0x87/0xa0
>> ? __audit_syscall_entry+0xac/0x100
>> SyS_ioctl+0x81/0xa0
>> ? do_page_fault+0xc/0x10
>> system_call_fastpath+0x12/0x17
>> ---[ end trace cb3c78163212ca1d ]---
>>
>> apparently Introduced by commit 355a70183848 ("drm/gem: Warn on
>> illegal use of the dumb buffer interface v2")
>>
>> The commit says "the next step is to fail".
>>
>> And I want to make it painfully clear that if somebody breaks existing
>> working setups, they don't get to work on the kernel.
>>
>> So get rid of the warning. And get rid of the notion that you can just
>> fail. You can try to fix Xorg, and then come back to this - in a
>> couple of years - when it no longer happens.
>>
>
> I'd be inclined to just revert this for now, it is annoying we let
> userspace away with this, but we probably need to find a better
> way to enforce it, since the cat is out of the bag.
Replace w/ DRM_ERROR? (perhaps ratelimited..)?
It's not a driver error, so much as a warning for userspace that it is
doing something that is not expected to work on all hw / generations,
and it appears to be finding more or less what it was intended to
find, although I'm not sure the stack trace serves much purpose.
BR,
-R
> Dave.
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: build failure after merge of the infiniband tree
Hi all, After merging the infiniband tree, today's linux-next build (x86_64 allmodconfig) failed like this: drivers/infiniband/hw/mlx5/main.c: In function 'mlx5_ib_query_device': drivers/infiniband/hw/mlx5/main.c:248:34: error: 'MLX5_DEV_CAP_FLAG_ON_DMND_PG' undeclared (first use in this function) if (dev->mdev->caps.gen.flags & MLX5_DEV_CAP_FLAG_ON_DMND_PG) ^ drivers/net/ethernet/mellanox/mlx5/core/fw.c: In function 'mlx5_query_odp_caps': drivers/net/ethernet/mellanox/mlx5/core/fw.c:79:30: error: 'MLX5_DEV_CAP_FLAG_ON_DMND_PG' undeclared (first use in this function) if (!(dev->caps.gen.flags & MLX5_DEV_CAP_FLAG_ON_DMND_PG)) ^ drivers/net/ethernet/mellanox/mlx5/core/eq.c: In function 'mlx5_start_eqs': drivers/net/ethernet/mellanox/mlx5/core/eq.c:459:28: error: 'MLX5_DEV_CAP_FLAG_ON_DMND_PG' undeclared (first use in this function) if (dev->caps.gen.flags & MLX5_DEV_CAP_FLAG_ON_DMND_PG) ^ Really? Code added half way though the merge window not even build tested? I have used the infiniband tree from next-20141215 for today. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpFQcrfr24oa.pgp Description: OpenPGP digital signature
Re: [LKP] [userns] BUG: unable to handle kernel NULL pointer dereference at (null)
On Mon, 2014-12-15 at 11:31 -0600, Eric W. Biederman wrote:
> Huang Ying writes:
>
> > FYI, we noticed the below changes on
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git
> > for-testing
> > commit bbea5f5532501fdd67f46442ba7b1122d7ff3123
> > ("userns: Add a knob to disable setgroups on a per user namespace basis")
>
> Thank you.
>
> I am quite puzzled by this failure. There was an similar failure when
> /proc/[pid]/setgroups was read (if I recall correctly). I don't see how
> that change could result at failures during open or failures during
> boot. I added a new file to proc which any reasonable system should
> leave alone. Are you by chance running trinity during boot?
Yes. We are running trinity during boot.
> If the reproducer gave me any clue about which file that was opened or
> which code path this happened on I would be bery interested. If for no
> other reason that to confirm that I have fixed the issue.
This is just boot test, with trinity running after kernel boot.
Fengguang, do you have more information?
Best Regards,
Huang, Ying
> I have rewritten the implementation of /proc/[pid]/setgroups so it is
> simpler and more robust and does not have any errors I can detect.
>
> Thank you very much for picking up my for-testing branch and beating up
> on it.
>
> Eric
--
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/5] Fix Intel IRQ remapping initialization order
On 2014/12/16 3:54, Thomas Gleixner wrote: > On Mon, 15 Dec 2014, Jiang Liu wrote: >> On 2014/12/15 23:13, Joerg Roedel wrote: >>> Hi, >>> >>> here is a patch-set against tip/x86/apic to fix an initialization order >>> problem with the IRQ remapping code. The problem is in the ordering of >>> the irq_remapping_prepare and irq_remapping_supported functions. >>> >>> Currently the call-order is irq_remapping_prepare -> >>> irq_remapping_supported, so that 'prepare' can succeed but 'supported' >>> fails, so that interrupt remapping gets initialized but not enabled. >>> This causes a broken interrupt setup on affected systems (machines with >>> an Intel IOMMU without, or broken, IRQ remapping support). The result >>> are lost interrupts and a non-bootable system. >>> >>> Both functions do checks whether IRQ remapping can be enabled on the >>> machine. The reason for this is that some checks rely on >>> dmar_table_init() and thus have to be done in irq_remapping_prepare(). >>> >>> This patch-set moves all these checks into the irq_remapping_prepare() >>> path with the right ordering and removes the irq_remapping_supported() >>> function and its call-backs. This fixes the initializion order problem >>> and simplifies the exported API from the IOMMU code. >>> >>> Please review. >> Hi Joerg, >> I have posted a patch set for the same purpose at: >> https://lkml.org/lkml/2014/12/10/20 >> Seems we need to combine these two patch sets:) > > Actually you want to combine it also with these patches: > > 326c2bb2c526: iommu/vt-d: Convert allocations to GFP_KERNEL > e9220e591375: iommu/vt-d: Move iommu preparatory allocations to > irq_remap_ops.prepare > e88edbd316ea: iommu, x86: Restructure setup of the irq remapping feature > dd60143c04f2: x86, smpboot: Remove pointless preempt_disable() in > native_smp_prepare_cpus() > > against 3.19 independent of the irqdomain stuff. > > So that would be a clean base to put the rest of the irqdomain and > hotplug stuff on top. > > So the ordering of the patches for 3.20 would become: > >iommu cleanup (init and allocations) >acpi cleanup and parser extensions >ioapic hotplug >irqdomain conversion > > I will route dd60143c04f2 "x86, smpboot: Remove pointless > preempt_disable() in native_smp_prepare_cpus()" into -rc1. I'm going > to do so for a few other cherry-picks from x86/apic. > > So can you please create a combined series, which just deals with the > init cleanup and the allocation conversion (ATOMIC -> GFP) based on > current Linus tree should be fine. Hi Thomas, I will work on that, hope we will have something after Christmas Holiday:) Regards! Gerry > > 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/
Re: [PATCH v6 1/2] Input: add regulator haptic driver
On Tue, Dec 16, 2014 at 10:09:25AM +0900, Jaewon Kim wrote:
> Hi Dmitry,
>
> 2014년 12월 14일 04:56에 Dmitry Torokhov 이(가) 쓴 글:
> >Hi Jaewon,
> >
> >On Fri, Dec 12, 2014 at 07:32:28PM +0900, Jaewon Kim wrote:
...
> >>+static int __maybe_unused regulator_haptic_suspend(struct device *dev)
> >>+{
> >>+ struct platform_device *pdev = to_platform_device(dev);
> >>+ struct regulator_haptic *haptic = platform_get_drvdata(pdev);
> >>+
> >>+ mutex_lock(>mutex);
> >>+ if (haptic->enabled) {
> >>+ regulator_haptic_enable(haptic, false);
> >>+ haptic->suspend_state = true;
> >Why do we only set suspend_state if an effect was playing? I think we
> >should always indicate that the device is suspended so that we do not
> >try to start playing another effect - while it is true that normally
> >effects are played by request from userspace which should be frozen by
> >now, it is theoretically possible to trigger an effect from kernel as
> >well.
>
> This variable name seems to make you confuse.
> I used this variable to restore the old state.
>
> When kernel is entering suspend state while the motor is vibrating,
> I store vibrating state for vibrate again after escape suspend state.
>
>
> I will change variable name to "suspend_restore".
> And prevent to start playing effect when kernel entering suspend state.
You do not need to save if haptic was playing or not - on resume, if
haptic->magnitude != 0 you need to restart playing, otherwise leave it
off.
Thanks.
--
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the infiniband tree with Linus' tree
Hi all,
Today's linux-next merge of the infiniband tree got a conflict in
drivers/infiniband/hw/mlx5/mr.c between commit 479163f46082 ("mlx5:
don't duplicate kvfree()") from Linus' tree and commit 89c925949c1f
("IB/mlx5: Implement on demand paging by adding support for MMU
notifiers") from the infiniband tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/infiniband/hw/mlx5/mr.c
index 5a80dd993761,a2dd7bfc129b..
--- a/drivers/infiniband/hw/mlx5/mr.c
+++ b/drivers/infiniband/hw/mlx5/mr.c
@@@ -856,7 -1009,8 +1012,8 @@@ static struct mlx5_ib_mr *reg_create(st
goto err_2;
}
mr->umem = umem;
+ mr->live = 1;
- mlx5_vfree(in);
+ kvfree(in);
mlx5_ib_dbg(dev, "mkey = 0x%x\n", mr->mmr.key);
pgpxStP5IIXtz.pgp
Description: OpenPGP digital signature
RE: [PATCH v15 00/12] input: cyapa: instruction of cyapa patches
Jeremiah, No problem. :-) Thank you very much for your help and so much time on review these patches. I will fix this issue as soon as possible. Thanks, Dudley > -Original Message- > From: linux-input-ow...@vger.kernel.org > [mailto:linux-input-ow...@vger.kernel.org] On Behalf Of Jeremiah Mahler > Sent: 2014?12?15? 22:10 > To: Dudley Du > Cc: dmitry.torok...@gmail.com; rydb...@euromail.se; ble...@google.com; > David Solda; linux-in...@vger.kernel.org; linux-kernel@vger.kernel.org > Subject: Re: [PATCH v15 00/12] input: cyapa: instruction of cyapa patches > > Dudley, > > On Mon, Dec 15, 2014 at 02:23:11PM +0800, Dudley Du wrote: > > V15 patches have below updates, details of other updates see history list: > > 1) Fix all warning errors of sparse tool when running with "make C=1". > > 2) Change variable name "unique_str" to "product_id" for clearer meanings. > > > > > > This patch series is aimed to re-design the cyapa driver to support > > old gen3 trackpad devices and new gen5 trackpad devices in one > [...] > > The patch set still tests fine on my Acer C720. > > I went through all the patches and found lots of minor things to fix > as you would expect from this large amount of code. > > I hope you don't get discouraged :-) > > -- > - Jeremiah Mahler > -- > To unsubscribe from this list: send the line "unsubscribe linux-input" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html This message and any attachments may contain Cypress (or its subsidiaries) confidential information. If it has been received in error, please advise the sender and immediately delete this message. -- 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 PATCHv3 1/7] devfreq: event: Add new devfreq_event class to provide basic data for devfreq governor
Hi Krzysztof,
On 12/15/2014 11:53 PM, Krzysztof Kozlowski wrote:
> On pią, 2014-12-12 at 17:27 +0900, Chanwoo Choi wrote:
>> This patch add new devfreq_event class for devfreq_event device which provide
>> raw data (e.g., memory bus utilization/GPU utilization). This raw data from
>> devfreq_event data would be used for the governor of devfreq subsystem.
>> - devfreq_event device : Provide raw data for governor of existing devfreq
>> device
>> - devfreq device : Monitor device state and change frequency/voltage
>> of device
>> using the raw data from devfreq_event device
>>
>> The devfreq subsystem support generic DVFS(Dynamic Voltage/Frequency Scaling)
>> for Non-CPU Devices. The devfreq device would dertermine current device state
>> using various governor (e.g., ondemand, performance, powersave). After
>> completed
>> determination of system state, devfreq device would change the
>> frequency/voltage
>> of devfreq device according to the result of governor.
>>
>> But, devfreq governor must need basic data which indicates current device
>> state.
>> Existing devfreq subsystem only consider devfreq device which check current
>> system
>> state and determine proper system state using basic data. There is no
>> subsystem
>> for device providing basic data to devfreq device.
>>
>> The devfreq subsystem must need devfreq_event device(data-provider device)
>> for
>> existing devfreq device. So, this patch add new devfreq_event class for
>> devfreq_event device which read various basic data(e.g, memory bus
>> utilization,
>> GPU utilization) and provide measured data to existing devfreq device through
>> standard APIs of devfreq_event class.
>>
>> The following description explains the feature of two kind of devfreq class:
>> - devfreq class (existing)
>> : devfreq consumer device use raw data from devfreq_event device for
>>determining proper current system state and change voltage/frequency
>>dynamically using various governors.
>>
>> - devfreq_event class (new)
>> : Provide measured raw data to devfreq device for governor
>>
>> Cc: MyungJoo Ham
>> Cc: Kyungmin Park
>> Signed-off-by: Chanwoo Choi
>
> [...]
>
>> +/**
>> + * devfreq_event_get_event() - Get event and total_event from devfreq-event
>> dev.
>> + * @edev: the devfreq-event device
>> + *
>> + * Note that this function get the calculated event data from devfreq-event
>> dev
>> + * after stoping the progress of whole sequence of devfreq-event dev. Return
>> + * current event data and total_event should be stored in second parameter
>> + * (total_event).
>> + */
>> +u64 devfreq_event_get_event(struct devfreq_event_dev *edev, u64
>> *total_event)
>> +{
>
> I think this function should return int (0 for success, negative
> otherwise) and store the "event" under pointer passed as argument.
> Why? Because:
> 1. error conditions are indicated with 'return 0' but should be 'return
> -EINVAL'
> 2. Exynos-ppmu driver returns -EINVAL.
> Checking for error conditions is in such case more complex than it
> should.
In this patchset,
the return value (event) and *total_event of devfreq_event_get_event() should
be used for busy_time/total_time of struct devfreq_dev_status
(include/linux/devfreq.h).
The busy_time/total_time is 'unsigned long' type.
So, I'll modify the prototype of devfreq_event_get_event() as following by
adding
new 'devfreq_event_data' structure.
struct devfreq_event_data {
u64 event;
u64 total_event;
};
int devfreq_event_get_event(struct devfreq_event_edev *edev, struct
devfreq_event_data *edata);
Best Regards,
Chanwoo Choi
--
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 PATCHv3 2/7] devfreq: event: Add the list of supported devfreq-event type
Hi Krzysztof,
On 12/15/2014 11:53 PM, Krzysztof Kozlowski wrote:
> On pią, 2014-12-12 at 17:27 +0900, Chanwoo Choi wrote:
>> This patch adds the list of supported devfreq-event type as following.
>> Each devfreq-event device driver would support the various devfreq-event type
>> for devfreq governor at the same time.
>> - DEVFREQ_EVENT_TYPE_RAW_DATA
>> - DEVFREQ_EVENT_TYPE_UTILIZATION
>> - DEVFREQ_EVENT_TYPE_BANDWIDTH
>> - DEVFREQ_EVENT_TYPE_LATENCY
>>
>> Cc: MyungJoo Ham
>> Cc: Kyungmin Park
>> Signed-off-by: Chanwoo Choi
>> ---
>> drivers/devfreq/devfreq-event.c | 44
>> +
>> include/linux/devfreq.h | 29 ++-
>> 2 files changed, 64 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/devfreq/devfreq-event.c
>> b/drivers/devfreq/devfreq-event.c
>> index eaf59c1..9444f93 100644
>> --- a/drivers/devfreq/devfreq-event.c
>> +++ b/drivers/devfreq/devfreq-event.c
>> @@ -29,6 +29,9 @@
>> #include
>> #include "governor.h"
>>
>> +#define EVENT_TYPE_RAW_DATA_MAX U64_MAX
>> +#define EVENT_TYPE_UTILIZATION_MAX 100
>> +
>> static struct class *devfreq_event_class;
>>
>> /* The list of all devfreq event list */
>> @@ -144,7 +147,8 @@ EXPORT_SYMBOL_GPL(devfreq_event_is_enabled);
>> * Note that this function set the event to the devfreq-event device to
>> start
>> * for getting the event data which could be various event type.
>> */
>> -int devfreq_event_set_event(struct devfreq_event_dev *edev)
>> +int devfreq_event_set_event(struct devfreq_event_dev *edev,
>> +enum devfreq_event_type type)
>> {
>> int ret;
>>
>> @@ -158,7 +162,15 @@ int devfreq_event_set_event(struct devfreq_event_dev
>> *edev)
>> return -EPERM;
>>
>> mutex_lock(>lock);
>> -ret = edev->desc->ops->set_event(edev);
>> +
>> +if ((edev->desc->type & type) == 0) {
>> +dev_err(>dev, "unsupported of devfreq-event type\n");
>> +mutex_unlock(>lock);
>> +return -EINVAL;
>> +}
>> +
>> +ret = edev->desc->ops->set_event(edev, type);
>> +
>> mutex_unlock(>lock);
>>
>> return ret;
>> @@ -174,7 +186,9 @@ EXPORT_SYMBOL_GPL(devfreq_event_set_event);
>> * current event data and total_event should be stored in second parameter
>> * (total_event).
>> */
>> -u64 devfreq_event_get_event(struct devfreq_event_dev *edev, u64
>> *total_event)
>> +u64 devfreq_event_get_event(struct devfreq_event_dev *edev,
>> +enum devfreq_event_type type,
>> +u64 *total_event)
>> {
>> u64 event;
>>
>> @@ -190,7 +204,27 @@ u64 devfreq_event_get_event(struct devfreq_event_dev
>> *edev, u64 *total_event)
>> return 0;
>>
>> mutex_lock(>lock);
>> -event = edev->desc->ops->get_event(edev, total_event);
>> +
>> +if ((edev->desc->type & type) == 0) {
>> +dev_err(>dev, "unsupported of devfreq-event type\n");
>> +return -EINVAL;
>> +}
>> +
>> +event = edev->desc->ops->get_event(edev, type, total_event);
>> +
>> +switch (type) {
>> +case DEVFREQ_EVENT_TYPE_RAW_DATA:
>> +case DEVFREQ_EVENT_TYPE_BANDWIDTH:
>> +case DEVFREQ_EVENT_TYPE_LATENCY:
>> +if ((event > *total_event)
>> +|| ((event > EVENT_TYPE_RAW_DATA_MAX) ||
>> +*total_event > EVENT_TYPE_RAW_DATA_MAX))
>> +event = 0;
>
> missing break here.
My mistake. I'll add it and 'default' case statement.
Best Regards,
Chanwoo Choi
--
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 2/3] mmc: dw_mmc: Use mmc_regulator_set_vqmmc in start_signal_voltage_switch
Doug, On Mon, Dec 15, 2014 at 4:22 PM, Doug Anderson wrote: > We've introduced a new helper in the MMC core: > mmc_regulator_set_vqmmc(). Let's use this in dw_mmc. Using this new > helper has some advantages: > > 1. We get the mmc_regulator_set_vqmmc() behavior of trying to match >VQMMC and VMMC when the signal voltage is 3.3V. This ensures max >compatibility. > > 2. We get rid of a few more warnings when probing unsupported >voltages. > > 3. We get rid of some non-dw_mmc specific code in dw_mmc. > > Signed-off-by: Doug Anderson Reviewed-by: Andrew Bresticker -- 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 v6 1/2] Input: add regulator haptic driver
Hi Dmitry,
2014년 12월 14일 04:56에 Dmitry Torokhov 이(가) 쓴 글:
Hi Jaewon,
On Fri, Dec 12, 2014 at 07:32:28PM +0900, Jaewon Kim wrote:
This patch adds support for haptic driver controlled by
voltage of regulator. And this driver support for
Force Feedback interface from input framework
Signed-off-by: Jaewon Kim
Signed-off-by: Hyunhee Kim
Acked-by: Kyungmin Park
Tested-by: Chanwoo Choi
Reviewed-by: Chanwoo Choi
Reviewed-by: Pankaj Dubey
---
.../devicetree/bindings/input/regulator-haptic.txt | 21 ++
drivers/input/misc/Kconfig | 11 +
drivers/input/misc/Makefile|1 +
drivers/input/misc/regulator-haptic.c | 259
include/linux/input/regulator-haptic.h | 31 +++
5 files changed, 323 insertions(+)
create mode 100644
Documentation/devicetree/bindings/input/regulator-haptic.txt
create mode 100644 drivers/input/misc/regulator-haptic.c
create mode 100644 include/linux/input/regulator-haptic.h
diff --git a/Documentation/devicetree/bindings/input/regulator-haptic.txt
b/Documentation/devicetree/bindings/input/regulator-haptic.txt
new file mode 100644
index 000..3ed1c7e
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/regulator-haptic.txt
@@ -0,0 +1,21 @@
+* Regulator Haptic Device Tree Bindings
+
+Required Properties:
+ - compatible : Should be "regulator-haptic"
+ - haptic-supply : Power supply to the haptic motor.
+ [*] refer Documentation/devicetree/bindings/regulator/regulator.txt
+
+ - max-microvolt : The maximum voltage value supplied to the haptic motor.
+ [The unit of the voltage is a micro]
+
+ - min-microvolt : The minimum voltage value supplied to the haptic motor.
+ [The unit of the voltage is a micro]
+
+Example:
+
+ haptics {
+ compatible = "regulator-haptic";
+ haptic-supply = <_regulator>;
+ max-microvolt = <270>;
+ min-microvolt = <110>;
+ };
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 23297ab..e5e556d 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -394,6 +394,17 @@ config INPUT_CM109
To compile this driver as a module, choose M here: the module will be
called cm109.
+config INPUT_REGULATOR_HAPTIC
+ tristate "regulator haptics support"
+ select INPUT_FF_MEMLESS
+ help
+ This option enables device driver support for the haptic controlled
+ by regulator. This driver supports ff-memless interface
+ from input framework.
+
+ To compile this driver as a module, choose M here: the
+ module will be called regulator-haptic.
+
config INPUT_RETU_PWRBUTTON
tristate "Retu Power button Driver"
depends on MFD_RETU
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index 19c7603..1f135af 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -53,6 +53,7 @@ obj-$(CONFIG_INPUT_PMIC8XXX_PWRKEY) += pmic8xxx-pwrkey.o
obj-$(CONFIG_INPUT_POWERMATE) += powermate.o
obj-$(CONFIG_INPUT_PWM_BEEPER)+= pwm-beeper.o
obj-$(CONFIG_INPUT_RB532_BUTTON) += rb532_button.o
+obj-$(CONFIG_INPUT_REGULATOR_HAPTIC) += regulator-haptic.o
obj-$(CONFIG_INPUT_RETU_PWRBUTTON)+= retu-pwrbutton.o
obj-$(CONFIG_INPUT_GPIO_ROTARY_ENCODER) += rotary_encoder.o
obj-$(CONFIG_INPUT_SGI_BTNS) += sgi_btns.o
diff --git a/drivers/input/misc/regulator-haptic.c
b/drivers/input/misc/regulator-haptic.c
new file mode 100644
index 000..2fa94bc
--- /dev/null
+++ b/drivers/input/misc/regulator-haptic.c
@@ -0,0 +1,259 @@
+/*
+ * Regulator haptic driver
+ *
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ * Author: Jaewon Kim
+ * Author: Hyunhee Kim
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define MAX_MAGNITUDE_SHIFT16
+
+struct regulator_haptic {
+ struct device *dev;
+ struct input_dev *input_dev;
+ struct regulator *regulator;
+
+ struct work_struct work;
+ struct mutex mutex;
+
+ bool enabled;
+ bool suspend_state;
+ unsigned int max_volt;
+ unsigned int min_volt;
+ unsigned int intensity;
+ unsigned int magnitude;
+};
+
+static void regulator_haptic_enable(struct regulator_haptic *haptic, bool
state)
+{
+ int error;
+
+ if (haptic->enabled == state)
+ return;
+
+ if (state)
+ error = regulator_enable(haptic->regulator);
+ else
+ error = regulator_disable(haptic->regulator);
+ if (error) {
Hmm, maybe:
error = state ? regulator_enable(haptic->regulator) :
mmotm 2014-12-15-17-05 uploaded
The mm-of-the-moment snapshot 2014-12-15-17-05 has been uploaded to http://www.ozlabs.org/~akpm/mmotm/ mmotm-readme.txt says README for mm-of-the-moment: http://www.ozlabs.org/~akpm/mmotm/ This is a snapshot of my -mm patch queue. Uploaded at random hopefully more than once a week. You will need quilt to apply these patches to the latest Linus release (3.x or 3.x-rcY). The series file is in broken-out.tar.gz and is duplicated in http://ozlabs.org/~akpm/mmotm/series The file broken-out.tar.gz contains two datestamp files: .DATE and .DATE--mm-dd-hh-mm-ss. Both contain the string -mm-dd-hh-mm-ss, followed by the base kernel version against which this patch series is to be applied. This tree is partially included in linux-next. To see which patches are included in linux-next, consult the `series' file. Only the patches within the #NEXT_PATCHES_START/#NEXT_PATCHES_END markers are included in linux-next. A git tree which contains the memory management portion of this tree is maintained at git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git by Michal Hocko. It contains the patches which are between the "#NEXT_PATCHES_START mm" and "#NEXT_PATCHES_END" markers, from the series file, http://www.ozlabs.org/~akpm/mmotm/series. A full copy of the full kernel tree with the linux-next and mmotm patches already applied is available through git within an hour of the mmotm release. Individual mmotm releases are tagged. The master branch always points to the latest release, so it's constantly rebasing. http://git.cmpxchg.org/?p=linux-mmotm.git;a=summary To develop on top of mmotm git: $ git remote add mmotm git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git $ git remote update mmotm $ git checkout -b topic mmotm/master $ git send-email mmotm/master.. [...] To rebase a branch with older patches to a new mmotm release: $ git remote update mmotm $ git rebase --onto mmotm/master topic The directory http://www.ozlabs.org/~akpm/mmots/ (mm-of-the-second) contains daily snapshots of the -mm tree. It is updated more frequently than mmotm, and is untested. A git copy of this tree is available at http://git.cmpxchg.org/?p=linux-mmots.git;a=summary and use of this tree is similar to http://git.cmpxchg.org/?p=linux-mmotm.git, described above. This mmotm tree contains the following patches against 3.18: (patches marked "*" will be included in linux-next) origin.patch i-need-old-gcc.patch arch-alpha-kernel-systblss-remove-debug-check.patch * remove-unnecessary-is_valid_nodemask.patch * hfsplus-fix-longname-handling.patch * mm-cma-split-cma-reserved-in-dmesg-log.patch * fs-proc-include-cma-info-in-proc-meminfo.patch * lib-show_mem-this-patch-adds-cma-reserved-infromation.patch * exit-fix-race-between-wait_consider_task-and-wait_task_zombie.patch * mm-page_allocc-__alloc_pages_nodemask-dont-alter-arg-gfp_mask.patch * mm-page_allocc-__alloc_pages_nodemask-dont-alter-arg-gfp_mask-fix.patch * input-route-kbd-leds-through-the-generic-leds-layer.patch * fs-ext4-fsyncc-generic_file_fsync-call-based-on-barrier-flag.patch * o2dlm-fix-null-pointer-dereference-in-o2dlm_blocking_ast_wrapper.patch * ocfs2-free-inode-when-i_count-becomes-zero.patch * ocfs2-call-ocfs2_journal_access_di-before-ocfs2_journal_dirty-in-ocfs2_write_end_nolock.patch * ocfs2-avoid-access-invalid-address-when-read-o2dlm-debug-messages.patch * ocfs2-dlm-fix-race-between-dispatched_work-and-dlm_lockres_grab_inflight_worker.patch * ocfs2-reflink-fix-slow-unlink-for-refcounted-file.patch * ocfs2-fix-journal-commit-deadlock.patch * ocfs2-eliminate-the-static-flag-of-some-functions.patch * ocfs2-add-functions-to-add-and-remove-inode-in-orphan-dir.patch * ocfs2-add-orphan-recovery-types-in-ocfs2_recover_orphans.patch * ocfs2-implement-ocfs2_direct_io_write.patch * ocfs2-allocate-blocks-in-ocfs2_direct_io_get_blocks.patch * ocfs2-do-not-fallback-to-buffer-i-o-write-if-appending.patch * ocfs2-do-not-fallback-to-buffer-i-o-write-if-fill-holes.patch * ocfs2-fix-leftover-orphan-entry-caused-by-append-o_direct-write-crash.patch * block-restore-proc-partitions-to-not-display-non-partitionable-removable-devices.patch mm.patch * mm-replace-remap_file_pages-syscall-with-emulation.patch * mm-page_isolation-check-pfn-validity-before-access.patch * mm-page_alloc-embed-oom-killing-naturally-into-allocation-slowpath.patch * mm-fix-invalid-use-of-pfn_valid_within-in-test_pages_in_a_zone.patch * mm-introduce-do_shared_fault-and-drop-do_fault-fix-fix.patch * fs-mpagec-forgotten-write_sync-in-case-of-data-integrity-write.patch * mm-support-madvisemadv_free.patch * mm-support-madvisemadv_free-fix.patch * x86-add-pmd_-for-thp.patch * x86-add-pmd_-for-thp-fix.patch * sparc-add-pmd_-for-thp.patch * sparc-add-pmd_-for-thp-fix.patch * powerpc-add-pmd_-for-thp.patch * arm-add-pmd_mkclean-for-thp.patch * arm64-add-pmd_-for-thp.patch * mm-dont-split-thp-page-when-syscall-is-called.patch *
Re: [git pull] drm for 3.19-rc1
On Mon, Dec 15, 2014 at 4:48 PM, Dave Airlie wrote: > > I'd be inclined to just revert this for now, it is annoying we let > userspace away with this, but we probably need to find a better > way to enforce it, since the cat is out of the bag. .. why did that commit ever even get far enough to get to me? It seems to happen on any reasonably modern Intel graphics - at least it happens on both my laptop and my desktop. And I'm running bog-standard F20, so either nobody ever even tested that broken thing, or nobody bothered to look at the messages to notice it was broken. Either way, it shows a rather distinct lack of actual testing, wouldn't you say? I really see no excuse for crap like this. If I find obvious bugs immediately, on my very normal hardware and very normal distribution, that means that there is something wrong in the development process. If I was some subtle timing-dependent thing, or I were to be using eally odd hardware, or I had to do something special to trigger it, that would be one thing. But that's definitely not the case here. Linus "not happy" Torvalds -- 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] cpufreq: exynos5440: protect call to dev_pm_opp_get_opp_count with RCU lock
dev_pm_opp_get_opp_count() must be called with RCU lock held. Signed-off-by: Dmitry Torokhov --- Again, not tested... drivers/cpufreq/exynos5440-cpufreq.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/cpufreq/exynos5440-cpufreq.c b/drivers/cpufreq/exynos5440-cpufreq.c index 21a90ed..588b9ee 100644 --- a/drivers/cpufreq/exynos5440-cpufreq.c +++ b/drivers/cpufreq/exynos5440-cpufreq.c @@ -373,7 +373,11 @@ static int exynos_cpufreq_probe(struct platform_device *pdev) "failed to init cpufreq table: %d\n", ret); goto err_free_opp; } + + rcu_read_lock(); dvfs_info->freq_count = dev_pm_opp_get_opp_count(dvfs_info->dev); + rcu_read_unlock(); + exynos_sort_descend_freq_table(); if (of_property_read_u32(np, "clock-latency", _info->latency)) -- 2.2.0.rc0.207.ga3a616c -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[alsa][intel-hda] Dell M6800 - Realtek ALC3226 - Headphone Microphone not detected/working
Hello ALSA/Kernel devs, I have a Dell Precision M6800 with latest BIOS here is output from the HDA driver [ 20.783635] snd_hda_intel :00:03.0: enabling device ( -> 0002) [ 20.783804] snd_hda_intel :00:1b.0: irq 34 for MSI/MSI-X [ 20.783911] snd_hda_intel :01:00.1: Handle VGA-switcheroo audio client [ 20.783914] snd_hda_intel :01:00.1: VGA controller is disabled [ 20.783914] snd_hda_intel :01:00.1: Delaying initialization [ 20.785722] snd_hda_intel :00:03.0: irq 35 for MSI/MSI-X [ 20.798841] input: HDA Intel HDMI HDMI/DP,pcm=3 as /devices/pci:00/:00:03.0/sound/card1/input16 [ 20.798881] input: HDA Intel HDMI HDMI/DP,pcm=7 as /devices/pci:00/:00:03.0/sound/card1/input17 [ 20.798914] input: HDA Intel HDMI HDMI/DP,pcm=8 as /devices/pci:00/:00:03.0/sound/card1/input18 [ 20.800208] sound hdaudioC2D0: autoconfig: line_outs=1 (0x16/0x0/0x0/0x0/0x0) type:line [ 20.800209] sound hdaudioC2D0:speaker_outs=1 (0x14/0x0/0x0/0x0/0x0) [ 20.800210] sound hdaudioC2D0:hp_outs=1 (0x15/0x0/0x0/0x0/0x0) [ 20.800210] sound hdaudioC2D0:mono: mono_out=0x0 [ 20.800211] sound hdaudioC2D0:inputs: [ 20.800212] sound hdaudioC2D0: Front Mic=0x18 [ 20.800212] sound hdaudioC2D0: Dock Mic=0x19 [ 20.800213] sound hdaudioC2D0: Headset Mic=0x1a [ 20.800213] sound hdaudioC2D0: Internal Mic=0x12 [ 20.805683] input: HDA Intel PCH Front Mic as /devices/pci:00/:00:1b.0/sound/card2/input19 [ 20.805724] input: HDA Intel PCH Dock Mic as /devices/pci:00/:00:1b.0/sound/card2/input20 [ 20.805756] input: HDA Intel PCH Dock Line Out as /devices/pci:00/:00:1b.0/sound/card2/input21 [ 20.805784] input: HDA Intel PCH Front Headphone as /devices/pci:00/:00:1b.0/sound/card2/input22 [ 78.191344] snd_hda_intel :01:00.1: Start delayed initialization [ 78.195309] snd_hda_intel :01:00.1: irq 36 for MSI/MSI-X [ 78.298530] snd_hda_intel :01:00.1: CORB reset timeout#2, CORBRP = 65535 [ 78.300524] snd_hda_intel :01:00.1: no AFG or MFG node found [ 78.303813] snd_hda_intel :01:00.1: no AFG or MFG node found [ 78.306054] snd_hda_intel :01:00.1: no AFG or MFG node found [ 78.308797] snd_hda_intel :01:00.1: no AFG or MFG node found [ 78.311717] snd_hda_intel :01:00.1: no codecs initialized [ 78.314116] snd_hda_intel :01:00.1: initialization error [ 264.477548] snd_hda_intel :00:1b.0: Unstable LPIB (352800 >= 176400); disabling LPIB delay counting [ 381.091720] snd_hda_intel :01:00.1: enabling device ( -> 0002) [ 381.095346] snd_hda_intel :01:00.1: Handle VGA-switcheroo audio client [ 381.097754] snd_hda_intel :01:00.1: VGA controller is disabled [ 381.100294] snd_hda_intel :01:00.1: Delaying initialization When I have the analog headphones plugged in the headphone speakers work but microphone does not, interestingly in another OS, it also didn't show it functioning. If someone has had similar issues in Linux, let me know, I will also test patches. Thanks, Shawn -- 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: [E1000-devel] [PATCH] ixgbe, ixgbevf: Add new mbox API to enable MC promiscuous mode
> > Subject: Re: [E1000-devel] [PATCH] ixgbe, ixgbevf: Add new mbox API to > > enable MC promiscuous mode > > > > On 11/27/2014 02:39 AM, Hiroshi Shimamoto wrote: > > > From: Hiroshi Shimamoto > > > > > > The limitation of the number of multicast address for VF is not enough > > > for the large scale server with SR-IOV feature. > > > IPv6 requires the multicast MAC address for each IP address to handle > > > the Neighbor Solicitation message. > > > We couldn't assign over 30 IPv6 addresses to a single VF interface. > > > > > > The easy way to solve this is enabling multicast promiscuous mode. > > > It is good to have a functionality to enable multicast promiscuous mode > > > for each VF from VF driver. > > > > > > This patch introduces the new mbox API, IXGBE_VF_SET_MC_PROMISC, to > > > enable/disable multicast promiscuous mode in VF. If multicast promiscuous > > > mode is enabled the VF can receive all multicast packets. > > > > > > With this patch, the ixgbevf driver automatically enable multicast > > > promiscuous mode when the number of multicast addresses is over than 30 > > > if possible. > > > > > > This also bump the API version up to 1.2 to check whether the API, > > > IXGBE_VF_SET_MC_PROMISC is available. > > > > > > Signed-off-by: Hiroshi Shimamoto > > > CC: Choi, Sy Jong > > > Reviewed-by: Hayato Momma > > > > This is a REALLY bad idea unless you plan to limit this to privileged VFs. > > > > I would recommend looking at adding an ndo operation to control this > > feature so that it could be disabled by default in the PF and only > > enabled on the host side if specifically requested. Otherwise the > > Do you mean that PF driver should have the flag to enable or disable per VF > and disallow the request from VF? Could you answer about that? > > > problem is I can easily see this leading security issues as the VFs > > might begin getting access to messages that they aren't supposed to. > > OK, by the way, I think that the current ixgbe and ixgbevf implementation > has already such issue. The guest can add hash entry to receive MAC and it > can get every multicast MAC frame with the current mbox API. > Does your concern come from the easiness of doing that? There is the single MTA per PF, not per VF. VF requests PF to register the hash of MC MAC, then PF set a bit in the MTA and set the flag IXGBE_VMOLR_ROMPE of VF, which enables packets switching to the VF if MC MAC hits the hash entry in the MTA. If VM1 has VF1 which uses MC MAC1 and VM2 has VF2 which uses MC MAC2, both of VM1 and VM2 will receive MC MAC1. VM2 doesn't know why it receives MAC1. In other words, in the current implementation, a VF receives all multicast packets which are registered from other VFs. Because the above reason, I hadn't imagined that enabling MC promiscuous mode increases receiving the MC messages that they aren't supposed to. I think that this patch doesn't change that behavior. thanks, Hiroshi -- 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/3] HID: logitech-hidpp: detect HID++ 2.0 errors too
Devices speaking HID++ 2.0 report a different error code (0xff). Detect
these errors too to avoid 5 second delays when the device reports an
error. Caught by... well, a bug in the QEMU emulation of this receiver.
Renamed fap to rap for HID++ 1.0 errors because it is more logical,
it has no functional difference.
Signed-off-by: Peter Wu
---
drivers/hid/hid-logitech-hidpp.c | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
index 2f420c0..ae23dec 100644
--- a/drivers/hid/hid-logitech-hidpp.c
+++ b/drivers/hid/hid-logitech-hidpp.c
@@ -105,6 +105,7 @@ struct hidpp_device {
};
+/* HID++ 1.0 error codes */
#define HIDPP_ERROR0x8f
#define HIDPP_ERROR_SUCCESS0x00
#define HIDPP_ERROR_INVALID_SUBID 0x01
@@ -119,6 +120,8 @@ struct hidpp_device {
#define HIDPP_ERROR_REQUEST_UNAVAILABLE0x0a
#define HIDPP_ERROR_INVALID_PARAM_VALUE0x0b
#define HIDPP_ERROR_WRONG_PIN_CODE 0x0c
+/* HID++ 2.0 error codes */
+#define HIDPP20_ERROR 0xff
static void hidpp_connect_event(struct hidpp_device *hidpp_dev);
@@ -192,9 +195,16 @@ static int hidpp_send_message_sync(struct hidpp_device
*hidpp,
}
if (response->report_id == REPORT_ID_HIDPP_SHORT &&
- response->fap.feature_index == HIDPP_ERROR) {
+ response->rap.sub_id == HIDPP_ERROR) {
+ ret = response->rap.params[1];
+ dbg_hid("%s:got hidpp error %02X\n", __func__, ret);
+ goto exit;
+ }
+
+ if (response->report_id == REPORT_ID_HIDPP_LONG &&
+ response->fap.feature_index == HIDPP20_ERROR) {
ret = response->fap.params[1];
- dbg_hid("__hidpp_send_report got hidpp error %02X\n", ret);
+ dbg_hid("%s:got hidpp 2.0 error %02X\n", __func__, ret);
goto exit;
}
@@ -271,7 +281,8 @@ static inline bool hidpp_match_answer(struct hidpp_report
*question,
static inline bool hidpp_match_error(struct hidpp_report *question,
struct hidpp_report *answer)
{
- return (answer->fap.feature_index == HIDPP_ERROR) &&
+ return ((answer->rap.sub_id == HIDPP_ERROR) ||
+ (answer->fap.feature_index == HIDPP20_ERROR)) &&
(answer->fap.funcindex_clientid == question->fap.feature_index) &&
(answer->fap.params[0] == question->fap.funcindex_clientid);
}
--
2.1.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/3] HID: logitech-{dj,hidpp}: more reliability fixes
Hi Jiri,
Here are more fixes intended for the 3.19 tree after a review. Two bugfixes.
one which was mentioned in a mail with Benjamin ("avoid unintended
fall-through") and a fix to avoid a possible 5 second delay for HID++ 2.0
errors. I haven't encountered a case where the hidpp module generates a HID++
2.0 error though, so maybe that change can go to 3.20 too if you want to keep
the changeset small.
The third (second) patch adds a check to avoid passing a short report. A similar
fix should probably be written for stable kernels (the code was changed in 3.19,
but the length check was already missing in older kernels).
Kind regards,
Peter
Peter Wu (3):
HID: logitech-hidpp: detect HID++ 2.0 errors too
HID: logitech-{dj,hidpp}: check report length
HID: logitech-hidpp: avoid unintended fall-through
drivers/hid/hid-logitech-dj.c| 16 +++-
drivers/hid/hid-logitech-hidpp.c | 30 --
2 files changed, 39 insertions(+), 7 deletions(-)
--
2.1.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] HID: logitech-{dj,hidpp}: check report length
Malicious USB devices can send bogus reports smaller than the expected
buffer size. Ensure that the length is valid to avoid reading out of
bounds.
For the old WTP, I do not have a HID descriptor so just check for the
minimum length in hidpp_raw_event (this can be changed to an inequality
later).
Signed-off-by: Peter Wu
---
Hi,
If you know that the WTP report (ID 2) has a length of 2, then you can change
"<" to "!=" and remove the paragraph from the commit message.
Kind regards,
Peter
---
drivers/hid/hid-logitech-dj.c| 16 +++-
drivers/hid/hid-logitech-hidpp.c | 12 +---
2 files changed, 24 insertions(+), 4 deletions(-)
diff --git a/drivers/hid/hid-logitech-dj.c b/drivers/hid/hid-logitech-dj.c
index c917ab6..5bc6d80 100644
--- a/drivers/hid/hid-logitech-dj.c
+++ b/drivers/hid/hid-logitech-dj.c
@@ -962,10 +962,24 @@ static int logi_dj_raw_event(struct hid_device *hdev,
switch (data[0]) {
case REPORT_ID_DJ_SHORT:
+ if (size != DJREPORT_SHORT_LENGTH) {
+ dev_err(>dev, "DJ report of bad size (%d)", size);
+ return false;
+ }
return logi_dj_dj_event(hdev, report, data, size);
case REPORT_ID_HIDPP_SHORT:
- /* intentional fallthrough */
+ if (size != HIDPP_REPORT_SHORT_LENGTH) {
+ dev_err(>dev,
+ "Short HID++ report of bad size (%d)", size);
+ return false;
+ }
+ return logi_dj_hidpp_event(hdev, report, data, size);
case REPORT_ID_HIDPP_LONG:
+ if (size != HIDPP_REPORT_LONG_LENGTH) {
+ dev_err(>dev,
+ "Long HID++ report of bad size (%d)", size);
+ return false;
+ }
return logi_dj_hidpp_event(hdev, report, data, size);
}
diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
index ae23dec..2315358 100644
--- a/drivers/hid/hid-logitech-hidpp.c
+++ b/drivers/hid/hid-logitech-hidpp.c
@@ -992,11 +992,17 @@ static int hidpp_raw_event(struct hid_device *hdev,
struct hid_report *report,
return 1;
}
return hidpp_raw_hidpp_event(hidpp, data, size);
+ case 0x02:
+ if (size < 2) {
+ hid_err(hdev, "Received HID report of bad size (%d)",
+ size);
+ return 1;
+ }
+ if (hidpp->quirks & HIDPP_QUIRK_CLASS_WTP)
+ return wtp_raw_event(hdev, data, size);
+ return 1;
}
- if (hidpp->quirks & HIDPP_QUIRK_CLASS_WTP)
- return wtp_raw_event(hdev, data, size);
-
return 0;
}
--
2.1.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] cpufreq: imx6: prorect calls to dev_pm_opp_get_opp_count with RCU lock
dev_pm_opp_get_opp_count() must be called with RCU lock held.
Signed-off-by: Dmitry Torokhov
---
Not tested at all...
drivers/cpufreq/imx6q-cpufreq.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/cpufreq/imx6q-cpufreq.c b/drivers/cpufreq/imx6q-cpufreq.c
index 380a90d..851d4fd 100644
--- a/drivers/cpufreq/imx6q-cpufreq.c
+++ b/drivers/cpufreq/imx6q-cpufreq.c
@@ -200,7 +200,9 @@ static int imx6q_cpufreq_probe(struct platform_device *pdev)
* Just, incase the platform did not supply the OPP
* table, it will try to get it.
*/
+ rcu_read_lock();
num = dev_pm_opp_get_opp_count(cpu_dev);
+ rcu_read_unlock();
if (num < 0) {
ret = of_init_opp_table(cpu_dev);
if (ret < 0) {
@@ -211,7 +213,9 @@ static int imx6q_cpufreq_probe(struct platform_device *pdev)
/* Because we have added the OPPs here, we must free them */
free_opp = true;
+ rcu_read_lock();
num = dev_pm_opp_get_opp_count(cpu_dev);
+ rcu_read_unlock();
if (num < 0) {
ret = num;
dev_err(cpu_dev, "no OPP table is found: %d\n", ret);
--
2.2.0.rc0.207.ga3a616c
--
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] checkpatch giving bogus advice (was staging: goldfish: Fix minor coding style)
On Mon, 2014-12-15 at 14:59 +0300, Dan Carpenter wrote: > I prefer !foo because it is more common in the kernel and I think it's > easier to read but I don't feel strongly about this. Me too. But I do prefer consistency. fyi: for variants of: "if (!foo)" vs "if (foo == NULL)" a little cocci script shows a preference for "if (!foo)" of >5:1 in drivers/net/ (actual: 11557:2145) and a little less (>3:1) in net/ (actual: 10263:3045) $ cat pointer_style.cocci @@ type T; T *a; @@ * a == NULL @@ type T; T *a; @@ * a != NULL @@ type T; T *a; @@ * !a -- 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] HID: logitech-hidpp: avoid unintended fall-through
Add a return to avoid a fall-through. Introduced in commit
57ac86cf52e903d9e3e0f12b34c814cce6b65550 ("HID: logitech-hidpp: add
support of the first Logitech Wireless Touchpad").
Signed-off-by: Peter Wu
---
drivers/hid/hid-logitech-hidpp.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
index 2315358..09eee17 100644
--- a/drivers/hid/hid-logitech-hidpp.c
+++ b/drivers/hid/hid-logitech-hidpp.c
@@ -811,6 +811,7 @@ static int wtp_raw_event(struct hid_device *hdev, u8 *data,
int size)
input_event(wd->input, EV_KEY, BTN_RIGHT,
!!(data[1] & 0x02));
input_sync(wd->input);
+ return 0;
} else {
if (size < 21)
return 1;
--
2.1.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: [RFC PATCH] sg3_utils: Added hybrid information log utility
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 11/25/2014 02:13 PM, Akers, Jason B wrote: > Hi Phillip, It turns out that this patch was based on an old > github repository that doesn't appear to be updated. Doug Gilbert > reached out after the initial RFC and directed us to his page > (http://sg.danny.cz/sg/) where he has updated sg3_utils code. > > As we continue to work through the feedback from our SSHD kernel > patches, I'm going to follow up with Doug again on sg3_utils. So is there a set of patches that applies to a release from that web site? Also is the source only released as tarballs? There is no source repo? -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCgAGBQJUj4DKAAoJENRVrw2cjl5RwEwH/147w+N+z9r3J70AQrLdXgtN mRF2VLEK/v0l7rpnnyiKyL7Trjc3/YXY9tLf3feC225l9UL6K73moLKGWMI+iRU2 xvCWIJKHQyf8E/j6qFqid0G9V/IQNG9vXAZSEmrTcvT5NaEJ0U3kSCKe5w9xEYEE 6SLYTF+FRHkXceloFvW/8PAwj/2K4g/KsZShIS07kdzAh+fIoZM6qQP3XbEK5v1T x+zuFZtIVzVglQmQWF6wAn5pBjHGNLCA1Yw1+Lx3tuJCoVv1B5ze1k0FOnWu6xOQ bjeOQ0cgZOjYGjgywhoJn5hgKxOhfXsNsIhSSqA/SNky4vMOV5gRXKjA2WgHu6g= =7jVR -END PGP SIGNATURE- -- 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] drm for 3.19-rc1
On 16 December 2014 at 10:35, Linus Torvalds
wrote:
> On Sun, Dec 14, 2014 at 11:17 PM, Dave Airlie wrote:
>>
>> i915:
>> Initial Skylake (SKL) support
>> gen3/4 reset work
>> start of dri1/ums removal
>> infoframe tracking
>> fixes for lots of things.
>
> So I'm not sure how happy I am about this. It seems to work, but on
> the very first boot I get this:
>
> [ cut here ]
> WARNING: CPU: 1 PID: 1292 at
> drivers/gpu/drm/i915/i915_gem_execbuffer.c:125
> eb_lookup_vmas.isra.18+0x333/0x3d0 [i915]()
> GPU use of dumb buffer is illegal.
> Modules linked in: ip6t_rpfilter bnep ip6t_REJECT nf_reject_ipv6
> bluetooth nf_conntrack_ipv6 ...
>video
> CPU: 1 PID: 1292 Comm: Xorg Not tainted 3.18.0-09423-g988adfdffdd4 #1
> Hardware name: /DH87RL, BIOS
> RLH8710H.86A.0327.2014.0924.1645 09/24/2014
> Call Trace:
> dump_stack+0x45/0x57
> warn_slowpath_common+0x80/0xc0
> warn_slowpath_fmt+0x41/0x50
> ? sg_kfree+0x30/0x30
> eb_lookup_vmas.isra.18+0x333/0x3d0 [i915]
> i915_gem_do_execbuffer.isra.25+0x50d/0xd80 [i915]
> ? unlock_page+0x6d/0x80
> i915_gem_execbuffer2+0xb1/0x2c0 [i915]
> drm_ioctl+0x19c/0x630 [drm]
> do_vfs_ioctl+0x2e0/0x4e0
> ? file_has_perm+0x87/0xa0
> ? __audit_syscall_entry+0xac/0x100
> SyS_ioctl+0x81/0xa0
> ? do_page_fault+0xc/0x10
> system_call_fastpath+0x12/0x17
> ---[ end trace cb3c78163212ca1d ]---
>
> apparently Introduced by commit 355a70183848 ("drm/gem: Warn on
> illegal use of the dumb buffer interface v2")
>
> The commit says "the next step is to fail".
>
> And I want to make it painfully clear that if somebody breaks existing
> working setups, they don't get to work on the kernel.
>
> So get rid of the warning. And get rid of the notion that you can just
> fail. You can try to fix Xorg, and then come back to this - in a
> couple of years - when it no longer happens.
>
I'd be inclined to just revert this for now, it is annoying we let
userspace away with this, but we probably need to find a better
way to enforce it, since the cat is out of the bag.
Dave.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] powercap/rapl: add ids for future xeon cpus
On Mon, Dec 15, 2014 at 10:14:15AM -0800, Jacob Pan wrote:
> Enable RAPL driver on Xeon cpu id 0x56.
>
> Signed-off-by: Jacob Pan
> ---
> drivers/powercap/intel_rapl.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/powercap/intel_rapl.c b/drivers/powercap/intel_rapl.c
> index c71443c..ee00ffb 100644
> --- a/drivers/powercap/intel_rapl.c
> +++ b/drivers/powercap/intel_rapl.c
> @@ -1041,6 +1041,7 @@ static const struct x86_cpu_id rapl_ids[] = {
> RAPL_CPU(0x45, rapl_defaults_core),/* Haswell ULT */
> RAPL_CPU(0x4C, rapl_defaults_atom),/* Braswell */
> RAPL_CPU(0x4A, rapl_defaults_atom),/* Tangier */
> + RAPL_CPU(0x56, rapl_defaults_atom),/* Future Xeon */
Is rapl_defaults_atom correct, or should this be rapl_defaults_core ?
Guenter
> RAPL_CPU(0x5A, rapl_defaults_atom),/* Annidale */
> {}
> };
> --
> 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/
>
>
--
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/4] mmc: sunxi: Correcting SDXC_HARDWARE_RESET bit
Fixing the register name in sunxi_mmc_reset_host since the SDXC_HARDWARE_RESET
bit
is actually located within REG_GCTRL and not REG_CMDR as it was pointed out by
Allwinner.
Signed-off-by: David Lanzendörfer
Reported-by: 李想
---
drivers/mmc/host/sunxi-mmc.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
index 25ba321..50bd3d2 100644
--- a/drivers/mmc/host/sunxi-mmc.c
+++ b/drivers/mmc/host/sunxi-mmc.c
@@ -252,7 +252,7 @@ static int sunxi_mmc_reset_host(struct sunxi_mmc_host *host)
unsigned long expire = jiffies + msecs_to_jiffies(250);
u32 rval;
- mmc_writel(host, REG_CMDR, SDXC_HARDWARE_RESET);
+ mmc_writel(host, REG_GCTRL, SDXC_HARDWARE_RESET);
do {
rval = mmc_readl(host, REG_GCTRL);
} while (time_before(jiffies, expire) && (rval & SDXC_HARDWARE_RESET));
--
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] mmc: sunxi: Reset behavior fix
When there is only one DES available the DMA performs a FIFO reset and waits until the reinitialization has been completed. Disabling the SDXC_IDMAC_DES0_DIC bit prevents the DMA from sending an interrupt after it has finished this reinitialization. The flags SDXC_IDMAC_DES0_FD and SDXC_IDMAC_DES0_LD are both required in order to use the controller with more than one DES. Signed-off-by: David Lanzendörfer Reported-by: 李想 --- drivers/mmc/host/sunxi-mmc.c | 12 +++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c index 50bd3d2..5331c88 100644 --- a/drivers/mmc/host/sunxi-mmc.c +++ b/drivers/mmc/host/sunxi-mmc.c @@ -310,7 +310,17 @@ static void sunxi_mmc_init_idma_des(struct sunxi_mmc_host *host, } pdes[0].config |= SDXC_IDMAC_DES0_FD; - pdes[i - 1].config = SDXC_IDMAC_DES0_OWN | SDXC_IDMAC_DES0_LD; + + /* +* When there is only one DES available the DMA performs a FIFO reset and waits +* until the reinitialization has been completed. +* Disabling the SDXC_IDMAC_DES0_DIC bit prevents the DMA from sending an interrupt +* after it has finished this reinitialization. +*/ + pdes[i - 1].config = SDXC_IDMAC_DES0_OWN; + pdes[i - 1].config |= SDXC_IDMAC_DES0_FD; + pdes[i - 1].config |= SDXC_IDMAC_DES0_LD; + pdes[i - 1].config &= ~SDXC_IDMAC_DES0_DIC; /* * Avoid the io-store starting the idmac hitting io-mem before the -- 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/4] mmc: sunxi: Lock fix
1) Adding a comment in order to clarify the choice of the locks within
sunxi_mmc_handle_manual_stop
2) As 李想 has pointed out the wait_dma variable was not accessed within the
spin lock
block in sunxi_mmc_request and so (even if it should never happend) it
would have
theoretically been possible that some other function would access the
variable
at the same time as the function.
This has been changed now and the function is using local variables
outside the lock
and copys the value over during the lock phase.
Signed-off-by: David Lanzendörfer
Reported-by: 李想
---
drivers/mmc/host/sunxi-mmc.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
index 15cb8b7..25ba321 100644
--- a/drivers/mmc/host/sunxi-mmc.c
+++ b/drivers/mmc/host/sunxi-mmc.c
@@ -570,6 +570,15 @@ static irqreturn_t sunxi_mmc_handle_manual_stop(int irq,
void *dev_id)
}
dev_err(mmc_dev(host->mmc), "data error, sending stop command\n");
+
+ /*
+* We will never have more than one outstanding request,
+* and we do not complete the request until after
+* we've cleared host->manual_stop_mrq so we do not need to
+* spin lock this function.
+* Additionally we have wait states within this function
+* so having it in a lock is a very bad idea.
+*/
sunxi_mmc_send_manual_stop(host, mrq);
spin_lock_irqsave(>lock, iflags);
@@ -766,6 +775,7 @@ static void sunxi_mmc_request(struct mmc_host *mmc, struct
mmc_request *mrq)
unsigned long iflags;
u32 imask = SDXC_INTERRUPT_ERROR_BIT;
u32 cmd_val = SDXC_START | (cmd->opcode & 0x3f);
+ bool wait_dma = host->wait_dma;
int ret;
/* Check for set_ios errors (should never happen) */
@@ -816,7 +826,7 @@ static void sunxi_mmc_request(struct mmc_host *mmc, struct
mmc_request *mrq)
if (cmd->data->flags & MMC_DATA_WRITE)
cmd_val |= SDXC_WRITE;
else
- host->wait_dma = true;
+ wait_dma = true;
} else {
imask |= SDXC_COMMAND_DONE;
}
@@ -850,6 +860,7 @@ static void sunxi_mmc_request(struct mmc_host *mmc, struct
mmc_request *mrq)
}
host->mrq = mrq;
+ host->wait_dma = wait_dma;
mmc_writel(host, REG_IMASK, host->sdio_imask | imask);
mmc_writel(host, REG_CARG, cmd->arg);
mmc_writel(host, REG_CMDR, cmd_val);
--
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] mmc: sunxi: Removing unused code
Removing a relict from reverse engineering of the Android driver code in
sunxi_mmc_clk_set_rate.
Signed-off-by: David Lanzendörfer
Reported-by: 李想
---
drivers/mmc/host/sunxi-mmc.c | 10 +-
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
index 5331c88..f73a569 100644
--- a/drivers/mmc/host/sunxi-mmc.c
+++ b/drivers/mmc/host/sunxi-mmc.c
@@ -635,7 +635,7 @@ static int sunxi_mmc_oclk_onoff(struct sunxi_mmc_host
*host, u32 oclk_en)
static int sunxi_mmc_clk_set_rate(struct sunxi_mmc_host *host,
struct mmc_ios *ios)
{
- u32 rate, oclk_dly, rval, sclk_dly, src_clk;
+ u32 rate, oclk_dly, rval, sclk_dly;
int ret;
rate = clk_round_rate(host->clk_mmc, ios->clock);
@@ -680,14 +680,6 @@ static int sunxi_mmc_clk_set_rate(struct sunxi_mmc_host
*host,
sclk_dly = 4;
}
- src_clk = clk_get_rate(clk_get_parent(host->clk_mmc));
- if (src_clk >= 3 && src_clk <= 4) {
- if (oclk_dly)
- oclk_dly--;
- if (sclk_dly)
- sclk_dly--;
- }
-
clk_sunxi_mmc_phase_control(host->clk_mmc, sclk_dly, oclk_dly);
return sunxi_mmc_oclk_onoff(host, 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 0/4] mmc: sunxi: General fixup
Hello This patchset was inspired questions from 李想 of Allwinner and incorporates as well suggestions from Hans related to spin locks. For example have not all attributes of the shared host object been protected by the spin lock, this has been changed. Also some register names and reset behavior have been fixed now. And a minor cleanup happened at the clock frequecy setting, since there has been a piece of left over code which has been there because it was in the Android driver and we just adapted it because we didn't have proper documentation about the timing of the module. Looking forward to your feedback Cheers David --- David Lanzendörfer (4): mmc: sunxi: Lock fix mmc: sunxi: Correcting SDXC_HARDWARE_RESET bit mmc: sunxi: Reset behavior fix mmc: sunxi: Removing unused code drivers/mmc/host/sunxi-mmc.c | 37 + 1 file changed, 25 insertions(+), 12 deletions(-) -- Signature -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] mm/zsmalloc: adjust order of functions
Hello Ganesh,
On Sat, Dec 13, 2014 at 09:43:23PM +0800, Ganesh Mahendran wrote:
> Currently functions in zsmalloc.c does not arranged in a readable
> and reasonable sequence. With the more and more functions added,
> we may meet below inconvenience. For example:
>
> Current functions:
> void zs_init()
> {
> }
>
> static void get_maxobj_per_zspage()
> {
> }
>
> Then I want to add a func_1() which is called from zs_init(), and this new
> added
> function func_1() will used get_maxobj_per_zspage() which is defined below
> zs_init().
>
> void func_1()
> {
> get_maxobj_per_zspage()
> }
>
> void zs_init()
> {
> func_1()
> }
>
> static void get_maxobj_per_zspage()
> {
> }
>
> This will cause compiling issue. So we must add a declaration:
> static void get_maxobj_per_zspage();
> before func_1() if we do not put get_maxobj_per_zspage() before func_1().
Yes, I suffered from that when I made compaction but was not sure
it's it was obviously wrong.
Stupid question:
What's the problem if we should put function declaration on top of
source code?
>
> In addition, puting module_[init|exit] functions at the bottom of the file
> conforms to our habit.
Normally, we do but without any strong reason, I don't want to rub git-blame
by clean up patches.
In summary, I like this patch but don't like to churn git-blame by clean-up
patchset without strong reason so I need something I am sure.
>
> So, this patch ajusts function sequence as:
> /* helper functions */
> ...
> obj_location_to_handle()
> ...
>
> /* Some exported functions */
> ...
>
> zs_map_object()
> zs_unmap_object()
>
> zs_malloc()
> zs_free()
>
> zs_init()
> zs_exit()
>
> Signed-off-by: Ganesh Mahendran
> ---
> mm/zsmalloc.c | 374
> -
> 1 file changed, 187 insertions(+), 187 deletions(-)
>
> diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c
> index 4d0a063..b724039 100644
> --- a/mm/zsmalloc.c
> +++ b/mm/zsmalloc.c
> @@ -884,19 +884,6 @@ static struct notifier_block zs_cpu_nb = {
> .notifier_call = zs_cpu_notifier
> };
>
> -static void zs_unregister_cpu_notifier(void)
> -{
> - int cpu;
> -
> - cpu_notifier_register_begin();
> -
> - for_each_online_cpu(cpu)
> - zs_cpu_notifier(NULL, CPU_DEAD, (void *)(long)cpu);
> - __unregister_cpu_notifier(_cpu_nb);
> -
> - cpu_notifier_register_done();
> -}
> -
> static int zs_register_cpu_notifier(void)
> {
> int cpu, uninitialized_var(ret);
> @@ -914,40 +901,28 @@ static int zs_register_cpu_notifier(void)
> return notifier_to_errno(ret);
> }
>
> -static void init_zs_size_classes(void)
> +static void zs_unregister_cpu_notifier(void)
> {
> - int nr;
> + int cpu;
>
> - nr = (ZS_MAX_ALLOC_SIZE - ZS_MIN_ALLOC_SIZE) / ZS_SIZE_CLASS_DELTA + 1;
> - if ((ZS_MAX_ALLOC_SIZE - ZS_MIN_ALLOC_SIZE) % ZS_SIZE_CLASS_DELTA)
> - nr += 1;
> + cpu_notifier_register_begin();
>
> - zs_size_classes = nr;
> -}
> + for_each_online_cpu(cpu)
> + zs_cpu_notifier(NULL, CPU_DEAD, (void *)(long)cpu);
> + __unregister_cpu_notifier(_cpu_nb);
>
> -static void __exit zs_exit(void)
> -{
> -#ifdef CONFIG_ZPOOL
> - zpool_unregister_driver(_zpool_driver);
> -#endif
> - zs_unregister_cpu_notifier();
> + cpu_notifier_register_done();
> }
>
> -static int __init zs_init(void)
> +static void init_zs_size_classes(void)
> {
> - int ret = zs_register_cpu_notifier();
> -
> - if (ret) {
> - zs_unregister_cpu_notifier();
> - return ret;
> - }
> + int nr;
>
> - init_zs_size_classes();
> + nr = (ZS_MAX_ALLOC_SIZE - ZS_MIN_ALLOC_SIZE) / ZS_SIZE_CLASS_DELTA + 1;
> + if ((ZS_MAX_ALLOC_SIZE - ZS_MIN_ALLOC_SIZE) % ZS_SIZE_CLASS_DELTA)
> + nr += 1;
>
> -#ifdef CONFIG_ZPOOL
> - zpool_register_driver(_zpool_driver);
> -#endif
> - return 0;
> + zs_size_classes = nr;
> }
>
> static unsigned int get_maxobj_per_zspage(int size, int pages_per_zspage)
> @@ -967,113 +942,101 @@ static bool can_merge(struct size_class *prev, int
> size, int pages_per_zspage)
> return true;
> }
>
> +unsigned long zs_get_total_pages(struct zs_pool *pool)
> +{
> + return atomic_long_read(>pages_allocated);
> +}
> +EXPORT_SYMBOL_GPL(zs_get_total_pages);
> +
> /**
> - * zs_create_pool - Creates an allocation pool to work from.
> - * @flags: allocation flags used to allocate pool metadata
> + * zs_map_object - get address of allocated object from handle.
> + * @pool: pool from which the object was allocated
> + * @handle: handle returned from zs_malloc
> *
> - * This function must be called before anything when using
> - * the zsmalloc allocator.
> + * Before using an object allocated from zs_malloc, it must be mapped using
> + * this function. When done with the object, it must be
[PATCH] PM / OPP: add some lockdep annotations
Certain OPP APIs need to be called under RCU lock; let's add a few
rcu_lockdep_assert() calls to warn about potential misuse.
Signed-off-by: Dmitry Torokhov
---
drivers/base/power/opp.c | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/base/power/opp.c b/drivers/base/power/opp.c
index d24dd614a..852eebf 100644
--- a/drivers/base/power/opp.c
+++ b/drivers/base/power/opp.c
@@ -218,6 +218,11 @@ int dev_pm_opp_get_opp_count(struct device *dev)
struct dev_pm_opp *temp_opp;
int count = 0;
+ rcu_lockdep_assert(rcu_read_lock_held() ||
+ lockdep_is_held(_opp_list_lock),
+ "dev_pm_opp_get_opp_count() needs rcu_read_lock() "
+ "or dev_opp_list_lock protection");
+
dev_opp = find_device_opp(dev);
if (IS_ERR(dev_opp)) {
int r = PTR_ERR(dev_opp);
@@ -267,6 +272,11 @@ struct dev_pm_opp *dev_pm_opp_find_freq_exact(struct
device *dev,
struct device_opp *dev_opp;
struct dev_pm_opp *temp_opp, *opp = ERR_PTR(-ERANGE);
+ rcu_lockdep_assert(rcu_read_lock_held() ||
+ lockdep_is_held(_opp_list_lock),
+ "dev_pm_opp_find_freq_exact() needs rcu_read_lock() "
+ "or dev_opp_list_lock protection");
+
dev_opp = find_device_opp(dev);
if (IS_ERR(dev_opp)) {
int r = PTR_ERR(dev_opp);
@@ -313,6 +323,11 @@ struct dev_pm_opp *dev_pm_opp_find_freq_ceil(struct device
*dev,
struct device_opp *dev_opp;
struct dev_pm_opp *temp_opp, *opp = ERR_PTR(-ERANGE);
+ rcu_lockdep_assert(rcu_read_lock_held() ||
+ lockdep_is_held(_opp_list_lock),
+ "dev_pm_opp_find_freq_ceil() needs rcu_read_lock() "
+ "or dev_opp_list_lock protection");
+
if (!dev || !freq) {
dev_err(dev, "%s: Invalid argument freq=%p\n", __func__, freq);
return ERR_PTR(-EINVAL);
@@ -361,6 +376,11 @@ struct dev_pm_opp *dev_pm_opp_find_freq_floor(struct
device *dev,
struct device_opp *dev_opp;
struct dev_pm_opp *temp_opp, *opp = ERR_PTR(-ERANGE);
+ rcu_lockdep_assert(rcu_read_lock_held() ||
+ lockdep_is_held(_opp_list_lock),
+ "dev_pm_opp_find_freq_floor() needs rcu_read_lock() "
+ "or dev_opp_list_lock protection");
+
if (!dev || !freq) {
dev_err(dev, "%s: Invalid argument freq=%p\n", __func__, freq);
return ERR_PTR(-EINVAL);
--
2.2.0.rc0.207.ga3a616c
--
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [git pull] drm for 3.19-rc1
On Sun, Dec 14, 2014 at 11:17 PM, Dave Airlie wrote:
>
> i915:
> Initial Skylake (SKL) support
> gen3/4 reset work
> start of dri1/ums removal
> infoframe tracking
> fixes for lots of things.
So I'm not sure how happy I am about this. It seems to work, but on
the very first boot I get this:
[ cut here ]
WARNING: CPU: 1 PID: 1292 at
drivers/gpu/drm/i915/i915_gem_execbuffer.c:125
eb_lookup_vmas.isra.18+0x333/0x3d0 [i915]()
GPU use of dumb buffer is illegal.
Modules linked in: ip6t_rpfilter bnep ip6t_REJECT nf_reject_ipv6
bluetooth nf_conntrack_ipv6 ...
video
CPU: 1 PID: 1292 Comm: Xorg Not tainted 3.18.0-09423-g988adfdffdd4 #1
Hardware name: /DH87RL, BIOS
RLH8710H.86A.0327.2014.0924.1645 09/24/2014
Call Trace:
dump_stack+0x45/0x57
warn_slowpath_common+0x80/0xc0
warn_slowpath_fmt+0x41/0x50
? sg_kfree+0x30/0x30
eb_lookup_vmas.isra.18+0x333/0x3d0 [i915]
i915_gem_do_execbuffer.isra.25+0x50d/0xd80 [i915]
? unlock_page+0x6d/0x80
i915_gem_execbuffer2+0xb1/0x2c0 [i915]
drm_ioctl+0x19c/0x630 [drm]
do_vfs_ioctl+0x2e0/0x4e0
? file_has_perm+0x87/0xa0
? __audit_syscall_entry+0xac/0x100
SyS_ioctl+0x81/0xa0
? do_page_fault+0xc/0x10
system_call_fastpath+0x12/0x17
---[ end trace cb3c78163212ca1d ]---
apparently Introduced by commit 355a70183848 ("drm/gem: Warn on
illegal use of the dumb buffer interface v2")
The commit says "the next step is to fail".
And I want to make it painfully clear that if somebody breaks existing
working setups, they don't get to work on the kernel.
So get rid of the warning. And get rid of the notion that you can just
fail. You can try to fix Xorg, and then come back to this - in a
couple of years - when it no longer happens.
Linus
--
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] VERIFY_OCTAL_PERMISSIONS: Move to where it belongs
Hi George, On 15 Dec 2014 19:14:53 -0500 "George Spelvin" wrote: > > Stephen Rothwell wrote: > > Please do *not* mix changes up like this. Split this out into a > > separate patch, please (1 logical change per patch). > > Um... I thought I was doing that. More particularly, the task of > untangling header file dependencies eseemed sufficiently cohesive > that it could be considered one logical change. Well, given the subject of the commit, I expected a simple change that just did the move (and any immediately associated include changes). You then said "Some other extraneous header files pruned while I was at it" and that part I would expect to be in a separate patch. > It was one round of thinking and analysis about what declarations the > affected files depend on. Which is separate from what VERIFY_OCTAL_PERMISSIONS() requires. > Although syntactically possible, given the small size of the change (I > deleted a total of 5 #includes, 2 from moduleparam.h and 3 from sysfs.h), > it didn't seem worth breaking it up further. > > > And testing only > > on x86_64 is not "sure" when talking about header file pruning (but at > > least you did the "all" configs). > > Well, the first round was reading and understanding the headers; the > compile was just to make sure. Understood, it was more a "actually changing architectures was more likely to show breakage than building lots of stuff". I guess I see more breakage from pruning includes than most people since I build for multiple architectures more than most. > The files I was messing with (moduleparam.h and sysfs.h) don't have a > lot of architecture-specificness within them. The main danger is that > they're used in a zillion places and some caller might depend on the > over-inclusion. The problem is not the direct includes and direct architecture depenedencies, but the fact that lost of stuff ends up include asm/ include files at some point in the chain and that affects the set of files implicitly included. X86 seems to implicitly include more than some other architectures. > If my haste made me judge wrong, I apologize. Was I very wrong, or > just a bit over the line? Probably just a bit over the line. The advantage of the split would be that when it hits Andrew's tree and then breaks linux-next (for me), I can pick on a smaller patch to get rid of/correct. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgp2zlIyro0pO.pgp Description: OpenPGP digital signature
Re: [PATCH v2 2/4] PCI: iproc: Add Broadcom iProc PCIe driver
On 12/15/2014 1:37 PM, Arnd Bergmann wrote: On Monday 15 December 2014 11:16:31 Ray Jui wrote: On 12/12/2014 9:21 AM, Arnd Bergmann wrote: On Friday 12 December 2014 09:08:48 Ray Jui wrote: One way to solve this would be by turning the driver into a library the same way as the pcie-dw driver, and have separate front-ends for it for platform_device and bcma_device. I'm fine with this solution, i.e., to introduce a common pcie-iproc core driver (just like pcie-designware) and have different front-ends depending on the device/bus type. If we end up deciding to go with this solution, I need to discuss with Hauke to come up with a plan to collaborate. Ok But before we choose to go with that route, may I ask, what is the purpose of tying a PCIe host driver to BCMA? What benefit does BCMA give us? If we have a generic platform based PCIe driver that can work on all iProc SoCs + BCM4708 and BCM5301X with all HW specific configurations taken care of by device tree, why do we still need to use BCMA? I thought all a BCMA device here does is to auto-instantiate based on some register readings? Basically, DT is a hack that we only need for nondiscoverable buses. As BCMA is (mostly) discoverable, we should use that, just like we do for things like PCI and USB. There are clearly some limitations to BCMA as well, e.g. on bcm4708 we don't have proper IRQ numbers in the device list and we need to work around that using DT, but overall it still seems to have more upsides than downsides to use it. It's also good to point other SoC makers to Broadcom as a good example for how to do things they claim are impossible to do. Arnd Okay. Fair enough. Let's go with your proposal to create a generic driver pcie-iproc to be used by both bcma and platform bus. I'll initiate another email thread with you, Hauke, Scott, and me. We can discuss how to collaborate on that email thread. Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 2/3] mmc: dw_mmc: Use mmc_regulator_set_vqmmc in start_signal_voltage_switch
We've introduced a new helper in the MMC core:
mmc_regulator_set_vqmmc(). Let's use this in dw_mmc. Using this new
helper has some advantages:
1. We get the mmc_regulator_set_vqmmc() behavior of trying to match
VQMMC and VMMC when the signal voltage is 3.3V. This ensures max
compatibility.
2. We get rid of a few more warnings when probing unsupported
voltages.
3. We get rid of some non-dw_mmc specific code in dw_mmc.
Signed-off-by: Doug Anderson
---
Changes in v3:
- Continue to check for errors if VQMMC is not an error as per Andrew.
Changes in v2: None
drivers/mmc/host/dw_mmc.c | 17 ++---
1 file changed, 6 insertions(+), 11 deletions(-)
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 67c0451..b3993d4 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -1160,7 +1160,6 @@ static int dw_mci_switch_voltage(struct mmc_host *mmc,
struct mmc_ios *ios)
struct dw_mci *host = slot->host;
u32 uhs;
u32 v18 = SDMMC_UHS_18V << slot->id;
- int min_uv, max_uv;
int ret;
/*
@@ -1169,22 +1168,18 @@ static int dw_mci_switch_voltage(struct mmc_host *mmc,
struct mmc_ios *ios)
* does no harm but you need to set the regulator directly. Try both.
*/
uhs = mci_readl(host, UHS_REG);
- if (ios->signal_voltage == MMC_SIGNAL_VOLTAGE_330) {
- min_uv = 270;
- max_uv = 360;
+ if (ios->signal_voltage == MMC_SIGNAL_VOLTAGE_330)
uhs &= ~v18;
- } else {
- min_uv = 170;
- max_uv = 195;
+ else
uhs |= v18;
- }
+
if (!IS_ERR(mmc->supply.vqmmc)) {
- ret = regulator_set_voltage(mmc->supply.vqmmc, min_uv, max_uv);
+ ret = mmc_regulator_set_vqmmc(mmc, ios);
if (ret) {
dev_dbg(>class_dev,
-"Regulator set error %d: %d - %d\n",
-ret, min_uv, max_uv);
+"Regulator set error %d - %s V\n",
+ret, uhs & v18 ? "1.8" : "3.3");
return ret;
}
}
--
2.2.0.rc0.207.ga3a616c
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 1/3] mmc: core: Add mmc_regulator_set_vqmmc()
This adds logic to the MMC core to set VQMMC. This is expected to be
called by MMC drivers like dw_mmc as part of (or instead of) their
start_signal_voltage_switch() callback.
A few notes:
* When setting the signal voltage to 3.3V we do our best to make VQMMC
and VMMC match. It's been reported that this makes some old cards
happy since they were tested back in the day before UHS when VQMMC
and VMMC were provided by the same regulator. A nice side effect of
this is that we don't end up on the hairy edge of VQMMC (2.7V),
which some EEs claim is a little too close to the minimum for
comfort.
* When setting the signal voltage to 1.8V or 1.2V we aim for that
specific voltage instead of picking the lowest one in the range.
* We very purposely don't print errors in mmc_regulator_set_vqmmc().
There are cases where the MMC core will try several different
voltages and we don't want to pollute the logs.
Signed-off-by: Doug Anderson
Reviewed-by: Andrew Bresticker
---
Changes in v3: None
Changes in v2:
- Now use existing regulator_set_voltage_tol() function.
drivers/mmc/core/core.c | 51
include/linux/mmc/host.h | 7 +++
2 files changed, 58 insertions(+)
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 9584bff..670dc65 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -1333,6 +1333,57 @@ int mmc_regulator_set_ocr(struct mmc_host *mmc,
}
EXPORT_SYMBOL_GPL(mmc_regulator_set_ocr);
+static int mmc_regulator_set_voltage_if_supported(struct regulator *regulator,
+ int new_uV, int tol_uV)
+{
+ /*
+* Check if supported first to avoid errors since we may try several
+* signal levels during power up and don't want to show errors.
+*/
+ if (!regulator_is_supported_voltage_tol(regulator, new_uV, tol_uV))
+ return -EINVAL;
+
+ return regulator_set_voltage_tol(regulator, new_uV, tol_uV);
+}
+
+/**
+ * mmc_regulator_set_vqmmc - Set VQMMC as per the ios
+ *
+ * For 3.3V signaling, we try to match VQMMC to VMMC as closely as possible.
+ * That will match the behavior of old boards where VQMMC and VMMC were
supplied
+ * by the same supply. The Bus Operating conditions for 3.3V signaling in the
+ * SD card spec also define VQMMC in terms of VMMC.
+ *
+ * For 1.2V and 1.8V signaling we'll try to get as close as possible to the
+ * requested voltage. This is definitely a good idea for UHS where there's a
+ * separate regulator on the card that's trying to make 1.8V and it's best if
+ * we match.
+ *
+ * This function is expected to be used by a controller's
+ * start_signal_voltage_switch() function.
+ */
+int mmc_regulator_set_vqmmc(struct mmc_host *mmc, struct mmc_ios *ios)
+{
+ /* If no vqmmc supply then we can't change the voltage */
+ if (IS_ERR(mmc->supply.vqmmc))
+ return -EINVAL;
+
+ switch (ios->signal_voltage) {
+ case MMC_SIGNAL_VOLTAGE_120:
+ return mmc_regulator_set_voltage_if_supported(mmc->supply.vqmmc,
+ 120, 10);
+ case MMC_SIGNAL_VOLTAGE_180:
+ return mmc_regulator_set_voltage_if_supported(mmc->supply.vqmmc,
+ 180, 10);
+ case MMC_SIGNAL_VOLTAGE_330:
+ return mmc_regulator_set_voltage_if_supported(mmc->supply.vqmmc,
+ regulator_get_voltage(mmc->supply.vmmc), 30);
+ default:
+ return -EINVAL;
+ }
+}
+EXPORT_SYMBOL_GPL(mmc_regulator_set_vqmmc);
+
#endif /* CONFIG_REGULATOR */
int mmc_regulator_get_supply(struct mmc_host *mmc)
diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
index 9f32270..524d6fc 100644
--- a/include/linux/mmc/host.h
+++ b/include/linux/mmc/host.h
@@ -416,6 +416,7 @@ int mmc_regulator_get_ocrmask(struct regulator *supply);
int mmc_regulator_set_ocr(struct mmc_host *mmc,
struct regulator *supply,
unsigned short vdd_bit);
+int mmc_regulator_set_vqmmc(struct mmc_host *mmc, struct mmc_ios *ios);
#else
static inline int mmc_regulator_get_ocrmask(struct regulator *supply)
{
@@ -428,6 +429,12 @@ static inline int mmc_regulator_set_ocr(struct mmc_host
*mmc,
{
return 0;
}
+
+static inline int mmc_regulator_set_vqmmc(struct mmc_host *mmc,
+ struct mmc_ios *ios)
+{
+ return -EINVAL;
+}
#endif
int mmc_regulator_get_supply(struct mmc_host *mmc);
--
2.2.0.rc0.207.ga3a616c
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 3/3] ARM: dts: Specify VMMC and VQMMC on rk3288-evb
Specifying these rails should eventually let us do UHS.
Signed-off-by: Doug Anderson
---
Changes in v3: None
Changes in v2:
- Fix subject line
arch/arm/boot/dts/rk3288-evb.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/rk3288-evb.dtsi
b/arch/arm/boot/dts/rk3288-evb.dtsi
index 3e067dd..d660fe6 100644
--- a/arch/arm/boot/dts/rk3288-evb.dtsi
+++ b/arch/arm/boot/dts/rk3288-evb.dtsi
@@ -114,6 +114,8 @@
pinctrl-names = "default";
pinctrl-0 = <_clk _cmd _cd _bus4>;
status = "okay";
+ vmmc-supply = <_io>;
+ vqmmc-supply = <_sd>;
};
{
--
2.2.0.rc0.207.ga3a616c
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] VERIFY_OCTAL_PERMISSIONS: Move to where it belongs
Stephen Rothwell wrote: > Please do *not* mix changes up like this. Split this out into a > separate patch, please (1 logical change per patch). Um... I thought I was doing that. More particularly, the task of untangling header file dependencies eseemed sufficiently cohesive that it could be considered one logical change. It was one round of thinking and analysis about what declarations the affected files depend on. Although syntactically possible, given the small size of the change (I deleted a total of 5 #includes, 2 from moduleparam.h and 3 from sysfs.h), it didn't seem worth breaking it up further. > And testing only > on x86_64 is not "sure" when talking about header file pruning (but at > least you did the "all" configs). Well, the first round was reading and understanding the headers; the compile was just to make sure. The files I was messing with (moduleparam.h and sysfs.h) don't have a lot of architecture-specificness within them. The main danger is that they're used in a zillion places and some caller might depend on the over-inclusion. I was rushing to get that to Andrew while the coversation was ongoing (if you check the mail headers, only a few minutes separated the various messages) so I was less cautious than usual, but given that a mistake would result in a nice obvious compile error (with an almost as obvious fix), it seemed worth the risk. If my haste made me judge wrong, I apologize. Was I very wrong, or just a bit over the line? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] ASoC: Intel: fix possible acpi enumeration panic
A crash can occur on some platforms where adsp is enumerated but codec is not
matched. Define codec_id as a pointer intead of an array so that it gets
initialized to NULL for the terminating element of sst_acpi_bytcr[] and
sst_acpi_chv[].
Signed-off-by: Kevin Strasser
---
sound/soc/intel/sst/sst_acpi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/intel/sst/sst_acpi.c b/sound/soc/intel/sst/sst_acpi.c
index 31124aa..87b5090 100644
--- a/sound/soc/intel/sst/sst_acpi.c
+++ b/sound/soc/intel/sst/sst_acpi.c
@@ -43,7 +43,7 @@
#include "sst.h"
struct sst_machines {
- char codec_id[32];
+ char *codec_id;
char board[32];
char machine[32];
void (*machine_quirk)(void);
--
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/
[PATCH] cpufreq-dt: defer probing if OPP table is not ready
cpufreq-dt driver supports mode when OPP table is provided by platform
code and not device tree. However on certain platforms code that fills
OPP table may run after cpufreq driver tries to initialize, so let's
report -EPROBE_DEFER if we do not find any entires in OPP table for the
CPU.
Signed-off-by: Dmitry Torokhov
---
drivers/cpufreq/cpufreq-dt.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/cpufreq/cpufreq-dt.c b/drivers/cpufreq/cpufreq-dt.c
index f56147a..4f874fa 100644
--- a/drivers/cpufreq/cpufreq-dt.c
+++ b/drivers/cpufreq/cpufreq-dt.c
@@ -211,6 +211,19 @@ static int cpufreq_init(struct cpufreq_policy *policy)
/* OPPs might be populated at runtime, don't check for error here */
of_init_opp_table(cpu_dev);
+ /*
+* But we need OPP table to function so if it is not there let's
+* give platform code chance to provide it for us.
+*/
+ rcu_read_lock();
+ ret = dev_pm_opp_get_opp_count(cpu_dev);
+ rcu_read_unlock();
+ if (ret <= 0) {
+ pr_debug("OPP table is not ready, deferring probe\n");
+ ret = -EPROBE_DEFER;
+ goto out_free_opp;
+ }
+
priv = kzalloc(sizeof(*priv), GFP_KERNEL);
if (!priv) {
ret = -ENOMEM;
--
2.2.0.rc0.207.ga3a616c
--
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/3] mmc: dw_mmc: Use mmc_regulator_set_vqmmc in start_signal_voltage_switch
Andrew,
On Mon, Dec 15, 2014 at 3:44 PM, Andrew Bresticker
wrote:
>> - if (!IS_ERR(mmc->supply.vqmmc)) {
>> - ret = regulator_set_voltage(mmc->supply.vqmmc, min_uv,
>> max_uv);
>> -
>> - if (ret) {
>> - dev_dbg(>class_dev,
>> -"Regulator set error %d: %d - %d\n",
>> -ret, min_uv, max_uv);
>> - return ret;
>> - }
>> - }
>> + mmc_regulator_set_vqmmc(mmc, ios);
>
> Shouldn't we check the return value here and bail out of the voltage
> switch procedure if it fails?
My thought was to purposely _not_ check the return value. The comment
right above this says:
* Program the voltage. Note that some instances of dw_mmc may use
* the UHS_REG for this. For other instances (like exynos) the UHS_REG
* does no harm but you need to set the regulator directly. Try both.
...I'm not 100% sure that I understand how the UHS_REG is supposed to
be implemented since I've never seen a system that uses it. I was
assuming that if you have UHS_REG you don't need the regulator...
...but probably a better solution is to return the error if "
!IS_ERR(mmc->supply.vqmmc)". Let me fix that up and repost.
-Doug
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 1/3] gpio: Cygnus: define Broadcom Cygnus GPIO binding
On 12/15/2014 1:57 PM, Arnd Bergmann wrote: On Monday 15 December 2014 13:35:47 Ray Jui wrote: Like I said previously, dynamic GPIO allocation works fine in the kernel, as long as all of our GPIO clients in the kernel use gpiod based API, which is what we will enforce going forward. The only problem is with some of our customers who use GPIO through sysfs and expect fixed global GPIO numbers. Thinking about this more, it's probably not that difficult to add a script for those customers to convert/map the GPIO numbers based on readings parsed from sysfs, so I guess that's fine. I think we discussed the user space interface a number of times in the past, but I forgot the outcome. Either there is already a way to name gpio lines uniquely in sysfs, or there should be one. Can you reach the gpio interfaces using /sys/devices/0001234.bus/1234566.gpiocontroller/...? Arnd We use entries under /sys/class/gpio/ to control GPIOs. All base, label, and ngpio info specific to a GPIO controller can be found there. -- 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] staging: rtl8723au: os_dep: usb_intf.c: Fix for possible null pointer dereference
On 12/15/2014 05:01 PM, Rickard Strandqvist wrote: Hi No the rtw_hw_resume23a() is not used anywhere. I also do a check of all functions that are not used, but not in the drivers/staging, I suspected that these might be under development and used in the future. What do you want to do, who decides? The original developers of this code do not include any of the Linux maintainers. If you see an unused routine, submit a patch to delete it. If a maintainer thinks it should be kept, your patch will be NACKed, but that is pnot likely. Larry -- 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] Staging: rtl8723au: core: rtw_ap: checkpatch.pl fixes
On Mon, Dec 15, 2014 at 06:26:09PM -0500, Joe Borg wrote: > Fixing errors found with checkpatch.pl. What exact errors? Please be specific here and describe what you are doing. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: lustre: lustre: obdclass: lprocfs_status.c: Fix for possible null pointer dereference
On Mon, 2014-12-15 at 23:23 +0100, Rickard Strandqvist wrote:
> Hi Joe
Hello Rickard
> No, it does not look like end can be NULL then.
> Then remove the end != NULL instead?
> ...
> if (end != NULL && *end == '.') {
Up to you.
> However, I am hesitant to the tolower() I think double case is faster...?
I doubt code execution speed is paramount here.
Maybe see if the object code size is smaller one
way or the other.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[git pull] vfs.git pile 2
Next pile (and there'll be one or two more). The large piece in this one is getting rid of /proc/*/ns/* weirdness; among other things, it allows to (finally) make nameidata completely opaque outside of fs/namei.c, making for easier further cleanups in there. I have _not_ included removal of unshare_fs_struct() into that pile; I think it'll turn out to be OK, but it's clearly the next cycle fodder. Please, pull from the usual place - git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git for-linus Shortlog: Al Viro (20): common object embedded into various struct ns make mntns ->get()/->put()/->install()/->inum() work with _ns->ns netns: switch ->get()/->put()/->install()/->inum() to working with >ns switch the rest of proc_ns_operations to working with &...->ns make proc_ns_operations work with struct ns_common * instead of void * new helpers: ns_alloc_inum/ns_free_inum copy address of proc_ns_ops into ns_common bury struct proc_ns in fs/proc take the targets of /proc/*/ns/* symlinks to separate fs kill proc_ns completely make nameidata completely opaque outside of fs/namei.c make default ->i_fop have ->open() fail with ENXIO path_init(): store the "base" pointer to file in nameidata itself fs/namei.c: new helper (path_cleanup()) path_init(): don't bother with LOOKUP_PARENT in argument fs/namei.c: fold link_path_walk() call into path_init() coda_venus_readdir(): use file_inode() spawn PID 1 without CLONE_FS, give kernel threads zero umask lustre: get rid of playing with ->fs btrfs: filp_open() returns ERR_PTR() on failure, not NULL... Diffstat: arch/ia64/kernel/perfmon.c | 10 -- .../lustre/lustre/include/linux/lustre_compat25.h | 24 --- drivers/staging/lustre/lustre/llite/dir.c | 2 +- drivers/staging/lustre/lustre/llite/llite_lib.c| 17 +-- fs/Makefile| 2 +- fs/btrfs/volumes.c | 2 +- fs/coda/dir.c | 4 +- fs/fs_struct.c | 2 +- fs/inode.c | 11 +- fs/internal.h | 5 + fs/mount.h | 3 +- fs/namei.c | 98 +++-- fs/namespace.c | 51 +++ fs/nsfs.c | 161 + fs/proc/inode.c| 10 +- fs/proc/internal.h | 2 +- fs/proc/namespaces.c | 153 ++-- include/linux/fs.h | 1 - include/linux/ipc_namespace.h | 3 +- include/linux/namei.h | 25 +--- include/linux/ns_common.h | 12 ++ include/linux/pid_namespace.h | 3 +- include/linux/proc_ns.h| 43 +++--- include/linux/user_namespace.h | 3 +- include/linux/utsname.h| 3 +- include/net/net_namespace.h| 3 +- include/uapi/linux/magic.h | 1 + init/main.c| 6 +- init/version.c | 5 +- ipc/msgutil.c | 5 +- ipc/namespace.c| 32 ++-- kernel/kmod.c | 2 + kernel/nsproxy.c | 10 +- kernel/pid.c | 5 +- kernel/pid_namespace.c | 29 ++-- kernel/user.c | 5 +- kernel/user_namespace.c| 29 ++-- kernel/utsname.c | 31 ++-- net/Makefile | 2 - net/core/net_namespace.c | 39 ++--- net/nonet.c| 26 net/socket.c | 19 --- 42 files changed, 425 insertions(+), 474 deletions(-) create mode 100644 fs/nsfs.c create mode 100644 include/linux/ns_common.h delete mode 100644 net/nonet.c -- 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 v10] iopoll: Introduce memory-mapped IO polling macros
From: Matt Wagantall
It is sometimes necessary to poll a memory-mapped register until its value
satisfies some condition. Introduce a family of convenience macros that do
this. Tight-looping, sleeping, and timing out can all be accomplished using
these macros.
Cc: Thierry Reding
Cc: Will Deacon
Cc: Arnd Bergmann
Cc: Andrew Morton
Cc: Robert Elliott
Signed-off-by: Matt Wagantall
Signed-off-by: Mitchel Humpherys
---
v9..10:
- Actually added the comments mentioned in v8..v9 (doh!)
v8..v9:
- Added note in comments about max sleep time (Rob Elliott)
v7..v8:
- sorted helper macros by size (b, w, l, q)
- removed some of the more esoteric (or flat-out bogus) helper macros
This patch was originally part of a series [1] for adding support for IOMMU
address translations through an ARM SMMU hardware register. The other
patch in the series (the one that actually uses these macros and implements
said hardware address translations) was Ack'd by the driver maintainer
there (Will Deacon) so I've pulled this patch out to avoid resending an
already Ack'd patch over and over again.
In short, please see [1] for previous discussion and the first user of
these macros.
Will also acked this patch in [2]. I didn't retain his Ack here because I
added to the macro comments.
[1] http://thread.gmane.org/gmane.linux.kernel.iommu/7140
[2] http://thread.gmane.org/gmane.linux.kernel.iommu/7449
---
include/linux/iopoll.h | 144 +
1 file changed, 144 insertions(+)
create mode 100644 include/linux/iopoll.h
diff --git a/include/linux/iopoll.h b/include/linux/iopoll.h
new file mode 100644
index ..08fd52cdb5a0
--- /dev/null
+++ b/include/linux/iopoll.h
@@ -0,0 +1,144 @@
+/*
+ * Copyright (c) 2012-2014 The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#ifndef _LINUX_IOPOLL_H
+#define _LINUX_IOPOLL_H
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+/**
+ * readx_poll_timeout - Periodically poll an address until a condition is met
or a timeout occurs
+ * @op: accessor function (takes @addr as its only argument)
+ * @addr: Address to poll
+ * @val: Variable to read the value into
+ * @cond: Break condition (usually involving @val)
+ * @sleep_us: Maximum time to sleep between reads in us (0
+ *tight-loops). Should be less than ~20ms since usleep_range
+ *is used (see Documentation/timers/timers-howto.txt).
+ * @timeout_us: Timeout in us, 0 means never timeout
+ *
+ * Returns 0 on success and -ETIMEDOUT upon a timeout. In either
+ * case, the last read value at @addr is stored in @val. Must not
+ * be called from atomic context if sleep_us or timeout_us are used.
+ *
+ * When available, you'll probably want to use one of the specialized
+ * macros defined below rather than this macro directly.
+ */
+#define readx_poll_timeout(op, addr, val, cond, sleep_us, timeout_us) \
+({ \
+ ktime_t timeout = ktime_add_us(ktime_get(), timeout_us); \
+ might_sleep_if(sleep_us); \
+ for (;;) { \
+ (val) = op(addr); \
+ if (cond) \
+ break; \
+ if (timeout_us && ktime_compare(ktime_get(), timeout) > 0) { \
+ (val) = op(addr); \
+ break; \
+ } \
+ if (sleep_us) \
+ usleep_range((sleep_us >> 2) + 1, sleep_us); \
+ } \
+ (cond) ? 0 : -ETIMEDOUT; \
+})
+
+/**
+ * readx_poll_timeout_atomic - Periodically poll an address until a condition
is met or a timeout occurs
+ * @op: accessor function (takes @addr as its only argument)
+ * @addr: Address to poll
+ * @val: Variable to read the value into
+ * @cond: Break condition (usually involving @val)
+ * @delay_us: Time to udelay between reads in us (0 tight-loops). Should
+ *be less than ~10us since udelay is used (see
+ *Documentation/timers/timers-howto.txt).
+ * @timeout_us: Timeout in us, 0 means never timeout
+ *
+ * Returns 0 on success and -ETIMEDOUT upon a timeout. In either
+ * case, the last read value at @addr is stored in @val.
+ *
+ * When available, you'll probably want to use one of the specialized
+ * macros defined below rather than this macro directly.
+ */
+#define readx_poll_timeout_atomic(op, addr, val, cond, delay_us, timeout_us) \
+({ \
+ ktime_t timeout = ktime_add_us(ktime_get(), timeout_us); \
+ for (;;) { \
+ (val) = op(addr); \
+ if (cond) \
+
Re: frequent lockups in 3.18rc4
On Mon, Dec 15, 2014 at 10:21 AM, Linus Torvalds
wrote:
>
> So let's just fix it. Here's a completely untested patch.
So after looking at this more, I'm actually really convinced that this
was a pretty nasty bug.
I'm *not* convinced that it's necessarily *your* bug, but I still
think it could be.
I cleaned up the patch a bit, split it up into two to clarify it, and
have committed it to my tree. I'm not marking the patches for stable,
because while I'm convinced it's a bug, I'm also not sure why even if
it triggers it doesn't eventually recover when the IO completes. So
I'd mark them for stable only if they are actually confirmed to fix
anything in the wild, and after they've gotten some testing in
general. The patches *look* straightforward, they remove more lines
than they add, and I think the code is more understandable too, but
maybe I just screwed up. Whatever. Some care is warranted, but this is
the first time I feel like I actually fixed something that matched at
least one of your lockup symptoms.
Anyway, it's there as
26178ec11ef3 ("x86: mm: consolidate VM_FAULT_RETRY handling")
7fb08eca4527 ("x86: mm: move mmap_sem unlock from mm_fault_error() to caller")
and I'll continue to look at the page fault patch. I still have a
slight worry that it's something along the lines of corrupted page
tables or some core VM issue, but I apart from my general nervousness
about the auto-numa code (which will be cleaned up eventually though
the pte_protnone patches), I can't actually see how you'd get into
endless page faults any other way. So I'm really hoping that the buggy
VM_FAULT_RETRY handling explains it.
But me not seeing any other bug clearly doesn't mean it doesn't exist.
Linus
--
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: [nohz] 2a16fc93d2c: kernel lockup on idle injection
On Mon, Dec 15, 2014 at 03:02:17PM +0530, Viresh Kumar wrote: > On 15 December 2014 at 12:55, Preeti U Murthy > wrote: > > Hi Viresh, > > > > Let me explain why I think this is happening. > > > > 1. tick_nohz_irq_enter/exit() both get called *only if the cpu is idle* > > and receives an interrupt. > > Bang on target. Yeah that's the part we missed while writing this patch :) > > > 2. Commit 2a16fc93d2c9568e1, cancels programming of tick_sched timer > > in its handler, assuming that tick_nohz_irq_exit() will take care of > > programming the clock event device appropriately, and hence it would > > requeue or cancel the tick_sched timer. > > Correct. > > > 3. But the intel_powerclamp driver injects an idle period only. > > *The CPU however is not idle*. It has work on its runqueue and the > > rq->curr != idle. This means that *tick_nohz_irq_enter()/exit() will not > > get called on any interrupt*. > > Still good.. > > > 4. As a consequence, when we get a hrtimer interrupt during the period > > that the powerclamp driver is mimicking idle, the exit path of the > > interrupt never calls tick_nohz_irq_exit(). Hence the tick_sched timer > > that would have got removed due to the above commit will not get > > enqueued back on for any pending timers that there might be. Besides > > this, *jiffies never gets updated*. > > Jiffies can be updated by any CPU and there is something called a control > cpu with powerclamp driver. BUT we may have got interrupted before the > powerclamp timer expired and so we are stuck in the > > while (time_before(jiffies, target_jiffies)) > > loop for ever. > > > Hope the above explanation makes sense. > > Mostly good. Thanks for helping out. > > Now, what's the right solution going forward ? > > - Revert the offending commit .. > - Or still try to avoid reprogramming if we can .. > > This is what I could come up with to still avoid reprogramming of tick: > > diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c > index cc0a5b6f741b..49f4278f69e2 100644 > --- a/kernel/time/tick-sched.c > +++ b/kernel/time/tick-sched.c > @@ -1100,7 +1100,7 @@ static enum hrtimer_restart > tick_sched_timer(struct hrtimer *timer) > tick_sched_handle(ts, regs); > > /* No need to reprogram if we are in idle or full dynticks mode */ > - if (unlikely(ts->tick_stopped)) > + if (unlikely(ts->tick_stopped && (is_idle_task(current) || > !ts->inidle))) > return HRTIMER_NORESTART; > > hrtimer_forward(timer, now, tick_period); So to summarize: I see it enqueues a timer then it loops on that timer expiration. On that loop we stop the CPU and we expect the timer to fire and wake the thread up. But if the delayed tick fires too early, before the timer actually expires, then we go to sleep again because we haven't yet reached the delay, but since tick_nohz_irq_exit() is only called on idle tasks and not for threads like powerclamp, the tick isn't rescheduled to handle the remaining timer slice so we sleep forever. Hence if we really want to stop the tick when we mimic idle from powerclamp driver, we must call tick_nohz_irq_exit() on irq exit to do it correctly. It happened to work by accident before the commit because we were rescheduling the tick from itself without tick_nohz_irq_exit() to cancel anything. And that restored the periodic behaviour necessary to complete the delay. So the above change is rather a hack than a solution. We have several choices: 1) Revert the commit. But this has to be a temporary solution really. Powerclamp has to be fixed and handle tick_nohz_irq_exit(). 2) Remove powerclamp tick stop until somebody fixes it to handle nohz properly. 2) Fix it directly. But I believe there is a release that is going to miss the fix and suffer the regression. Does the regression matter for anybody? Is powerclamp meant for anything else than testing (I have no idea what it's used for)? So to fix powerclamp to handle nohz correctly, tick_nohz_irq_exit() must be called for both idle tasks and powerclamp kthreads. Checking ts->inidle can be a good way to match both. That means we might need to use a reduced part of idle_cpu() to avoid redundant checks. tick_irq_enter() must be called as well for powerclamp, in case it's the only CPU running, it has to fixup the timekeeping alone. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v9] iopoll: Introduce memory-mapped IO polling macros
On Mon, Dec 15 2014 at 03:31:20 PM, Mitchel Humpherys wrote: > From: Matt Wagantall > > It is sometimes necessary to poll a memory-mapped register until its value > satisfies some condition. Introduce a family of convenience macros that do > this. Tight-looping, sleeping, and timing out can all be accomplished using > these macros. > > Cc: Thierry Reding > Cc: Will Deacon > Cc: Arnd Bergmann > Cc: Andrew Morton > Cc: Robert Elliott > Signed-off-by: Matt Wagantall > Signed-off-by: Mitchel Humpherys > --- > v8..v9: > - Added note in comments about max sleep time (Rob Elliott) Sorry, just noticed that I somehow dropped these additional comments that Rob requested... Let me send a v10 that actually includes them. Please ignore this version. -Mitch -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/3] mmc: dw_mmc: Use mmc_regulator_set_vqmmc in start_signal_voltage_switch
Hi Doug,
On Mon, Dec 15, 2014 at 3:25 PM, Doug Anderson wrote:
> We've introduced a new helper in the MMC core:
> mmc_regulator_set_vqmmc(). Let's use this in dw_mmc. Using this new
> helper has some advantages:
>
> 1. We get the mmc_regulator_set_vqmmc() behavior of trying to match
>VQMMC and VMMC when the signal voltage is 3.3V. This ensures max
>compatibility.
>
> 2. We get rid of a few more warnings when probing unsupported
>voltages.
>
> 3. We get rid of some non-dw_mmc specific code in dw_mmc.
>
> Signed-off-by: Doug Anderson
One small comment below...
> @@ -1170,24 +1168,11 @@ static int dw_mci_switch_voltage(struct mmc_host
> *mmc, struct mmc_ios *ios)
> */
> uhs = mci_readl(host, UHS_REG);
> if (ios->signal_voltage == MMC_SIGNAL_VOLTAGE_330) {
> - min_uv = 270;
> - max_uv = 360;
> uhs &= ~v18;
> } else {
> - min_uv = 170;
> - max_uv = 195;
> uhs |= v18;
> }
> - if (!IS_ERR(mmc->supply.vqmmc)) {
> - ret = regulator_set_voltage(mmc->supply.vqmmc, min_uv,
> max_uv);
> -
> - if (ret) {
> - dev_dbg(>class_dev,
> -"Regulator set error %d: %d - %d\n",
> -ret, min_uv, max_uv);
> - return ret;
> - }
> - }
> + mmc_regulator_set_vqmmc(mmc, ios);
Shouldn't we check the return value here and bail out of the voltage
switch procedure if it fails?
--
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] mmc: core: Add mmc_regulator_set_vqmmc()
Hi Doug, On Mon, Dec 15, 2014 at 3:25 PM, Doug Anderson wrote: > This adds logic to the MMC core to set VQMMC. This is expected to be > called by MMC drivers like dw_mmc as part of (or instead of) their > start_signal_voltage_switch() callback. > > A few notes: > > * When setting the signal voltage to 3.3V we do our best to make VQMMC > and VMMC match. It's been reported that this makes some old cards > happy since they were tested back in the day before UHS when VQMMC > and VMMC were provided by the same regulator. A nice side effect of > this is that we don't end up on the hairy edge of VQMMC (2.7V), > which some EEs claim is a little too close to the minimum for > comfort. > > * When setting the signal voltage to 1.8V or 1.2V we aim for that > specific voltage instead of picking the lowest one in the range. > > * We very purposely don't print errors in mmc_regulator_set_vqmmc(). > There are cases where the MMC core will try several different > voltages and we don't want to pollute the logs. > > Signed-off-by: Doug Anderson Looks good to me. Reviewed-by: Andrew Bresticker -- 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 7/7] CXL: Unmap MMIO regions when detaching a context
On Mon, 2014-12-15 at 14:32 +1100, Ian Munsie wrote: > Excerpts from Ian Munsie's message of 2014-12-08 19:18:01 +1100: > > From: Ian Munsie > > > > If we need to force detach a context (e.g. due to EEH or simply force > > unbinding the driver) we should prevent the userspace contexts from > > being able to access the Problem State Area MMIO region further, which > > they may have mapped with mmap(). > > > > This patch unmaps any mapped MMIO regions when detaching a userspace > > context. > > Might want to drop this one for now - Philippe found that it sometimes > causes an issue when multiple contexts are using the afu. Seems that > unmap_mapping_range() unmapped a bit more than I expected. Sorry, it's already in next. https://git.kernel.org/cgit/linux/kernel/git/mpe/linux.git/commit/?h=next=b123429e6a9e8d03aacf888d23262835f0081448 Send me a revert or a fixup. cheers -- 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 v9] iopoll: Introduce memory-mapped IO polling macros
From: Matt Wagantall
It is sometimes necessary to poll a memory-mapped register until its value
satisfies some condition. Introduce a family of convenience macros that do
this. Tight-looping, sleeping, and timing out can all be accomplished using
these macros.
Cc: Thierry Reding
Cc: Will Deacon
Cc: Arnd Bergmann
Cc: Andrew Morton
Cc: Robert Elliott
Signed-off-by: Matt Wagantall
Signed-off-by: Mitchel Humpherys
---
v8..v9:
- Added note in comments about max sleep time (Rob Elliott)
v7..v8:
- sorted helper macros by size (b, w, l, q)
- removed some of the more esoteric (or flat-out bogus) helper macros
This patch was originally part of a series [1] for adding support for IOMMU
address translations through an ARM SMMU hardware register. The other
patch in the series (the one that actually uses these macros and implements
said hardware address translations) was Ack'd by the driver maintainer
there (Will Deacon) so I've pulled this patch out to avoid resending an
already Ack'd patch over and over again.
In short, please see [1] for previous discussion and the first user of
these macros.
Will also acked this patch in [2]. I didn't retain his Ack here because I
added to the macro comments.
[1] http://thread.gmane.org/gmane.linux.kernel.iommu/7140
[2] http://thread.gmane.org/gmane.linux.kernel.iommu/7449
---
include/linux/iopoll.h | 140 +
1 file changed, 140 insertions(+)
create mode 100644 include/linux/iopoll.h
diff --git a/include/linux/iopoll.h b/include/linux/iopoll.h
new file mode 100644
index ..bd161dae2d40
--- /dev/null
+++ b/include/linux/iopoll.h
@@ -0,0 +1,140 @@
+/*
+ * Copyright (c) 2012-2014 The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#ifndef _LINUX_IOPOLL_H
+#define _LINUX_IOPOLL_H
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+/**
+ * readx_poll_timeout - Periodically poll an address until a condition is met
or a timeout occurs
+ * @op: accessor function (takes @addr as its only argument)
+ * @addr: Address to poll
+ * @val: Variable to read the value into
+ * @cond: Break condition (usually involving @val)
+ * @sleep_us: Maximum time to sleep between reads in us (0 tight-loops)
+ * @timeout_us: Timeout in us, 0 means never timeout
+ *
+ * Returns 0 on success and -ETIMEDOUT upon a timeout. In either
+ * case, the last read value at @addr is stored in @val. Must not
+ * be called from atomic context if sleep_us or timeout_us are used.
+ *
+ * When available, you'll probably want to use one of the specialized
+ * macros defined below rather than this macro directly.
+ */
+#define readx_poll_timeout(op, addr, val, cond, sleep_us, timeout_us) \
+({ \
+ ktime_t timeout = ktime_add_us(ktime_get(), timeout_us); \
+ might_sleep_if(sleep_us); \
+ for (;;) { \
+ (val) = op(addr); \
+ if (cond) \
+ break; \
+ if (timeout_us && ktime_compare(ktime_get(), timeout) > 0) { \
+ (val) = op(addr); \
+ break; \
+ } \
+ if (sleep_us) \
+ usleep_range((sleep_us >> 2) + 1, sleep_us); \
+ } \
+ (cond) ? 0 : -ETIMEDOUT; \
+})
+
+/**
+ * readx_poll_timeout_atomic - Periodically poll an address until a condition
is met or a timeout occurs
+ * @op: accessor function (takes @addr as its only argument)
+ * @addr: Address to poll
+ * @val: Variable to read the value into
+ * @cond: Break condition (usually involving @val)
+ * @delay_us: Time to udelay between reads in us (0 tight-loops)
+ * @timeout_us: Timeout in us, 0 means never timeout
+ *
+ * Returns 0 on success and -ETIMEDOUT upon a timeout. In either
+ * case, the last read value at @addr is stored in @val.
+ *
+ * When available, you'll probably want to use one of the specialized
+ * macros defined below rather than this macro directly.
+ */
+#define readx_poll_timeout_atomic(op, addr, val, cond, delay_us, timeout_us) \
+({ \
+ ktime_t timeout = ktime_add_us(ktime_get(), timeout_us); \
+ for (;;) { \
+ (val) = op(addr); \
+ if (cond) \
+ break; \
+ if (timeout_us && ktime_compare(ktime_get(), timeout) > 0) { \
+ (val) = op(addr); \
+ break; \
+ } \
+ if (delay_us) \
+ udelay(delay_us); \
+ } \
+ (cond) ? 0 :
[PATCH v2 2/3] mmc: dw_mmc: Use mmc_regulator_set_vqmmc in start_signal_voltage_switch
We've introduced a new helper in the MMC core:
mmc_regulator_set_vqmmc(). Let's use this in dw_mmc. Using this new
helper has some advantages:
1. We get the mmc_regulator_set_vqmmc() behavior of trying to match
VQMMC and VMMC when the signal voltage is 3.3V. This ensures max
compatibility.
2. We get rid of a few more warnings when probing unsupported
voltages.
3. We get rid of some non-dw_mmc specific code in dw_mmc.
Signed-off-by: Doug Anderson
---
Changes in v2: None
drivers/mmc/host/dw_mmc.c | 17 +
1 file changed, 1 insertion(+), 16 deletions(-)
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 67c0451..4ae800c 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -1160,8 +1160,6 @@ static int dw_mci_switch_voltage(struct mmc_host *mmc,
struct mmc_ios *ios)
struct dw_mci *host = slot->host;
u32 uhs;
u32 v18 = SDMMC_UHS_18V << slot->id;
- int min_uv, max_uv;
- int ret;
/*
* Program the voltage. Note that some instances of dw_mmc may use
@@ -1170,24 +1168,11 @@ static int dw_mci_switch_voltage(struct mmc_host *mmc,
struct mmc_ios *ios)
*/
uhs = mci_readl(host, UHS_REG);
if (ios->signal_voltage == MMC_SIGNAL_VOLTAGE_330) {
- min_uv = 270;
- max_uv = 360;
uhs &= ~v18;
} else {
- min_uv = 170;
- max_uv = 195;
uhs |= v18;
}
- if (!IS_ERR(mmc->supply.vqmmc)) {
- ret = regulator_set_voltage(mmc->supply.vqmmc, min_uv, max_uv);
-
- if (ret) {
- dev_dbg(>class_dev,
-"Regulator set error %d: %d - %d\n",
-ret, min_uv, max_uv);
- return ret;
- }
- }
+ mmc_regulator_set_vqmmc(mmc, ios);
mci_writel(host, UHS_REG, uhs);
return 0;
--
2.2.0.rc0.207.ga3a616c
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/3] mmc: core: Add mmc_regulator_set_vqmmc()
This adds logic to the MMC core to set VQMMC. This is expected to be
called by MMC drivers like dw_mmc as part of (or instead of) their
start_signal_voltage_switch() callback.
A few notes:
* When setting the signal voltage to 3.3V we do our best to make VQMMC
and VMMC match. It's been reported that this makes some old cards
happy since they were tested back in the day before UHS when VQMMC
and VMMC were provided by the same regulator. A nice side effect of
this is that we don't end up on the hairy edge of VQMMC (2.7V),
which some EEs claim is a little too close to the minimum for
comfort.
* When setting the signal voltage to 1.8V or 1.2V we aim for that
specific voltage instead of picking the lowest one in the range.
* We very purposely don't print errors in mmc_regulator_set_vqmmc().
There are cases where the MMC core will try several different
voltages and we don't want to pollute the logs.
Signed-off-by: Doug Anderson
---
Changes in v2:
- Now use existing regulator_set_voltage_tol() function.
drivers/mmc/core/core.c | 51
include/linux/mmc/host.h | 7 +++
2 files changed, 58 insertions(+)
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 9584bff..670dc65 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -1333,6 +1333,57 @@ int mmc_regulator_set_ocr(struct mmc_host *mmc,
}
EXPORT_SYMBOL_GPL(mmc_regulator_set_ocr);
+static int mmc_regulator_set_voltage_if_supported(struct regulator *regulator,
+ int new_uV, int tol_uV)
+{
+ /*
+* Check if supported first to avoid errors since we may try several
+* signal levels during power up and don't want to show errors.
+*/
+ if (!regulator_is_supported_voltage_tol(regulator, new_uV, tol_uV))
+ return -EINVAL;
+
+ return regulator_set_voltage_tol(regulator, new_uV, tol_uV);
+}
+
+/**
+ * mmc_regulator_set_vqmmc - Set VQMMC as per the ios
+ *
+ * For 3.3V signaling, we try to match VQMMC to VMMC as closely as possible.
+ * That will match the behavior of old boards where VQMMC and VMMC were
supplied
+ * by the same supply. The Bus Operating conditions for 3.3V signaling in the
+ * SD card spec also define VQMMC in terms of VMMC.
+ *
+ * For 1.2V and 1.8V signaling we'll try to get as close as possible to the
+ * requested voltage. This is definitely a good idea for UHS where there's a
+ * separate regulator on the card that's trying to make 1.8V and it's best if
+ * we match.
+ *
+ * This function is expected to be used by a controller's
+ * start_signal_voltage_switch() function.
+ */
+int mmc_regulator_set_vqmmc(struct mmc_host *mmc, struct mmc_ios *ios)
+{
+ /* If no vqmmc supply then we can't change the voltage */
+ if (IS_ERR(mmc->supply.vqmmc))
+ return -EINVAL;
+
+ switch (ios->signal_voltage) {
+ case MMC_SIGNAL_VOLTAGE_120:
+ return mmc_regulator_set_voltage_if_supported(mmc->supply.vqmmc,
+ 120, 10);
+ case MMC_SIGNAL_VOLTAGE_180:
+ return mmc_regulator_set_voltage_if_supported(mmc->supply.vqmmc,
+ 180, 10);
+ case MMC_SIGNAL_VOLTAGE_330:
+ return mmc_regulator_set_voltage_if_supported(mmc->supply.vqmmc,
+ regulator_get_voltage(mmc->supply.vmmc), 30);
+ default:
+ return -EINVAL;
+ }
+}
+EXPORT_SYMBOL_GPL(mmc_regulator_set_vqmmc);
+
#endif /* CONFIG_REGULATOR */
int mmc_regulator_get_supply(struct mmc_host *mmc)
diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
index 9f32270..524d6fc 100644
--- a/include/linux/mmc/host.h
+++ b/include/linux/mmc/host.h
@@ -416,6 +416,7 @@ int mmc_regulator_get_ocrmask(struct regulator *supply);
int mmc_regulator_set_ocr(struct mmc_host *mmc,
struct regulator *supply,
unsigned short vdd_bit);
+int mmc_regulator_set_vqmmc(struct mmc_host *mmc, struct mmc_ios *ios);
#else
static inline int mmc_regulator_get_ocrmask(struct regulator *supply)
{
@@ -428,6 +429,12 @@ static inline int mmc_regulator_set_ocr(struct mmc_host
*mmc,
{
return 0;
}
+
+static inline int mmc_regulator_set_vqmmc(struct mmc_host *mmc,
+ struct mmc_ios *ios)
+{
+ return -EINVAL;
+}
#endif
int mmc_regulator_get_supply(struct mmc_host *mmc);
--
2.2.0.rc0.207.ga3a616c
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 3/3] ARM: dts: Specify VMMC and VQMMC on rk3288-evb
Specifying these rails should eventually let us do UHS.
Signed-off-by: Doug Anderson
---
Changes in v2:
- Fix subject line
arch/arm/boot/dts/rk3288-evb.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/rk3288-evb.dtsi
b/arch/arm/boot/dts/rk3288-evb.dtsi
index 3e067dd..d660fe6 100644
--- a/arch/arm/boot/dts/rk3288-evb.dtsi
+++ b/arch/arm/boot/dts/rk3288-evb.dtsi
@@ -114,6 +114,8 @@
pinctrl-names = "default";
pinctrl-0 = <_clk _cmd _cd _bus4>;
status = "okay";
+ vmmc-supply = <_io>;
+ vqmmc-supply = <_sd>;
};
{
--
2.2.0.rc0.207.ga3a616c
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [alsa-devel] [PATCH] ASoC: Intel: fix possible acpi enumeration panic
On Mon, Dec 15, 2014 at 05:06:45PM +, Mark Brown wrote: > Please fix your mailer to word wrap comfortably under 80 colums so that your > mails are easily legible. Understood > > > This changes the check from verifying if a codec_id is present to > > > verifying if the first character in the codec_id is non-NULL. That > > > doesn't seem obviously safer and the tables of machines seem to be > > > terminated by having an entry with all fields set to zero (which is a > > > common idiom in Linux) which would now crash with this change. > > > In this case mach->codec_id is non-NULL, even for the terminating element, > > because it is defined to be a fixed width. So we have to take a look at the > > first character to see if it has been initialized. > > That's a really unusual and (as you've seen) error prone idiom - is it not > better to fix the struct to use the more common idiom? That seems like a good idea to me. I'll prepare a new patch to change the sst_machines definition so that codec_id gets initialized to NULL. -Kevin -- 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] arch: arm: mach-msm: smd.c: Remove some unused functions
Hi
My script looks for the same function name, so if they then would be
named exactly the same, they would come up.
But I can not even find drivers/staging/dream/ or is this really new code?
Kind regards
Rickard Strandqvist
2014-12-09 15:46 GMT+01:00 :
>
> Seems ok to me. These files, and functions, are also in drivers/staging/dream/
> are you removing them there also ?
>
>
> On Sun, Dec 07, 2014 at 02:12:20AM +0100, Rickard Strandqvist wrote:
>> Removes some functions that are not used anywhere:
>> smsm_set_sleep_duration() smsm_get_state() smd_wait_until_writable()
>> smd_wait_until_readable() smd_write_atomic() smd_sleep_exit()
>>
>> This was partially found by using a static code analysis program called
>> cppcheck.
>>
>> Signed-off-by: Rickard Strandqvist
>> ---
>> arch/arm/mach-msm/include/mach/msm_smd.h |9 ---
>> arch/arm/mach-msm/smd.c | 105
>> --
>> arch/arm/mach-msm/smd_private.h |2 -
>> 3 files changed, 116 deletions(-)
>>
>> diff --git a/arch/arm/mach-msm/include/mach/msm_smd.h
>> b/arch/arm/mach-msm/include/mach/msm_smd.h
>> index 029463e..48ddef98 100644
>> --- a/arch/arm/mach-msm/include/mach/msm_smd.h
>> +++ b/arch/arm/mach-msm/include/mach/msm_smd.h
>> @@ -40,7 +40,6 @@ int smd_read(smd_channel_t *ch, void *data, int len);
>> ** it will return the requested length written or an error.
>> */
>> int smd_write(smd_channel_t *ch, const void *data, int len);
>> -int smd_write_atomic(smd_channel_t *ch, const void *data, int len);
>>
>> int smd_write_avail(smd_channel_t *ch);
>> int smd_read_avail(smd_channel_t *ch);
>> @@ -57,14 +56,6 @@ int smd_cur_packet_size(smd_channel_t *ch);
>> void smd_kick(smd_channel_t *ch);
>>
>>
>> -#if 0
>> -/* these are interruptable waits which will block you until the specified
>> -** number of bytes are readable or writable.
>> -*/
>> -int smd_wait_until_readable(smd_channel_t *ch, int bytes);
>> -int smd_wait_until_writable(smd_channel_t *ch, int bytes);
>> -#endif
>> -
>> typedef enum {
>> SMD_PORT_DS = 0,
>> SMD_PORT_DIAG,
>> diff --git a/arch/arm/mach-msm/smd.c b/arch/arm/mach-msm/smd.c
>> index b1588a1..4bc1e71 100644
>> --- a/arch/arm/mach-msm/smd.c
>> +++ b/arch/arm/mach-msm/smd.c
>> @@ -401,36 +401,6 @@ static inline int smd_need_int(struct smd_channel *ch)
>> return 0;
>> }
>>
>> -void smd_sleep_exit(void)
>> -{
>> - unsigned long flags;
>> - struct smd_channel *ch;
>> - int need_int = 0;
>> -
>> - spin_lock_irqsave(_lock, flags);
>> - list_for_each_entry(ch, _ch_list_modem, ch_list) {
>> - if (smd_need_int(ch)) {
>> - need_int = 1;
>> - break;
>> - }
>> - }
>> - list_for_each_entry(ch, _ch_list_dsp, ch_list) {
>> - if (smd_need_int(ch)) {
>> - need_int = 1;
>> - break;
>> - }
>> - }
>> - spin_unlock_irqrestore(_lock, flags);
>> - do_smd_probe();
>> -
>> - if (need_int) {
>> - if (msm_smd_debug_mask & MSM_SMD_DEBUG)
>> - pr_info("smd_sleep_exit need interrupt\n");
>> - tasklet_schedule(_fake_irq_tasklet);
>> - }
>> -}
>> -
>> -
>> void smd_kick(smd_channel_t *ch)
>> {
>> unsigned long flags;
>> @@ -747,16 +717,6 @@ int smd_write(smd_channel_t *ch, const void *data, int
>> len)
>> return ch->write(ch, data, len);
>> }
>>
>> -int smd_write_atomic(smd_channel_t *ch, const void *data, int len)
>> -{
>> - unsigned long flags;
>> - int res;
>> - spin_lock_irqsave(_lock, flags);
>> - res = ch->write(ch, data, len);
>> - spin_unlock_irqrestore(_lock, flags);
>> - return res;
>> -}
>> -
>> int smd_read_avail(smd_channel_t *ch)
>> {
>> return ch->read_avail(ch);
>> @@ -767,16 +727,6 @@ int smd_write_avail(smd_channel_t *ch)
>> return ch->write_avail(ch);
>> }
>>
>> -int smd_wait_until_readable(smd_channel_t *ch, int bytes)
>> -{
>> - return -1;
>> -}
>> -
>> -int smd_wait_until_writable(smd_channel_t *ch, int bytes)
>> -{
>> - return -1;
>> -}
>> -
>> int smd_cur_packet_size(smd_channel_t *ch)
>> {
>> return ch->current_packet;
>> @@ -875,61 +825,6 @@ int smsm_change_state(enum smsm_state_item item,
>> return 0;
>> }
>>
>> -uint32_t smsm_get_state(enum smsm_state_item item)
>> -{
>> - unsigned long flags;
>> - uint32_t rv;
>> -
>> - spin_lock_irqsave(_lock, flags);
>> -
>> - rv = readl(smd_info.state + item * 4);
>> -
>> - if (item == SMSM_STATE_MODEM && (rv & SMSM_RESET))
>> - handle_modem_crash();
>> -
>> - spin_unlock_irqrestore(_lock, flags);
>> -
>> - return rv;
>> -}
>> -
>> -#ifdef CONFIG_ARCH_MSM_SCORPION
>> -
>> -int smsm_set_sleep_duration(uint32_t delay)
>> -{
>> - struct msm_dem_slave_data *ptr;
>> -
>> - ptr = smem_find(SMEM_APPS_DEM_SLAVE_DATA, sizeof(*ptr));
>> - if (ptr == NULL) {
>> -
Re: [PATCH v4 6/6] iio: imu: kmx61: Add support for any motion trigger
Daniel Baluta schrieb am 03.12.2014 um 14:31:
> We use WUFE (Wake Up from Sleep Engine) and BTSE (Back to Sleep Engine)
> to detect general motion input.
>
A few recommendations, issues and questions inline.
> Signed-off-by: Daniel Baluta
> ---
> drivers/iio/imu/kmx61.c | 433
> +++-
> 1 file changed, 426 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/iio/imu/kmx61.c b/drivers/iio/imu/kmx61.c
> index 0f6816a..972424b 100644
> --- a/drivers/iio/imu/kmx61.c
> +++ b/drivers/iio/imu/kmx61.c
> @@ -20,6 +20,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -30,6 +31,8 @@
> #define KMX61_IRQ_NAME "kmx61_event"
>
> #define KMX61_REG_WHO_AM_I 0x00
> +#define KMX61_REG_INS1 0x01
> +#define KMX61_REG_INS2 0x02
>
> /*
> * three 16-bit accelerometer output registers for X/Y/Z axis
> @@ -63,20 +66,36 @@
> #define KMX61_REG_INL0x28
> #define KMX61_REG_STBY 0x29
> #define KMX61_REG_CTRL1 0x2A
> +#define KMX61_REG_CTRL2 0x2B
> #define KMX61_REG_ODCNTL 0x2C
> #define KMX61_REG_INC1 0x2D
>
> +#define KMX61_REG_WUF_THRESH 0x3D
> +#define KMX61_REG_WUF_TIMER 0x3E
> +
> #define KMX61_ACC_STBY_BIT BIT(0)
> #define KMX61_MAG_STBY_BIT BIT(1)
> #define KMX61_ACT_STBY_BIT BIT(7)
>
> #define KMX61_ALL_STBY (KMX61_ACC_STBY_BIT |
> KMX61_MAG_STBY_BIT)
>
> +#define KMX61_REG_INS1_BIT_WUFS BIT(1)
> +
> +#define KMX61_REG_INS2_BIT_ZPBIT(0)
> +#define KMX61_REG_INS2_BIT_ZNBIT(1)
> +#define KMX61_REG_INS2_BIT_YPBIT(2)
> +#define KMX61_REG_INS2_BIT_YNBIT(3)
> +#define KMX61_REG_INS2_BIT_XPBIT(4)
> +#define KMX61_REG_INS2_BIT_XNBIT(5)
> +
> #define KMX61_REG_CTRL1_GSEL_MASK0x03
>
> #define KMX61_REG_CTRL1_BIT_RES BIT(4)
> #define KMX61_REG_CTRL1_BIT_DRDYEBIT(5)
> +#define KMX61_REG_CTRL1_BIT_WUFE BIT(6)
> +#define KMX61_REG_CTRL1_BIT_BTSE BIT(7)
>
> +#define KMX61_REG_INC1_BIT_WUFS BIT(0)
> #define KMX61_REG_INC1_BIT_DRDYM BIT(1)
> #define KMX61_REG_INC1_BIT_DRDYA BIT(2)
> #define KMX61_REG_INC1_BIT_IEN BIT(5)
> @@ -86,6 +105,11 @@
> #define KMX61_ACC_ODR_MASK 0x0F
> #define KMX61_MAG_ODR_MASK 0xF0
>
> +#define KMX61_OWUF_MASK 0x7
> +
> +#define KMX61_DEFAULT_WAKE_THRESH1
> +#define KMX61_DEFAULT_WAKE_DURATION 1
> +
> #define KMX61_SLEEP_DELAY_MS 2000
>
> #define KMX61_CHIP_ID0x12
> @@ -111,11 +135,16 @@ struct kmx61_data {
> /* config bits */
> u8 range;
> u8 odr_bits;
> + u8 wake_thresh;
> + u8 wake_duration;
>
> /* accelerometer specific data */
> struct iio_dev *acc_indio_dev;
> struct iio_trigger *acc_dready_trig;
> + struct iio_trigger *motion_trig;
> bool acc_dready_trig_on;
> + bool motion_trig_on;
> + bool ev_enable_state;
>
> /* magnetometer specific data */
> struct iio_dev *mag_indio_dev;
> @@ -154,6 +183,23 @@ static const struct {
> {3, 125000, 0x0A},
> {6, 25, 0x0B} };
>
> +static const struct {
> + int val;
> + int val2;
> + int odr_bits;
> +} kmx61_wake_up_odr_table[] = { {0, 781000, 0x00},
> + {1, 563000, 0x01},
> + {3, 125000, 0x02},
> + {6, 25, 0x03},
> + {12, 50, 0x04},
> + {25, 0, 0x05},
> + {50, 0, 0x06},
> + {100, 0, 0x06},
> + {200, 0, 0x06},
> + {400, 0, 0x06},
> + {800, 0, 0x06},
> + {1600, 0, 0x06} };
Is it intentional, that values above 50 share the same odr_bits?
> +
> static IIO_CONST_ATTR(accel_scale_available, "0.009582 0.019163 0.038326");
> static IIO_CONST_ATTR(magn_scale_available, "0.001465");
> static IIO_CONST_ATTR_SAMP_FREQ_AVAIL(
> @@ -179,6 +225,14 @@ static const struct attribute_group
> kmx61_mag_attribute_group = {
> .attrs = kmx61_mag_attributes,
> };
>
> +static const struct iio_event_spec kmx61_event = {
> + .type = IIO_EV_TYPE_THRESH,
> + .dir = IIO_EV_DIR_EITHER,
> + .mask_separate = BIT(IIO_EV_INFO_VALUE) |
> + BIT(IIO_EV_INFO_ENABLE) |
> + BIT(IIO_EV_INFO_PERIOD),
> +};
> +
> #define KMX61_ACC_CHAN(_axis) { \
> .type = IIO_ACCEL, \
> .modified = 1, \
> @@ -195,6 +249,8 @@ static const struct attribute_group
> kmx61_mag_attribute_group = {
> .shift = 4, \
> .endianness = IIO_LE, \
> }, \
> + .event_spec = _event, \
> +
Re: [PATCH] ioc3: fix incorrect use of htons/ntohs
On Mon, 2014-12-15 at 19:14 +0100, Ralf Baechle wrote:
> On Mon, Dec 01, 2014 at 04:09:36AM +, Ben Hutchings wrote:
>
> > > /* Same as tx - compute csum of pseudo header */
> > > csum = hwsum +
> > > -(ih->tot_len - (ih->ihl << 2)) +
> > > -htons((uint16_t)ih->protocol) +
> > > +(ih->tot_len - (ih->ihl << 2)) + ih->protocol +
> > > (ih->saddr >> 16) + (ih->saddr & 0x) +
> > > (ih->daddr >> 16) + (ih->daddr & 0x);
> > >
> >
> > The pseudo-header is specified as:
> >
> > +++++
> > | Source Address |
> > +++++
> > | Destination Address |
> > +++++
> > | zero | PTCL |TCP Length |
> > +++++
> >
> > The current code zero-extends the protocol number to produce the 5th
> > 16-bit word of the pseudo-header, then uses htons() to put it in
> > big-endian order, consistent with the other fields. (Yes, it's doing
> > addition on big-endian words; this works even on little-endian machines
> > due to the way the checksum is specified.)
> >
> > The driver should not be doing this at all, though. It should set
> > skb->csum = hwsum; skb->ip_summed = CHECKSUM_COMPLETE; and let the
> > network stack adjust the hardware checksum.
>
> Really? The IOC3 isn't the exactly the smartest NIC around; it does add up
> everything and the kitchen sink, that is ethernet headers, IP headers and
> on RX the frame's trailing CRC.
That is almost exactly what CHECKSUM_COMPLETE means on receive; only the
CRC would need to be subtracted. Then the driver can validate
{TCP,UDP}/IPv{4,6} checksums without any header parsing.
> All that needs to be subtracted in software
> which is what this does. I think others NICs are all smarted and don't
> need this particular piece of magic.
It may not be smart, but that allows it to cover more cases than most
smart network controllers!
On transmit, the driver should:
- Calculate the partial checksum of data up to offset csum_start
- Subtract this from the checksum at offset (csum_start + csum_offset)
It should set the NETIF_F_GEN_CSUM feature flag rather than
NETIF_F_IP_CSUM. Then it will be able to generate {TCP,UDP}/IPv{4,6}
checksums.
Ben.
> I agree with your other comment wrt. to htons().
--
Ben Hutchings
The two most common things in the universe are hydrogen and stupidity.
signature.asc
Description: This is a digitally signed message part
Re: [PATCH v2] VERIFY_OCTAL_PERMISSIONS: Move to where it belongs
Hi George, On Mon, 15 Dec 2014 14:26:15 +1030 Rusty Russell wrote: > > George Spelvin writes: > > It's the only user of in kernel.h, so that reduces > > the compile-time cost of #include > > > > Only one user has to change: . The > > there is needed for one function prototype that passes s16 parameters. > > My first reaction is to wonder if that can be gotten rid of, too. > > > > Some other extraneous header files pruned while I was at it. > > Tested with allyesconfig & allmodconfig on x86-64, just to > > be sure. Please do *not* mix changes up like this. Split this out into a separate patch, please (1 logical change per patch). And testing only on x86_64 is not "sure" when talking about header file pruning (but at least you did the "all" configs). -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpS1tHMV6E2O.pgp Description: OpenPGP digital signature
Re: [PATCH] staging: lustre: lustre: osc: lproc_osc.c: Fix for possible null pointer dereference
Hi Dan
Quite right! Had to try it.
Do nothing then?
But you must agree that it is still ugly and confusing code.
Kind regards
Rickard Strandqvist
2014-12-15 11:25 GMT+01:00 Dan Carpenter :
> On Sun, Dec 14, 2014 at 11:37:18PM +0100, Rickard Strandqvist wrote:
>> There is otherwise a risk of a possible null pointer dereference.
>>
>> Was largely found by using a static code analysis program called cppcheck.
>>
>> Signed-off-by: Rickard Strandqvist
>> ---
>> drivers/staging/lustre/lustre/osc/lproc_osc.c |4 +++-
>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/staging/lustre/lustre/osc/lproc_osc.c
>> b/drivers/staging/lustre/lustre/osc/lproc_osc.c
>> index 9f719bc..9ba6293 100644
>> --- a/drivers/staging/lustre/lustre/osc/lproc_osc.c
>> +++ b/drivers/staging/lustre/lustre/osc/lproc_osc.c
>> @@ -237,13 +237,15 @@ static ssize_t osc_cur_grant_bytes_seq_write(struct
>> file *file, const char *buff
>> size_t count, loff_t *off)
>> {
>> struct obd_device *obd = ((struct seq_file
>> *)file->private_data)->private;
>> - struct client_obd *cli = >u.cli;
>> + struct client_obd *cli;
>
> This isn't really a dereference. You're just getting the address of
> obd->u.cli. So if obd is NULL then it won't crash.
>
> 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] staging: rtl8723au: os_dep: usb_intf.c: Fix for possible null pointer dereference
Hi
No the rtw_hw_resume23a() is not used anywhere.
I also do a check of all functions that are not used, but not in the
drivers/staging, I suspected that these might be under development and
used in the future.
What do you want to do, who decides?
Kind regards
Rickard Strandqvist
2014-12-15 16:48 GMT+01:00 Jes Sorensen :
> Dan Carpenter writes:
>> On Sun, Dec 14, 2014 at 11:39:14PM +0100, Rickard Strandqvist wrote:
>>> There is otherwise a risk of a possible null pointer dereference.
>>>
>>> Was largely found by using a static code analysis program called cppcheck.
>>>
>>> Signed-off-by: Rickard Strandqvist
>>> ---
>>> drivers/staging/rtl8723au/os_dep/usb_intf.c |3 ++-
>>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/staging/rtl8723au/os_dep/usb_intf.c
>>> b/drivers/staging/rtl8723au/os_dep/usb_intf.c
>>> index 865743e..71a6330 100644
>>> --- a/drivers/staging/rtl8723au/os_dep/usb_intf.c
>>> +++ b/drivers/staging/rtl8723au/os_dep/usb_intf.c
>>> @@ -351,10 +351,11 @@ error_exit:
>>> int rtw_hw_resume23a(struct rtw_adapter *padapter)
>>
>> That's weird. Is this function even called?
>
> [jes@ultrasam jes.git]$ find drivers/staging/rtl8723au -name \*.[ch] |xargs
> grep rtw_hw_resume
> drivers/staging/rtl8723au/include/osdep_intf.h:int rtw_hw_resume23a(struct
> rtw_adapter *padapter);
> drivers/staging/rtl8723au/os_dep/usb_intf.c:int rtw_hw_resume23a(struct
> rtw_adapter *padapter)
> drivers/staging/rtl8723au/os_dep/usb_intf.c:DBG_8723A("==>
> rtw_hw_resume23a\n");
> [jes@ultrasam jes.git]$ find drivers/staging/rtl8723au -name \*.[ch] |xargs
> grep rtw_hw_suspend
> drivers/staging/rtl8723au/include/osdep_intf.h:int rtw_hw_suspend23a(struct
> rtw_adapter *padapter);
> drivers/staging/rtl8723au/os_dep/usb_intf.c:int rtw_hw_suspend23a(struct
> rtw_adapter *padapter)
> drivers/staging/rtl8723au/os_dep/usb_intf.c:DBG_8723A("==>
> rtw_hw_suspend23a\n");
>
> A more useful patch would be one removing those two functions IMHO.
>
> Jes
--
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: [perf tool] cgroup support broken on Debian?
Vince, On Mon, Dec 15, 2014 at 11:01 PM, Arnaldo Carvalho de Melo wrote: > Em Mon, Dec 15, 2014 at 04:07:46PM -0500, Vince Weaver escreveu: >> Hello >> >> has anyone tested the perf tool cgroup support recently? >> >> I was trying to get it working with a command like >> sudo perf stat -a -e cycles:u,cycles:u,cycles:u -G systemd -- sleep 1 >> It fails for me on Ubuntu Trusty as well. I think they have changed the way cgroup fs is visible. The cgroup file system type is not there anymore. They are using tmpfs which is not ideal to detect just cgroup. Looks like now, we have to look at the mount point which is flaky. >> and it just failed by unhelfully dumping the "-G" help text. >> Once I added a lot of extra debug printfs to tools/perf/util/cgroup.c >> things became a little clearer. >> >> First, you apparently need "perf_event" passed as a mount option to the >> cgroup or you cannot attach perf to it (should perf be modified to >> print a warning in this case rather than just printing the unhelpful >> helf text?) > > yes, please > Yes, the error needs to be improved or even added. The following common errors are encountered: - -G option requires -a (system-wide), otherwise it does not work at all - -G option must always be specified AFTER the ALL event list - -G and explicit event groups is not well supported by the tool yet. An event group must have the same cgroup. - Cgroups are specified per event - -G cgroup order follows the event order: -e e1, e2, e3 -G g1,g2,g3: g1->e1, g2->e2, g3->e3 - It is possible to indicate no cgroup with -G: -e e1,e2,e3 -G g1,,g3 using empty group (,,) >> Secondly, the cgroup mount point detection completely fails on my debian >> box. On my machine /proc/mounts has this: >> >> ... >> none /sys/fs/cgroup tmpfs rw,relatime,size=4k,mode=755 0 0 Yes, my Ubuntu system too. >> systemd /sys/fs/cgroup/systemd cgroup >> rw,nosuid,nodev,noexec,relatime,perf_event,name=systemd 0 0 >> >> The current perf code looks for "cgroup" in the type field to find the >> root cgroupfs tree. This fails because as seen above on my machine the >> cgroup mount has type tmpfs. And when it finds >> /sys/fs/cgroup/systemd as the root it tacks the name onto the end >> (/sys/fs/cgroup/systemd/systemd) which obviously doesn't exist. >> >> Once I hack the code to avoid that I do finally get some cgroup readings. >> >> I was checking if this was a known problem, a Debian issue, or what... > Obviously, the way cgroups are exposed has changed since I wrote the code an it needs to update. Thanks for looking into this. > Its just that the cgroup support is rough, patches are welcome to > improve the situation. > > BTW, here its fedora20, same problem: > > [root@zoo ~]# mount | grep cgroup > tmpfs on /sys/fs/cgroup type tmpfs > (rw,nosuid,nodev,noexec,seclabel,mode=755) > cgroup on /sys/fs/cgroup/systemd type cgroup > (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd) > > - Arnaldo -- 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] Docs: Modernize SubmittingPatches
No comments besides the ones Randy already mentioned. Thanks, -corey On 12/15/2014 09:52 AM, Jonathan Corbet wrote: > The SubmittingPatches file still shows a lot of its roots from the era when > we all sent stuff straight to Linus and hoped for the best. I've gone in > and thrashed it up to reflect an age where few of us type our own "diff" > commands anymore. Also added a section on preparing signed tags for pull > requests. > > Signed-off-by: Jonathan Corbet > --- > Documentation/SubmittingPatches | 433 > > 1 file changed, 212 insertions(+), 221 deletions(-) > > diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches > index 1fa1caa198eb..787d0711e18a 100644 > --- a/Documentation/SubmittingPatches > +++ b/Documentation/SubmittingPatches > @@ -10,27 +10,48 @@ kernel, the process can sometimes be daunting if you're > not familiar > with "the system." This text is a collection of suggestions which > can greatly increase the chances of your change being accepted. > > -Read Documentation/SubmitChecklist for a list of items to check > -before submitting code. If you are submitting a driver, also read > +This document contains a large number of suggestions in a relatively terse > +format. For detailed information on how the kernel development process > +works, see Documentation/development-process. Also, read > +Documentation/SubmitChecklist for a list of items to check before > +submitting code. If you are submitting a driver, also read > Documentation/SubmittingDrivers. > > Many of these steps describe the default behavior of the git version > control system; if you use git to prepare your patches, you'll find much > of the mechanical work done for you, though you'll still need to prepare > -and document a sensible set of patches. > +and document a sensible set of patches. In general, use of git will make > +your life as a kernel developer easier. > > > SECTION 1 - CREATING AND SENDING YOUR CHANGE > > > > +0) Obtain a current source tree > +--- > + > +If you do not have a repository with the current kernel source handy, use > +git to obtain one. You'll want to start with the mainline repository, > +which can be grabbed with: > + > + git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > + > +Note, however, that you may not want to develop against the mainline tree > +directly. Most subsystem maintainers run their own trees and want to see > +patches prepared against those trees. See the "T:" entry for the subsystem > +in the MAINTAINERS file to find that tree, or simply ask the maintainer if > +the tree is not listed there. > + > +It is still possible to download kernel releases via tarballs (as described > +in the next section), but that is the hard way to do kernel development. > > 1) "diff -up" > > > -Use "diff -up" or "diff -uprN" to create patches. git generates patches > -in this form by default; if you're using git, you can skip this section > -entirely. > +If you must generate your patches by hand, use "diff -up" or "diff -uprN" > +to create patches. Git generates patches in this form by default; if > +you're using git, you can skip this section entirely. > > All changes to the Linux kernel occur in the form of patches, as > generated by diff(1). When creating your patch, make sure to create it > @@ -42,7 +63,7 @@ not in any lower subdirectory. > > To create a patch for a single file, it is often sufficient to do: > > - SRCTREE= linux-2.6 > + SRCTREE= linux > MYFILE= drivers/net/mydriver.c > > cd $SRCTREE > @@ -55,17 +76,16 @@ To create a patch for multiple files, you should unpack a > "vanilla", > or unmodified kernel source tree, and generate a diff against your > own source tree. For example: > > - MYSRC= /devel/linux-2.6 > + MYSRC= /devel/linux > > - tar xvfz linux-2.6.12.tar.gz > - mv linux-2.6.12 linux-2.6.12-vanilla > - diff -uprN -X linux-2.6.12-vanilla/Documentation/dontdiff \ > - linux-2.6.12-vanilla $MYSRC > /tmp/patch > + tar xvfz linux-3.19.tar.gz > + mv linux-3.19 linux-3.19-vanilla > + diff -uprN -X linux-3.19-vanilla/Documentation/dontdiff \ > + linux-3.19-vanilla $MYSRC > /tmp/patch > > "dontdiff" is a list of files which are generated by the kernel during > the build process, and should be ignored in any diff(1)-generated > -patch. The "dontdiff" file is included in the kernel tree in > -2.6.12 and later. > +patch. > > Make sure your patch does not include any extra files which do not > belong in a patch submission. Make sure to review your patch -after- > @@ -83,6 +103,7 @@ is another popular alternative. > > > 2) Describe your changes. > +- > > Describe your problem. Whether your
Re: [PATCH] PM QoS: Add debugfs support to view the list of constraints
Dave Gerlach writes: > From: Nishanth Menon > > PM QoS requests are notoriously hard to debug and made even > more so due to their highly dynamic nature. Having visibility > into the internal data representation per constraint allows > us to have much better appreciation of potential issues or > bad usage by drivers in the system. > > So introduce for all classes of PM QoS, an entry in > /sys/kernel/debug/pm_qos that shall show all the current > requests as well as the snapshot of the value these requests > boil down to. For example: > ==> /sys/kernel/debug/pm_qos/cpu_dma_latency <== > 1: : Active > 2: 20: Default > 3: 20: Default > 4: 20: Default > Type=Minimum, Value=, Requests: active=1 / total=4 > > ==> /sys/kernel/debug/pm_qos/memory_bandwidth <== > Empty! > > ... > > The actual value listed will have their meaning based > on the QoS it is on, the 'Type' indicates what logic > it would use to collate the information - Minimum, > Maximum, or Sum. Value is the collation of all requests. > This interface also compares the values with the defaults > for the QoS class and marks the ones that are > currently active. > > Signed-off-by: Nishanth Menon > Signed-off-by: Dave Gerlach A very useful feature indeed, Acked-by: Kevin Hilman Kevin -- 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/5] ARM: at91: fix irq_pm_install_action WARNING
On Monday, December 15, 2014 11:20:17 PM Rafael J. Wysocki wrote: > On Monday, December 15, 2014 05:15:47 PM Boris Brezillon wrote: > > Commit cab303be91dc47942bc25de33dc1140123540800 [1] introduced a WARN_ON > > test which triggers a WARNING backtrace on at91 platforms. > > Pretty much as intended. > > > While this WARN_ON is absolutely necessary to warn users that they should > > not mix request with and without IRQF_NO_SUSPEND flags on shared IRQs, > > there is no easy way to solve this issue on at91 platforms. > > > > The main reason is that the init timer is often using a shared irq line > > and thus request this irq with IRQF_NO_SUSPEND flag set, while other > > peripherals request the same irq line without this flag. > > > > We could deal with that by identifying whether a given peripheral is > > connected to the init timer shared irq line and add the IRQF_NO_SUSPEND > > in this case, but this implies adding the logic in all peripheral drivers > > that could be connected to this shared irq. > > > > This series takes the reverse approach: force IRQ users to specify that > > they take care of disabling peripheral interrupts and that IRQ core can > > safely leave the handler in a suspended state without having to bother > > about spurious interrupts. > > This is done by mean of a new IRQF_SUSPEND_NOACTION flag which tells the > > core to move the action handler to a suspended list, thus preventing its > > execution when we are in suspend mode. > > Of course, specifying the IRQF_SUSPEND_NOACTION flag implies taking care > > of masking/unmasking the peripheral interrupts in the suspend/resume > > implementation. > > Well, I'm not sure how much value is in all that to be honest. The only > thing it helps with is to make the WARN_ON go away in some cases, while > the drivers in question need to make sure that they disable their interrupts > properly anyway, so what exactly is the purpose of the new irqaction > shuffling? > > It might just be simpler to add a flag to suppress the WARN_ON that would be > set by the user of IRQF_NO_SUSPEND that is broken enough to have to share the > interrupt with others ... Or even set IRFQ_NO_SUSPEND for all of the users of this interrupt and add comments to them explaining why it is set. -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] clk: samsung: Fix Exynos 5420 pinctrl setup and clock disable failure due to domain being gated
Kevin Hilman writes: > Sylwester Nawrocki writes: > >> On 09/12/14 13:59, Krzysztof Kozlowski wrote: >>> On pią, 2014-12-05 at 15:15 +0100, Krzysztof Kozlowski wrote: > Audio subsystem clocks are located in separate block. On Exynos 5420 if > clock for this block (from main clock domain) 'mau_epll' is gated then > any read or write to audss registers will block. > > This kind of boot hang was observed on Arndale Octa and Peach Pi/Pit > after introducing runtime PM to pl330 DMA driver. After that commit the > 'mau_epll' was gated, because the "amba" clock was disabled and there > were no more users of mau_epll. > > The system hang on one of steps: > 1. Disabling unused clocks from audss block. > 2. During audss GPIO setup (just before probing i2s0 because >samsung_pinmux_setup() tried to access memory from audss block which > was >gated. > > Add a workaround for this by enabling the 'mau_epll' clock in probe. > > Signed-off-by: Krzysztof Kozlowski > --- > drivers/clk/samsung/clk-exynos-audss.c | 29 > - > 1 file changed, 28 insertions(+), 1 deletion(-) >>> >>> Sorry for pinging so quick but merge window is open and it looks like >>> booting Exynos542x boards will be broken (because pl330 will no longer >>> hold adma clock enabled so whole audss domain will be gated). >>> >>> This is a non-intrusive workaround for that issue, as wanted by >>> Sylwester: >>> https://lkml.org/lkml/2014/12/5/223 >>> >>> Any comments on this? >> >> The patch looks OK to me, it would be good though if someone else >> has confirmed it fixes the bug. I don't have any clock patches queued >> at the moment. Perhaps you could apply it directly, Mike ? > > I confirm it fixes the boot hang in linux-next (next-20141210) on my > exynos5800-peach-pi and exynos5420-arndale-octa. Tested both > exynos_defconfig and multi_v7_defconfig. > > Tested-by: Kevin Hilman What's the status of this patch? linux-next is still broken for several Exynos5 platforms without this fix. Kevin -- 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] staging: lustre: lustre: obdclass: lprocfs_status.c: Fix for possible null pointer dereference
Hi Joe
No, it does not look like end can be NULL then.
Then remove the end != NULL instead?
...
if (end != NULL && *end == '.') {
However, I am hesitant to the tolower() I think double case is faster...?
Kind regards
Rickard Strandqvist
2014-12-15 2:51 GMT+01:00 Joe Perches :
> On Sun, 2014-12-14 at 23:52 +0100, Rickard Strandqvist wrote:
>> There is otherwise a risk of a possible null pointer dereference.
>>
>> Was largely found by using a static code analysis program called cppcheck.
>
> Perhaps the tool could use a little work.
> It's not possible for end to be NULL no?
>
> unsigned long long simple_strtoull(const char *cp, char **endp, unsigned int
> base)
> {
> unsigned long long result;
> unsigned int rv;
>
> cp = _parse_integer_fixup_radix(cp, );
> rv = _parse_integer(cp, base, );
> /* FIXME */
> cp += (rv & ~KSTRTOX_OVERFLOW);
>
> if (endp)
> *endp = (char *)cp;
>
> return result;
> }
> EXPORT_SYMBOL(simple_strtoull);
>
>
>> diff --git a/drivers/staging/lustre/lustre/obdclass/lprocfs_status.c
>> b/drivers/staging/lustre/lustre/obdclass/lprocfs_status.c
> []
>
> Above this:
>
> whole = simple_strtoull(pbuf, , 10);
>
>> +++ b/drivers/staging/lustre/lustre/obdclass/lprocfs_status.c
>> @@ -1897,17 +1897,19 @@ int lprocfs_write_frac_u64_helper(const char
>> *buffer, unsigned long count,
>> }
>>
>> units = 1;
>> - switch (*end) {
>> - case 'p': case 'P':
>> - units <<= 10;
>> - case 't': case 'T':
>> - units <<= 10;
>> - case 'g': case 'G':
>> - units <<= 10;
>> - case 'm': case 'M':
>> - units <<= 10;
>> - case 'k': case 'K':
>> - units <<= 10;
>> + if (end) {
>> + switch (*end) {
>> + case 'p': case 'P':
>> + units <<= 10;
>> + case 't': case 'T':
>> + units <<= 10;
>> + case 'g': case 'G':
>> + units <<= 10;
>> + case 'm': case 'M':
>> + units <<= 10;
>> + case 'k': case 'K':
>> + units <<= 10;
>> + }
>
> The only thing I might do is
>
> switch (tolower(*end)) {
>
> and remove the second case entry for each line
>
--
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] at91: fixes for 3.19 #1
Nicolas Ferre writes: > Arnd, Olof, Kevin, > > I'm sending today a "fixes" branch which somehow continues the cleanup with > only code removal. I was waiting for the arm-soc *and* pinctrl material to > reach Linus T.'s tree before sending this pull-request. In fact this sequence > was needed for the gpio header removal. The little patch about #include > deletion just follows an earlier merge conflict in arm-soc tree: I was also > waiting for this moment before sending the definitive fix, just to be sure. > > Otherwise, all is pretty straightforward. > > Oh, one more thing: it is based on the current Linus' git tree, I can > obviously > rebase everything on top of 3.19-rc1 once it is released if you prefer. Yes, waiting a bit and basing on v3.19-rc1 is preferred since none of this seems like urgent fixes needed for stuff introduced during the merge window. Thanks, Kevin -- 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 v4 3/3] vt: fix console lock vs. kernfs s_active lock order
Currently there is a lock order problem between the console lock and the
kernfs s_active lock of the console driver's bind sysfs entry. When
writing to the sysfs entry the lock order is first s_active then console
lock, when unregistering the console driver via
do_unregister_con_driver() the order is the opposite. See the below
bugzilla reference for one instance of a lockdep backtrace.
Fix this by unregistering the console driver from a deferred work, where
we can safely drop the console lock while unregistering the device and
corresponding sysfs entries (which in turn acquire s_active). Note that
we have to keep the console driver slot in the registered_con_driver
array reserved for the driver that's being unregistered until it's fully
removed. Otherwise a concurrent call to do_register_con_driver could
try to reuse the same slot and fail when registering the corresponding
device with a minor index that's still in use.
Note that the referenced bug report contains two dmesg logs with two
distinct lockdep reports: [1] is about a locking scenario involving
s_active, console_lock and the fb_notifier list lock, while [2] is
about a locking scenario involving only s_active and console_lock.
In [1] locking fb_notifier triggers the lockdep warning only because
of its dependence on console_lock, otherwise case [1] is the same
s_active<->console_lock dependency problem fixed by this patch.
Before this change we have the following locking scenarios involving
the 3 locks:
a) via do_unregister_framebuffer()->...->do_unregister_con_driver():
1. console lock 2. fb_notifier lock 3. s_active lock
b) for example via give_up_console()->do_unregister_con_driver():
1. console lock 2. s_active lock
c) via vt_bind()/vt_unbind():
1. s_active lock 2. console lock
Since c) is the console bind sysfs entry's write code path we can't
change the locking order there. We can only fix this issue by removing
s_active's dependence on the other two locks in a) and b). We can do
this only in the vt code which owns the corresponding sysfs entry, so
that after the change we have:
a) 1. console lock 2. fb_notifier lock
b) 1. console lock
c) 1. s_active lock 2. console lock
d) in the new con_driver_unregister_callback():
1. s_active lock
[1] https://bugs.freedesktop.org/attachment.cgi?id=87716
[2] https://bugs.freedesktop.org/attachment.cgi?id=107602
v2:
- get console_lock earlier in con_driver_unregister_callback(), so we
protect the following console driver field assignments there
- add code coment explaining the reason for deferring the sysfs entry
removal
- add a third paragraph to the commit message explaining why there are
two distinct lockdep reports and that this issue is independent of
fb/fbcon. (Peter Hurley)
v3:
- clarify further the third paragraph
v4:
- rebased on v4 of patch 1/3
Reference: https://bugs.freedesktop.org/show_bug.cgi?id=70523
Signed-off-by: Imre Deak
---
drivers/tty/vt/vt.c | 61 -
1 file changed, 51 insertions(+), 10 deletions(-)
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index 5d36c23..921854e 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -108,6 +108,7 @@
#define CON_DRIVER_FLAG_MODULE 1
#define CON_DRIVER_FLAG_INIT 2
#define CON_DRIVER_FLAG_ATTR 4
+#define CON_DRIVER_FLAG_ZOMBIE 8
struct con_driver {
const struct consw *con;
@@ -153,6 +154,7 @@ static int set_vesa_blanking(char __user *p);
static void set_cursor(struct vc_data *vc);
static void hide_cursor(struct vc_data *vc);
static void console_callback(struct work_struct *ignored);
+static void con_driver_unregister_callback(struct work_struct *ignored);
static void blank_screen_t(unsigned long dummy);
static void set_palette(struct vc_data *vc);
@@ -182,6 +184,7 @@ static int blankinterval = 10*60;
core_param(consoleblank, blankinterval, int, 0444);
static DECLARE_WORK(console_work, console_callback);
+static DECLARE_WORK(con_driver_unregister_work,
con_driver_unregister_callback);
/*
* fg_console is the current virtual console,
@@ -3603,7 +3606,8 @@ static int do_register_con_driver(const struct consw
*csw, int first, int last)
for (i = 0; i < MAX_NR_CON_DRIVER; i++) {
con_driver = _con_driver[i];
- if (con_driver->con == NULL) {
+ if (con_driver->con == NULL &&
+ !(con_driver->flag & CON_DRIVER_FLAG_ZOMBIE)) {
con_driver->con = csw;
con_driver->desc = desc;
con_driver->node = i;
@@ -3665,16 +3669,20 @@ int do_unregister_con_driver(const struct consw *csw)
struct con_driver *con_driver = _con_driver[i];
if (con_driver->con == csw) {
- vtconsole_deinit_device(con_driver);
- device_destroy(vtconsole_class,
- MKDEV(0, con_driver->node));
+
[PATCH v4 1/3] vt: fix check for system/busy console drivers when unregistering them
The default console driver (conswitchp) and busy drivers bound to a
console (as reported by con_is_bound()) shouldn't be unregistered.
System console drivers (without the CON_DRIVER_FLAG_MODULE flag) can be
unregistered, provided they are neither default nor busy. The current
code checks for the CON_DRIVER_FLAG_INIT flag but this doesn't make
sense: this flag is set for a driver whenever its associated console's
con_startup() function is called, which first happens when the console
driver is registered (so before the console gets bound) and gets cleared
when the console gets unbound. The purpose of this flag is to show if we
need to call con_startup() on a console before we use it.
Based on the above, do_unregister_con_driver() in its current form will
allow unregistering a console driver only if it was never bound, but
will refuse to unregister one that was bound and later unbound.
Fix this by dropping the CON_DRIVER_FLAG_INIT check, allowing
unregistering of any console driver provided that it's not the default
one and it's not busy.
v2:
- reword the third paragraph to clarify how the fix works (Peter Hurley)
v3:
- unchanged
v4:
- Allow unregistering a system console driver too, needed by i915 to
unregister vgacon. Update commit description accordingly. (Daniel)
Signed-off-by: Imre Deak
---
drivers/tty/vt/vt.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index f3fbbbc..9c046fb 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -3665,8 +3665,7 @@ int do_unregister_con_driver(const struct consw *csw)
for (i = 0; i < MAX_NR_CON_DRIVER; i++) {
struct con_driver *con_driver = _con_driver[i];
- if (con_driver->con == csw &&
- con_driver->flag & CON_DRIVER_FLAG_INIT) {
+ if (con_driver->con == csw) {
vtconsole_deinit_device(con_driver);
device_destroy(vtconsole_class,
MKDEV(0, con_driver->node));
--
1.8.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 2/3] vt: fix locking around vt_bind/vt_unbind
Currently vt_bind and vt_unbind access at least the con_driver object
and registered_con_driver array without holding the console lock. Fix
this by locking around the whole function in each case.
Signed-off-by: Imre Deak
Reviewed-by: Peter Hurley
---
drivers/tty/vt/vt.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index 9c046fb..5d36c23 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -3318,11 +3318,8 @@ static int vt_bind(struct con_driver *con)
if (first == 0 && last == MAX_NR_CONSOLES -1)
deflt = 1;
- if (first != -1) {
- console_lock();
+ if (first != -1)
do_bind_con_driver(csw, first, last, deflt);
- console_unlock();
- }
first = -1;
last = -1;
@@ -3362,9 +3359,7 @@ static int vt_unbind(struct con_driver *con)
deflt = 1;
if (first != -1) {
- console_lock();
ret = do_unbind_con_driver(csw, first, last, deflt);
- console_unlock();
if (ret != 0)
return ret;
}
@@ -3394,11 +3389,15 @@ static ssize_t store_bind(struct device *dev, struct
device_attribute *attr,
struct con_driver *con = dev_get_drvdata(dev);
int bind = simple_strtoul(buf, NULL, 0);
+ console_lock();
+
if (bind)
vt_bind(con);
else
vt_unbind(con);
+ console_unlock();
+
return count;
}
--
1.8.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [perf tool] cgroup support broken on Debian?
Em Mon, Dec 15, 2014 at 04:07:46PM -0500, Vince Weaver escreveu: > Hello > > has anyone tested the perf tool cgroup support recently? > > I was trying to get it working with a command like > sudo perf stat -a -e cycles:u,cycles:u,cycles:u -G systemd -- sleep 1 > > and it just failed by unhelfully dumping the "-G" help text. > Once I added a lot of extra debug printfs to tools/perf/util/cgroup.c > things became a little clearer. > > First, you apparently need "perf_event" passed as a mount option to the > cgroup or you cannot attach perf to it (should perf be modified to > print a warning in this case rather than just printing the unhelpful > helf text?) yes, please > Secondly, the cgroup mount point detection completely fails on my debian > box. On my machine /proc/mounts has this: > > ... > none /sys/fs/cgroup tmpfs rw,relatime,size=4k,mode=755 0 0 > systemd /sys/fs/cgroup/systemd cgroup > rw,nosuid,nodev,noexec,relatime,perf_event,name=systemd 0 0 > > The current perf code looks for "cgroup" in the type field to find the > root cgroupfs tree. This fails because as seen above on my machine the > cgroup mount has type tmpfs. And when it finds > /sys/fs/cgroup/systemd as the root it tacks the name onto the end > (/sys/fs/cgroup/systemd/systemd) which obviously doesn't exist. > > Once I hack the code to avoid that I do finally get some cgroup readings. > > I was checking if this was a known problem, a Debian issue, or what... Its just that the cgroup support is rough, patches are welcome to improve the situation. BTW, here its fedora20, same problem: [root@zoo ~]# mount | grep cgroup tmpfs on /sys/fs/cgroup type tmpfs (rw,nosuid,nodev,noexec,seclabel,mode=755) cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd) - Arnaldo -- 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/8] swap: lock i_mutex for swap_writepage direct_IO
On Mon, Dec 15, 2014 at 08:56:15AM -0800, Christoph Hellwig wrote:
> On Mon, Dec 15, 2014 at 05:27:05PM +0100, Jan Kara wrote:
> > On Sun 14-12-14 21:26:56, Omar Sandoval wrote:
> > > The generic write code locks i_mutex for a direct_IO. Swap-over-NFS
> > > doesn't grab the mutex because nfs_direct_IO doesn't expect i_mutex to
> > > be held, but most direct_IO implementations do.
> > I think you are speaking about direct IO writes only, aren't you? For DIO
> > reads we don't hold i_mutex AFAICS. And also for DIO writes we don't
> > necessarily hold i_mutex - see for example XFS which doesn't take i_mutex
> > for direct IO writes. It uses it's internal rwlock for this (see
> > xfs_file_dio_aio_write()). So I think this is just wrong.
>
> The problem is that the use of ->direct_IO by the swap code is a gross
> layering violation. ->direct_IO is a callback for the filesystem, and
> the swap code need to call ->read_iter instead of ->readpage and
> ->write_tier instead of ->direct_IO, and leave the locking to the
> filesystem.
>
Ok, I got the swap code working with ->read_iter/->write_iter without
too much trouble. I wanted to double check before I submit if there's
any gotchas involved with adding the O_DIRECT flag to a file pointer
after it has been opened -- swapon opens the swapfile before we know if
we're using the SWP_FILE infrastructure, and we need to add O_DIRECT so
->{read,write}_iter use direct I/O, but we can't add O_DIRECT to the
original open without excluding filesystems that support the old bmap
path but not direct I/O.
--
Omar
--
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] regulator: core: Support trying to get close to a certain voltage
Mark, On Fri, Dec 12, 2014 at 4:59 AM, Mark Brown wrote: >> > There's also the potential >> > performance considerations for the DVS type applications now I think >> > about it. > >> Iterating through voltages is really that slow? If so, perhaps we >> could add some caching to keep track of what voltage we actually got >> last time... I could also add an optimization to try the exact >> requested voltage right away... > > Applications like DVS get pretty performance sensitive and for a > regulator with high resolution if you're trying to hit a voltage at the > top of the range you could be iterating over a hundred or more values. OK, you've convinced me. :) > Perhaps doing something based on the various factorings out of the > voltage mapping would do the trick, add a new op for getting to the > closest voltage? I'd really rather add a new op because I think it would mean that all the old regulators that don't implement the op would be slow all of a sudden. :( I looked at trying to refactor everything, but I think the answer is that I should drop my patch and consider the existing regulator_set_voltage_tol() experience good enough. While I could go through and try to make regulator_set_voltage_tol() better: 1. It fixes no issues that I know of. On all boards that I've worked with it is possible to make VMMC and VQMMC exactly equal. 2. As you said, regulator_set_voltage_tol() is on the critical path for CPUfreq and the existing code is heavily optimized to work fast on a large number of different types of regulators. Trying to replicate that without huge code duplication and without any bugs would be difficult. I'll spin my MMC patch to use regulator_set_voltage_tol(). If Ulf responds and says that he'd like to more accurately specify the min/max voltage then I'll post up a new function using a scheme like regulator_set_voltage_tol() but asymmetric. As always, thanks for your great feedback! -Doug -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 13/14] MIPS: OCTEON: Add register definitions for OCTEON III reset unit.
Hi, On Mon, Dec 15, 2014 at 01:31:28PM -0800, David Daney wrote: > On 12/15/2014 01:09 PM, Aaro Koskinen wrote: > >Hi, > > > >On Mon, Dec 15, 2014 at 09:03:19PM +0300, Aleksey Makarov wrote: > >>From: David Daney > >> > >>Needed by follow-on patches. > > > >Looks like only one of the unions was needed (cvmx_rst_boot)...? > > This follows the form of the other register definition files. > > If Ralf requests it, we would consider deleting some of the currently unused > definitions. Most of this stuff looks like machine generated. Can you at least just make it to minimize the amount of C code it produces? What's the point of having union definitions like e.g. these: + struct cvmx_rst_boot_scn70xx; + struct cvmx_rst_boot_scn70xxp1; + struct cvmx_rst_boot_scn73xx; + struct cvmx_rst_boot_scn78xx; etc? A. -- 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/5] ARM: at91: fix irq_pm_install_action WARNING
On Monday, December 15, 2014 05:15:47 PM Boris Brezillon wrote: > Commit cab303be91dc47942bc25de33dc1140123540800 [1] introduced a WARN_ON > test which triggers a WARNING backtrace on at91 platforms. Pretty much as intended. > While this WARN_ON is absolutely necessary to warn users that they should > not mix request with and without IRQF_NO_SUSPEND flags on shared IRQs, > there is no easy way to solve this issue on at91 platforms. > > The main reason is that the init timer is often using a shared irq line > and thus request this irq with IRQF_NO_SUSPEND flag set, while other > peripherals request the same irq line without this flag. > > We could deal with that by identifying whether a given peripheral is > connected to the init timer shared irq line and add the IRQF_NO_SUSPEND > in this case, but this implies adding the logic in all peripheral drivers > that could be connected to this shared irq. > > This series takes the reverse approach: force IRQ users to specify that > they take care of disabling peripheral interrupts and that IRQ core can > safely leave the handler in a suspended state without having to bother > about spurious interrupts. > This is done by mean of a new IRQF_SUSPEND_NOACTION flag which tells the > core to move the action handler to a suspended list, thus preventing its > execution when we are in suspend mode. > Of course, specifying the IRQF_SUSPEND_NOACTION flag implies taking care > of masking/unmasking the peripheral interrupts in the suspend/resume > implementation. Well, I'm not sure how much value is in all that to be honest. The only thing it helps with is to make the WARN_ON go away in some cases, while the drivers in question need to make sure that they disable their interrupts properly anyway, so what exactly is the purpose of the new irqaction shuffling? It might just be simpler to add a flag to suppress the WARN_ON that would be set by the user of IRQF_NO_SUSPEND that is broken enough to have to share the interrupt with others ... -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- 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/3] gpio: Cygnus: define Broadcom Cygnus GPIO binding
On Monday 15 December 2014 13:35:47 Ray Jui wrote: > > Like I said previously, dynamic GPIO allocation works fine in the > kernel, as long as all of our GPIO clients in the kernel use gpiod based > API, which is what we will enforce going forward. The only problem is > with some of our customers who use GPIO through sysfs and expect fixed > global GPIO numbers. Thinking about this more, it's probably not that > difficult to add a script for those customers to convert/map the GPIO > numbers based on readings parsed from sysfs, so I guess that's fine. > I think we discussed the user space interface a number of times in the past, but I forgot the outcome. Either there is already a way to name gpio lines uniquely in sysfs, or there should be one. Can you reach the gpio interfaces using /sys/devices/0001234.bus/1234566.gpiocontroller/...? Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
