Re: [PATCH] extcon: add MAX3355 driver
On 2015년 10월 21일 03:20, Sergei Shtylyov wrote:
> Hello.
>
> On 12/18/2014 12:58 AM, Sergei Shtylyov wrote:
>
MAX3355E chip integrates a charge pump and comparators to enable a system
with
an integrated USB OTG dual-role transceiver to function as a USB OTG
dual-role
device. In addition to sensing/controlling Vbus, the chip also passes thru
the
ID signal from the USB OTG connector. On some Renesas boards, this signal
is
just fed into the SoC thru a GPIO pin -- there's no real OTG controller,
only
host and gadget USB controllers sharing the same USB bus; however, we'd
like
to allow host or gadget drivers to be loaded depending on the cable type,
hence
the need for the MAX3355 extcon driver. The Vbus status signals are also
wired
to GPIOs (however, we're not currently intested in them), the OFFVBUS#
signal
is controlled by the host controllers, there's also the SHDN# signal
wired to
GPIO, which should be high for normal operation.
>>
Signed-off-by: Sergei Shtylyov
>>
---
The patch is against the 'extcon-next' branch of the 'extcon.git' repo.
>>
Documentation/devicetree/bindings/extcon/extcon-max3355.txt | 21 ++
drivers/extcon/Kconfig |6
drivers/extcon/Makefile |1
drivers/extcon/extcon-max3355.c | 122
4 files changed, 150 insertions(+)
>>
Index: extcon/Documentation/devicetree/bindings/extcon/extcon-max3355.txt
===
--- /dev/null
+++ extcon/Documentation/devicetree/bindings/extcon/extcon-max3355.txt
@@ -0,0 +1,21 @@
+MAX3355 USB OTG chip
>>
>>> Need manufactor information as following :
>>>-> Maxim MAX3355
>>
>> Would be Maxim enough? Or perhaps I should use Maxim Integrated
>> [Products]?
>
>You haven't replied to my questions.
>
+
+
+MAX3355 integrates a charge pump and comparators to enable a system with
an
+integrated USB OTG dual-role transceiver to function as a USB OTG
dual-role
+device.
+
+Required properties:
+- compatible: should be "maxim,max3355";
+- maxim,shdn-gpio: should contain a phandle and GPIO specifier for the
GPIO pin
+ connected to the MAX3355's SHDN# pin;
+- maxim,id-gpio: should contain a phandle and GPIO specifier for the GPIO
pin
+ connected to the MAX3355's ID_OUT pin.
+
+Example (Koelsch board):
+
+usb-otg {
+compatible = "maxim,max3355";
+maxim,shdn-gpio = < 4 GPIO_ACTIVE_LOW>;
+maxim,id-gpio = < 31 GPIO_ACTIVE_HIGH>;
>>
>>> Kernel already supported the gpio helper function to get gpio from
>>> devicetree.
>>> I prefer use follwoing style by using of_get_gpio()/of_get_gpio_flags() in
>>> include/linux/of_gpio.h.
>>
>>> gpios = < 4 GPIO_ACTIVE_LOW>, < 31 GPIO_ACTIVE_HIGH>;
>>
>> OK, though Documentation/devicetree/bindings/gpio/gpio.txt does not seem
>> to insist on using this one...
>
>Moreover, it now says "gpios" isn't allowed for the new bindings. So I
> have to strongly disagree here...
OK. But, I recommend you use the 'gpiod' with devm_gpiod_get
instead of using devm_gpio_request_one() directly as following:
You can refer drivers/extcon/extcon-usb-gpio.c about using gpiod.
For example,
data->shdn_gpiod = devm_gpiod_get(dev, "maxim,shdn", GPIOD_IN);
data->id_gpiod = devm_gpiod_get(dev, "maxim,id", GPIOD_IN);
>
> [...]
>
+static irqreturn_t max3355_id_irq(int irq, void *dev_id)
+{
+struct max3355_data *data = dev_id;
+int id = gpio_get_value(data->id_gpio);
+
+extcon_set_cable_state(data->edev, "USB-HOST", !id);
>>
>>> You have to get the gpio flag in the devicetree by using of_get_gpio_flags()
>>> function
>>> and then you would set the cable state according to gpio state and flag.
>>
>> I'm sorry but I just don't see why I have to do it. This is not a generic
>> GPIO driver, and the polarities of the GPIOs are determined solely by the
>> MAX3355 specs.
>
>Again, got not reply...
OK. you don't need to consider the gpio flag from devicetree.
>
>> [...]
+static int max3355_probe(struct platform_device *pdev)
+{
+struct device_node *np = pdev->dev.of_node;
+struct max3355_data *data;
+int gpio, irq, ret;
+
+data = devm_kzalloc(>dev, sizeof(struct max3355_data),
+GFP_KERNEL);
+if (!data)
+return -ENOMEM;
+
+data->edev = devm_extcon_dev_allocate(>dev, max3355_cable);
+if (IS_ERR(data->edev)) {
+dev_err(>dev, "failed to allocate extcon device\n");
+return PTR_ERR(data->edev);
[PATCH] staging: lustre: lnet :socklnd Braces not necessary
Braces not needed for single statement block
Signed-off-by: Nilesh Kokane
---
drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c
b/drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c
index 2b08e28..471b151 100644
--- a/drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c
+++ b/drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c
@@ -2262,9 +2262,8 @@ ksocknal_base_shutdown(void)
case SOCKNAL_INIT_ALL:
case SOCKNAL_INIT_DATA:
LASSERT(ksocknal_data.ksnd_peers != NULL);
- for (i = 0; i < ksocknal_data.ksnd_peer_hash_size; i++) {
+ for (i = 0; i < ksocknal_data.ksnd_peer_hash_size; i++)
LASSERT(list_empty(_data.ksnd_peers[i]));
- }
LASSERT(list_empty(_data.ksnd_nets));
LASSERT(list_empty(_data.ksnd_enomem_conns));
--
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: [Ksummit-discuss] Linux Foundation Technical Advisory Board Elections and Nomination process
Kristen Accardi writes: > On Oct 22, 2015 7:04 PM, "Neil Brown" wrote: >> >> Darren Hart writes: >> >> > >> > Is there a good description of what is expected of a TAB member? How > much time >> > is involved? What makes a great TAB member? >> > >> > I've found: > http://www.linuxfoundation.org/programs/advisory-councils/tab >> > >> > I've read the charter and scanned some of the minutes, but I'd still > like to >> > hear from some of the "incumbants". Specifically, what makes you > successful as a >> > member of the TAB? >> >> Also on the topic of the TAB and elections, I cannot figure out what: >> >> "Only one vote per candidate will be counted." >> >> means in: >> >> Voting: >> --- >> Each person present at the time of the election shall be handed a printed >> ballot. Voters may vote for as many candidates as they wish. Only one >> vote per candidate will be counted. A space will be provided where >> they can fill out the ballot in private and place it into a box to be >> counted in private. >> >> >> in >> > http://www.linuxfoundation.org/collaborate/workgroups/technical-advisory-board-tab/minutes-july-2015-tab-meeting >> >> Is it "Only one vote per candidate per voter will be counted"? > > Sorry this was a bit confusing. Basically, it means you can vote for as > many candidates as you like, but if you can't vote multiple times for the > same candidate on your ballot. Thanks. That was the only explanation I could come up with that made any sense, but it definitely isn't obvious (to me) that that is the meaning of the words. Thanks, NeilBrown signature.asc Description: PGP signature
[PATCH v3 1/3] leds: rt5033: Add DT binding for RT5033
This patch adds the device tree bindings for RT5033 flash LEDs.
Signed-off-by: Ingi Kim
Acked-by: Rob Herring
---
.../devicetree/bindings/leds/leds-rt5033.txt | 38 ++
1 file changed, 38 insertions(+)
create mode 100644 Documentation/devicetree/bindings/leds/leds-rt5033.txt
diff --git a/Documentation/devicetree/bindings/leds/leds-rt5033.txt
b/Documentation/devicetree/bindings/leds/leds-rt5033.txt
new file mode 100644
index 000..2ef7bdc
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/leds-rt5033.txt
@@ -0,0 +1,38 @@
+* Richtek Technology Corporation - RT5033 Flash LED Driver
+
+The RT5033 Flash LED Circuit is designed for one or two LEDs driving
+for torch and strobe applications, it provides an I2C software command
+to trigger the torch and strobe operation.
+
+Required properties:
+- compatible : Must be "richtek,rt5033-led".
+
+A discrete LED element connected to the device must be represented by a child
+node - see Documentation/devicetree/bindings/leds/common.txt.
+
+Required properties of the LED child node:
+ See Documentation/devicetree/bindings/leds/common.txt
+- led-max-microamp : Minimum Threshold for Timer protection
+ is defined internally (Maximum 200mA).
+- flash-max-microamp : Flash LED maximum current
+- flash-max-timeout-us : Flash LED maximum timeout
+
+Optional properties of the LED child node:
+- label : see Documentation/devicetree/bindings/leds/common.txt
+
+Example:
+
+rt5033 {
+ compatible = "richtek,rt5033";
+
+ led {
+ compatible = "richtek,rt5033-led";
+
+ flash-led {
+ label = "rt5033-flash";
+ led-max-microamp = <20>;
+ flash-max-microamp = <80>;
+ flash-max-timeout-us = <1216000>;
+ };
+ };
+}
--
2.0.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 v3 3/3] leds: rt5033: Add RT5033 Flash led device driver
This patch adds device driver of Richtek RT5033 PMIC.
The driver supports a current regulated output to drive
white LEDs for camera flash.
Signed-off-by: Ingi Kim
---
drivers/leds/Kconfig | 8 +
drivers/leds/Makefile | 1 +
drivers/leds/leds-rt5033.c | 314 +
include/linux/mfd/rt5033-private.h | 49 ++
include/linux/mfd/rt5033.h | 13 ++
5 files changed, 385 insertions(+)
create mode 100644 drivers/leds/leds-rt5033.c
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 42990f2..29613e3 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -345,6 +345,14 @@ config LEDS_PCA963X
LED driver chip accessed via the I2C bus. Supported
devices include PCA9633 and PCA9634
+config LEDS_RT5033
+ tristate "LED support for RT5033 PMIC"
+ depends on LEDS_CLASS_FLASH && OF
+ depends on MFD_RT5033
+ help
+ This option enables support for on-chip LED driver on
+ RT5033 PMIC.
+
config LEDS_WM831X_STATUS
tristate "LED support for status LEDs on WM831x PMICs"
depends on LEDS_CLASS
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index b503f92..bcc4d93 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -23,6 +23,7 @@ obj-$(CONFIG_LEDS_COBALT_QUBE)+=
leds-cobalt-qube.o
obj-$(CONFIG_LEDS_COBALT_RAQ) += leds-cobalt-raq.o
obj-$(CONFIG_LEDS_SUNFIRE) += leds-sunfire.o
obj-$(CONFIG_LEDS_PCA9532) += leds-pca9532.o
+obj-$(CONFIG_LEDS_RT5033) += leds-rt5033.o
obj-$(CONFIG_LEDS_GPIO_REGISTER) += leds-gpio-register.o
obj-$(CONFIG_LEDS_GPIO)+= leds-gpio.o
obj-$(CONFIG_LEDS_LP3944) += leds-lp3944.o
diff --git a/drivers/leds/leds-rt5033.c b/drivers/leds/leds-rt5033.c
new file mode 100644
index 000..4ba1ec6
--- /dev/null
+++ b/drivers/leds/leds-rt5033.c
@@ -0,0 +1,314 @@
+/*
+ * led driver for RT5033
+ *
+ * Copyright (C) 2015 Samsung Electronics, Co., Ltd.
+ * Ingi 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
+
+#define RT5033_LED_FLASH_TIMEOUT_MIN 64000
+#define RT5033_LED_FLASH_TIMEOUT_STEP 32000
+#define RT5033_LED_FLASH_BRIGHTNESS_MIN5
+#define RT5033_LED_FLASH_BRIGHTNESS_STEP 25000
+#define RT5033_LED_TORCH_BRIGHTNESS_MIN12500
+#define RT5033_LED_TORCH_BRIGHTNESS_STEP 12500
+
+/* Macro to get offset of rt5033_led_config_data */
+#define RT5033_LED_CONFIG_DATA_OFFSET(val, step, min) (((val) - (min)) \
+ / (step))
+
+struct rt5033_led_config_data {
+ u32 flash_max_microamp;
+ u32 flash_max_timeout;
+ u32 torch_max_microamp;
+};
+
+static struct rt5033_led *flcdev_to_led(
+ struct led_classdev_flash *fled_cdev)
+{
+ return container_of(fled_cdev, struct rt5033_led, fled_cdev);
+}
+
+static void rt5033_brightness_set(struct rt5033_led *led,
+ enum led_brightness brightness)
+{
+ mutex_lock(>lock);
+
+ if (!brightness) {
+ regmap_update_bits(led->regmap, RT5033_REG_FLED_FUNCTION2,
+ RT5033_FLED_FUNC2_MASK, 0x0);
+ } else {
+ regmap_update_bits(led->regmap, RT5033_REG_FLED_FUNCTION1,
+ RT5033_FLED_FUNC1_MASK, RT5033_FLED_PINCTRL);
+ regmap_update_bits(led->regmap, RT5033_REG_FLED_CTRL1,
+ RT5033_FLED_CTRL1_MASK,
+ (brightness - 1) << 4);
+ regmap_update_bits(led->regmap, RT5033_REG_FLED_FUNCTION2,
+ RT5033_FLED_FUNC2_MASK, RT5033_FLED_ENFLED);
+ }
+
+ mutex_unlock(>lock);
+}
+
+static void rt5033_brightness_set_work(struct work_struct *work)
+{
+ struct rt5033_led *led =
+ container_of(work, struct rt5033_led, work_brightness_set);
+
+ rt5033_brightness_set(led, led->torch_brightness);
+}
+
+static void rt5033_led_brightness_set(struct led_classdev *led_cdev,
+ enum led_brightness brightness)
+{
+ struct led_classdev_flash *fled_cdev = lcdev_to_flcdev(led_cdev);
+ struct rt5033_led *led = flcdev_to_led(fled_cdev);
+
+ led->torch_brightness = brightness;
+ schedule_work(>work_brightness_set);
+}
+
+static int rt5033_led_brightness_set_sync(struct led_classdev *led_cdev,
+ enum led_brightness brightness)
+{
+ struct led_classdev_flash *fled_cdev = lcdev_to_flcdev(led_cdev);
+ struct rt5033_led *led =
Re: [PATCH] pinctrl-zynq: Initialize early
On Fri, 2015-10-23 at 07:43AM +0200, Mike Looijmans wrote: > On 23-10-15 07:31, Mike Looijmans wrote: > >On 22-10-15 18:07, Sören Brinkmann wrote: > >>Hi Mike, > >> > >>On Thu, 2015-10-22 at 01:30PM +0200, Mike Looijmans wrote: > >>>Supplying pinmux configuration for e.g. gpio pins leads to deferred > >>>probes because the pinctrl device is probed much later than gpio. > >>>Move the init call to a much earlier stage so it probes before the > >>>devices that may need it. > >>> > >>>Signed-off-by: Mike Looijmans > >> > >>in general, the change should be OK, but neither on zc702 nor zc706 do I > >>see a difference in respect to deferred probes. With and without the > >>patch I see: > >> root@zynq:~# dmesg | grep -i defer > >> [0.097021] zynq-gpio e000a000.gpio: could not find pctldev for node > >>/amba/slcr@f800/pinctrl@700/gpio0-default, deferring probe > >> root@zynq:~# > >> > >>If you have a case this patch improves things though, feel free to add my > >>Tested-by: Sören Brinkmann > >> > > > >On the Florida boards there are i2c controlled clocks, power supplies and > >reset signals. Replacing the Cadence I2C controller with a GPIO-bitbang > >controller solved the I2C problems but caused a storm of dozens of deferred > >probes because of the pinmux driver arriving even after the first probe > >attempt of the i2c bus driver. Moving the pinmux driver to an earlier stage > >solved that problem neatly, now the "zynq-pinctrl 700.pinctrl: zynq pinctrl > >initialized" message appears after the OCM driver. > >Judging from your comment the GPIO driver still probes earlier (I don't have > >any GPIO-only pinmuxes yet), so maybe we should amend the patch to probe even > >earlier. The pinmux driver doesn't depend on anything, so it can potentially > >probe very early. What do you think? > > Minor addition: > The gpio-zynq driver probes at "postcore_initcall", so to beat that, the > zynq-pinmux driver should move to "core_initcall" (instead of > "arch_initcall"). That would make the gpio deferral go away. > > An alternative would be to move the gpio driver to "arch", then "postcore" > would be enough for the pinmux. If the gpio probe gets deferred, it > apparently has already been moved to below "subsys" already, with aparently > no ill effects. Makes me wonder whether a single deferred probe is worth the risk of breaking something by moving these things around. But probably worth a try. Sören -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] mfd: rt5033: Add RT5033 Flash led sub device
This patch adds rt5033-led sub device to support it.
Signed-off-by: Ingi Kim
Acked-by: Lee Jones
---
drivers/mfd/rt5033.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/mfd/rt5033.c b/drivers/mfd/rt5033.c
index d60f916..035421c 100644
--- a/drivers/mfd/rt5033.c
+++ b/drivers/mfd/rt5033.c
@@ -47,6 +47,9 @@ static const struct mfd_cell rt5033_devs[] = {
}, {
.name = "rt5033-battery",
.of_compatible = "richtek,rt5033-battery",
+ }, {
+ .name = "rt5033-led",
+ .of_compatible = "richtek,rt5033-led",
},
};
--
2.0.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 v3 0/3] Add RT5033 Flash LED driver
This patch supports flash led of RT5033 PMIC. Changes since v3: - Use mutex and work queue - Split brightness set func (sync / async) - Add flash API (flash_brightness_set) - Move struct(rt5033_led_config_data) to local area - Code clean Changes since v2: - Split MFC code from rt5033 flash led patch - Fix typo error - Change naming of mfd register back again - Fix compile error Ingi Kim (3): leds: rt5033: Add DT binding for RT5033 mfd: rt5033: Add RT5033 Flash led sub device leds: rt5033: Add RT5033 Flash led device driver .../devicetree/bindings/leds/leds-rt5033.txt | 38 +++ drivers/leds/Kconfig | 8 + drivers/leds/Makefile | 1 + drivers/leds/leds-rt5033.c | 314 + drivers/mfd/rt5033.c | 3 + include/linux/mfd/rt5033-private.h | 49 include/linux/mfd/rt5033.h | 13 + 7 files changed, 426 insertions(+) create mode 100644 Documentation/devicetree/bindings/leds/leds-rt5033.txt create mode 100644 drivers/leds/leds-rt5033.c -- 2.0.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pinctrl-zynq: Initialize early
On Fri, 2015-10-23 at 07:31AM +0200, Mike Looijmans wrote: > On 22-10-15 18:07, Sören Brinkmann wrote: > >Hi Mike, > > > >On Thu, 2015-10-22 at 01:30PM +0200, Mike Looijmans wrote: > >>Supplying pinmux configuration for e.g. gpio pins leads to deferred > >>probes because the pinctrl device is probed much later than gpio. > >>Move the init call to a much earlier stage so it probes before the > >>devices that may need it. > >> > >>Signed-off-by: Mike Looijmans > > > >in general, the change should be OK, but neither on zc702 nor zc706 do I > >see a difference in respect to deferred probes. With and without the > >patch I see: > > root@zynq:~# dmesg | grep -i defer > > [0.097021] zynq-gpio e000a000.gpio: could not find pctldev for node > > /amba/slcr@f800/pinctrl@700/gpio0-default, deferring probe > > root@zynq:~# > > > >If you have a case this patch improves things though, feel free to add my > >Tested-by: Sören Brinkmann > > > > On the Florida boards there are i2c controlled clocks, power supplies and > reset signals. Replacing the Cadence I2C controller with a GPIO-bitbang > controller solved the I2C problems but caused a storm of dozens of deferred > probes because of the pinmux driver arriving even after the first probe > attempt of the i2c bus driver. Moving the pinmux driver to an earlier stage > solved that problem neatly, now the "zynq-pinctrl 700.pinctrl: zynq pinctrl > initialized" message appears after the OCM driver. OK, makes sense. Thanks for the background. > Judging from your comment the GPIO driver still probes earlier (I don't have > any GPIO-only pinmuxes yet), so maybe we should amend the patch to probe > even earlier. The pinmux driver doesn't depend on anything, so it can > potentially probe very early. What do you think? I'm pretty neutral on this one :) Hasn't the probe deferral mechanism been introduced to avoid having to create ordering through the initcall stages? But I agree, having the probe deferral notices is not particularly pretty. So, I'd definitely not oppose changing this. Though, there is one dependency on the SLCR regmap, but that is initialized fairly early. Sören -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] pinctrl-zynq: Initialize early
On 23-10-15 07:31, Mike Looijmans wrote: On 22-10-15 18:07, Sören Brinkmann wrote: Hi Mike, On Thu, 2015-10-22 at 01:30PM +0200, Mike Looijmans wrote: Supplying pinmux configuration for e.g. gpio pins leads to deferred probes because the pinctrl device is probed much later than gpio. Move the init call to a much earlier stage so it probes before the devices that may need it. Signed-off-by: Mike Looijmans in general, the change should be OK, but neither on zc702 nor zc706 do I see a difference in respect to deferred probes. With and without the patch I see: root@zynq:~# dmesg | grep -i defer [0.097021] zynq-gpio e000a000.gpio: could not find pctldev for node /amba/slcr@f800/pinctrl@700/gpio0-default, deferring probe root@zynq:~# If you have a case this patch improves things though, feel free to add my Tested-by: Sören Brinkmann On the Florida boards there are i2c controlled clocks, power supplies and reset signals. Replacing the Cadence I2C controller with a GPIO-bitbang controller solved the I2C problems but caused a storm of dozens of deferred probes because of the pinmux driver arriving even after the first probe attempt of the i2c bus driver. Moving the pinmux driver to an earlier stage solved that problem neatly, now the "zynq-pinctrl 700.pinctrl: zynq pinctrl initialized" message appears after the OCM driver. Judging from your comment the GPIO driver still probes earlier (I don't have any GPIO-only pinmuxes yet), so maybe we should amend the patch to probe even earlier. The pinmux driver doesn't depend on anything, so it can potentially probe very early. What do you think? Minor addition: The gpio-zynq driver probes at "postcore_initcall", so to beat that, the zynq-pinmux driver should move to "core_initcall" (instead of "arch_initcall"). That would make the gpio deferral go away. An alternative would be to move the gpio driver to "arch", then "postcore" would be enough for the pinmux. If the gpio probe gets deferred, it apparently has already been moved to below "subsys" already, with aparently no ill effects. Mike. Kind regards, Mike Looijmans System Expert TOPIC Embedded Products Eindhovenseweg 32-C, NL-5683 KH Best Postbus 440, NL-5680 AK Best Telefoon: +31 (0) 499 33 69 79 Telefax: +31 (0) 499 33 69 70 E-mail: mike.looijm...@topicproducts.com Website: www.topicproducts.com Please consider the environment before printing this e-mail Visit us at : Aerospace Electrical Systems Expo Europe which will be held from 17.11.2015 till 19.11.2015, Findorffstrasse 101 Bremen, Germany, Hall 5, stand number C65 http://www.aesexpo.eu -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] libata: add support for NCQ commands for SG interface
Hello, On Fri, Oct 23, 2015 at 10:01:35AM +0530, Vinayak Kale wrote: > > It looks like it'd work given that it's forcing qc->tag into > > tf->nsect. What's the use case tho? > > We need to issue NCQ commands with priority bit from user space application. > > BTW, Sergei Shtylyov raised concern regarding usefulness of adding > ATA_TFLAG_LBA to tf->flags. Can you please comment on that as well? > Accordingly I will either keep it or discard it in V2. Thanks. I like the change but can you please put that in a separate patch? Also, can you please verify that this works fine with multiple regular NCQ commands in flight? Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 03/60] sparc/PCI: Unify pci_register_region()
On Thu, Oct 22, 2015 at 02:47:42PM +1100, Benjamin Herrenschmidt wrote: > On Wed, 2015-10-21 at 18:27 -0700, David Miller wrote: > > From: Yinghai Lu > > Date: Wed, 21 Oct 2015 11:16:53 -0700 > > > > > otherwise we need to compare res with pbm->mem_space or pbm > > ->mem64_space > > > to get direct parent for request_resource_conflict() calling in > > > pci_register_legacy_regions(). > > > > Right, this is the issue. > > > > On sparc64, the cpu physical base address used for accessing 64-bit > > and non-64-bit memory spaces is different. > > > > And that's why the resource values will be different. > > This is the same on power btw, we have separate PowerBus windows to the > PHB that get mapped respectively to 32-bit PCI MMIO and 64-bit PCI > MMIO. The former gets "remapped" to generates 0-based PCI cycles, while > the latter is 1:1. So the offset between CPU and PCI changes depending > on which window you hit. Lots of architectures do this, and the PCI core supports it by keeping a list of all the host bridge windows. Each entry has a struct resource that contains the CPU address, as well as the offset from the CPU address to the PCI address. The arch or host bridge driver uses pci_add_resource_offset() to tell the core about the window and the offset. Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v7] can: xilinx: Convert to runtime_pm
Instead of enabling/disabling clocks at several locations in the driver,
Use the runtime_pm framework. This consolidates the actions for runtime PM
In the appropriate callbacks and makes the driver more readable and mantainable.
Signed-off-by: Kedareswara rao Appana
---
Changes for v7:
- Removed the unnecessary clk_prepare/clk_unprepare calls
From the probe and remove as suggested by Soren.
Changes for v6:
- Updated the driver with review comments as suggested by Marc.
Changes for v5:
- Updated with the review comments.
Updated the remove fuction to use runtime_pm.
Chnages for v4:
- Updated with the review comments.
Changes for v3:
- Converted the driver to use runtime_pm.
Changes for v2:
- Removed the struct platform_device* from suspend/resume
as suggest by Lothar.
drivers/net/can/xilinx_can.c | 177 +--
1 file changed, 102 insertions(+), 75 deletions(-)
diff --git a/drivers/net/can/xilinx_can.c b/drivers/net/can/xilinx_can.c
index fc55e8e..fcb584f 100644
--- a/drivers/net/can/xilinx_can.c
+++ b/drivers/net/can/xilinx_can.c
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#define DRIVER_NAME"xilinx_can"
@@ -138,7 +139,7 @@ struct xcan_priv {
u32 (*read_reg)(const struct xcan_priv *priv, enum xcan_reg reg);
void (*write_reg)(const struct xcan_priv *priv, enum xcan_reg reg,
u32 val);
- struct net_device *dev;
+ struct device *dev;
void __iomem *reg_base;
unsigned long irq_flags;
struct clk *bus_clk;
@@ -843,6 +844,13 @@ static int xcan_open(struct net_device *ndev)
struct xcan_priv *priv = netdev_priv(ndev);
int ret;
+ ret = pm_runtime_get_sync(priv->dev);
+ if (ret < 0) {
+ netdev_err(ndev, "%s: pm_runtime_get failed(%d)\n",
+ __func__, ret);
+ return ret;
+ }
+
ret = request_irq(ndev->irq, xcan_interrupt, priv->irq_flags,
ndev->name, ndev);
if (ret < 0) {
@@ -850,29 +858,17 @@ static int xcan_open(struct net_device *ndev)
goto err;
}
- ret = clk_prepare_enable(priv->can_clk);
- if (ret) {
- netdev_err(ndev, "unable to enable device clock\n");
- goto err_irq;
- }
-
- ret = clk_prepare_enable(priv->bus_clk);
- if (ret) {
- netdev_err(ndev, "unable to enable bus clock\n");
- goto err_can_clk;
- }
-
/* Set chip into reset mode */
ret = set_reset_mode(ndev);
if (ret < 0) {
netdev_err(ndev, "mode resetting failed!\n");
- goto err_bus_clk;
+ goto err_irq;
}
/* Common open */
ret = open_candev(ndev);
if (ret)
- goto err_bus_clk;
+ goto err_irq;
ret = xcan_chip_start(ndev);
if (ret < 0) {
@@ -888,13 +884,11 @@ static int xcan_open(struct net_device *ndev)
err_candev:
close_candev(ndev);
-err_bus_clk:
- clk_disable_unprepare(priv->bus_clk);
-err_can_clk:
- clk_disable_unprepare(priv->can_clk);
err_irq:
free_irq(ndev->irq, ndev);
err:
+ pm_runtime_put(priv->dev);
+
return ret;
}
@@ -911,12 +905,11 @@ static int xcan_close(struct net_device *ndev)
netif_stop_queue(ndev);
napi_disable(>napi);
xcan_chip_stop(ndev);
- clk_disable_unprepare(priv->bus_clk);
- clk_disable_unprepare(priv->can_clk);
free_irq(ndev->irq, ndev);
close_candev(ndev);
can_led_event(ndev, CAN_LED_EVENT_STOP);
+ pm_runtime_put(priv->dev);
return 0;
}
@@ -935,27 +928,20 @@ static int xcan_get_berr_counter(const struct net_device
*ndev,
struct xcan_priv *priv = netdev_priv(ndev);
int ret;
- ret = clk_prepare_enable(priv->can_clk);
- if (ret)
- goto err;
-
- ret = clk_prepare_enable(priv->bus_clk);
- if (ret)
- goto err_clk;
+ ret = pm_runtime_get_sync(priv->dev);
+ if (ret < 0) {
+ netdev_err(ndev, "%s: pm_runtime_get failed(%d)\n",
+ __func__, ret);
+ return ret;
+ }
bec->txerr = priv->read_reg(priv, XCAN_ECR_OFFSET) & XCAN_ECR_TEC_MASK;
bec->rxerr = ((priv->read_reg(priv, XCAN_ECR_OFFSET) &
XCAN_ECR_REC_MASK) >> XCAN_ESR_REC_SHIFT);
- clk_disable_unprepare(priv->bus_clk);
- clk_disable_unprepare(priv->can_clk);
+ pm_runtime_put(priv->dev);
return 0;
-
-err_clk:
- clk_disable_unprepare(priv->can_clk);
-err:
- return ret;
}
@@ -968,15 +954,45 @@ static const struct net_device_ops xcan_netdev_ops = {
/**
* xcan_suspend - Suspend method for the driver
- * @dev: Address of the platform_device structure
+ * @dev: Address of
Re: [PATCH 1/2] i2c: designware: register clkdev during acpi device configuration
On Wed, 2015-10-21 at 13:46 +0300, Mika Westerberg wrote:
> You are saying that the original commit a445900c906092 ("i2c:
> designware: Add support for AMD I2C controller") actually never worked
> because it failed to register the clock with clkdev? In that case it is
> not even a regression ;-) Oh my...
You are right :-). The new patch for reverting a445900c906092 is
submitted.
Please help to review. 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 1/1] i2c: designware: reverts "i2c: designware: Add support for AMD I2C controller"
The patch reverts commit a445900c9060 (i2c: designware: Add support for
AMD I2C controller)
Since kernel starts to support APD(drivers/acpi/acpi_apd.c), there is
no need to get freq from id->driver_data for AMD0010. clkdev is supposed
to be already registered in APD.
So, revert old design and make AMD0010 looks like other ones.
Signed-off-by: Ken Xue
Signed-off-by: Xiangliang Yu
---
drivers/i2c/busses/i2c-designware-platdrv.c | 27 +--
1 file changed, 1 insertion(+), 26 deletions(-)
diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c
b/drivers/i2c/busses/i2c-designware-platdrv.c
index 472b882..4bf5fc1 100644
--- a/drivers/i2c/busses/i2c-designware-platdrv.c
+++ b/drivers/i2c/busses/i2c-designware-platdrv.c
@@ -97,7 +97,6 @@ static void dw_i2c_acpi_params(struct platform_device *pdev,
char method[],
static int dw_i2c_acpi_configure(struct platform_device *pdev)
{
struct dw_i2c_dev *dev = platform_get_drvdata(pdev);
- const struct acpi_device_id *id;
dev->adapter.nr = -1;
dev->tx_fifo_depth = 32;
@@ -111,29 +110,9 @@ static int dw_i2c_acpi_configure(struct platform_device
*pdev)
dw_i2c_acpi_params(pdev, "FMCN", >fs_hcnt, >fs_lcnt,
>sda_hold_time);
- /*
-* Provide a way for Designware I2C host controllers that are not
-* based on Intel LPSS to specify their input clock frequency via
-* id->driver_data.
-*/
- id = acpi_match_device(pdev->dev.driver->acpi_match_table, >dev);
- if (id && id->driver_data)
- clk_register_fixed_rate(>dev, dev_name(>dev), NULL,
- CLK_IS_ROOT, id->driver_data);
-
return 0;
}
-static void dw_i2c_acpi_unconfigure(struct platform_device *pdev)
-{
- struct dw_i2c_dev *dev = platform_get_drvdata(pdev);
- const struct acpi_device_id *id;
-
- id = acpi_match_device(pdev->dev.driver->acpi_match_table, >dev);
- if (id && id->driver_data)
- clk_unregister(dev->clk);
-}
-
static const struct acpi_device_id dw_i2c_acpi_match[] = {
{ "INT33C2", 0 },
{ "INT33C3", 0 },
@@ -141,7 +120,7 @@ static const struct acpi_device_id dw_i2c_acpi_match[] = {
{ "INT3433", 0 },
{ "80860F41", 0 },
{ "808622C1", 0 },
- { "AMD0010", 133 * 1000 * 1000 },
+ { "AMD0010", 0 },
{ }
};
MODULE_DEVICE_TABLE(acpi, dw_i2c_acpi_match);
@@ -150,7 +129,6 @@ static inline int dw_i2c_acpi_configure(struct
platform_device *pdev)
{
return -ENODEV;
}
-static inline void dw_i2c_acpi_unconfigure(struct platform_device *pdev) { }
#endif
static int dw_i2c_probe(struct platform_device *pdev)
@@ -306,9 +284,6 @@ static int dw_i2c_remove(struct platform_device *pdev)
pm_runtime_put_sync(>dev);
pm_runtime_disable(>dev);
- if (has_acpi_companion(>dev))
- dw_i2c_acpi_unconfigure(pdev);
-
return 0;
}
--
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] Staging: lustre: lnet :socklnd return statement in void function not useful
Return function in void function is not needed. Signed-off-by: Nilesh Kokane --- drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c b/drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c index 4128a92..2b08e28 100644 --- a/drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c +++ b/drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c @@ -1838,7 +1838,6 @@ ksocknal_query(lnet_ni_t *ni, lnet_nid_t nid, unsigned long *when) ksocknal_launch_all_connections_locked(peer); write_unlock_bh(glock); - return; } static 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/
Re: [PATCH v11 3/6] pci:host: Add Altera PCIe host controller driver
Hi Ley,
On Thu, Oct 22, 2015 at 05:27:28PM +0800, Ley Foon Tan wrote:
> This patch adds the Altera PCIe host controller driver.
> +static void altera_pcie_fixups(struct pci_bus *bus)
> +{
> + struct pci_dev *dev;
> +
> + list_for_each_entry(dev, >devices, bus_list) {
> + altera_pcie_retrain(dev);
> + altera_pcie_fixup_res(dev);
> + }
> +}
I'd really like to avoid this particular fixup because it's done
between pci_scan_root_bus() and pci_assign_unassigned_bus_resources()
and pci_bus_add_devices(). That path is almost 100% arch-independent,
and someday we should be able to pull all that out into one PCI core
interface.
You might be able to do the link retrain fixup as a header quirk.
That's not really ideal either, but I don't think we have a good
mechanism of inserting per-host bridge hooks in the enumeration path.
There are some pcibios_*() hooks, but those are per-arch, not per-host
bridge, so they're not really what you want here.
I think other host drivers have handled the "prevent enumeration of
root complex resources" problem by adding a similar check in the
config accessors.
> +static int altera_pcie_cfg_write(struct pci_bus *bus, unsigned int devfn,
> + int where, int size, u32 value)
This needs a comment to the effect that this hardware can only generate
32-bit config accesses. We also need a printk in the probe routine so
there's a note in dmesg so we have a clue that RW1C bits in config space
may be corrupted.
> +{
> + struct altera_pcie *pcie = bus->sysdata;
> + u32 data32;
> + u32 shift = 8 * (where & 3);
> + u8 byte_en;
> +
> + if (!altera_pcie_valid_config(pcie, bus, PCI_SLOT(devfn)))
> + return PCIBIOS_DEVICE_NOT_FOUND;
> +
> + switch (size) {
> + case 1:
> + data32 = (value & 0xff) << shift;
> + byte_en = 1 << (where & 3);
> + break;
> + case 2:
> + data32 = (value & 0x) << shift;
> + byte_en = 3 << (where & 3);
> + break;
> + default:
> + data32 = value;
> + byte_en = 0xf;
> + break;
> + }
> +
> + return tlp_cfg_dword_write(pcie, bus->number, devfn,
> + (where & ~DWORD_MASK), byte_en, data32);
> +}
> +static void altera_pcie_isr(struct irq_desc *desc)
> +{
> + struct irq_chip *chip = irq_desc_get_chip(desc);
> + struct altera_pcie *pcie;
> + unsigned long status;
> + u32 bit;
> + u32 virq;
> +
> + chained_irq_enter(chip, desc);
> + pcie = irq_desc_get_handler_data(desc);
> +
> + while ((status = cra_readl(pcie, P2A_INT_STATUS)
> + & P2A_INT_STS_ALL) != 0) {
> + for_each_set_bit(bit, , INTX_NUM) {
> + /* clear interrupts */
> + cra_writel(pcie, 1 << bit, P2A_INT_STATUS);
> +
> + virq = irq_find_mapping(pcie->irq_domain, bit + 1);
> + if (virq)
> + generic_handle_irq(virq);
> + else
> + dev_err(>pdev->dev, "unexpected IRQ\n");
Include the bit number here. A printk string with no % substitutions
is rarely as useful as it could be.
> ...
> + bus = pci_scan_root_bus(>dev, pcie->root_bus_nr, _pcie_ops,
> + pcie, >resources);
> + if (!bus)
> + return -ENOMEM;
> +
> + altera_pcie_fixups(bus);
> + pci_fixup_irqs(pci_common_swizzle, of_irq_parse_and_map_pci);
> + pci_assign_unassigned_bus_resources(bus);
> + pci_bus_add_devices(bus);
> +
> + /* Configure PCI Express setting. */
> + list_for_each_entry(child, >children, node)
> + pcie_bus_configure_settings(child);
This loop should be before pci_bus_add_devices(). When we call
pci_bus_add_devices(), drivers may claim devices immediately, and the
PCI core shouldn't be changing device configuration while a driver
owns the device.
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] pinctrl-zynq: Initialize early
On 22-10-15 18:07, Sören Brinkmann wrote: Hi Mike, On Thu, 2015-10-22 at 01:30PM +0200, Mike Looijmans wrote: Supplying pinmux configuration for e.g. gpio pins leads to deferred probes because the pinctrl device is probed much later than gpio. Move the init call to a much earlier stage so it probes before the devices that may need it. Signed-off-by: Mike Looijmans in general, the change should be OK, but neither on zc702 nor zc706 do I see a difference in respect to deferred probes. With and without the patch I see: root@zynq:~# dmesg | grep -i defer [0.097021] zynq-gpio e000a000.gpio: could not find pctldev for node /amba/slcr@f800/pinctrl@700/gpio0-default, deferring probe root@zynq:~# If you have a case this patch improves things though, feel free to add my Tested-by: Sören Brinkmann On the Florida boards there are i2c controlled clocks, power supplies and reset signals. Replacing the Cadence I2C controller with a GPIO-bitbang controller solved the I2C problems but caused a storm of dozens of deferred probes because of the pinmux driver arriving even after the first probe attempt of the i2c bus driver. Moving the pinmux driver to an earlier stage solved that problem neatly, now the "zynq-pinctrl 700.pinctrl: zynq pinctrl initialized" message appears after the OCM driver. Judging from your comment the GPIO driver still probes earlier (I don't have any GPIO-only pinmuxes yet), so maybe we should amend the patch to probe even earlier. The pinmux driver doesn't depend on anything, so it can potentially probe very early. What do you think? Mike. Kind regards, Mike Looijmans System Expert TOPIC Embedded Products Eindhovenseweg 32-C, NL-5683 KH Best Postbus 440, NL-5680 AK Best Telefoon: +31 (0) 499 33 69 79 Telefax: +31 (0) 499 33 69 70 E-mail: mike.looijm...@topicproducts.com Website: www.topicproducts.com Please consider the environment before printing this e-mail Visit us at : Aerospace Electrical Systems Expo Europe which will be held from 17.11.2015 till 19.11.2015, Findorffstrasse 101 Bremen, Germany, Hall 5, stand number C65 http://www.aesexpo.eu -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] usb: gadget: Add the console support for usb-to-serial port
It dose not work when we want to use the usb-to-serial port based
on one usb gadget as a console. Thus this patch adds the console
initialization to support this request.
Signed-off-by: Baolin Wang
---
drivers/usb/gadget/Kconfig |6 +
drivers/usb/gadget/function/u_serial.c | 239
2 files changed, 245 insertions(+)
diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
index 33834aa..be5aab9 100644
--- a/drivers/usb/gadget/Kconfig
+++ b/drivers/usb/gadget/Kconfig
@@ -127,6 +127,12 @@ config USB_GADGET_STORAGE_NUM_BUFFERS
a module parameter as well.
If unsure, say 2.
+config U_SERIAL_CONSOLE
+ bool "Serial gadget console support"
+ depends on USB_G_SERIAL
+ help
+ It supports the serial gadget can be used as a console.
+
source "drivers/usb/gadget/udc/Kconfig"
#
diff --git a/drivers/usb/gadget/function/u_serial.c
b/drivers/usb/gadget/function/u_serial.c
index 9cc6a13..343d530 100644
--- a/drivers/usb/gadget/function/u_serial.c
+++ b/drivers/usb/gadget/function/u_serial.c
@@ -27,6 +27,8 @@
#include
#include
#include
+#include
+#include
#include "u_serial.h"
@@ -79,6 +81,16 @@
*/
#define QUEUE_SIZE 16
#define WRITE_BUF_SIZE 8192/* TX only */
+#define GS_BUFFER_SIZE (4096)
+#define GS_CONSOLE_BUF_SIZE(2 * GS_BUFFER_SIZE)
+
+struct gscons_info {
+ struct gs_port *port;
+ struct tty_driver *tty_driver;
+ struct work_struct work;
+ int buf_tail;
+ charbuf[GS_CONSOLE_BUF_SIZE];
+};
/* circular buffer */
struct gs_buf {
@@ -117,6 +129,7 @@ struct gs_port {
/* REVISIT this state ... */
struct usb_cdc_line_coding port_line_coding;/* 8-N-1 etc */
+ struct usb_request *console_req;
};
static struct portmaster {
@@ -1052,6 +1065,7 @@ gs_port_alloc(unsigned port_num, struct
usb_cdc_line_coding *coding)
port->port_num = port_num;
port->port_line_coding = *coding;
+ port->console_req = NULL;
ports[port_num].port = port;
out:
@@ -1141,6 +1155,227 @@ err:
}
EXPORT_SYMBOL_GPL(gserial_alloc_line);
+#ifdef CONFIG_U_SERIAL_CONSOLE
+
+static struct usb_request *gs_request_new(struct usb_ep *ep, int buffer_size)
+{
+ struct usb_request *req = usb_ep_alloc_request(ep, GFP_ATOMIC);
+
+ if (!req)
+ return NULL;
+
+ /* now allocate buffers for the requests */
+ req->buf = kmalloc(buffer_size, GFP_ATOMIC);
+ if (!req->buf) {
+ usb_ep_free_request(ep, req);
+ return NULL;
+ }
+
+ return req;
+}
+
+static void gs_request_free(struct usb_request *req, struct usb_ep *ep)
+{
+ if (req) {
+ kfree(req->buf);
+ usb_ep_free_request(ep, req);
+ }
+}
+
+static void gs_complete_out(struct usb_ep *ep, struct usb_request *req)
+{
+ if (req->status != 0 && req->status != -ECONNRESET)
+ return;
+}
+
+static struct console gserial_cons;
+static int gs_console_connect(void)
+{
+ struct gscons_info *info = gserial_cons.data;
+ int port_num = gserial_cons.index;
+ struct usb_request *req;
+ struct gs_port *port;
+ struct usb_ep *ep;
+
+ if (port_num >= MAX_U_SERIAL_PORTS || port_num < 0) {
+ pr_err("%s: port num [%d] exceeds the range.\n",
+ __func__, port_num);
+ return -ENXIO;
+ }
+
+ port = ports[port_num].port;
+ if (!port) {
+ pr_err("%s: serial line [%d] not allocated.\n",
+ __func__, port_num);
+ return -ENODEV;
+ }
+
+ if (!port->port_usb) {
+ pr_err("%s: no port usb.\n", __func__);
+ return -ENODEV;
+ }
+
+ ep = port->port_usb->in;
+ if (!ep) {
+ pr_err("%s: no usb endpoint.\n", __func__);
+ return -ENXIO;
+ }
+
+ req = port->console_req;
+ if (!req) {
+ req = gs_request_new(ep, GS_BUFFER_SIZE);
+ if (!req) {
+ pr_err("%s: request fail.\n", __func__);
+ return -ENOMEM;
+ }
+ req->complete = gs_complete_out;
+ }
+
+ info->port = port;
+
+ pr_debug("%s: port[%d] console connect!\n", __func__, port_num);
+ return 0;
+}
+
+static void gs_console_work(struct work_struct *work)
+{
+ struct gscons_info *info = container_of(work, struct gscons_info, work);
+ struct gs_port *port = info->port;
+ struct usb_request *req;
+ struct usb_ep *ep;
+ int xfer, ret, count;
+ char *p;
+
+ if (!port || !port->port_usb)
+ return;
+
+ req = port->console_req;
+ ep = port->port_usb->in;
+ if (!req || !ep)
+ return;
+
+
RE: [PATCH 2/2] can: xilinx: fix bug in bus error handling
Hi Soren, > -Original Message- > From: Sören Brinkmann [mailto:soren.brinkm...@xilinx.com] > Sent: Thursday, October 22, 2015 10:03 PM > To: Appana Durga Kedareswara Rao > Cc: Anirudha Sarangi; w...@grandegger.com; m...@pengutronix.de; Michal > Simek; Appana Durga Kedareswara Rao; linux-...@vger.kernel.org; > net...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux- > ker...@vger.kernel.org > Subject: Re: [PATCH 2/2] can: xilinx: fix bug in bus error handling > > On Thu, 2015-10-22 at 10:16AM +0530, Kedareswara rao Appana wrote: > > Simply resetting the peripheral on bus off condition is not enough, > > Because we also need to re-initialize the whole device. > > This patch fixes this issue. > > > > Signed-off-by: Kedareswara rao Appana > > --- > > drivers/net/can/xilinx_can.c | 7 +-- > > 1 file changed, 5 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/net/can/xilinx_can.c > > b/drivers/net/can/xilinx_can.c index 055d6f3..9aeb85f 100644 > > --- a/drivers/net/can/xilinx_can.c > > +++ b/drivers/net/can/xilinx_can.c > > @@ -529,6 +529,8 @@ static int xcan_rx(struct net_device *ndev) > > return 1; > > } > > > > +static void xcan_chip_stop(struct net_device *ndev); > > Isn't it possible to move the function and avoid the forward declaration? Yes it is possible to move the function will fix it in the next version of the patch. Regards, Kedar. > > Sören
Serial No.PMSQ021542311,
Confirmation Batch No. GDFS-25-30-29-3-26, Contact Person:Juan De la Silva EMAIL: freelot...@gmail.com TELL:+34-603-307-989 Reference Nr.XKHL-37-14-29-13), Batch No. GDFS-25-30-29-3-26, Serial No.PMSQ021542311, Ticket No.11-48-19-15-14, lucky No.4-19-26-27-30-3-8, You have won( ONE MILLION POUNDS ) in Free lotto online sweepstakes program corporations hold today 21st of October 2015 here In Madrid (SPAIN). This email is been sent to notify you officially about the award and to advise you to contact the processing office immediately for remittance of your Funds. Provide him with these following details with which he will begin the processing of your winnings. 1.NAME: 2.ADDRESS: 3.AGE: 4.PHONE: 5.SEX: 6.MARITAL STATUS: 7.OCCUPATION: 8.COUNTRY: 9.NATIONALITY: Sincerely Daniel Fernández Juanes Lottery Co ordinator -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] ASoC: wm8962: set ALC2 as non-volatile register
Previously ALC2 register is set as a volatile register, declare
it as one of ALC Coefficients register together with other non-volatile
registers will cause issue, in case wm8962 has enter suspend mode,
and cache_only flag is set, any attempt to read from ALC2 will fail.
Because the 5 status bits in ALC2 aren't used anywhere nor are useful
to end user, so this patch removes ALC2 register from volatile
register list to make ALC2 be possible to be accessed when cache_only
flag is set.
Signed-off-by: Jiada Wang
---
sound/soc/codecs/wm8962.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/sound/soc/codecs/wm8962.c b/sound/soc/codecs/wm8962.c
index 2fbc6ef..371ec72 100644
--- a/sound/soc/codecs/wm8962.c
+++ b/sound/soc/codecs/wm8962.c
@@ -131,7 +131,7 @@ static const struct reg_default wm8962_reg[] = {
{ 15, 0x6243 }, /* R15- Software Reset */
{ 17, 0x007B }, /* R17- ALC1 */
-
+ { 18, 0x }, /* R18- ALC2 */
{ 19, 0x1C32 }, /* R19- ALC3 */
{ 20, 0x3200 }, /* R20- Noise Gate */
{ 21, 0x00C0 }, /* R21- Left ADC volume */
@@ -794,7 +794,6 @@ static bool wm8962_volatile_register(struct device *dev,
unsigned int reg)
case WM8962_CLOCKING1:
case WM8962_CLOCKING2:
case WM8962_SOFTWARE_RESET:
- case WM8962_ALC2:
case WM8962_THERMAL_SHUTDOWN_STATUS:
case WM8962_ADDITIONAL_CONTROL_4:
case WM8962_DC_SERVO_6:
--
2.4.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v6] can: xilinx: Convert to runtime_pm
Hi Soren,
> -Original Message-
> From: Sören Brinkmann [mailto:soren.brinkm...@xilinx.com]
> Sent: Friday, October 23, 2015 3:43 AM
> To: Appana Durga Kedareswara Rao
> Cc: Anirudha Sarangi; w...@grandegger.com; m...@pengutronix.de; Michal
> Simek; linux-...@vger.kernel.org; net...@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; linux-kernel@vger.kernel.org; Appana Durga
> Kedareswara Rao
> Subject: Re: [PATCH v6] can: xilinx: Convert to runtime_pm
>
> Hi Kedar,
>
> On Thu, 2015-10-22 at 10:15AM +0530, Kedareswara rao Appana wrote:
> > Instead of enabling/disabling clocks at several locations in the
> > driver, Use the runtime_pm framework. This consolidates the actions
> > for runtime PM In the appropriate callbacks and makes the driver more
> readable and mantainable.
> >
> > Signed-off-by: Kedareswara rao Appana
> [...]
> > /**
> > * xcan_probe - Platform registration call @@ -1072,7 +1103,7 @@
> > static int xcan_probe(struct platform_device *pdev)
> > return -ENOMEM;
> >
> > priv = netdev_priv(ndev);
> > - priv->dev = ndev;
> > + priv->dev = >dev;
> > priv->can.bittiming_const = _bittiming_const;
> > priv->can.do_set_mode = xcan_do_set_mode;
> > priv->can.do_get_berr_counter = xcan_get_berr_counter; @@ -
> 1114,21
> > +1145,30 @@ static int xcan_probe(struct platform_device *pdev)
> > }
> > }
> >
> > - ret = clk_prepare_enable(priv->can_clk);
> > + ret = clk_prepare(priv->can_clk);
> > if (ret) {
> > dev_err(>dev, "unable to enable device clock\n");
> > goto err_free;
> > }
> >
> > - ret = clk_prepare_enable(priv->bus_clk);
> > + ret = clk_prepare(priv->bus_clk);
>
> Are these clk_prepare calls needed here? The runtime PM calls do
> clk_prepare_enable and clk_disable_unprepare.
Ok Sure will remove.
>
> > if (ret) {
> > dev_err(>dev, "unable to enable bus clock\n");
> > - goto err_unprepare_disable_dev;
> > + goto err_unprepare_dev;
> > }
> >
> > priv->write_reg = xcan_write_reg_le;
> > priv->read_reg = xcan_read_reg_le;
> >
> > + pm_runtime_irq_safe(>dev);
> > + pm_runtime_enable(>dev);
> > + ret = pm_runtime_get_sync(>dev);
> > + if (ret < 0) {
> > + netdev_err(ndev, "%s: pm_runtime_get failed(%d)\n",
> > + __func__, ret);
> > + goto err_unprepare_busclk;
> > + }
> > +
> > if (priv->read_reg(priv, XCAN_SR_OFFSET) != XCAN_SR_CONFIG_MASK) {
> > priv->write_reg = xcan_write_reg_be;
> > priv->read_reg = xcan_read_reg_be;
> > @@ -1141,22 +1181,26 @@ static int xcan_probe(struct platform_device
> *pdev)
> > ret = register_candev(ndev);
> > if (ret) {
> > dev_err(>dev, "fail to register failed (err=%d)\n", ret);
> > - goto err_unprepare_disable_busclk;
> > + goto err_disableclks;
> > }
> >
> > devm_can_led_init(ndev);
> > - clk_disable_unprepare(priv->bus_clk);
> > - clk_disable_unprepare(priv->can_clk);
> > +
> > + pm_runtime_put(>dev);
> > +
> > netdev_dbg(ndev, "reg_base=0x%p irq=%d clock=%d, tx fifo
> depth:%d\n",
> > priv->reg_base, ndev->irq, priv->can.clock.freq,
> > priv->tx_max);
> >
> > return 0;
> >
> > -err_unprepare_disable_busclk:
> > - clk_disable_unprepare(priv->bus_clk);
> > -err_unprepare_disable_dev:
> > - clk_disable_unprepare(priv->can_clk);
> > +err_disableclks:
> > + pm_runtime_put(priv->dev);
> > +err_unprepare_busclk:
> > + pm_runtime_disable(>dev);
> > + clk_unprepare(priv->bus_clk);
> > +err_unprepare_dev:
> > + clk_unprepare(priv->can_clk);
> > err_free:
> > free_candev(ndev);
> > err:
> > @@ -1175,11 +1219,11 @@ static int xcan_remove(struct platform_device
> *pdev)
> > struct net_device *ndev = platform_get_drvdata(pdev);
> > struct xcan_priv *priv = netdev_priv(ndev);
> >
> > - if (set_reset_mode(ndev) < 0)
> > - netdev_err(ndev, "mode resetting failed!\n");
> > -
> > unregister_candev(ndev);
> > + pm_runtime_disable(>dev);
> > netif_napi_del(>napi);
> > + clk_unprepare(priv->bus_clk);
> > + clk_unprepare(priv->can_clk);
>
> I think this can go away when the prepare calls in probe go away.
Ok will fix and will send next version of the patch.
Regards,
Kedar.
>
> Thanks,
> Sören
[PATCH v3 2/2] arm64: dts: Add BRCM IPROC NAND DT node for NS2
The NAND controller on NS2 SoC is compatible with existing
BRCM IPROC NAND driver so let's enable it in NS2 DT and
NS2 SVK DT.
This patch also fixes use of node labels in ns2-svk.dts.
Signed-off-by: Anup Patel
Reviewed-by: Ray Jui
Reviewed-by: Scott Branden
---
arch/arm64/boot/dts/broadcom/ns2-svk.dts | 30 --
arch/arm64/boot/dts/broadcom/ns2.dtsi| 14 ++
2 files changed, 34 insertions(+), 10 deletions(-)
diff --git a/arch/arm64/boot/dts/broadcom/ns2-svk.dts
b/arch/arm64/boot/dts/broadcom/ns2-svk.dts
index e5950d5..6bb3d4d 100644
--- a/arch/arm64/boot/dts/broadcom/ns2-svk.dts
+++ b/arch/arm64/boot/dts/broadcom/ns2-svk.dts
@@ -50,18 +50,28 @@
device_type = "memory";
reg = <0x0 0x8000 0x 0x4000>;
};
+};
- soc: soc {
- i2c0: i2c@6608 {
- status = "ok";
- };
+ {
+ status = "ok";
+};
- i2c1: i2c@660b {
- status = "ok";
- };
+ {
+ status = "ok";
+};
+
+ {
+ status = "ok";
+};
- uart3: serial@6613 {
- status = "ok";
- };
+ {
+ nandcs@0 {
+ compatible = "brcm,nandcs";
+ reg = <0>;
+ nand-ecc-mode = "hw";
+ nand-ecc-strength = <8>;
+ nand-ecc-step-size = <512>;
+ #address-cells = <1>;
+ #size-cells = <1>;
};
};
diff --git a/arch/arm64/boot/dts/broadcom/ns2.dtsi
b/arch/arm64/boot/dts/broadcom/ns2.dtsi
index f603277..9610822 100644
--- a/arch/arm64/boot/dts/broadcom/ns2.dtsi
+++ b/arch/arm64/boot/dts/broadcom/ns2.dtsi
@@ -212,5 +212,19 @@
compatible = "brcm,iproc-rng200";
reg = <0x6622 0x28>;
};
+
+ nand: nand@6646 {
+ compatible = "brcm,nand-iproc", "brcm,brcmnand-v6.1";
+ reg = <0x6646 0x600>,
+ <0x67015408 0x600>,
+ <0x66460f00 0x20>;
+ reg-names = "nand", "iproc-idm", "iproc-ext";
+ interrupts = ;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ brcm,nand-has-wp;
+ };
};
};
--
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 v3 1/2] mtd: brcmnand: Force 8bit mode before doing nand_scan_ident()
Just like other NAND controllers, the NAND READID command only works
in 8bit mode for all versions of BRCMNAND controller.
This patch forces 8bit mode for each NAND CS in brcmnand_init_cs()
before doing nand_scan_ident() to ensure that BRCMNAND controller
is in 8bit mode when NAND READID command is issued.
Signed-off-by: Anup Patel
Reviewed-by: Ray Jui
Reviewed-by: Scott Branden
---
drivers/mtd/nand/brcmnand/brcmnand.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/mtd/nand/brcmnand/brcmnand.c
b/drivers/mtd/nand/brcmnand/brcmnand.c
index 4cba03d..0be8ef9 100644
--- a/drivers/mtd/nand/brcmnand/brcmnand.c
+++ b/drivers/mtd/nand/brcmnand/brcmnand.c
@@ -1888,6 +1888,7 @@ static int brcmnand_init_cs(struct brcmnand_host *host)
struct mtd_info *mtd;
struct nand_chip *chip;
int ret;
+ u16 cfg_offs;
struct mtd_part_parser_data ppdata = { .of_node = dn };
ret = of_property_read_u32(dn, "reg", >cs);
@@ -1930,6 +1931,14 @@ static int brcmnand_init_cs(struct brcmnand_host *host)
chip->controller = >controller;
+ /*
+* The bootloader might have configured 16bit mode but
+* NAND READID command only works in 8bit mode. We force
+* 8bit mode here to ensure that NAND READID commands works.
+*/
+ cfg_offs = brcmnand_cs_offset(ctrl, host->cs, BRCMNAND_CS_CFG);
+ nand_writereg(ctrl, cfg_offs, nand_readreg(ctrl, cfg_offs) & ~BIT(23));
+
if (nand_scan_ident(mtd, 1, NULL))
return -ENXIO;
--
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 v3 0/2] NAND support for Broadcom NS2 SoC
We enable NAND support for Broadcom NS2 SoC by reusing existing BRCMNAND driver. This patchset applies on-top of "arm64: Simple additions to NS2 DT" v1 patchset and is available in ns2_nand_v3 branch of https://github.com/Broadcom/arm64-linux.git. The patchset is tested on NS2 SVK. Changes since v2: - Dropped patch1 and patch2 because these are already merged by MTD maintainer. - Avoid using absolute node paths in ns2-svk.dts. Changes since v1: - Dropped patch3 and patch4 because we don't need to reset BRCMNAND controller for NS2. - Added patch to force 8bit mode before doing nand_scan_ident() in brcmnand_init_cs(). Anup Patel (2): mtd: brcmnand: Force 8bit mode before doing nand_scan_ident() arm64: dts: Add BRCM IPROC NAND DT node for NS2 arch/arm64/boot/dts/broadcom/ns2-svk.dts | 30 -- arch/arm64/boot/dts/broadcom/ns2.dtsi| 14 ++ drivers/mtd/nand/brcmnand/brcmnand.c | 9 + 3 files changed, 43 insertions(+), 10 deletions(-) -- 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 2/2] Staging: lustre: lnet: lib-move return of an errno should typically be negative (ie: return -EAGAIN)
On Fri, Oct 23, 2015 at 10:00:03AM +0530, Nilesh Kokane wrote: > Fixed- Return of an errno should typically be negative (ie: return -EAGAIN) > The changelog needs to describe the use visible effects of this change. 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/
[PATCH net] macvtap: unbreak receiving of gro skb with frag list
We don't have fraglist support in TAP_FEATURES. This will lead
software segmentation of gro skb with frag list. Fixes by having
frag list support in TAP_FEATURES.
With this patch single session of netperf receiving were restored from
about 5Gb/s to about 12Gb/s on mlx4.
Fixes a567dd6252 ("macvtap: simplify usage of tap_features")
Cc: Vlad Yasevich
Cc: Michael S. Tsirkin
Signed-off-by: Jason Wang
---
drivers/net/macvtap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
index 248478c..197c939 100644
--- a/drivers/net/macvtap.c
+++ b/drivers/net/macvtap.c
@@ -137,7 +137,7 @@ static const struct proto_ops macvtap_socket_ops;
#define TUN_OFFLOADS (NETIF_F_HW_CSUM | NETIF_F_TSO_ECN | NETIF_F_TSO | \
NETIF_F_TSO6 | NETIF_F_UFO)
#define RX_OFFLOADS (NETIF_F_GRO | NETIF_F_LRO)
-#define TAP_FEATURES (NETIF_F_GSO | NETIF_F_SG)
+#define TAP_FEATURES (NETIF_F_GSO | NETIF_F_SG | NETIF_F_FRAGLIST)
static struct macvlan_dev *macvtap_get_vlan_rcu(const struct net_device *dev)
{
--
1.8.3.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 v2] gpio: xilinx: Drop architecture dependencies
The driver does not have any real architecture dependencies. To avoid listing each architecture that might use this driver on some FPGA-enabled platform, drop these dependencies. Signed-off-by: Soren Brinkmann Acked-by: Moritz Fischer --- v2: - rebased --- drivers/gpio/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig index 597b8d4ab74f..45dfeef6018f 100644 --- a/drivers/gpio/Kconfig +++ b/drivers/gpio/Kconfig @@ -506,7 +506,7 @@ config GPIO_XGENE_SB config GPIO_XILINX tristate "Xilinx GPIO support" - depends on OF_GPIO && (PPC || MICROBLAZE || ARCH_ZYNQ || X86 || MIPS) + depends on OF_GPIO help Say yes here to support the Xilinx FPGA GPIO device -- 2.6.2.3.ga463a5b -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [Tech-board-discuss] [Ksummit-discuss] Linux Foundation Technical Advisory Board Elections and Nomination process
On Thu, Oct 22, 2015 at 08:00:20PM -0700, Kristen Accardi wrote: > On Oct 22, 2015 7:04 PM, "Neil Brown" wrote: > > > > Darren Hart writes: > > > > > > > > Is there a good description of what is expected of a TAB member? How > much time > > > is involved? What makes a great TAB member? > > > > > > I've found: > http://www.linuxfoundation.org/programs/advisory-councils/tab > > > > > > I've read the charter and scanned some of the minutes, but I'd still > like to > > > hear from some of the "incumbants". Specifically, what makes you > successful as a > > > member of the TAB? > > > > Also on the topic of the TAB and elections, I cannot figure out what: > > > > "Only one vote per candidate will be counted." > > > > means in: > > > > Voting: > > --- > > Each person present at the time of the election shall be handed a printed > > ballot. Voters may vote for as many candidates as they wish. Only one > > vote per candidate will be counted. A space will be provided where > > they can fill out the ballot in private and place it into a box to be > > counted in private. > > > > > > in > > > http://www.linuxfoundation.org/collaborate/workgroups/technical-advisory-board-tab/minutes-july-2015-tab-meeting > > > > Is it "Only one vote per candidate per voter will be counted"? > > Sorry this was a bit confusing. Basically, it means you can vote for as > many candidates as you like, but if you can't vote multiple times for the > same candidate on your ballot. So, in other words, "this is approval voting, not range voting"? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 4/7] perf tools: Enable BPF object configure syntax
On 2015/10/17 18:48, Wang Nan wrote:
[SNIP]
event_bpf_file:
-PE_BPF_OBJECT
+PE_BPF_OBJECT event_bpf_config
{
struct parse_events_evlist *data = _data;
struct parse_events_error *error = data->error;
struct list_head *list;
ALLOC_LIST(list);
- ABORT_ON(parse_events_load_bpf(data, list, $1, false));
+ ABORT_ON(parse_events_load_bpf(data, list, $1, false, $2));
+ parse_events__free_terms($2);
Here found a bug that $2 is possible to be NULL, but parse_events_free_terms
can't accept NULL param.
Will be fixed in next version.
Thank you.
$$ = list;
}
|
-PE_BPF_SOURCE
+PE_BPF_SOURCE event_bpf_config
{
struct parse_events_evlist *data = _data;
struct list_head *list;
ALLOC_LIST(list);
- ABORT_ON(parse_events_load_bpf(data, list, $1, true));
+ ABORT_ON(parse_events_load_bpf(data, list, $1, true, $2));
+ parse_events__free_terms($2);
$$ = list;
}
+event_bpf_config:
+'/' event_config '/'
+{
+ $$ = $2;
+}
+|
+{
+ $$ = NULL;
+}
+
start_terms: event_config
{
struct parse_events_terms *data = _data;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] Staging: lustre: lnet: lib-move return of an errno should typically be negative (ie: return -EAGAIN)
Fixed- Return of an errno should typically be negative (ie: return -EAGAIN)
Signed-off-by: Nilesh Kokane
---
drivers/staging/lustre/lnet/lnet/lib-move.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/staging/lustre/lnet/lnet/lib-move.c
b/drivers/staging/lustre/lnet/lnet/lib-move.c
index 433faae..10f886f 100644
--- a/drivers/staging/lustre/lnet/lnet/lib-move.c
+++ b/drivers/staging/lustre/lnet/lnet/lib-move.c
@@ -808,7 +808,7 @@ lnet_post_send_locked(lnet_msg_t *msg, int do_send)
lnet_finalize(ni, msg, -EHOSTUNREACH);
lnet_net_lock(cpt);
- return EHOSTUNREACH;
+ return -EHOSTUNREACH;
}
if (msg->msg_md != NULL &&
@@ -821,7 +821,7 @@ lnet_post_send_locked(lnet_msg_t *msg, int do_send)
lnet_finalize(ni, msg, -ECANCELED);
lnet_net_lock(cpt);
- return ECANCELED;
+ return -ECANCELED;
}
if (!msg->msg_peertxcredit) {
@@ -838,7 +838,7 @@ lnet_post_send_locked(lnet_msg_t *msg, int do_send)
if (lp->lp_txcredits < 0) {
msg->msg_tx_delayed = 1;
list_add_tail(>msg_list, >lp_txq);
- return EAGAIN;
+ return -EAGAIN;
}
}
@@ -855,7 +855,7 @@ lnet_post_send_locked(lnet_msg_t *msg, int do_send)
if (tq->tq_credits < 0) {
msg->msg_tx_delayed = 1;
list_add_tail(>msg_list, >tq_delayed);
- return EAGAIN;
+ return -EAGAIN;
}
}
@@ -922,7 +922,7 @@ lnet_post_routed_recv_locked(lnet_msg_t *msg, int do_recv)
LASSERT(msg->msg_rx_ready_delay);
msg->msg_rx_delayed = 1;
list_add_tail(>msg_list, >lp_rtrq);
- return EAGAIN;
+ return -EAGAIN;
}
}
@@ -942,7 +942,7 @@ lnet_post_routed_recv_locked(lnet_msg_t *msg, int do_recv)
LASSERT(msg->msg_rx_ready_delay);
msg->msg_rx_delayed = 1;
list_add_tail(>msg_list, >rbp_msgs);
- return EAGAIN;
+ return -EAGAIN;
}
}
@@ -1426,7 +1426,7 @@ lnet_parse_put(lnet_ni_t *ni, lnet_msg_t *msg)
libcfs_id2str(info.mi_id), info.mi_portal,
info.mi_mbits, info.mi_roffset, info.mi_rlength, rc);
- return ENOENT; /* +ve: OK but no match */
+ return -ENOENT; /* +ve: OK but no match */
}
}
@@ -1457,7 +1457,7 @@ lnet_parse_get(lnet_ni_t *ni, lnet_msg_t *msg, int
rdma_get)
CNETERR("Dropping GET from %s portal %d match %llu offset %d
length %d\n",
libcfs_id2str(info.mi_id), info.mi_portal,
info.mi_mbits, info.mi_roffset, info.mi_rlength);
- return ENOENT; /* +ve: OK but no match */
+ return -ENOENT; /* +ve: OK but no match */
}
LASSERT(rc == LNET_MATCHMD_OK);
@@ -1524,7 +1524,7 @@ lnet_parse_reply(lnet_ni_t *ni, lnet_msg_t *msg)
md->md_me->me_portal);
lnet_res_unlock(cpt);
- return ENOENT;/* +ve: OK but no match */
+ return -ENOENT; /* +ve: OK but no match */
}
LASSERT(md->md_offset == 0);
@@ -1539,7 +1539,7 @@ lnet_parse_reply(lnet_ni_t *ni, lnet_msg_t *msg)
rlength, hdr->msg.reply.dst_wmd.wh_object_cookie,
mlength);
lnet_res_unlock(cpt);
- return ENOENT;/* +ve: OK but no match */
+ return -ENOENT; /* +ve: OK but no match */
}
CDEBUG(D_NET, "%s: Reply from %s of length %d/%d into md %#llx\n",
@@ -1592,7 +1592,7 @@ lnet_parse_ack(lnet_ni_t *ni, lnet_msg_t *msg)
md->md_me->me_portal);
lnet_res_unlock(cpt);
- return ENOENT;/* +ve! */
+ return -ENOENT; /* +ve! */
}
CDEBUG(D_NET, "%s: ACK from %s into md %#llx\n",
--
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] mm,vmscan: Use accurate values for zone_reclaimable() checks
Hello,
So, something like the following. Just compile tested but this is
essentially partial revert of 3270476a6c0c ("workqueue: reimplement
WQ_HIGHPRI using a separate worker_pool") - resurrecting the old
WQ_HIGHPRI implementation under WQ_IMMEDIATE, so we know this works.
If for some reason, it gets decided against simply adding one jiffy
sleep, please let me know. I'll verify the operation and post a
proper patch. That said, given that this prolly needs -stable
backport and vmstat is likely to be the only user (busy loops are
really rare in the kernel after all), I think the better approach
would be reinstating the short sleep.
Thanks.
---
include/linux/workqueue.h |7 ++---
kernel/workqueue.c| 63 +++---
2 files changed, 63 insertions(+), 7 deletions(-)
--- a/include/linux/workqueue.h
+++ b/include/linux/workqueue.h
@@ -278,9 +278,10 @@ enum {
WQ_UNBOUND = 1 << 1, /* not bound to any cpu */
WQ_FREEZABLE= 1 << 2, /* freeze during suspend */
WQ_MEM_RECLAIM = 1 << 3, /* may be used for memory reclaim */
- WQ_HIGHPRI = 1 << 4, /* high priority */
- WQ_CPU_INTENSIVE= 1 << 5, /* cpu intensive workqueue */
- WQ_SYSFS= 1 << 6, /* visible in sysfs, see
wq_sysfs_register() */
+ WQ_IMMEDIATE= 1 << 4, /* bypass concurrency management */
+ WQ_HIGHPRI = 1 << 5, /* high priority */
+ WQ_CPU_INTENSIVE= 1 << 6, /* cpu intensive workqueue */
+ WQ_SYSFS= 1 << 7, /* visible in sysfs, see
wq_sysfs_register() */
/*
* Per-cpu workqueues are generally preferred because they tend to
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -68,6 +68,7 @@ enum {
* attach_mutex to avoid changing binding state while
* worker_attach_to_pool() is in progress.
*/
+ POOL_IMMEDIATE_PENDING = 1 << 0, /* WQ_IMMEDIATE items on queue
*/
POOL_DISASSOCIATED = 1 << 2, /* cpu can't serve workers */
/* worker flags */
@@ -731,7 +732,8 @@ static bool work_is_canceling(struct wor
static bool __need_more_worker(struct worker_pool *pool)
{
- return !atomic_read(>nr_running);
+ return !atomic_read(>nr_running) ||
+ (pool->flags & POOL_IMMEDIATE_PENDING);
}
/*
@@ -757,7 +759,8 @@ static bool may_start_working(struct wor
static bool keep_working(struct worker_pool *pool)
{
return !list_empty(>worklist) &&
- atomic_read(>nr_running) <= 1;
+ (atomic_read(>nr_running) <= 1 ||
+(pool->flags & POOL_IMMEDIATE_PENDING));
}
/* Do we need a new worker? Called from manager. */
@@ -1021,6 +1024,42 @@ static void move_linked_works(struct wor
}
/**
+ * pwq_determine_ins_pos - find insertion position
+ * @pwq: pwq a work is being queued for
+ *
+ * A work for @pwq is about to be queued on @pwq->pool, determine insertion
+ * position for the work. If @pwq is for IMMEDIATE wq, the work item is
+ * queued at the head of the queue but in FIFO order with respect to other
+ * IMMEDIATE work items; otherwise, at the end of the queue. This function
+ * also sets POOL_IMMEDIATE_PENDING flag to hint @pool that there are
+ * IMMEDIATE works pending.
+ *
+ * CONTEXT:
+ * spin_lock_irq(gcwq->lock).
+ *
+ * RETURNS:
+ * Pointer to insertion position.
+ */
+static struct list_head *pwq_determine_ins_pos(struct pool_workqueue *pwq)
+{
+ struct worker_pool *pool = pwq->pool;
+ struct work_struct *twork;
+
+ if (likely(!(pwq->wq->flags & WQ_IMMEDIATE)))
+ return >worklist;
+
+ list_for_each_entry(twork, >worklist, entry) {
+ struct pool_workqueue *tpwq = get_work_pwq(twork);
+
+ if (!(tpwq->wq->flags & WQ_IMMEDIATE))
+ break;
+ }
+
+ pool->flags |= POOL_IMMEDIATE_PENDING;
+ return >entry;
+}
+
+/**
* get_pwq - get an extra reference on the specified pool_workqueue
* @pwq: pool_workqueue to get
*
@@ -1081,9 +1120,10 @@ static void put_pwq_unlocked(struct pool
static void pwq_activate_delayed_work(struct work_struct *work)
{
struct pool_workqueue *pwq = get_work_pwq(work);
+ struct list_head *pos = pwq_determine_ins_pos(pwq);
trace_workqueue_activate_work(work);
- move_linked_works(work, >pool->worklist, NULL);
+ move_linked_works(work, pos, NULL);
__clear_bit(WORK_STRUCT_DELAYED_BIT, work_data_bits(work));
pwq->nr_active++;
}
@@ -1384,7 +1424,7 @@ retry:
if (likely(pwq->nr_active < pwq->max_active)) {
trace_workqueue_activate_work(work);
pwq->nr_active++;
- worklist = >pool->worklist;
+ worklist = pwq_determine_ins_pos(pwq);
} else {
work_flags |= WORK_STRUCT_DELAYED;
worklist =
Re: + doc-slub-document-slabinfo-gnuplotsh-script.patch added to -mm tree
On (10/22/15 13:21), a...@linux-foundation.org wrote:
[..]
> --
> From: Sergey Senozhatsky
> Subject: Doc/slub: document slabinfo-gnuplot.sh script
>
> Add documentation on how to use slabinfo-gnuplot.sh script.
>
> Signed-off-by: Sergey Senozhatsky
> Signed-off-by: Andrew Morton
Oh, sent "Documentation/vm/slub.txt: document slabinfo-gnuplot.sh" patch
(addressed Christoph's comments) before I saw this message.
V2 message-id: 1445557905-9565-1-git-send-email-sergey.senozhat...@gmail.com
Andrew, should I send an incremental update to this patch instead or you
will 'replace' it with the v2?
-ss
> ---
>
> Documentation/vm/slub.txt | 58
> 1 file changed, 58 insertions(+)
>
> diff -puN
> Documentation/vm/slub.txt~doc-slub-document-slabinfo-gnuplotsh-script
> Documentation/vm/slub.txt
> --- a/Documentation/vm/slub.txt~doc-slub-document-slabinfo-gnuplotsh-script
> +++ a/Documentation/vm/slub.txt
> @@ -280,4 +280,62 @@ of other objects.
>
> slub_debug=FZ,dentry
>
> +Extended slabinfo mode and plotting
> +---
> +
> +slabinfo tool has a special 'extended' ('-X') mode that includes:
> + - Slabcache Totals
> + - Slabs sorted by size (up to -N slabs, default 1)
> + - Slabs sorted by loss (up to -N slabs, default 1)
> +
> +Additionally, in this mode slabinfo does not dynamically scale sizes (G/M/K)
> +and reports everything in bytes (this functionality is also available to
> +other slabinfo modes via '-B' option) which makes reporting more precise and
> +accurate. Moreover, in some sense the `-X' mode also simplifies the analysis
> +of slabs' behaviour, because its output can be plotted using the
> +slabinfo-gnuplot.sh script. So it pushes the analysis from looking through
> +the numbers (tons of numbers) to something easier -- visual analysis.
> +
> +To generate plots:
> +a) collect slabinfo extended records, for example:
> +
> + while [ 1 ]; do slabinfo -X >> FOO_STATS; sleep 1; done
> +
> +b) pass stats file(-s) to slabinfo-gnuplot.sh script:
> + slabinfo-gnuplot.sh FOO_STATS [FOO_STATS2 .. FOO_STATSN]
> +
> +The slabinfo-gnuplot.sh script will pre-processes the collected records
> +and generates 3 png files (and 3 pre-processing cache files) per STATS
> +file:
> + - Slabcache Totals: FOO_STATS-totals.png
> + - Slabs sorted by size: FOO_STATS-slabs-by-size.png
> + - Slabs sorted by loss: FOO_STATS-slabs-by-loss.png
> +
> +Another use case, when slabinfo-gnuplot can be useful, is when you need
> +to compare slabs' behaviour "prior to" and "after" some code modification.
> +To help you out there, slabinfo-gnuplot.sh script can 'merge' the
> +`Slabcache Totals` sections from different measurements. To visually
> +compare N plots:
> +
> +a) Collect as many STATS1, STATS2, .. STATSN files as you need
> + while [ 1 ]; do slabinfo -X >> STATS; sleep 1; done
> +
> +b) Pre-process those STATS files
> + slabinfo-gnuplot.sh STATS1 STATS2 .. STATSN
> +
> +c) Execute slabinfo-gnuplot.sh in '-t' mode, passing all of the
> +generated pre-processed *-totals
> + slabinfo-gnuplot.sh -t STATS1-totals STATS2-totals .. STATSN-totals
> +
> +This will produce a single plot (png file).
> +
> +Plots, expectedly, can be large so some fluctuations or small spikes
> +can go unnoticed. To deal with that, `slabinfo-gnuplot.sh' has two
> +options to 'zoom-in'/'zoom-out':
> + a) -s %d,%d overwrites the default image width and heigh
> + b) -r %d,%d specifies a range of samples to use (for example,
> + in `slabinfo -X >> FOO_STATS; sleep 1;' case, using
> + a "-r 40,60" range will plot only samples collected
> + between 40th and 60th seconds).
> +
> Christoph Lameter, May 30, 2007
> _
>
> Patches currently in -mm which might be from sergey.senozhat...@gmail.com are
>
> maintainers-add-myself-as-zsmalloc-reviewer.patch
> tools-vm-slabinfo-use-getopt-no_argument-optional_argument.patch
> tools-vm-slabinfo-limit-the-number-of-reported-slabs.patch
> tools-vm-slabinfo-sort-slabs-by-loss.patch
> tools-vm-slabinfo-fix-alternate-opts-names.patch
> tools-vm-slabinfo-introduce-extended-totals-mode.patch
> tools-vm-slabinfo-output-sizes-in-bytes.patch
> tools-vm-slabinfo-cosmetic-globals-cleanup.patch
> tools-vm-slabinfo-gnuplot-slabifo-extended-stat.patch
> doc-slub-document-slabinfo-gnuplotsh-script.patch
> zram-keep-the-exact-overcommited-value-in-mem_used_max.patch
> mm-zsmalloc-constify-struct-zs_pool-name.patch
> zsmalloc-use-preempth-for-in_interrupt.patch
>
> --
> To unsubscribe from this list: send the line "unsubscribe mm-commits" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at
[PATCH] Documentation: ARM: EXYNOS: Update bootloader interface on Exynos542x
Update the documentation about: 1. Usage of PMU_SPARE2 register. Bootloaders on Exynos542x-based boards often use the register PMU_SPARE2 (0x908) in the same way as on Exynos3250: as a indicator the secondary CPU was booted on. The bootloader will set this value to non-zero, after sucessfull power up of secondary CPU. In the same time this booted CPU will stuck (spin) waiting for software reset. 2. Exynos542x entry address for secondary CPU boot up after system suspend (with MCPM enabled and in non-secure mode). See arch/arm/mach-exynos/mcpm-exynos.c for source code. Signed-off-by: Krzysztof Kozlowski --- Documentation/arm/Samsung/Bootloader-interface.txt | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/Documentation/arm/Samsung/Bootloader-interface.txt b/Documentation/arm/Samsung/Bootloader-interface.txt index df8d4fb85939..ed494ac0beb2 100644 --- a/Documentation/arm/Samsung/Bootloader-interface.txt +++ b/Documentation/arm/Samsung/Bootloader-interface.txt @@ -19,7 +19,7 @@ executing kernel. Address: sysram_ns_base_addr OffsetValuePurpose = -0x08 exynos_cpu_resume_ns System suspend +0x08 exynos_cpu_resume_ns, mcpm_entry_point System suspend 0x0c 0x0bad (Magic cookie)System suspend 0x1c exynos4_secondary_startupSecondary CPU boot 0x1c + 4*cpu exynos4_secondary_startup (Exynos4412) Secondary CPU boot @@ -56,7 +56,8 @@ OffsetValue Purpose Address: pmu_base_addr OffsetValue Purpose = -0x0908Non-zero (only Exynos3250) Secondary CPU boot up indicator +0x0908Non-zeroSecondary CPU boot up indicator + on Exynos3250 and Exynos542x 4. Glossary -- 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 v2] sunrpc: fix waitqueue_active without memory barrier in sunrpc
J. Bruce Fields wrote:
> On Fri, Oct 16, 2015 at 02:28:10AM +, Kosuke Tatsukawa wrote:
>> Tatsukawa Kosuke wrote:
>> > J. Bruce Fields wrote:
>> >> On Thu, Oct 15, 2015 at 11:44:20AM +, Kosuke Tatsukawa wrote:
>> >>> Tatsukawa Kosuke wrote:
>> >>> > J. Bruce Fields wrote:
>> >>> >> Thanks for the detailed investigation.
>> >>> >>
>> >>> >> I think it would be worth adding a comment if that might help someone
>> >>> >> having to reinvestigate this again some day.
>> >>> >
>> >>> > It would be nice, but I find it difficult to write a comment in the
>> >>> > sunrpc layer why a memory barrier isn't necessary, using the knowledge
>> >>> > of how nfsd uses it, and the current implementation of the network
>> >>> > code.
>> >>> >
>> >>> > Personally, I would prefer removing the call to waitqueue_active()
>> >>> > which
>> >>> > would make the memory barrier totally unnecessary at the cost of a
>> >>> > spin_lock + spin_unlock by unconditionally calling
>> >>> > wake_up_interruptible.
>> >>>
>> >>> On second thought, the callbacks will be called frequently from the tcp
>> >>> code, so it wouldn't be a good idea.
>> >>
>> >> So, I was even considering documenting it like this, if it's not
>> >> overkill.
>> >>
>> >> Hmm... but if this is right, then we may as well ask why we're doing the
>> >> wakeups at all. Might be educational to test the code with them
>> >> removed.
>> >
>> > sk_write_space will be called in sock_wfree() with UDP/IP each time
>> > kfree_skb() is called. With TCP/IP, sk_write_space is only called if
>> > SOCK_NOSPACE has been set.
>> >
>> > sk_data_ready will be called in both tcp_rcv_established() for TCP/IP
>> > and in sock_queue_rcv_skb() for UDP/IP. The latter lacks a memory
>> > barrier with sk_data_ready called right after __skb_queue_tail().
>> > I think this hasn't caused any problems because sk_data_ready wasn't
>> > used.
>>
>> Actually, svc_udp_data_ready() calls set_bit() which is an atomic
>> operation. So there won't be a problem unless svsk is NULL.
>
> So is it true that every caller of these socket callbacks has adequate
> memory barriers between the time the change is made visible and the time
> the callback is called?
>
> If so, then there's nothing really specific about nfsd here.
>
> In that case maybe it's the networking code that use some documentation,
> if it doesn't already? (Or maybe common helper functions for this
>
> if (waitqueue_active(wq))
> wake_up(wq)
>
> pattern?)
Some of the other places defining these callback functions are using
static inline bool wq_has_sleeper(struct socket_wq *wq)
defined in include/net/sock.h
The comment above the function explains that it was introduced for
exactly this purpose.
Even thought the argument variable uses the same name "wq", it has a
different type from the wq used in svcsock.c (struct socket_wq *
vs. wait_queue_head_t *).
> --b.
>
>>
>>
>> >> --b.
>> >>
>> >> commit 0882cfeb39e0
>> >> Author: J. Bruce Fields
>> >> Date: Thu Oct 15 16:53:41 2015 -0400
>> >>
>> >> svcrpc: document lack of some memory barriers.
>> >>
>> >> Kosuke Tatsukawa points out an odd lack of memory barriers in some
>> >> sites
>> >> here. I think the code's correct, but it's probably worth
>> >> documenting.
>> >>
>> >> Reported-by: Kosuke Tatsukawa
>> >>
>> >> diff --git a/net/sunrpc/svcsock.c b/net/sunrpc/svcsock.c
>> >> index 856407fa085e..90480993ec4a 100644
>> >> --- a/net/sunrpc/svcsock.c
>> >> +++ b/net/sunrpc/svcsock.c
>> >> @@ -399,6 +399,25 @@ static int svc_sock_secure_port(struct svc_rqst
>> >> *rqstp)
>> >> return svc_port_is_privileged(svc_addr(rqstp));
>> >> }
>> >>
>> >> +static void svc_no_smp_mb(void)
>> >> +{
>> >> + /*
>> >> + * Kosuke Tatsukawa points out there should normally be an
>> >> + * smp_mb() at the callsites of this function. (Either that or
>> >> + * we could just drop the waitqueue_active() checks.)
>> >> + *
>> >> + * It appears they aren't currently necessary, though, basically
>> >> + * because nfsd does non-blocking reads from these sockets, so
>> >> + * the only places we wait on this waitqueue is in sendpage and
>> >> + * sendmsg, which won't be waiting for wakeups on newly arrived
>> >> + * data.
>> >> + *
>> >> + * Maybe we should add the memory barriers anyway, but these are
>> >> + * hot paths so we'd need to be convinced there's no sigificant
>> >> + * penalty.
>> >> + */
>> >> +}
>> >> +
>> >> /*
>> >> * INET callback when data has been received on the socket.
>> >> */
>> >> @@ -414,7 +433,7 @@ static void svc_udp_data_ready(struct sock *sk)
>> >> set_bit(XPT_DATA, >sk_xprt.xpt_flags);
>> >> svc_xprt_enqueue(>sk_xprt);
>> >> }
>> >> - smp_mb();
>> >> + svc_no_smp_mb();
>> >> if (wq && waitqueue_active(wq))
>> >> wake_up_interruptible(wq);
>> >> }
>> >> @@ -433,7 +452,7 @@ static void svc_write_space(struct sock *sk)
>> >>
Re: [PATCH v3 2/3] thermal: rockchip: ensure the otp states before resetting the controller
Caesar, On Thu, Oct 22, 2015 at 9:54 PM, Caesar Wang wrote: > We need the OTP pin is gpio state before resetting the TSADC controller, > since the tshut polarity will generate a high signal. > > Says: > The TSHUT temperature is setting more than 80 degree, the > default tshut polarity is high. > > If T > 80C, the OTP output the high signal. > If T < 80C, the OTP output the low signal. > > On the moment, the tshut polarity will be low in a short period of time > if the TSADC controller is reset. > > So: > If T < 80C, the OTP output the High Signal. > If T > 80C, the OTP output the Low Signal. > > In some cases, the OTP pin is connected to the PMIC, maybe the PMIC can > accept the reset response time to avoid this issue. > In other words, the system will be always reboot if we > make the OTP pin is connected the others IC to control the power. > > Signed-off-by: Caesar Wang > > --- > > Changes in v3: > - Add the pinctrl state for in the suspend/resume. > > Changes in v2: None > Changes in v1: None > > drivers/thermal/rockchip_thermal.c | 4 > 1 file changed, 4 insertions(+) > > diff --git a/drivers/thermal/rockchip_thermal.c > b/drivers/thermal/rockchip_thermal.c > index c89ffb2..3b8fbda 100644 > --- a/drivers/thermal/rockchip_thermal.c > +++ b/drivers/thermal/rockchip_thermal.c > @@ -642,6 +642,8 @@ static int __maybe_unused rockchip_thermal_suspend(struct > device *dev) > clk_disable(thermal->pclk); > clk_disable(thermal->clk); > > + pinctrl_pm_select_sleep_state(dev); > + > return 0; > } > > @@ -678,6 +680,8 @@ static int __maybe_unused rockchip_thermal_resume(struct > device *dev) > for (i = 0; i < ARRAY_SIZE(thermal->sensors); i++) > rockchip_thermal_toggle_sensor(>sensors[i], true); > > + pinctrl_pm_select_default_state(dev); > + > return 0; > } The patch looks totally fine, but the description is a little confusing. Reading this patch it's all about adding support for the "sleep" state in the tsadc driver, but nothing in the description talks about that. I'd expect something like: thermal: rockchip: support the sleep pinctrl state to avoid glitches in s2r When we come out of system suspend state (S3) the tsadc will have been reset and back at its default state. While reprogramming the tsadc it's possible that we'll glitch the output and unintentionally cause the "over temperature" GPIO to be asserted. Since the over temperature GPIO is often hooked up to something that will cause a reboot or shutdown in hardware, this glitch can be catastrophic on some boards. We'll add support for selecting the "sleep" pinctrl state at suspend time. Boards can use this to effectively disable the tsadc at suspend time and avoid glitches when the system is resumed. --- Note that although this pinctrl approach is fine IMHO, I am left wondering whether we could just change the tsadc init sequence to avoid the glitch. I can't easily test myself, but if we can program the temperatures before re-enabling the tsadc would it avoid the problem too? Like could we just swap things like: thermal->chip->set_tshut_temp(id, thermal->regs, thermal->hw_shut_temp); thermal->chip->set_tshut_mode(id, thermal->regs, thermal->tshut_mode); Does that help? -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 v11 02/14] HMM: add special swap filetype for memory migrated to device v2.
On Fri, Oct 23, 2015 at 11:23:26AM +0800, Hillf Danton wrote:
> > > > + if (cnt_hmm_entry) {
> > > > + int ret;
> > > > +
> > > > + ret = hmm_mm_fork(src_mm, dst_mm, dst_vma,
> > > > + dst_pmd, start, end);
> > >
> > > Given start, s/end/addr/, no?
> >
> > No, end is the right upper limit here.
> >
> Then in the first loop, hmm_mm_fork is invoked for
> the _entire_ range, from input addr to end.
> In subsequent loops(if necessary), start is updated to
> addr, and hmm_mm_fork is also invoked for remaining
> range, from start to end.
>
> Is the above overlap in range making sense?
Well yes and no, hmm_mm_fork() will do nothing for address >= addr
i feel like end is easier to understand.
Cheers,
Jérôme
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 4/4] ARM: dts: sun6i: Add dts file for MSI Primo81 tablet
From: Karsten Merker
The MSI Primo81 is an A31s based tablet, with 1G RAM, 16G NAND,
768x1024 IPS LCD display, mono speaker, 0.3 MP front camera, 2.0 MP
rear camera, 3500 mAh battery, gt911 touchscreen, mma8452 accelerometer
and rtl8188etv usb wifi. Has "power", "volume+" and "volume-" buttons
(both volume buttons are also connected to the UBOOT_SEL pin). The
external connectors are represented by MicroSD slot, MiniHDMI, MicroUSB
OTG and 3.5mm headphone jack.
USB OTG is enabled in host only mode. AXP221 USB power supply and
GPIO support are required for full USB OTG support.
Signed-off-by: Siarhei Siamashka
Signed-off-by: Karsten Merker
Signed-off-by: Chen-Yu Tsai
---
Changes since last submission (was part of Sinlinx SinA31s series)
- Update axp22x.dtsi file name
- Sort regulators
- Drop URL in commit message
- Drop comment for capacitive touch panel
- Add simplefb regulators
- Drop regulator-always-on for regulators that aren't critical
- Fix CPU and GPU regulator supply mix-up
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/sun6i-a31s-primo81.dts | 255 +++
2 files changed, 256 insertions(+)
create mode 100644 arch/arm/boot/dts/sun6i-a31s-primo81.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index c00b72e750ab..78ade1a5e886 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -612,6 +612,7 @@ dtb-$(CONFIG_MACH_SUN6I) += \
sun6i-a31-m9.dtb \
sun6i-a31-mele-a1000g-quad.dtb \
sun6i-a31s-cs908.dtb \
+ sun6i-a31s-primo81.dtb \
sun6i-a31s-sina31s.dtb \
sun6i-a31s-sinovoip-bpi-m2.dtb \
sun6i-a31s-yones-toptech-bs1078-v2.dtb
diff --git a/arch/arm/boot/dts/sun6i-a31s-primo81.dts
b/arch/arm/boot/dts/sun6i-a31s-primo81.dts
new file mode 100644
index ..2d4250b1faf8
--- /dev/null
+++ b/arch/arm/boot/dts/sun6i-a31s-primo81.dts
@@ -0,0 +1,255 @@
+/*
+ * Copyright 2014 Siarhei Siamashka
+ * Copyright 2015 Karsten Merker
+ * Copyright 2015 Chen-Yu Tsai
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file 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.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "sun6i-a31s.dtsi"
+#include "sunxi-common-regulators.dtsi"
+
+#include
+#include
+#include
+
+/ {
+ model = "MSI Primo81 tablet";
+ compatible = "msi,primo81", "allwinner,sun6i-a31s";
+};
+
+ {
+ cpu-supply = <_dcdc3>;
+};
+
+ {
+ /* rtl8188etv wifi is connected here */
+ status = "okay";
+};
+
+ {
+ /* pull-ups and device VDDIO use AXP221 DLDO3 */
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins_a>;
+ status = "failed";
+};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins_a>;
+ status = "okay";
+
+ ctp@5d {
+ pinctrl-names = "default";
+ pinctrl-0 = <_int_primo81>;
+ compatible = "goodix,gt911";
+ reg = <0x5d>;
+ interrupt-parent = <>;
+ interrupts = <0 3 IRQ_TYPE_LEVEL_HIGH>; /* PA3 */
+ };
+};
+
+ {
+ pinctrl-names = "default";
+
[PATCH v4 0/4] simplefb: Add regulator handling support
Hi everyone, This is v4 of the simplefb regulator support series. This series adds regulator claiming and enabling support for simplefb. Changes since v4: - Fixed inverted logic when testing the property name. - Fixed regulator supply name string copy length off by 1. - Added real world user, MSI Primo 81 dts patches. Changes since v3: - Dropped extra "if" which is always true, leftover from v1. - Updated commit message of patch 1 Sometimes the simplefb display output path consits of external conversion chips and/or LCD drivers and backlights. These devices normally have GPIOs to turn them on and/or bring them out of reset, and regulators supplying power to them. While the kernel does not touch unclaimed GPIOs, the regulator core happily disables unused regulators. Thus we need simplefb to claim and enable the regulators used throughout the display pipeline. The binding supports any named regulator supplies under its device node. The driver will look through its properties, and claim any regulators by matching "*-supply", as Mark suggested. I've not done a generic helper in the regulator core yet, instead doing the regulator property handling in the simplefb code for now. Patch 1 adds the regulator properties to the DT binding. Patch 2 adds code to the simplefb driver to claim and enable regulators. Hans, I dropped your Reviewed-by tag from this patch. Patch 3 adds labels to the simplefb device nodes in sun6i-a31.dtsi so we can reference them in the board dts files, like in the next patch. Patch 4 adds a dts file for MSI's Primo 81 tablet. Regards ChenYu Chen-Yu Tsai (3): dt-bindings: simplefb: Support regulator supply properties simplefb: Claim and enable regulators ARM: dts: sun6i: Add simplefb node labels to reference at board level Karsten Merker (1): ARM: dts: sun6i: Add dts file for MSI Primo81 tablet .../bindings/video/simple-framebuffer.txt | 13 +- arch/arm/boot/dts/Makefile | 1 + arch/arm/boot/dts/sun6i-a31.dtsi | 4 +- arch/arm/boot/dts/sun6i-a31s-primo81.dts | 255 + drivers/video/fbdev/simplefb.c | 120 +- 5 files changed, 386 insertions(+), 7 deletions(-) create mode 100644 arch/arm/boot/dts/sun6i-a31s-primo81.dts -- 2.6.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 v4 1/4] dt-bindings: simplefb: Support regulator supply properties
The physical display tied to the framebuffer may have regulators
providing power to it, such as power for LCDs or interface conversion
chips.
The number of regulators in use may vary, but the regulator supply
binding can not be a list. Instead just support any named regulator
supply properties under the device node. These should be properly
named to match the device schematics / design. The driver should
take care to go through them all.
Signed-off-by: Chen-Yu Tsai
Reviewed-by: Hans de Goede
Acked-by: Mark Brown
---
.../devicetree/bindings/video/simple-framebuffer.txt| 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/video/simple-framebuffer.txt
b/Documentation/devicetree/bindings/video/simple-framebuffer.txt
index 4474ef6e0b95..8c9e9f515c87 100644
--- a/Documentation/devicetree/bindings/video/simple-framebuffer.txt
+++ b/Documentation/devicetree/bindings/video/simple-framebuffer.txt
@@ -47,10 +47,14 @@ Required properties:
- a8b8g8r8 (32-bit pixels, d[31:24]=a, d[23:16]=b, d[15:8]=g, d[7:0]=r).
Optional properties:
-- clocks : List of clocks used by the framebuffer. Clocks listed here
- are expected to already be configured correctly. The OS must
- ensure these clocks are not modified or disabled while the
- simple framebuffer remains active.
+- clocks : List of clocks used by the framebuffer.
+- *-supply : Any number of regulators used by the framebuffer. These should
+be named according to the names in the device's design.
+
+ The above resources are expected to already be configured correctly.
+ The OS must ensure they are not modified or disabled while the simple
+ framebuffer remains active.
+
- display : phandle pointing to the primary display hardware node
Example:
@@ -68,6 +72,7 @@ chosen {
stride = <(1600 * 2)>;
format = "r5g6b5";
clocks = <_gates 36>, <_gates 43>, <_gates 44>;
+ lcd-supply = <_dc1sw>;
display = <>;
};
stdout-path = "display0";
--
2.6.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 v4 3/4] ARM: dts: sun6i: Add simplefb node labels to reference at board level
Some boards, such as tablets, have regulators providing power to parts
of the display pipeline, like signal converters and LCD panels.
Add labels to the simplefb device nodes so that we can reference them
in the board dts files to add regulator supply properties.
Signed-off-by: Chen-Yu Tsai
---
arch/arm/boot/dts/sun6i-a31.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi b/arch/arm/boot/dts/sun6i-a31.dtsi
index 83c18798cae0..b6ad7850fac6 100644
--- a/arch/arm/boot/dts/sun6i-a31.dtsi
+++ b/arch/arm/boot/dts/sun6i-a31.dtsi
@@ -61,7 +61,7 @@
#size-cells = <1>;
ranges;
- framebuffer@0 {
+ simplefb_hdmi: framebuffer@0 {
compatible = "allwinner,simple-framebuffer",
"simple-framebuffer";
allwinner,pipeline = "de_be0-lcd0-hdmi";
@@ -69,7 +69,7 @@
status = "disabled";
};
- framebuffer@1 {
+ simplefb_lcd: framebuffer@1 {
compatible = "allwinner,simple-framebuffer",
"simple-framebuffer";
allwinner,pipeline = "de_be0-lcd0";
--
2.6.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 v4 2/4] simplefb: Claim and enable regulators
This claims and enables regulators listed in the simple framebuffer dt
node. This is needed so that regulators powering the display pipeline
and external hardware, described in the device node and known by the
kernel code, will remain properly enabled.
Signed-off-by: Chen-Yu Tsai
Acked-by: Mark Brown
---
drivers/video/fbdev/simplefb.c | 120 -
1 file changed, 119 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/simplefb.c b/drivers/video/fbdev/simplefb.c
index 52c5c7e63b52..48ccf6db62a2 100644
--- a/drivers/video/fbdev/simplefb.c
+++ b/drivers/video/fbdev/simplefb.c
@@ -28,7 +28,10 @@
#include
#include
#include
+#include
#include
+#include
+#include
static struct fb_fix_screeninfo simplefb_fix = {
.id = "simple",
@@ -174,6 +177,10 @@ struct simplefb_par {
int clk_count;
struct clk **clks;
#endif
+#if defined CONFIG_OF && defined CONFIG_REGULATOR
+ u32 regulator_count;
+ struct regulator **regulators;
+#endif
};
#if defined CONFIG_OF && defined CONFIG_COMMON_CLK
@@ -269,6 +276,110 @@ static int simplefb_clocks_init(struct simplefb_par *par,
static void simplefb_clocks_destroy(struct simplefb_par *par) { }
#endif
+#if defined CONFIG_OF && defined CONFIG_REGULATOR
+
+#define SUPPLY_SUFFIX "-supply"
+
+/*
+ * Regulator handling code.
+ *
+ * Here we handle the num-supplies and vin*-supply properties of our
+ * "simple-framebuffer" dt node. This is necessary so that we can make sure
+ * that any regulators needed by the display hardware that the bootloader
+ * set up for us (and for which it provided a simplefb dt node), stay up,
+ * for the life of the simplefb driver.
+ *
+ * When the driver unloads, we cleanly disable, and then release the
+ * regulators.
+ *
+ * We only complain about errors here, no action is taken as the most likely
+ * error can only happen due to a mismatch between the bootloader which set
+ * up simplefb, and the regulator definitions in the device tree. Chances are
+ * that there are no adverse effects, and if there are, a clean teardown of
+ * the fb probe will not help us much either. So just complain and carry on,
+ * and hope that the user actually gets a working fb at the end of things.
+ */
+static int simplefb_regulators_init(struct simplefb_par *par,
+ struct platform_device *pdev)
+{
+ struct device_node *np = pdev->dev.of_node;
+ struct property *prop;
+ struct regulator *regulator;
+ const char *p;
+ int count = 0, i = 0, ret;
+
+ if (dev_get_platdata(>dev) || !np)
+ return 0;
+
+ /* Count the number of regulator supplies */
+ for_each_property_of_node(np, prop) {
+ p = strstr(prop->name, SUPPLY_SUFFIX);
+ if (p && p != prop->name)
+ count++;
+ }
+
+ if (!count)
+ return 0;
+
+ par->regulators = devm_kcalloc(>dev, count,
+ sizeof(struct regulator *), GFP_KERNEL);
+ if (!par->regulators)
+ return -ENOMEM;
+
+ /* Get all the regulators */
+ for_each_property_of_node(np, prop) {
+ char name[32]; /* 32 is max size of property name */
+
+ p = strstr(prop->name, SUPPLY_SUFFIX);
+ if (!p || p == prop->name)
+ continue;
+
+ strlcpy(name, prop->name,
+ strlen(prop->name) - strlen(SUPPLY_SUFFIX) + 1);
+ regulator = devm_regulator_get_optional(>dev, name);
+ if (IS_ERR(regulator)) {
+ if (PTR_ERR(regulator) == -EPROBE_DEFER)
+ return -EPROBE_DEFER;
+ dev_err(>dev, "regulator %s not found: %ld\n",
+ name, PTR_ERR(regulator));
+ continue;
+ }
+ par->regulators[i++] = regulator;
+ }
+ par->regulator_count = i;
+
+ /* Enable all the regulators */
+ for (i = 0; i < par->regulator_count; i++) {
+ ret = regulator_enable(par->regulators[i]);
+ if (ret) {
+ dev_err(>dev,
+ "failed to enable regulator %d: %d\n",
+ i, ret);
+ devm_regulator_put(par->regulators[i]);
+ par->regulators[i] = NULL;
+ }
+ }
+
+ return 0;
+}
+
+static void simplefb_regulators_destroy(struct simplefb_par *par)
+{
+ int i;
+
+ if (!par->regulators)
+ return;
+
+ for (i = 0; i < par->regulator_count; i++)
+ if (par->regulators[i])
+ regulator_disable(par->regulators[i]);
+}
+#else
+static int simplefb_regulators_init(struct simplefb_par *par,
+ struct platform_device *pdev) { return 0; }
+static void
Re: [PATCH v3 net-next] bpf: fix bpf_perf_event_read() helper
On 2015/10/23 8:10, Alexei Starovoitov wrote:
Fix safety checks for bpf_perf_event_read():
- only non-inherited events can be added to perf_event_array map
(do this check statically at map insertion time)
- dynamically check that event is local and !pmu->count
Otherwise buggy bpf program can cause kernel splat.
Also fix error path after perf_event_attrs()
and remove redundant 'extern'.
Fixes: 35578d798400 ("bpf: Implement function bpf_perf_event_read() that get the
selected hardware PMU conuter")
Signed-off-by: Alexei Starovoitov
Tested-by: Wang Nan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RESEND PATCH v4 3/3] mmc: sdhci-of-arasan: add runtime pm support
On 2015/10/22 20:08, Ulf Hansson wrote:
On 22 October 2015 at 11:06, Shawn Lin wrote:
This patch add runtime_suspend and runtime_resume for
sdhci-of-arasan. Currently we also power-off phy at
runtime_suspend for power-saving.
Signed-off-by: Shawn Lin
Serise-changes: 4
- remove ifdef for PM callback statement
- fix missing pm_runtime_set_active
- remove pm_runtime_dont_use_autosuspend from remove hook
- add pm_runtime_force_suspend|resume for PM callback to
deal with suspend invoked from rpm
- remove wrappers of phy ops
---
Changes in v2: None
drivers/mmc/host/sdhci-of-arasan.c | 85 --
1 file changed, 82 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/host/sdhci-of-arasan.c
b/drivers/mmc/host/sdhci-of-arasan.c
index 4f30716..fb1915c 100644
--- a/drivers/mmc/host/sdhci-of-arasan.c
+++ b/drivers/mmc/host/sdhci-of-arasan.c
@@ -30,6 +30,8 @@
#define CLK_CTRL_TIMEOUT_MASK (0xf << CLK_CTRL_TIMEOUT_SHIFT)
#define CLK_CTRL_TIMEOUT_MIN_EXP 13
+#define ARASAN_RPM_DELAY_MS50
+
/**
* struct sdhci_arasan_data
* @clk_ahb: Pointer to the AHB clock
@@ -71,6 +73,46 @@ static struct sdhci_pltfm_data sdhci_arasan_pdata = {
SDHCI_QUIRK2_CLOCK_DIV_ZERO_BROKEN,
};
+#ifdef CONFIG_PM
+static int sdhci_arasan_runtime_suspend(struct device *dev)
+{
+ struct sdhci_host *host = dev_get_drvdata(dev);
+ struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+ struct sdhci_arasan_data *sdhci_arasan = pltfm_host->priv;
+ int ret;
+
+ ret = sdhci_runtime_suspend_host(host);
+ if (ret)
+ return ret;
+
+ if (!IS_ERR(sdhci_arasan->phy))
+ phy_power_off(sdhci_arasan->phy);
+
+ clk_disable(sdhci_arasan->clk_ahb);
+ clk_disable(pltfm_host->clk);
The above calls can be changed to clk_disable_unprepare(). Vice verse
in sdhci_arasan_runtime_resume() below.
+
+ return 0;
+}
+
+static int sdhci_arasan_runtime_resume(struct device *dev)
+{
+ struct sdhci_host *host = dev_get_drvdata(dev);
+ struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+ struct sdhci_arasan_data *sdhci_arasan = pltfm_host->priv;
+
+ clk_enable(pltfm_host->clk);
+ clk_enable(sdhci_arasan->clk_ahb);
+
+ if (!IS_ERR(sdhci_arasan->phy))
+ phy_power_on(sdhci_arasan->phy);
+
+ return sdhci_runtime_resume_host(host);
+}
+#else
+#define sdhci_arasan_runtime_suspend NULL
+#define sdhci_arasan_runtime_resume NULL
+#endif
+
#ifdef CONFIG_PM_SLEEP
/**
* sdhci_arasan_suspend - Suspend method for the driver
@@ -87,6 +129,12 @@ static int sdhci_arasan_suspend(struct device *dev)
struct sdhci_arasan_data *sdhci_arasan = pltfm_host->priv;
int ret;
+ ret = pm_runtime_force_suspend(dev);
+ if (ret) {
+ dev_err(dev, "problem force suspending\n");
+ return ret;
+ }
+
I think your are in right track, but unfortunate you still have some
work to do. :-)
You can't call sdhci_suspend_host() with a runtime suspended host. You
will for example access sdhci internal registers, even-though the
clock to the SDHCI controller is gated, which is not a good idea.
Now, this leads me to the following questions/ideas, which I am really
glad we can bring up within this context.
So, sdhci_suspend_host() and sdhci_runtime_suspend_host() performs
very similar actions, but not completely the same.
I have a feeling that we might be able to merge the above functions
into one function. The only thing that may differ between system PM
and runtime PM, is probably the wakeup settings and since that is
possible to control before the sdhci variant host driver decide to
call these functions, merging them might work.
From a wakeup point of view, does your case have different settings
between system PM and runtime PM?
What do you think?
My case doesn't have diff settings between system PM and runtime PM.
If my understanding is proper, I guess you want to remove
sdhci_suspend|resume_host and assign pm_runtime_force_suspend|resume to
SET_SYSTEM_SLEEP_PM_OPS directly by sdhci variant HCs?
If that is the case, I guess we should look more precisely into other
sdhci variant HCs to check whether they need to do diff things for
system PM and RPM or not.
ret = sdhci_suspend_host(host);
if (ret)
return ret;
@@ -140,18 +188,39 @@ static int sdhci_arasan_resume(struct device *dev)
}
}
- return sdhci_resume_host(host);
+ ret = sdhci_resume_host(host);
+ if (ret)
+ goto err_resume_host;
+
+ ret = pm_runtime_force_resume(dev);
+ if (ret) {
+ dev_err(dev, "problem force resuming\n");
+ goto err_force_resume;
+ }
+
+ return 0;
+err_force_resume:
+ sdhci_suspend_host(host);
+err_resume_host:
+ if
Re: [PATCH] mm: Introduce kernelcore=reliable option
On 2015/10/15 21:32, Taku Izumi wrote:
> Xeon E7 v3 based systems supports Address Range Mirroring
> and UEFI BIOS complied with UEFI spec 2.5 can notify which
> ranges are reliable (mirrored) via EFI memory map.
> Now Linux kernel utilize its information and allocates
> boot time memory from reliable region.
>
> My requirement is:
> - allocate kernel memory from reliable region
> - allocate user memory from non-reliable region
>
> In order to meet my requirement, ZONE_MOVABLE is useful.
> By arranging non-reliable range into ZONE_MOVABLE,
> reliable memory is only used for kernel allocations.
>
> This patch extends existing "kernelcore" option and
> introduces kernelcore=reliable option. By specifying
> "reliable" instead of specifying the amount of memory,
> non-reliable region will be arranged into ZONE_MOVABLE.
>
> Earlier discussion is at:
> https://lkml.org/lkml/2015/10/9/24
>
> For example, suppose 2-nodes system with the following
> memory range:
> node 0 [mem 0x1000-0x00109fff]
> node 1 [mem 0x0010a000-0x00209fff]
>
> and the following ranges are marked as reliable (*):
> [0x-0x0001]
> [0x0001-0x00018000]
> [0x0010a000-0x00112000]
>
> If you specify kernelcore=reliable, Movable zones are
> arranged like the following:
> Movable zone start for each node
> Node 0: 0x00018000
> Node 1: 0x00112000
>
> (*) I specified the following instead of using UEFI BIOS
> complied with UEFI spec 2.5,
> efi_fake_mem=4G@0:0x1,2G@0x10a000:0x1,2G@4G:0x1
> efi_fake_mem is found at:
> git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi.git
> tags/efi-next
>
> Signed-off-by: Taku Izumi
> ---
> Documentation/kernel-parameters.txt | 9 -
> mm/page_alloc.c | 26 ++
> 2 files changed, 34 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/kernel-parameters.txt
> b/Documentation/kernel-parameters.txt
> index cd5312f..b2c8c13 100644
> --- a/Documentation/kernel-parameters.txt
> +++ b/Documentation/kernel-parameters.txt
> @@ -1663,7 +1663,8 @@ bytes respectively. Such letter suffixes can also be
> entirely omitted.
>
> keepinitrd [HW,ARM]
>
> - kernelcore=nn[KMG] [KNL,X86,IA-64,PPC] This parameter
> + kernelcore= Format: nn[KMG] | "reliable"
> + [KNL,X86,IA-64,PPC] This parameter
> specifies the amount of memory usable by the kernel
> for non-movable allocations. The requested amount is
> spread evenly throughout all nodes in the system. The
> @@ -1679,6 +1680,12 @@ bytes respectively. Such letter suffixes can also be
> entirely omitted.
> use the HighMem zone if it exists, and the Normal
> zone if it does not.
>
> + Instead of specifying the amount of memory (nn[KMS]),
> + you can specify "reliable" option. In case "reliable"
> + option is specified, reliable memory is used for
> + non-movable allocations and remaining memory is used
> + for Movable pages.
> +
> kgdbdbgp= [KGDB,HW] kgdb over EHCI usb debug port.
> Format: [,poll interval]
> The controller # is the number of the ehci usb debug
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index beda417..d0b3ac9 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -221,6 +221,7 @@ static unsigned long __meminitdata
> arch_zone_highest_possible_pfn[MAX_NR_ZONES];
> static unsigned long __initdata required_kernelcore;
> static unsigned long __initdata required_movablecore;
> static unsigned long __meminitdata zone_movable_pfn[MAX_NUMNODES];
> +static bool reliable_kernelcore __initdata;
>
> /* movable_zone is the "real" zone pages in ZONE_MOVABLE are taken from */
> int movable_zone;
> @@ -5618,6 +5619,25 @@ static void __init
> find_zone_movable_pfns_for_nodes(void)
> }
>
> /*
> + * If kernelcore=reliable is specified, ignore movablecore option
> + */
> + if (reliable_kernelcore) {
> + for_each_memblock(memory, r) {
> + if (memblock_is_mirror(r))
> + continue;
> +
> + nid = r->nid;
> +
> + usable_startpfn = PFN_DOWN(r->base);
> + zone_movable_pfn[nid] = zone_movable_pfn[nid] ?
> + min(usable_startpfn, zone_movable_pfn[nid]) :
> + usable_startpfn;
> + }
> +
> + goto out2;
Hi Taku,
If user set 0-1G is mirrored memory, 1-2G is normal memory, and 2-4G is hole.
Then the movable zone will start at 2G?
Thanks,
Xishi Qiu
> + }
> +
> + /*
>* If
Re: [PATCH 8/9] powerpc: simplify csum_add(a, b) in case a or b is constant 0
On Tue, 2015-09-22 at 16:34 +0200, Christophe Leroy wrote:
> Simplify csum_add(a, b) in case a or b is constant 0
>
> Signed-off-by: Christophe Leroy
> ---
> arch/powerpc/include/asm/checksum.h | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/arch/powerpc/include/asm/checksum.h
> b/arch/powerpc/include/asm/checksum.h
> index 56deea8..f8a9704 100644
> --- a/arch/powerpc/include/asm/checksum.h
> +++ b/arch/powerpc/include/asm/checksum.h
> @@ -119,7 +119,13 @@ static inline __wsum csum_add(__wsum csum, __wsum
> addend)
> {
> #ifdef __powerpc64__
> u64 res = (__force u64)csum;
> +#endif
> + if (__builtin_constant_p(csum) && csum == 0)
> + return addend;
> + if (__builtin_constant_p(addend) && addend == 0)
> + return csum;
>
> +#ifdef __powerpc64__
> res += (__force u64)addend;
> return (__force __wsum)((u32)res + (res >> 32));
> #else
How often does this happen?
-Scott
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Please pull powerpc/linux.git powerpc-4.3-5 tag
Hi Linus, Please pull some more powerpc fixes for 4.3: The following changes since commit abb39bc792aa8e9143e78a39ec13d7de1391f4b4: selftests/powerpc: Fix build failure of load_unaligned_zeropad test (2015-10-13 15:08:37 +1100) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git tags/powerpc-4.3-5 for you to fetch changes up to 8832317f662c06f5c06e638f57bfe89a71c9b266: powerpc/rtas: Validate rtas.entry before calling enter_rtas() (2015-10-22 11:03:25 +1100) powerpc fixes for 4.3 #4 - Revert "Use the POWER8 Micro Partition Prefetch Engine in KVM HV on POWER8" from Paul - Handle irq_happened flag correctly in off-line loop from Paul - Validate rtas.entry before calling enter_rtas() from Vasant Paul Mackerras (2): powerpc: Revert "Use the POWER8 Micro Partition Prefetch Engine in KVM HV on POWER8" powerpc/powernv: Handle irq_happened flag correctly in off-line loop Vasant Hegde (1): powerpc/rtas: Validate rtas.entry before calling enter_rtas() arch/powerpc/include/asm/cache.h | 7 - arch/powerpc/include/asm/kvm_host.h | 2 -- arch/powerpc/include/asm/ppc-opcode.h | 17 --- arch/powerpc/include/asm/reg.h| 1 - arch/powerpc/kernel/rtas.c| 3 ++ arch/powerpc/kvm/book3s_hv.c | 55 +-- arch/powerpc/platforms/powernv/smp.c | 29 ++ 7 files changed, 28 insertions(+), 86 deletions(-) signature.asc Description: This is a digitally signed message part
Re: [PATCH 9/9] powerpc: optimise csum_partial() call when len is constant
On Tue, 2015-09-22 at 16:34 +0200, Christophe Leroy wrote: > csum_partial is often called for small fixed length packets > for which it is suboptimal to use the generic csum_partial() > function. > > For instance, in my configuration, I got: > * One place calling it with constant len 4 > * Seven places calling it with constant len 8 > * Three places calling it with constant len 14 > * One place calling it with constant len 20 > * One place calling it with constant len 24 > * One place calling it with constant len 32 > > This patch renames csum_partial() to __csum_partial() and > implements csum_partial() as a wrapper inline function which > * uses csum_add() for small 16bits multiple constant length > * uses ip_fast_csum() for other 32bits multiple constant > * uses __csum_partial() in all other cases > > Signed-off-by: Christophe Leroy > --- > arch/powerpc/include/asm/checksum.h | 80 ++ > --- > arch/powerpc/lib/checksum_32.S | 4 +- > arch/powerpc/lib/checksum_64.S | 4 +- > arch/powerpc/lib/ppc_ksyms.c| 2 +- > 4 files changed, 62 insertions(+), 28 deletions(-) Benchmarks? -Scott -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 6/9] powerpc32: optimise a few instructions in csum_partial()
On Tue, 2015-09-22 at 16:34 +0200, Christophe Leroy wrote: > r5 does contain the value to be updated, so lets use r5 all way long > for that. It makes the code more readable. > > To avoid confusion, it is better to use adde instead of addc > > The first addition is useless. Its only purpose is to clear carry. > As r4 is a signed int that is always positive, this can be done by > using srawi instead of srwi > > Let's also remove the comment about bdnz having no overhead as it > is not correct on all powerpc, at least on MPC8xx > > In the last part, in our situation, the remaining quantity of bytes > to be proceeded is between 0 and 3. Therefore, we can base that part > on the value of bit 31 and bit 30 of r4 instead of anding r4 with 3 > then proceding on comparisons and substractions. > > Signed-off-by: Christophe Leroy > --- > arch/powerpc/lib/checksum_32.S | 37 + > 1 file changed, 17 insertions(+), 20 deletions(-) Do you have benchmarks for these optimizations? -Scott > > diff --git a/arch/powerpc/lib/checksum_32.S b/arch/powerpc/lib/checksum_32.S > index 3472372..9c12602 100644 > --- a/arch/powerpc/lib/checksum_32.S > +++ b/arch/powerpc/lib/checksum_32.S > @@ -27,35 +27,32 @@ > * csum_partial(buff, len, sum) > */ > _GLOBAL(csum_partial) > - addic r0,r5,0 > subir3,r3,4 > - srwi. r6,r4,2 > + srawi. r6,r4,2 /* Divide len by 4 and also clear carry */ > beq 3f /* if we're doing < 4 bytes */ > - andi. r5,r3,2 /* Align buffer to longword boundary */ > + andi. r0,r3,2 /* Align buffer to longword boundary */ > beq+1f > - lhz r5,4(r3)/* do 2 bytes to get aligned */ > - addir3,r3,2 > + lhz r0,4(r3)/* do 2 bytes to get aligned */ > subir4,r4,2 > - addcr0,r0,r5 > + addir3,r3,2 > srwi. r6,r4,2 /* # words to do */ > + adder5,r5,r0 > beq 3f > 1: mtctr r6 > -2: lwzur5,4(r3)/* the bdnz has zero overhead, so it should */ > - adder0,r0,r5/* be unnecessary to unroll this loop */ > +2: lwzur0,4(r3) > + adder5,r5,r0 > bdnz2b > - andi. r4,r4,3 > -3: cmpwi 0,r4,2 > - blt+4f > - lhz r5,4(r3) > +3: andi. r0,r4,2 > + beq+4f > + lhz r0,4(r3) > addir3,r3,2 > - subir4,r4,2 > - adder0,r0,r5 > -4: cmpwi 0,r4,1 > - bne+5f > - lbz r5,4(r3) > - slwir5,r5,8 /* Upper byte of word */ > - adder0,r0,r5 > -5: addze r3,r0 /* add in final carry */ > + adder5,r5,r0 > +4: andi. r0,r4,1 > + beq+5f > + lbz r0,4(r3) > + slwir0,r0,8 /* Upper byte of word */ > + adder5,r5,r0 > +5: addze r3,r5 /* add in final carry */ > blr > > /* -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/2] simplefb: Claim and enable regulators
On Fri, Oct 23, 2015 at 9:31 AM, Chen-Yu Tsai wrote:
> This claims and enables regulators listed in the simple framebuffer dt
> node. This is needed so that regulators powering the display pipeline
> and external hardware, described in the device node and known by the
> kernel code, will remain properly enabled.
>
> Signed-off-by: Chen-Yu Tsai
> Reviewed-by: Hans de Goede
> Acked-by: Mark Brown
> ---
> drivers/video/fbdev/simplefb.c | 120
> -
> 1 file changed, 119 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/video/fbdev/simplefb.c b/drivers/video/fbdev/simplefb.c
> index 52c5c7e63b52..9de34ee15ac0 100644
> --- a/drivers/video/fbdev/simplefb.c
> +++ b/drivers/video/fbdev/simplefb.c
> @@ -28,7 +28,10 @@
> #include
> #include
> #include
> +#include
> #include
> +#include
> +#include
>
> static struct fb_fix_screeninfo simplefb_fix = {
> .id = "simple",
> @@ -174,6 +177,10 @@ struct simplefb_par {
> int clk_count;
> struct clk **clks;
> #endif
> +#if defined CONFIG_OF && defined CONFIG_REGULATOR
> + u32 regulator_count;
> + struct regulator **regulators;
> +#endif
> };
>
> #if defined CONFIG_OF && defined CONFIG_COMMON_CLK
> @@ -269,6 +276,110 @@ static int simplefb_clocks_init(struct simplefb_par
> *par,
> static void simplefb_clocks_destroy(struct simplefb_par *par) { }
> #endif
>
> +#if defined CONFIG_OF && defined CONFIG_REGULATOR
> +
> +#define SUPPLY_SUFFIX "-supply"
> +
> +/*
> + * Regulator handling code.
> + *
> + * Here we handle the num-supplies and vin*-supply properties of our
> + * "simple-framebuffer" dt node. This is necessary so that we can make sure
> + * that any regulators needed by the display hardware that the bootloader
> + * set up for us (and for which it provided a simplefb dt node), stay up,
> + * for the life of the simplefb driver.
> + *
> + * When the driver unloads, we cleanly disable, and then release the
> + * regulators.
> + *
> + * We only complain about errors here, no action is taken as the most likely
> + * error can only happen due to a mismatch between the bootloader which set
> + * up simplefb, and the regulator definitions in the device tree. Chances are
> + * that there are no adverse effects, and if there are, a clean teardown of
> + * the fb probe will not help us much either. So just complain and carry on,
> + * and hope that the user actually gets a working fb at the end of things.
> + */
> +static int simplefb_regulators_init(struct simplefb_par *par,
> + struct platform_device *pdev)
> +{
> + struct device_node *np = pdev->dev.of_node;
> + struct property *prop;
> + struct regulator *regulator;
> + const char *p;
> + int count = 0, i = 0, ret;
> +
> + if (dev_get_platdata(>dev) || !np)
> + return 0;
> +
> + /* Count the number of regulator supplies */
> + for_each_property_of_node(np, prop) {
> + p = strstr(prop->name, SUPPLY_SUFFIX);
> + if (p && p != prop->name)
> + count++;
> + }
> +
> + if (!count)
> + return 0;
> +
> + par->regulators = devm_kcalloc(>dev, count,
> + sizeof(struct regulator *),
> GFP_KERNEL);
> + if (!par->regulators)
> + return -ENOMEM;
> +
> + /* Get all the regulators */
> + for_each_property_of_node(np, prop) {
> + char name[32]; /* 32 is max size of property name */
> +
> + p = strstr(prop->name, SUPPLY_SUFFIX);
> + if (p && p != prop->name)
Sorry, the test is completely reversed here.
> + continue;
> +
> + strlcpy(name, prop->name,
> + strlen(prop->name) - sizeof(SUPPLY_SUFFIX) + 1);
And string length is off by 1 due to using sizeof here.
I'll send a new version. Sorry for the noise.
ChenYu
> + regulator = devm_regulator_get_optional(>dev, name);
> + if (IS_ERR(regulator)) {
> + if (PTR_ERR(regulator) == -EPROBE_DEFER)
> + return -EPROBE_DEFER;
> + dev_err(>dev, "regulator %s not found: %ld\n",
> + name, PTR_ERR(regulator));
> + continue;
> + }
> + par->regulators[i++] = regulator;
> + }
> + par->regulator_count = i;
> +
> + /* Enable all the regulators */
> + for (i = 0; i < par->regulator_count; i++) {
> + ret = regulator_enable(par->regulators[i]);
> + if (ret) {
> + dev_err(>dev,
> + "failed to enable regulator %d: %d\n",
> + i, ret);
> + devm_regulator_put(par->regulators[i]);
> + par->regulators[i] = NULL;
> + }
> +
Re: [PATCH 3/9] powerpc32: checksum_wrappers_64 becomes checksum_wrappers
On Tue, 2015-09-22 at 16:34 +0200, Christophe Leroy wrote:
> The powerpc64 checksum wrapper functions adds csum_and_copy_to_user()
> which otherwise is implemented in include/net/checksum.h by using
> csum_partial() then copy_to_user()
>
> Those two wrapper fonctions are also applicable to powerpc32 as it is
> based on the use of csum_partial_copy_generic() which also
> exists on powerpc32
>
> This patch renames arch/powerpc/lib/checksum_wrappers_64.c to
> arch/powerpc/lib/checksum_wrappers.c and
> makes it non-conditional to CONFIG_WORD_SIZE
>
> Signed-off-by: Christophe Leroy
> ---
> arch/powerpc/include/asm/checksum.h | 9 --
> ---
> arch/powerpc/lib/Makefile| 3 +--
> arch/powerpc/lib/{checksum_wrappers_64.c => checksum_wrappers.c} | 0
> 3 files changed, 1 insertion(+), 11 deletions(-)
> rename arch/powerpc/lib/{checksum_wrappers_64.c => checksum_wrappers.c}
> (100%)
I wonder why it was 64-bit specific in the first place.
CCing Anton Blanchard.
-Scott
>
> diff --git a/arch/powerpc/include/asm/checksum.h
> b/arch/powerpc/include/asm/checksum.h
> index d2ca07b..afa6722 100644
> --- a/arch/powerpc/include/asm/checksum.h
> +++ b/arch/powerpc/include/asm/checksum.h
> @@ -47,21 +47,12 @@ extern __wsum csum_partial_copy_generic(const void
> *src, void *dst,
> int len, __wsum sum,
> int *src_err, int *dst_err);
>
> -#ifdef __powerpc64__
> #define _HAVE_ARCH_COPY_AND_CSUM_FROM_USER
> extern __wsum csum_and_copy_from_user(const void __user *src, void *dst,
> int len, __wsum sum, int *err_ptr);
> #define HAVE_CSUM_COPY_USER
> extern __wsum csum_and_copy_to_user(const void *src, void __user *dst,
> int len, __wsum sum, int *err_ptr);
> -#else
> -/*
> - * the same as csum_partial, but copies from src to dst while it
> - * checksums.
> - */
> -#define csum_partial_copy_from_user(src, dst, len, sum, errp) \
> -csum_partial_copy_generic((__force const void *)(src), (dst),
> (len), (sum), (errp), NULL)
> -#endif
>
> #define csum_partial_copy_nocheck(src, dst, len, sum) \
> csum_partial_copy_generic((src), (dst), (len), (sum), NULL, NULL)
> diff --git a/arch/powerpc/lib/Makefile b/arch/powerpc/lib/Makefile
> index a47e142..e46b068 100644
> --- a/arch/powerpc/lib/Makefile
> +++ b/arch/powerpc/lib/Makefile
> @@ -22,8 +22,7 @@ obj64-$(CONFIG_SMP) += locks.o
> obj64-$(CONFIG_ALTIVEC) += vmx-helper.o
>
> ifeq ($(CONFIG_GENERIC_CSUM),)
> -obj-y+= checksum_$(CONFIG_WORD_SIZE).o
> -obj-$(CONFIG_PPC64) += checksum_wrappers_64.o
> +obj-y+= checksum_$(CONFIG_WORD_SIZE).o
> checksum_wrappers.o
> endif
>
> obj-$(CONFIG_PPC_EMULATE_SSTEP) += sstep.o ldstfp.o
> diff --git a/arch/powerpc/lib/checksum_wrappers_64.c
> b/arch/powerpc/lib/checksum_wrappers.c
> similarity index 100%
> rename from arch/powerpc/lib/checksum_wrappers_64.c
> rename to arch/powerpc/lib/checksum_wrappers.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/
Re: [PATCH v11 07/14] HMM: mm add helper to update page table when migrating memory v2.
> > > This is a multi-stage process, first we save and replace page table > > > entry with special HMM entry, also flushing tlb in the process. If > > > we run into non allocated entry we either use the zero page or we > > > allocate new page. For swaped entry we try to swap them in. > > > > > Please elaborate why swap entry is handled this way. > > So first, this is only when you have a device then use HMM and a device > that use memory migration. So far it only make sense for discrete GPUs. > So regular workload that do not use a GPUs with HMM are not impacted and > will not go throught this code path. > > Now, here we are migrating memory because the device driver is asking for > it, so presumably we are expecting that the device will use that memory > hence we want to swap in anything that have been swap to disk. Once it is > swap in memory we copy it to device memory and free the pages. So in the > end we only need to allocate a page temporarily until we move things to > the device. > I prefer it is in log message. thanks Hillf -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v11 02/14] HMM: add special swap filetype for memory migrated to device v2.
> > > + if (cnt_hmm_entry) {
> > > + int ret;
> > > +
> > > + ret = hmm_mm_fork(src_mm, dst_mm, dst_vma,
> > > + dst_pmd, start, end);
> >
> > Given start, s/end/addr/, no?
>
> No, end is the right upper limit here.
>
Then in the first loop, hmm_mm_fork is invoked for
the _entire_ range, from input addr to end.
In subsequent loops(if necessary), start is updated to
addr, and hmm_mm_fork is also invoked for remaining
range, from start to end.
Is the above overlap in range making sense?
Hillf
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v12 6/6] QE: Move QE from arch/powerpc to drivers/soc
On Wed, Oct 14, 2015 at 03:16:08PM +0800, Zhao Qiang wrote: > diff --git a/arch/powerpc/platforms/Kconfig b/arch/powerpc/platforms/Kconfig > index 01626be7..c9541a5 100644 > --- a/arch/powerpc/platforms/Kconfig > +++ b/arch/powerpc/platforms/Kconfig > @@ -272,25 +272,6 @@ config TAU_AVERAGE > > If in doubt, say N here. > > -config QUICC_ENGINE > - bool "Freescale QUICC Engine (QE) Support" > - depends on FSL_SOC && PPC32 > - select GENERIC_ALLOCATOR > - select CRC32 > - help > - The QUICC Engine (QE) is a new generation of communications > - coprocessors on Freescale embedded CPUs (akin to CPM in older chips). > - Selecting this option means that you wish to build a kernel > - for a machine with a QE coprocessor. > - > -config QE_GPIO > - bool "QE GPIO support" > - depends on QUICC_ENGINE > - select ARCH_REQUIRE_GPIOLIB > - help > - Say Y here if you're going to use hardware that connects to the > - QE GPIOs. Why was QE_GPIO moved as part of this patch? > diff --git a/arch/powerpc/sysdev/qe_lib/Kconfig b/drivers/soc/fsl/qe/Kconfig > similarity index 50% > copy from arch/powerpc/sysdev/qe_lib/Kconfig > copy to drivers/soc/fsl/qe/Kconfig > index 3c25199..283fe0d 100644 > --- a/arch/powerpc/sysdev/qe_lib/Kconfig > +++ b/drivers/soc/fsl/qe/Kconfig > @@ -2,6 +2,17 @@ > # QE Communication options > # > > +config QUICC_ENGINE > + bool "Freescale QUICC Engine (QE) Support" > + depends on FSL_SOC && PPC32 > + select GENERIC_ALLOCATOR > + select CRC32 > + help > + The QUICC Engine (QE) is a new generation of communications > + coprocessors on Freescale embedded CPUs (akin to CPM in older chips). > + Selecting this option means that you wish to build a kernel > + for a machine with a QE coprocessor. > + > config UCC_SLOW > bool > default y if SERIAL_QE > @@ -19,9 +30,3 @@ config UCC_FAST > config UCC > bool > default y if UCC_FAST || UCC_SLOW > - > -config QE_USB > - bool > - default y if USB_FSL_QE > - help > - QE USB Controller support Why did some config symbols get moved and others not? > diff --git a/drivers/soc/fsl/qe/Makefile b/drivers/soc/fsl/qe/Makefile > new file mode 100644 > index 000..51c9dce > --- /dev/null > +++ b/drivers/soc/fsl/qe/Makefile > @@ -0,0 +1,9 @@ > +# > +#Makefile for the Linux fsl parts of QE > +# "fsl parts of QE"? Are there non-fsl parts of QE? -Scott -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v12 5/6] QE: use subsys_initcall to init qe
On Wed, 2015-10-14 at 15:16 +0800, Zhao Qiang wrote:
> diff --git a/arch/powerpc/sysdev/qe_lib/qe.c >
> b/arch/powerpc/sysdev/qe_lib/qe.c
> index c2518cd..3f9f596 100644
> --- a/arch/powerpc/sysdev/qe_lib/qe.c
> +++ b/arch/powerpc/sysdev/qe_lib/qe.c
> @@ -671,6 +671,21 @@ unsigned int qe_get_num_of_snums(void)
> }
> EXPORT_SYMBOL(qe_get_num_of_snums);
>
> +static int __init qe_init(void)
> +{
> + struct device_node *np;
> +
> + np = of_find_compatible_node(NULL, NULL, "fsl,qe");
> + if (!np) {
> + pr_err("%s: Could not find Quicc Engine node\n", __func__);
> + return -ENODEV;
> + }
> + qe_reset();
> + of_node_put(np);
> + return 0;
> +}
> +subsys_initcall(qe_init);
Do not print an error, just because QE is not present.
-Scott
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v12 4/6] QE/CPM: move muram management functions to qe_common
On Wed, 2015-10-14 at 15:16 +0800, Zhao Qiang wrote:
> QE and CPM have the same muram, they use the same management
> functions. Now QE support both ARM and PowerPC, it is necessary
> to move QE to "driver/soc", so move the muram management functions
> from cpm_common to qe_common for preparing to move QE code to "driver/soc"
>
> Signed-off-by: Zhao Qiang
> ---
> Changes for v2:
> - no changes
> Changes for v3:
> - no changes
> Changes for v4:
> - no changes
> Changes for v5:
> - no changes
> Changes for v6:
> - using genalloc instead rheap to manage QE MURAM
> - remove qe_reset from platform file, using
> - subsys_initcall to call qe_init function.
> Changes for v7:
> - move this patch from 3/3 to 2/3
> - convert cpm with genalloc
> - check for gen_pool allocation failure
> Changes for v8:
> - rebase
> - move BD_SC_* macro instead of copy
> Changes for v9:
> - doesn't modify CPM, add a new patch to modify.
> - rebase
> Changes for v10:
> - rebase
> Changes for v11:
> - remove renaming
> - delete removing qe_reset and delete adding qe_init.
> Changes for v12:
> - SPI_FSL_CPM depends on QE-MURAM, select QUICC_ENGINE for it.
Why is the SPI change part of this patch? Why is it even part of this
patchset, rather than an independent patch sent to the SPI list and
maintainer? If it's tied to other changes you're making, explain that. As
is, there is zero mention of the SPI change in the part of the e-mail that
will become the git changelog.
>
> arch/powerpc/include/asm/cpm.h | 44 -
> arch/powerpc/include/asm/qe.h | 16 ++
> arch/powerpc/sysdev/cpm_common.c | 210 +-
> ---
> arch/powerpc/sysdev/qe_lib/Makefile| 2 +-
> .../sysdev/{cpm_common.c => qe_lib/qe_common.c}| 188 +-
> drivers/spi/Kconfig| 1 +
> 6 files changed, 28 insertions(+), 433 deletions(-)
> copy arch/powerpc/sysdev/{cpm_common.c => qe_lib/qe_common.c} (54%)
>
> diff --git a/arch/powerpc/include/asm/cpm.h b/arch/powerpc/include/asm/cpm.h
> index 0e1ac3f..05a1c15 100644
> --- a/arch/powerpc/include/asm/cpm.h
> +++ b/arch/powerpc/include/asm/cpm.h
> @@ -155,50 +155,6 @@ typedef struct cpm_buf_desc {
> */
> #define BD_I2C_START (0x0400)
>
> -int cpm_muram_init(void);
> -
> -#if defined(CONFIG_CPM) || defined(CONFIG_QUICC_ENGINE)
> -unsigned long cpm_muram_alloc(unsigned long size, unsigned long align);
> -int cpm_muram_free(unsigned long offset);
> -unsigned long cpm_muram_alloc_fixed(unsigned long offset, unsigned long
> size);
> -unsigned long cpm_muram_alloc_common(unsigned long size, void *data);
> -void __iomem *cpm_muram_addr(unsigned long offset);
> -unsigned long cpm_muram_offset(void __iomem *addr);
> -dma_addr_t cpm_muram_dma(void __iomem *addr);
> -#else
> -static inline unsigned long cpm_muram_alloc(unsigned long size,
> - unsigned long align)
> -{
> - return -ENOSYS;
> -}
> -
> -static inline int cpm_muram_free(unsigned long offset)
> -{
> - return -ENOSYS;
> -}
> -
> -static inline unsigned long cpm_muram_alloc_fixed(unsigned long offset,
> - unsigned long size)
> -{
> - return -ENOSYS;
> -}
> -
> -static inline void __iomem *cpm_muram_addr(unsigned long offset)
> -{
> - return NULL;
> -}
> -
> -static inline unsigned long cpm_muram_offset(void __iomem *addr)
> -{
> - return -ENOSYS;
> -}
> -
> -static inline dma_addr_t cpm_muram_dma(void __iomem *addr)
> -{
> - return 0;
> -}
> -#endif /* defined(CONFIG_CPM) || defined(CONFIG_QUICC_ENGINE) */
> -
> #ifdef CONFIG_CPM
> int cpm_command(u32 command, u8 opcode);
> #else
> diff --git a/arch/powerpc/include/asm/qe.h b/arch/powerpc/include/asm/qe.h
> index 32b9bfa..c2dd8e6 100644
> --- a/arch/powerpc/include/asm/qe.h
> +++ b/arch/powerpc/include/asm/qe.h
> @@ -16,11 +16,15 @@
> #define _ASM_POWERPC_QE_H
> #ifdef __KERNEL__
>
> +#include
> #include
> #include
> #include
> #include
> #include
> +#include
> +#include
> +#include
>
> #define QE_NUM_OF_SNUM 256 /* There are 256 serial number in QE */
> #define QE_NUM_OF_BRGS 16
> @@ -92,6 +96,18 @@ extern void qe_reset(void);
> static inline void qe_reset(void) {}
> #endif
>
> +int cpm_muram_init(void);
> +
> +#if defined(CONFIG_CPM) || defined(CONFIG_QUICC_ENGINE)
> +unsigned long cpm_muram_alloc(unsigned long size, unsigned long align);
> +int cpm_muram_free(unsigned long offset);
> +unsigned long cpm_muram_alloc_fixed(unsigned long offset, unsigned long
> size);
> +unsigned long cpm_muram_alloc_common(unsigned long size, void *data);
> +void __iomem *cpm_muram_addr(unsigned long offset);
> +unsigned long cpm_muram_offset(void __iomem *addr);
> +dma_addr_t cpm_muram_dma(void __iomem *addr);
> +#endif /*
RE: [PATCH v2] EDAC: Add ARM64 EDAC
Hi Steve, Thanks for pointing the link, I have not seen that driver before; I was mainly looking at driver/edac/xgene_edac.c and some other arm edac drivers. My first attempt was to do AMD specific edac driver to log correctable L1/L2 error but based on feedback I worked on v2 generic driver which now looks very similar to your driver, are you planning to upstream your driver ? I can work with you to verify it on my current hardware setup. It seems your driver also handles single-bit and double-bit error which I have no way to test in my current hardware setup. On Seattle platform most of error handling is done through firmware APEI except correctable L1/L2. Let me know your thoughts. -Brijesh From: Stepan Moskovchenko [step...@codeaurora.org] Sent: Thursday, October 22, 2015 8:51 PM To: Singh, Brijeshkumar Cc: robh...@kernel.org; pawel.m...@arm.com; mark.rutl...@arm.com; ijc+devicet...@hellion.org.uk; ga...@codeaurora.org; dougthomp...@xmission.com; b...@alien8.de; mche...@osg.samsung.com; devicet...@vger.kernel.org; guohan...@huawei.com; andre.przyw...@arm.com; a...@arndb.de; linux-kernel@vger.kernel.org; linux-e...@vger.kernel.org Subject: Re: [PATCH v2] EDAC: Add ARM64 EDAC >>> +++ b/drivers/edac/cortex_arm64_edac.c >>> @@ -0,0 +1,457 @@ >>> +/* >>> + * Cortex ARM64 EDAC >>> + * >>> + * Copyright (c) 2015, Advanced Micro Devices >>> + * Author: Brijesh Singh >>> + * >Hi Brijesh, >Your ARM64 EDAC driver seems rather similar to the existing driver that >is linked below. If you have indeed based your driver on this one, can >you please provide the appropriate attribution? >https://www.codeaurora.org/cgit/quic/la/kernel/msm-3.14/tree/drivers/edac/cortex_arm64_edac.c?h=LA.HB.1.1.1_rb1.10 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v12 3/6] CPM/QE: use genalloc to manage CPM/QE muram
On Wed, 2015-10-14 at 15:16 +0800, Zhao Qiang wrote:
> Use genalloc to manage CPM/QE muram instead of rheap.
>
> Signed-off-by: Zhao Qiang
> ---
> Changes for v9:
> - splitted from patch 3/5, modify cpm muram management functions.
> Changes for v10:
> - modify cpm muram first, then move to qe_common
> - modify commit.
> Changes for v11:
> - factor out the common alloc code
> - modify min_alloc_order to zero for cpm_muram_alloc_fixed.
> Changes for v12:
> - Nil
>
> arch/powerpc/include/asm/cpm.h | 1 +
> arch/powerpc/platforms/Kconfig | 2 +-
> arch/powerpc/sysdev/cpm_common.c | 129 +++-
> ---
> 3 files changed, 93 insertions(+), 39 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/cpm.h b/arch/powerpc/include/asm/cpm.h
> index 4398a6c..0e1ac3f 100644
> --- a/arch/powerpc/include/asm/cpm.h
> +++ b/arch/powerpc/include/asm/cpm.h
> @@ -161,6 +161,7 @@ int cpm_muram_init(void);
> unsigned long cpm_muram_alloc(unsigned long size, unsigned long align);
> int cpm_muram_free(unsigned long offset);
> unsigned long cpm_muram_alloc_fixed(unsigned long offset, unsigned long
> size);
> +unsigned long cpm_muram_alloc_common(unsigned long size, void *data);
> void __iomem *cpm_muram_addr(unsigned long offset);
> unsigned long cpm_muram_offset(void __iomem *addr);
> dma_addr_t cpm_muram_dma(void __iomem *addr);
> diff --git a/arch/powerpc/platforms/Kconfig b/arch/powerpc/platforms/Kconfig
> index b7f9c40..01626be7 100644
> --- a/arch/powerpc/platforms/Kconfig
> +++ b/arch/powerpc/platforms/Kconfig
> @@ -275,7 +275,7 @@ config TAU_AVERAGE
> config QUICC_ENGINE
> bool "Freescale QUICC Engine (QE) Support"
> depends on FSL_SOC && PPC32
> - select PPC_LIB_RHEAP
> + select GENERIC_ALLOCATOR
> select CRC32
> help
> The QUICC Engine (QE) is a new generation of communications
> diff --git a/arch/powerpc/sysdev/cpm_common.c
> b/arch/powerpc/sysdev/cpm_common.c
> index 4f78695..ff47072 100644
> --- a/arch/powerpc/sysdev/cpm_common.c
> +++ b/arch/powerpc/sysdev/cpm_common.c
> @@ -17,6 +17,7 @@
> * published by the Free Software Foundation.
> */
>
> +#include
> #include
> #include
> #include
> @@ -27,7 +28,6 @@
>
> #include
> #include
> -#include
> #include
>
> #include
> @@ -65,14 +65,22 @@ void __init udbg_init_cpm(void)
> }
> #endif
>
> +static struct gen_pool *muram_pool;
> static spinlock_t cpm_muram_lock;
> -static rh_block_t cpm_boot_muram_rh_block[16];
> -static rh_info_t cpm_muram_info;
> static u8 __iomem *muram_vbase;
> static phys_addr_t muram_pbase;
>
> -/* Max address size we deal with */
> +struct muram_block {
> + struct list_head head;
> + unsigned long start;
> + int size;
> +};
> +
> +static LIST_HEAD(muram_block_list);
> +
> +/* max address size we deal with */
> #define OF_MAX_ADDR_CELLS4
> +#define GENPOOL_OFFSET (4096 * 8)
>
> int cpm_muram_init(void)
> {
> @@ -87,50 +95,52 @@ int cpm_muram_init(void)
> return 0;
>
> spin_lock_init(_muram_lock);
> - /* initialize the info header */
> - rh_init(_muram_info, 1,
> - sizeof(cpm_boot_muram_rh_block) /
> - sizeof(cpm_boot_muram_rh_block[0]),
> - cpm_boot_muram_rh_block);
> -
> np = of_find_compatible_node(NULL, NULL, "fsl,cpm-muram-data");
> if (!np) {
> /* try legacy bindings */
> np = of_find_node_by_name(NULL, "data-only");
> if (!np) {
> - printk(KERN_ERR "Cannot find CPM muram data node");
> + pr_err("Cannot find CPM muram data node");
> ret = -ENODEV;
> - goto out;
> + goto out_muram;
> }
> }
>
> + muram_pool = gen_pool_create(0, -1);
> muram_pbase = of_translate_address(np, zero);
> if (muram_pbase == (phys_addr_t)OF_BAD_ADDR) {
> - printk(KERN_ERR "Cannot translate zero through CPM muram node");
> + pr_err("Cannot translate zero through CPM muram node");
> ret = -ENODEV;
> - goto out;
> + goto out_pool;
> }
>
> while (of_address_to_resource(np, i++, ) == 0) {
> if (r.end > max)
> max = r.end;
> + ret = gen_pool_add(muram_pool, r.start - muram_pbase +
> +GENPOOL_OFFSET, resource_size(), -1);
> + if (ret) {
> + pr_err("QE: couldn't add muram to pool!\n");
> + goto out_pool;
> + }
>
Whitespace
> - rh_attach_region(_muram_info, r.start - muram_pbase,
> - resource_size());
> }
>
> muram_vbase = ioremap(muram_pbase, max - muram_pbase + 1);
> if (!muram_vbase) {
> - printk(KERN_ERR "Cannot
Re: nfs race condition
Nicolas Parpandet writes:
> Hello,
>
> I did some more investigations, (wireshark)
>
> The unlink of /tmp/crontab.vYPoHR/crontab is tranlated into a rename
> nfs call ? (.nfs file)
That happens if the file is still open.
>
> NFS 670 V3 READDIRPLUS Reply (Call In 731) crontab .. .
> NFS 210 V3 LOOKUP Call (Reply In 734), DH:
> 0x038abb3d/.nfs0098008a0019
> NFS 194 V3 LOOKUP Reply (Call In 733) Error: NFS3ERR_NOENT
> NFS 254 V3 RENAME Call (Reply In 736), From DH: 0x038abb3d/crontab To
> DH: 0x038abb3d/.nfs0098008a0019
> NFS 338 V3 RENAME Reply (Call In 735)
>
> and after, it tries to remove the directory /tmp/crontab.0wuoNx :
> NFS 198 V3 RMDIR Call (Reply In 738), DH: 0x954c28ec/crontab.0wuoNx
> NFS 222 V3 RMDIR Reply (Call In 737) Error: NFS3ERR_NOTEMPTY
>
> but the file /tmp/crontab.0wuoNx/crontab was renamed instead of being removed
> (nfs network, I cannot see .nfs000 file in fact),
> this prevent the removing of the directory /tmp/crontab.0wuoNx (notempty)
>
> It seems a race condition, see "nfs silly rename" keyword, but I have
> the problem with mysql temp files, and crontab temp file (crontab -e),
I don't think it is a race condition exactly. More of an ordering
problem.
Unlinking a file before closing it is rarely useful (sometimes it is,
but not here).
> am I the only one doing mysql and crontabs over NFS !!!?!?,
Probably.
> does anybody have a solution ?
Fix 'crontab' to close before unlinking...
Is this the Debian/Ubuntu crontab program it looks a bit like it,
but this bug was fixed 6 years ago.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=413962
Or use a tmpfs for /tmp/ rather than using NFS???
NeilBrown
>
>
> Regards
>
> Nicolas
>
>
> - Mail original -
> De: "npa"
> À: linux-kernel@vger.kernel.org
> Cc: "pcoustillas"
> Envoyé: Dimanche 4 Octobre 2015 09:57:26
> Objet: nfs race condition
>
> Hello,
>
> I'm doing some " crontab -e, exit with :x" on NFS mount point,
> and there is a race condition whent removing temporary files :
>
>
> 7701 write(2, "No modification made\n", 21) = 21
> 7701 open("/tmp/crontab.vYPoHR", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) =
> 4
> 7701 getdents(4, {{d_ino=73336409, d_off=1, d_reclen=24, d_name="."}
> {d_ino=73335455, d_off=2, d_reclen=24, d_name=".."} {d_ino=73340547, d_off=3,
> d_reclen=32, d_name="crontab"}}, 32768) = 80
> 7701 unlink("/tmp/crontab.vYPoHR/crontab") = 0
> 7701 getdents(4, {}, 32768) = 0
> 7701 close(4) = 0
> 7701 rmdir("/tmp/crontab.vYPoHR") = -1 ENOTEMPTY (Directory not empty)
> 7701 write(2, "/tmp/crontab.vYPoHR: Directory n"..., 41) = 41
> 7701 socket(PF_FILE, SOCK_DGRAM|SOCK_CLOEXEC, 0) = 4
>
> The unlink is really done after the rmdir,
> nfsv4 & nfsv3 over ipv6, so the rmdir fails and the directory isn't removed.
> I have same problem with mysql temporary files.
>
> If I mount with "nocto,noac,lookupcache=none" : same problem
> kernel version on server : 3.16.0-4-amd64 (debian8)
> kernel version on client : 2.6.32-39-pve (proxmox), same thing with
> 3.13.0-63-generic (ubuntu)
>
> Please answer me in CC, I'm not subscribed to the list.
>
> Regards
>
> Nicolas
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
signature.asc
Description: PGP signature
[Linux v4.3-rc6] i915: issues with Skylake integrated graphics
Hi, I am testing Linux v4.3-rc6 on a laptop with Intel 'Skylake' integrated graphics. The integrated display works, but I noticed several warnings in the kernel log, and a VGA monitor attached to the HDMI input via a VGA->HDMI adapter did not work. Furthermore, the system hung for several seconds during boot. The two WARNs were: [1.078097] WARNING: CPU: 0 PID: 1 at drivers/gpu/drm/i915/intel_pm.c:3321 skl_update_pipe_wm+0x7fa/0x810() [1.078097] WARN_ON(p->pixel_rate == 0) ... [1.353670] WARNING: CPU: 1 PID: 6 at drivers/gpu/drm/i915/intel_dp.c:854 intel_dp_aux_ch+0x10f/0x6a0() [1.353670] dp_aux_ch not started status 0xad40001f The following error was reported later, when the HDMI input was connected but the driver failed to report the input as connected: [ 52.553940] [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 130 I have attached the full 'dmesg' output for anyone who may find it useful. Eric dmesg.gz Description: Binary data
Re: [PATCH v8 00/14] support "task_isolation" mode for nohz_full
On Thu, Oct 22, 2015 at 04:31:44PM -0400, Chris Metcalf wrote: > On 10/21/2015 08:39 AM, Peter Zijlstra wrote: > >Can you *please* start a new thread with each posting? > > > >This is absolutely unmanageable. > > I've been explicitly threading the multiple patch series on purpose > due to this text in "git help send-email": > >--in-reply-to= > Make the first mail (or all the mails with --no-thread) appear > as a reply to the given Message-Id, which avoids breaking > threads to provide a new patch series. The second and subsequent > emails will be sent as replies according to the > --[no]-chain-reply-to setting. > > So for example when --thread and --no-chain-reply-to are > specified, the second and subsequent patches will be replies to > the first one like in the illustration below where [PATCH v2 > 0/3] is in reply to [PATCH 0/2]: > > [PATCH 0/2] Here is what I did... > [PATCH 1/2] Clean up and tests > [PATCH 2/2] Implementation > [PATCH v2 0/3] Here is a reroll > [PATCH v2 1/3] Clean up > [PATCH v2 2/3] New tests > [PATCH v2 3/3] Implementation > > It sounds like this is exactly the behavior you are objecting > to. It's all one to me because I am not seeing these emails > come up in some hugely nested fashion, but just viewing the > responses that I haven't yet triaged away. I personally (and I think this is the general LKML behaviour) use in-reply-to when I post a single patch that is a fix for a bug, or a small enhancement, discussed on some thread. It works well as it fits the conversation inline. But for anything that requires significant changes, namely a patchset, and that includes a new version of such patchset, it's usually better to create a new thread. Otherwise the thread becomes an infinite mess and it eventually expands further the mail client columns. Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 net-next] bpf: fix bpf_perf_event_read() helper
On 10/22/15 7:21 PM, Wangnan (F) wrote: +if (attr->inherit) +goto err; + Since Peter suggest it is pointless for a system-wide perf_event has inherit bit set [1], I think it should be safe to enable system-wide perf_event pass this check? here we don't know whether it's system wide or not, so the check is needed. The patch is the fix that should have been there from day one. We must be safe first and relax later. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 net-next] bpf: fix bpf_perf_event_read() helper
On 2015/10/23 8:10, Alexei Starovoitov wrote:
Fix safety checks for bpf_perf_event_read():
- only non-inherited events can be added to perf_event_array map
(do this check statically at map insertion time)
- dynamically check that event is local and !pmu->count
Otherwise buggy bpf program can cause kernel splat.
Also fix error path after perf_event_attrs()
and remove redundant 'extern'.
Fixes: 35578d798400 ("bpf: Implement function bpf_perf_event_read() that get the
selected hardware PMU conuter")
Signed-off-by: Alexei Starovoitov
---
v2->v3:
. refactor checks based on Wangnan's and Peter's feedback
while refactoring realized that these two issues need fixes as well:
. fix perf_event_attrs() error path
. remove redundant extern
v1->v2: fix compile in case of !CONFIG_PERF_EVENTS
Even in the worst case the crash is not possible.
Only warn_on_once, so imo net-next is ok.
include/linux/bpf.h |1 -
kernel/bpf/arraymap.c| 25 -
kernel/trace/bpf_trace.c |7 ++-
3 files changed, 22 insertions(+), 11 deletions(-)
diff --git a/include/linux/bpf.h b/include/linux/bpf.h
index e3a51b74e275..75718fa28260 100644
--- a/include/linux/bpf.h
+++ b/include/linux/bpf.h
@@ -194,7 +194,6 @@ extern const struct bpf_func_proto
bpf_map_lookup_elem_proto;
extern const struct bpf_func_proto bpf_map_update_elem_proto;
extern const struct bpf_func_proto bpf_map_delete_elem_proto;
-extern const struct bpf_func_proto bpf_perf_event_read_proto;
extern const struct bpf_func_proto bpf_get_prandom_u32_proto;
extern const struct bpf_func_proto bpf_get_smp_processor_id_proto;
extern const struct bpf_func_proto bpf_tail_call_proto;
diff --git a/kernel/bpf/arraymap.c b/kernel/bpf/arraymap.c
index e3cfe46b074f..3f4c99e06c6b 100644
--- a/kernel/bpf/arraymap.c
+++ b/kernel/bpf/arraymap.c
@@ -292,16 +292,23 @@ static void *perf_event_fd_array_get_ptr(struct bpf_map
*map, int fd)
attr = perf_event_attrs(event);
if (IS_ERR(attr))
- return (void *)attr;
+ goto err;
- if (attr->type != PERF_TYPE_RAW &&
- !(attr->type == PERF_TYPE_SOFTWARE &&
- attr->config == PERF_COUNT_SW_BPF_OUTPUT) &&
- attr->type != PERF_TYPE_HARDWARE) {
- perf_event_release_kernel(event);
- return ERR_PTR(-EINVAL);
- }
- return event;
+ if (attr->inherit)
+ goto err;
+
Since Peter suggest it is pointless for a system-wide perf_event
has inherit bit set [1], I think it should be safe to enable
system-wide perf_event pass this check?
I'll check code to make sure.
[1]
http://lkml.kernel.org/r/20151022124142.gq17...@twins.programming.kicks-ass.net
+ if (attr->type == PERF_TYPE_RAW)
+ return event;
+
+ if (attr->type == PERF_TYPE_HARDWARE)
+ return event;
+
+ if (attr->type == PERF_TYPE_SOFTWARE &&
+ attr->config == PERF_COUNT_SW_BPF_OUTPUT)
+ return event;
+err:
+ perf_event_release_kernel(event);
+ return ERR_PTR(-EINVAL);
}
static void perf_event_fd_array_put_ptr(void *ptr)
diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
index 47febbe7998e..003df3887287 100644
--- a/kernel/trace/bpf_trace.c
+++ b/kernel/trace/bpf_trace.c
@@ -199,6 +199,11 @@ static u64 bpf_perf_event_read(u64 r1, u64 index, u64 r3,
u64 r4, u64 r5)
if (!event)
return -ENOENT;
+ /* make sure event is local and doesn't have pmu::count */
+ if (event->oncpu != smp_processor_id() ||
+ event->pmu->count)
+ return -EINVAL;
+
/*
* we don't know if the function is run successfully by the
* return value. It can be judged in other places, such as
@@ -207,7 +212,7 @@ static u64 bpf_perf_event_read(u64 r1, u64 index, u64 r3,
u64 r4, u64 r5)
return perf_event_read_local(event);
}
-const struct bpf_func_proto bpf_perf_event_read_proto = {
+static const struct bpf_func_proto bpf_perf_event_read_proto = {
.func = bpf_perf_event_read,
.gpl_only = false,
.ret_type = RET_INTEGER,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] dma: dts: Add Freescale qDMA engine driver support
Add Freescale Queue Direct Memory Access(qDMA) controller support.
This module can be found on LS-1 and LS-2 SoCs.
This add the legacy mode support for qDMA.
Signed-off-by: Yuan Yao
---
arch/arm/boot/dts/ls1021a.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi
index 9430a99..9d7073b 100644
--- a/arch/arm/boot/dts/ls1021a.dtsi
+++ b/arch/arm/boot/dts/ls1021a.dtsi
@@ -428,6 +428,16 @@
<_clk 1>;
};
+ qdma: qdma@8389000 {
+ compatible = "fsl,ls1021a-qdma";
+ reg = <0x0 0x8389000 0x0 0x2>;
+ interrupts = ,
+;
+ interrupt-names = "qdma-tx", "qdma-err";
+ channels = <1>;
+ big-endian;
+ };
+
mdio0: mdio@2d24000 {
compatible = "gianfar";
device_type = "mdio";
--
2.1.0.27.g96db324
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] timer: Lazily wakup nohz CPU when adding new timer.
On 22-10-15, 14:40, Yunhong Jiang wrote: > A naive question is, why it's sure a tick will happen when the tickless > processor is in idle? How do you get this impression? I don't think anyone has said that. We are talking about deferrable timers, which by design are only required if the target CPU is not-idle. If it is idle, then the timer isn't required to be serviced until the CPU wakes up. And the CPU can take whatever time it wants to wake up again. > Is it because scheduler load balance is sure to send a > tick to the processor in future? No. We aren't expecting the CPU to wake up any time soon. Just ignore the deferrable timer. -- viresh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/3] dma: Binding for freescale qDMA engine driver support
Add Binding document for Freescale Queue Direct Memory Access(qDMA)
controller.
This module can be found on LS-1 and LS-2 SoCs.
Signed-off-by: Yuan Yao
---
Documentation/devicetree/bindings/dma/fsl-qdma.txt | 43 ++
1 file changed, 43 insertions(+)
create mode 100644 Documentation/devicetree/bindings/dma/fsl-qdma.txt
diff --git a/Documentation/devicetree/bindings/dma/fsl-qdma.txt
b/Documentation/devicetree/bindings/dma/fsl-qdma.txt
new file mode 100644
index 000..cdae71c
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/fsl-qdma.txt
@@ -0,0 +1,43 @@
+* Freescale queue Direct Memory Access Controller(qDMA) Controller
+
+ The qDMA controller transfers blocks of data between one source and one or
more
+destinations. The blocks of data transferred can be represented in memory as
contiguous
+or non-contiguous using scatter/gather table(s). Channel virtualization is
supported
+through enqueuing of DMA jobs to, or dequeuing DMA jobs from, different work
+queues.
+ Legacy mode is primarily included for software requiring the earlier
+QorIQ DMA programming model. This mode provides a simple programming
+model not utilizing the datapath architecture. In legacy mode, DMA
+operations are directly configured through a set of architectural
+registers per channel.
+
+* qDMA Controller
+Required properties:
+- compatible :
+ - "fsl,ls1021a-qdma" for qDMA used similar to that on LS SoC
+- reg : Specifies base physical address(s) and size of the qDMA registers.
+ The region is qDMA control register's address and size.
+- interrupts : A list of interrupt-specifiers, one for each entry in
+ interrupt-names.
+- interrupt-names : Should contain:
+ "qdma-tx" - the interrupt
+ "qdma-err" - the error interrupt
+- channels : Number of channels supported by the controller
+
+Optional properties:
+- big-endian: If present registers and hardware scatter/gather descriptors
+ of the qDMA are implemented in big endian mode, otherwise in little
+ mode.
+
+
+Examples:
+
+ qdma: qdma@839 {
+ compatible = "fsl,ls1021a-qdma";
+ reg = <0x0 0x838 0x0 0x2>;
+ interrupts = ,
+ ;
+ interrupt-names = "qdma-tx", "qdma-err";
+ big-endian;
+ channels = <1>;
+ };
--
2.1.0.27.g96db324
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] dma: Add Freescale qDMA engine driver support
Add Freescale Queue Direct Memory Access(qDMA) controller support.
This module can be found on LS-1 and LS-2 SoCs.
This add the legacy mode support for qDMA.
Signed-off-by: Yuan Yao
---
Changes since v1:
1. Separate Binding.
2. Remove dead code.
3. Add depend on for QDMA.
---
MAINTAINERS| 8 +
drivers/dma/Kconfig| 11 ++
drivers/dma/Makefile | 1 +
drivers/dma/fsl-qdma.c | 510 +
4 files changed, 530 insertions(+)
create mode 100644 drivers/dma/fsl-qdma.c
diff --git a/MAINTAINERS b/MAINTAINERS
index a2d50fe..bc504df 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4419,6 +4419,14 @@ L: linuxppc-...@lists.ozlabs.org
S: Maintained
F: drivers/dma/fsldma.*
+FREESCALE qDMA DRIVER
+M: Yuan Yao
+L: linux-arm-ker...@lists.infradead.org
+L: dmaeng...@vger.kernel.org
+S: Maintained
+F: Documentation/devicetree/bindings/dma/fsl-qdma.txt
+F: drivers/dma/fsl-qdma.c
+
FREESCALE I2C CPM DRIVER
M: Jochen Friedrich
L: linuxppc-...@lists.ozlabs.org
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index af81a7a..1743a89 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -193,6 +193,17 @@ config FSL_EDMA
multiplexing capability for DMA request sources(slot).
This module can be found on Freescale Vybrid and LS-1 SoCs.
+config FSL_QDMA
+ tristate "Freescale qDMA engine support"
+ depends on SOC_LS1021A || ARCH_LAYERSCAPE
+ select DMA_ENGINE
+ select DMA_VIRTUAL_CHANNELS
+ help
+ Support the Freescale qDMA engine with command queue and legacy mode.
+ Channel virtualization is supported through enqueuing of DMA jobs to,
+ or dequeuing DMA jobs from, different work queues.
+ This module can be found on Freescale LS SoCs.
+
config FSL_RAID
tristate "Freescale RAID engine Support"
depends on FSL_SOC && !ASYNC_TX_ENABLE_CHANNEL_SWITCH
diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
index ef9c099..47d63fe 100644
--- a/drivers/dma/Makefile
+++ b/drivers/dma/Makefile
@@ -29,6 +29,7 @@ obj-$(CONFIG_DW_DMAC_CORE) += dw/
obj-$(CONFIG_EP93XX_DMA) += ep93xx_dma.o
obj-$(CONFIG_FSL_DMA) += fsldma.o
obj-$(CONFIG_FSL_EDMA) += fsl-edma.o
+obj-$(CONFIG_FSL_QDMA) += fsl-qdma.o
obj-$(CONFIG_FSL_RAID) += fsl_raid.o
obj-$(CONFIG_HSU_DMA) += hsu/
obj-$(CONFIG_IMG_MDC_DMA) += img-mdc-dma.o
diff --git a/drivers/dma/fsl-qdma.c b/drivers/dma/fsl-qdma.c
new file mode 100644
index 000..b2c80d9
--- /dev/null
+++ b/drivers/dma/fsl-qdma.c
@@ -0,0 +1,510 @@
+/*
+ * drivers/dma/fsl-qdma.c
+ *
+ * Copyright 2014-2015 Freescale Semiconductor, Inc.
+ *
+ * Driver for the Freescale qDMA engine with legacy mode.
+ * This module can be found on Freescale LS SoCs.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
+ * by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "virt-dma.h"
+
+#define FSL_QDMA_DMR 0x0
+#define FSL_QDMA_DSR_P 0x4
+
+#define FSL_QDMA_DSR_M 0x10004
+#define FSL_QDMA_DLMR 0x10100
+#define FSL_QDMA_DLSR 0x10104
+#define FSL_QDMA_DLSATR0x10110
+#define FSL_QDMA_DLSAR 0x10114
+#define FSL_QDMA_DLDATR0x10118
+#define FSL_QDMA_DLDAR 0x1011c
+#define FSL_QDMA_DLBCR 0x10120
+#define FSL_QDMA_DLESAD0x10148
+#define FSL_QDMA_DLEDAD0x1014c
+
+#define FSL_QDMA_DLMR_CS 0x1
+#define FSL_QDMA_DLMR_EOSIE0x200
+#define FSL_QDMA_DLMR_EIE 0x40
+#define FSL_QDMA_DLSR_TE 0x80
+#define FSL_QDMA_DLSR_CH 0x20
+#define FSL_QDMA_DLSR_PE 0x10
+#define FSL_QDMA_DLSR_CB 0x4
+#define FSL_QDMA_DLSR_EOSI 0x2
+
+#define FSL_QDMA_SRTTYPE_R_N 0x4
+
+struct fsl_qdma_tcd {
+ u64 saddr;
+ u32 nbytes;
+ u64 daddr;
+};
+
+struct fsl_qdma_chan_config {
+ enum dma_transfer_direction dir;
+ enum dma_slave_buswidth addr_width;
+ u32 burst;
+ u32 attr;
+};
+
+struct fsl_qdma_desc {
+ struct virt_dma_descvdesc;
+ struct fsl_qdma_chan*qchan;
+ struct fsl_qdma_tcd tcd;
+};
+
+struct fsl_qdma_chan {
+ struct virt_dma_chanvchan;
+ struct fsl_qdma_desc*desc;
+ enum dma_status status;
+ u32 slave_id;
+ struct fsl_qdma_engine *qdma;
+};
+
+struct fsl_qdma_engine {
+ struct dma_device dma_dev;
+ void __iomem*membase;
+ u32 n_chans;
+ struct mutex
Re: [Ksummit-discuss] Linux Foundation Technical Advisory Board Elections and Nomination process
Darren Hart writes: > > Is there a good description of what is expected of a TAB member? How much time > is involved? What makes a great TAB member? > > I've found: http://www.linuxfoundation.org/programs/advisory-councils/tab > > I've read the charter and scanned some of the minutes, but I'd still like to > hear from some of the "incumbants". Specifically, what makes you successful > as a > member of the TAB? Also on the topic of the TAB and elections, I cannot figure out what: "Only one vote per candidate will be counted." means in: Voting: --- Each person present at the time of the election shall be handed a printed ballot. Voters may vote for as many candidates as they wish. Only one vote per candidate will be counted. A space will be provided where they can fill out the ballot in private and place it into a box to be counted in private. in http://www.linuxfoundation.org/collaborate/workgroups/technical-advisory-board-tab/minutes-july-2015-tab-meeting Is it "Only one vote per candidate per voter will be counted"? NeilBrown signature.asc Description: PGP signature
Re: [PATCH] x86/PCI: Don't alloc pcibios-irq when MSI is enabled
On 2015/10/22 0:23, Bjorn Helgaas wrote:
> On Fri, Oct 09, 2015 at 12:23:34PM +0200, Joerg Roedel wrote:
>> From: Joerg Roedel
>>
>> The pcibios-irq and MSI both use dev->irq to store the IRQ
>> number. While the MSI code checks for that and frees the
>> pcibios-irq before overwriting dev->irq, the
>> pcibios_alloc_irq function does not.
>>
>> Usually this is not a problem, as the pcibios-irq is
>> allocated before probe time of the device and the MSI irq is
>> allocted from the drivers probe path.
>>
>> But there are PCI devices handled by the core kernel and not
>> by a standard pci driver, like the AMD IOMMU for example.
>> For the AMD IOMMU a normal pci device driver does not make
>> sense, because a driver can be forcibly unbound from its
>> device, which is not a good idea for an IOMMU.
>>
>> Nevertheless the PCI core code tries to match the PCI device
>> implementing the AMD IOMMU against drivers, and
>> allocates/frees a pcibios IRQ every time it tries out a new
>> driver. This overwrites the dev->irq field set by
>> pci_enable_msi() and sets it to 0 in the end (because the
>> probe fails and the pcibios-irq is freed again).
>>
>> On suspend/resume this breaks the kernel, because the irq
>> descriptor for irq 0 is NULL.
>>
>> Fix this by not allocating a pcibios-irq when MSI is
>> already active. This also has the benefit, that a device
>> claimed by the core kernel can not be probed by a pci driver
>> later.
>>
>> Cc: Jiang Liu
>> Reported-by: Borislav Petkov
>> Signed-off-by: Joerg Roedel
>
> Applied with Thomas' reviewed-by to pci/msi for v4.4, thanks, Joerg!
Hi Bjorn,
There's another patch already merged into mainstream kernel,
which solves this issue in another way by making use of
pci_dev->match_driver flag. Please refer to:
cbbc00be2ce3 ("iommu/amd: Prevent binding other PCI drivers to IOMMU PCI
devices")
So I think this patch is redundant now.
Thanks,
Gerry
>
>> ---
>> arch/x86/pci/common.c | 8
>> 1 file changed, 8 insertions(+)
>>
>> diff --git a/arch/x86/pci/common.c b/arch/x86/pci/common.c
>> index dc78a4a..6254c06 100644
>> --- a/arch/x86/pci/common.c
>> +++ b/arch/x86/pci/common.c
>> @@ -675,6 +675,14 @@ int pcibios_add_device(struct pci_dev *dev)
>>
>> int pcibios_alloc_irq(struct pci_dev *dev)
>> {
>> +/*
>> + * If the PCI device was already claimed by core code and has
>> + * MSI enabled, probing of the pcibios irq will overwrite
>> + * dev->irq. So bail out if MSI is already enabled.
>> + */
>> +if (pci_dev_msi_enabled(dev))
>> +return -EBUSY;
>> +
>> return pcibios_enable_irq(dev);
>> }
>>
>> --
>> 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/
Re: [PATCH net-next] net: dsa: mv88e6xxx: remove debugfs interface
From: Vivien Didelot Date: Thu, 22 Oct 2015 16:54:31 -0400 > It is preferable to have a common debugfs interface for DSA or switchdev > instead of a driver specific one. Thus remove the mv88e6xxx debug code. > > Signed-off-by: Vivien Didelot Applied, 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 0/3] fix the TSHUT issue on rockchip thermal
Thank you all for providing inputs and comments on previous versions of this patchset. Especially thanks to the (Doug, Rob). We need the OTP pin is gpio state before resetting the TSADC controller, since the tshut polarity will generate a high signal. Says: The TSHUT temperature is setting more than 80 degree, the default tshut polarity is HIGH. If T > 80C, the OTP output the High Signal. If T < 80C, the OTP output the Low Signal. On the moment, the TSADC controller is reset, the tshut polarity will be Low in a short period of time. So: If T < 80C, the OTP output the High Signal. If T > 80C, the OTP output the Low Signal. In some cases, the OTP pin is connected to the PMIC, maybe the PMIC can accept the reset response time to avoid this issue. In other words, the system will be always reboot if we make the OTP pin is connected the others IC to control the power. This series patchs are depend on Doug's patch.(https://patchwork.kernel.org/patch/7454311/) This series patchs are based on the Linus master branch. 518cd44 ARM: dts: rockchip: Add the OTP gpio pinctrl 83e0bab dt-bindings: Add the "init" pinctrl in this document 150426c drivers/pinctrl: Add the concept of an "init" state ce1fad2 Merge branch 'keys-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs 1099f86 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net 911b79c KEYS: Don't permit request_key() to construct a new keyring 37850e3 net: bcmgenet: Fix early link interrupt enabling afc050d Merge tag 'wireless-drivers-for-davem-2015-10-17' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers e277de5 tunnels: Don't require remote endpoint or ID during creation. 740dbc2 openvswitch: Scrub skb between namespaces Tested on box board. Changes in v3: - Add the pictrl states decription in document. - Add the pinctrl state for in the suspend/resume. - Add the "sleep" pinctrl as the gpio state in PATCH[3/3] Changes in v2: - Add the 'init' pinctrl more decription in commit. - Fix the subject to make more obvious in PATCH[1/2] - Resend this patch v2 since fix the subject to be specific. - Add some commits for more obvious in PATCH[2/2] Changes in v1: - As the Doug comments, add the 'init' property to sync document. - As the Doug comments, drop the thermal driver patchs since we can with pinctrl changing to work. - As the Doug's patch to add the 'init' property. Caesar Wang (3): dt-bindings: rockchip-thermal: Add the pinctrl states in this document thermal: rockchip: ensure the otp states before resetting the controller ARM: dts: rockchip: Add the OTP gpio pinctrl .../devicetree/bindings/thermal/rockchip-thermal.txt | 11 +-- arch/arm/boot/dts/rk3288.dtsi | 10 -- drivers/thermal/rockchip_thermal.c| 4 3 files changed, 21 insertions(+), 4 deletions(-) -- 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 v3 1/3] dt-bindings: rockchip-thermal: Add the pinctrl states in this document
The "init" pinctrl is defined we'll set
pinctrl to this state before probe and then "default" after probe.
Add the "init" and "sleep" pinctrl as the OTP gpio state, since we need
switch the pin to gpio state before the TSADC controller is reset.
AFAIK, the TSADC controller is reset, the tshut polarity will be
a *low* signal in a short period of time for some devices.
Says:
The TSADC get the temperature on rockchip thermal.
If T(current temperature) < (setting temperature), the OTP output the
*high* signal.
If T(current temperature) > (setting temperature), the OTP output the
*low* Signal.
In some cases, the OTP pin is connected to the PMIC, maybe the
PMIC can accept the reset response time to avoid this issue.
In other words, the system will be always reboot if we make the
OTP pin is connected the others IC to control the power.
Signed-off-by: Caesar Wang
Reviewed-by: Douglas Anderson
---
Changes in v3:
- Add the pictrl states decription in document.
Changes in v2:
- Add the 'init' pinctrl more decription in commit.
- Fix the subject to make more obvious in PATCH[1/2]
- Resend this patch v2 since fix the subject to be specific.
Changes in v1:
- As the Doug comments, add the 'init' property to sync document.
.../devicetree/bindings/thermal/rockchip-thermal.txt | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt
b/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt
index ef802de..b38200d 100644
--- a/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt
+++ b/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt
@@ -12,6 +12,11 @@ Required properties:
- resets : Must contain an entry for each entry in reset-names.
See ../reset/reset.txt for details.
- reset-names : Must include the name "tsadc-apb".
+- pinctrl-names : The pin control state names;
+- pinctrl-0 : The "init" pinctrl state, it will be set before device probe.
+- pinctrl-1 : The "default" pinctrl state, it will be set after reset the
+ TSADC controller.
+- pinctrl-2 : The "sleep" pinctrl state, it will be in for suspend.
- #thermal-sensor-cells : Should be 1. See ./thermal.txt for a description.
- rockchip,hw-tshut-temp : The hardware-controlled shutdown temperature value.
- rockchip,hw-tshut-mode : The hardware-controlled shutdown mode 0:CRU 1:GPIO.
@@ -27,8 +32,10 @@ tsadc: tsadc@ff28 {
clock-names = "tsadc", "apb_pclk";
resets = < SRST_TSADC>;
reset-names = "tsadc-apb";
- pinctrl-names = "default";
- pinctrl-0 = <_out>;
+ pinctrl-names = "init", "default", "sleep";
+ pinctrl-0 = <_gpio>;
+ pinctrl-1 = <_out>;
+ pinctrl-2 = <_gpio>;
#thermal-sensor-cells = <1>;
rockchip,hw-tshut-temp = <95000>;
rockchip,hw-tshut-mode = <0>;
--
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 v3 2/3] thermal: rockchip: ensure the otp states before resetting the controller
We need the OTP pin is gpio state before resetting the TSADC controller, since the tshut polarity will generate a high signal. Says: The TSHUT temperature is setting more than 80 degree, the default tshut polarity is high. If T > 80C, the OTP output the high signal. If T < 80C, the OTP output the low signal. On the moment, the tshut polarity will be low in a short period of time if the TSADC controller is reset. So: If T < 80C, the OTP output the High Signal. If T > 80C, the OTP output the Low Signal. In some cases, the OTP pin is connected to the PMIC, maybe the PMIC can accept the reset response time to avoid this issue. In other words, the system will be always reboot if we make the OTP pin is connected the others IC to control the power. Signed-off-by: Caesar Wang --- Changes in v3: - Add the pinctrl state for in the suspend/resume. Changes in v2: None Changes in v1: None drivers/thermal/rockchip_thermal.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/thermal/rockchip_thermal.c b/drivers/thermal/rockchip_thermal.c index c89ffb2..3b8fbda 100644 --- a/drivers/thermal/rockchip_thermal.c +++ b/drivers/thermal/rockchip_thermal.c @@ -642,6 +642,8 @@ static int __maybe_unused rockchip_thermal_suspend(struct device *dev) clk_disable(thermal->pclk); clk_disable(thermal->clk); + pinctrl_pm_select_sleep_state(dev); + return 0; } @@ -678,6 +680,8 @@ static int __maybe_unused rockchip_thermal_resume(struct device *dev) for (i = 0; i < ARRAY_SIZE(thermal->sensors); i++) rockchip_thermal_toggle_sensor(>sensors[i], true); + pinctrl_pm_select_default_state(dev); + return 0; } -- 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 v3 3/3] ARM: dts: rockchip: Add the OTP gpio pinctrl
Add the "init" anf "sleep" pinctrl as the OTP gpio state.
We need the OTP pin is gpio state before resetting the TSADC controller,
since the tshut polarity will generate a high signal.
"init" pinctrl property is defined by Doug's Patch[0].
Patch[0]:
https://patchwork.kernel.org/patch/7454311/
Signed-off-by: Caesar Wang
Reviewed-by: Douglas Anderson
---
Changes in v3:
- Add the "sleep" pinctrl as the gpio state in PATCH[3/3]
Changes in v2:
- Add some commits for more obvious in PATCH[2/2]
Changes in v1:
- As the Doug comments, drop the thermal driver patchs since
we can with pinctrl changing to work.
- As the Doug's patch to add the 'init' property.
arch/arm/boot/dts/rk3288.dtsi | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index 906e938..13ff09a 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -447,8 +447,10 @@
clock-names = "tsadc", "apb_pclk";
resets = < SRST_TSADC>;
reset-names = "tsadc-apb";
- pinctrl-names = "default";
- pinctrl-0 = <_out>;
+ pinctrl-names = "init", "default", "sleep";
+ pinctrl-0 = <_gpio>;
+ pinctrl-1 = <_out>;
+ pinctrl-2 = <_gpio>;
#thermal-sensor-cells = <1>;
rockchip,hw-tshut-temp = <95000>;
status = "disabled";
@@ -1273,6 +1275,10 @@
};
tsadc {
+ otp_gpio: otp-gpio {
+ rockchip,pins = <0 10 RK_FUNC_GPIO
_pull_none>;
+ };
+
otp_out: otp-out {
rockchip,pins = <0 10 RK_FUNC_1
_pull_none>;
};
--
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 v11 2/6] pci: add Altera PCI vendor ID
On Fri, Oct 23, 2015 at 6:13 AM, Bjorn Helgaas wrote: > On Thu, Oct 22, 2015 at 05:27:27PM +0800, Ley Foon Tan wrote: >> Signed-off-by: Ley Foon Tan >> --- >> include/linux/pci_ids.h | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h >> index d9ba49c..08e4462 100644 >> --- a/include/linux/pci_ids.h >> +++ b/include/linux/pci_ids.h >> @@ -1550,6 +1550,8 @@ >> #define PCI_DEVICE_ID_SERVERWORKS_CSB6LPC 0x0227 >> #define PCI_DEVICE_ID_SERVERWORKS_HT1100LD 0x0408 >> >> +#define PCI_VENDOR_ID_ALTERA 0x1172 >> + > > This doesn't seem to be used anywhere, so I'll drop this patch. Okay. Thanks. Regards Ley Foon -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] A couple of questions about the paged I/O sub system
On Thu, 22 Oct 2015, Ian Kent wrote: > On Wed, 2015-10-21 at 12:56 -0700, Hugh Dickins wrote: > > On Wed, 21 Oct 2015, Ian Kent wrote: > > Thanks for taking the time to reply Hugh. > > > > > > Hi all, > > > > > > I've been looking through some of the page reclaim code and at > > > truncate_inode_pages(). > > > > > > I'm not familiar with the code and I'm struggling to understand it. > > > > > > One thing that is puzzling me right now is, if a file has pages > > that > > > have been modified and are swapped out when > > pagevec_lookup_entries() is > > > called will they be found? > > > > truncate_inode_pages() is a library function which a filesystem calls > > at some stage in its inode truncation processing, to take all the > > incore > > pages out of pagecache (out of its radix_tree), and free them up > > (usually: some might be otherwise pinned in memory at the time). > > > > A filesystem will have other work to do, very particular to that > > filesystem, to free up the actual disk blocks: that's definitely > > not part of truncate_inode_pages()'s job. > > > > It's also called when evicting an inode no longer needed in memory, > > to free the associated pagecache, when not deleting the blocks on > > disk. > > > > I think I don't understand your "swapped out": modifications occur to > > a page while it is in pagecache, and those modifications need to be > > written back to disk before that page can be reclaimed for other use. > > Indeed, now I think about it, "swapped out" is a bad choice of words > when talking about a paged IO system. > > What I'm trying to say is if pages allocated to a mapping are modified, > then under memory pressure, are they ever reclaimed by writing them to > swap storage or are they always reclaimed by writing them back to disk? > > Now I think about what you've said here and looking at the code I > suspect the answer is they are always reclaimed by writing them to > disk. Yes. > > > > > > > > > If not then how does truncate_inode_pages(_range)() handle waiting > > for > > > these pages to be swapped back in to perform the writeback and > > > truncation? > > > > Pages are never "swapped back in to perform the writeback": > > if writeback is needed, it's done before the page can be freed from > > pagecache; and if that data is needed again after the page was freed, > > it's read back in from disk to fresh page. > > That makes sense, using swap would be unnecessary double handling. > > > > > You may be worrying about what happens when a page is modified or > > under writeback when it is truncated: I think that's something each > > filesystem has to be careful of, and may deal with in different ways. > > I'm wondering how a mapping nrpages can be non-zero (read greater than > one) after calling truncate_inode_pages(). > > But I'm looking at a much older kernel so it's quite different to > current upstream and this seemed like a question relevant to both > kernels to get some idea of how page reclaim works. > > I guess what I'm really looking to work out is if it's possible, with > the current upstream kernel, for a mapping to have nrpages greater than > 1 after calling truncate_inode_pages() and hopefully get some > explanation of why if that's not so. I assume you're worrying about a truncate_inode_pages(mapping, 0). If it's truncate_inode_pages(mapping, 1), or lstart anything greater than 0, then it will leave behind the incompletely truncated pages at the start: no mystery in that. > > It's certainly possible with the older kernel I'm looking at but I need > some info. before I consider looking for possible changes to back port. Probably what you're looking for is Jan Kara's v3.0 commit 08142579b6ca "mm: fix assertion mapping->nrpages == 0 in end_writeback()". > > > > > I'm not sure how much to read in to your use of the word "swap". > > It's true that shmem/tmpfs uses swap (of the swapon/swapoff variety) > > as backing for its pages when under pressure (and uses its own > > variant > > shmem_undo_range() to manage that, instead of > > truncate_inode_pages()), > > but most filesystems don't use "swap" at all. > > > > I just noticed your subject "paged I/O sub system": I hope you > > realize > > that mm/page_io.c is solely concerned with swap (of the > > swapon/swapoff > > variety), and has next to nothing to do with filesystems. (Just as, > > conversely, mm/swap.c has next to nothing to do with swap.) > > LOL, right, I'm looking at the page reclaim code which, so far, hasn't > lead me to either of those source files. > > > > > > > > > Anyone, please? > > > > I hope something I've said there has helped, but warn you that > > I'm a terrible person to engage in an extended conversation with! > > Expect long silences, pray for someone else to jump in. > > As well as pointing out that swap storage shouldn't be used in this > case you've reminded me of the difference between swapping and demand > paging, so that's a good start. So long as you
RE: [PATCH 2/2] ARM: at91/pm: add ultra Low-power mode 1(ULP1) support
Hi Alexandre,
Sorry for late answer.
> -Original Message-
> From: Alexandre Belloni [mailto:alexandre.bell...@free-electrons.com]
> Sent: 2015年10月15日 21:22
> To: Yang, Wenyou
> Cc: Ferre, Nicolas; Jean-Christophe Plagniol-Villard; Russell King; Stephen
> Boyd;
> Michael Turquette; linux-arm-ker...@lists.infradead.org; linux-
> ker...@vger.kernel.org; linux-...@vger.kernel.org
> Subject: Re: [PATCH 2/2] ARM: at91/pm: add ultra Low-power mode 1(ULP1)
> support
>
> Hello Wenyou,
>
> On 15/10/2015 at 11:41:07 +0800, Wenyou Yang wrote :
> > +#define ULP0_MODE 0x00
> > +#define ULP1_MODE 0x11
>
> Those are not used.
>
> > +static void at91_config_ulp1_wkup_source(void)
> > +{
> > + if (at91_pmc_read(AT91_PMC_VERSION) >= SAMA5D2_PMC_VERSION)
> {
> > + at91_pmc_write(AT91_PMC_FSMR, AT91_PMC_RTCAL |
> > + AT91_PMC_FSTT9 |
> > + AT91_PMC_FSTT8 |
> > + AT91_PMC_FSTT7 |
> > + AT91_PMC_FSTT6 |
> > + AT91_PMC_FSTT5 |
> > + AT91_PMC_FSTT4 |
> > + AT91_PMC_FSTT3 |
> > + AT91_PMC_FSTT2 |
> > + AT91_PMC_FSTT0);
> > +
> > + at91_pmc_write(AT91_PMC_FSPR, 0);
>
> Shouldn't those be configured from irq_set_wake() in the aic driver instead of
> activating all the wakeup sources?
> I think you need to get the PMC syscon from the aic5 driver and implement a
> new
> irq_set_wake function when you can find the sam5d2 pmc.
I understand these code should not be here, but I don't think those should be
configured from irq_set_wake().
As said in datasheet, those configuration is to trigger a fast restart signal
to the PMC. I think they should not be related to irq.
>
> The PMC syscon is introduced with that series:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-October/376493.html
>
> > @@ -140,6 +165,10 @@ static void at91_pm_suspend(suspend_state_t state)
> > pm_data |= (state == PM_SUSPEND_MEM) ?
> > AT91_PM_MODE(AT91_PM_SLOW_CLOCK) : 0;
> >
> > + pm_data |= ((state == PM_SUSPEND_MEM) &&
> > + (at91_pmc_read(AT91_PMC_VERSION) >=
> SAMA5D2_PMC_VERSION)) ?
> > + AT91_PM_ULP(AT91_PM_ULP1_MODE) : 0;
> > +
>
> I would prefer not relying on the AT91_PMC_VERSION. Also, you probably
> shouldn't read the register each time you go to suspend.
> Finally, this could be better written by testing state only once.
Yes, it is not good.
>
>
> > flush_cache_all();
> > outer_disable();
> >
> > diff --git a/arch/arm/mach-at91/pm.h b/arch/arm/mach-at91/pm.h index
> > 3fcf881..2e76745 100644
> > --- a/arch/arm/mach-at91/pm.h
> > +++ b/arch/arm/mach-at91/pm.h
> > @@ -39,4 +39,11 @@ extern void __iomem *at91_ramc_base[];
> >
> > #defineAT91_PM_SLOW_CLOCK 0x01
> >
> > +#define AT91_PM_ULP_OFFSET 5
> > +#define AT91_PM_ULP_MASK 0x03
> > +#define AT91_PM_ULP(x) (((x) & AT91_PM_ULP_MASK) <<
> AT91_PM_ULP_OFFSET)
> > +
> > +#define AT91_PM_ULP0_MODE 0x00
> > +#define AT91_PM_ULP1_MODE 0x01
> > +
> > #endif
> > diff --git a/arch/arm/mach-at91/pm_suspend.S
> > b/arch/arm/mach-at91/pm_suspend.S index 825347b..543c430 100644
> > --- a/arch/arm/mach-at91/pm_suspend.S
> > +++ b/arch/arm/mach-at91/pm_suspend.S
> > @@ -41,6 +41,15 @@ tmp2 .reqr5
> > .endm
> >
> > /*
> > + * Wait for main oscillator selection is done */
> > + .macro wait_moscsels
> > +1: ldr tmp1, [pmc, #AT91_PMC_SR]
> > + tst tmp1, #AT91_PMC_MOSCSELS
> > + beq 1b
> > + .endm
> > +
> > +/*
> > * Wait until PLLA has locked.
> > */
> > .macro wait_pllalock
> > @@ -99,6 +108,10 @@ ENTRY(at91_pm_suspend_in_sram)
> > and r0, r0, #AT91_PM_MODE_MASK
> > str r0, .pm_mode
> >
> > + lsr r0, r3, #AT91_PM_ULP_OFFSET
> > + and r0, r0, #AT91_PM_ULP_MASK
> > + str r0, .ulp_mode
> > +
> > /* Active the self-refresh mode */
> > mov r0, #SRAMC_SELF_FRESH_ACTIVE
> > bl at91_sramc_self_refresh
> > @@ -107,6 +120,14 @@ ENTRY(at91_pm_suspend_in_sram)
> > tst r0, #AT91_PM_SLOW_CLOCK
> > beq standby_mode
> >
> > + ldr r0, .ulp_mode
> > + tst r0, #AT91_PM_ULP1_MODE
> > + beq ulp0_mode
> > +
> > +ulp1_mode:
> > + bl at91_pm_ulp1_mode
> > + b pm_exit
> > +
> > ulp0_mode:
> > bl at91_pm_ulp0_mode
> > b pm_exit
> > @@ -313,6 +334,94 @@ ENTRY(at91_pm_ulp0_mode)
> > mov pc, lr
> > ENDPROC(at91_pm_ulp0_mode)
> >
> > +/*
> > + * void at91_pm_ulp1_mode(void)
> > + *
> > + */
> > +ENTRY(at91_pm_ulp1_mode)
> > + ldr pmc, .pmc_base
> > +
> > + /* Save PMC_MCKR config */
> > + ldr tmp1, [pmc, #AT91_PMC_MCKR]
> > + str tmp1,
Re: [PATCH v2] EDAC: Add ARM64 EDAC
>>> +++ b/drivers/edac/cortex_arm64_edac.c >>> @@ -0,0 +1,457 @@ >>> +/* >>> + * Cortex ARM64 EDAC >>> + * >>> + * Copyright (c) 2015, Advanced Micro Devices >>> + * Author: Brijesh Singh >>> + * Hi Brijesh, Your ARM64 EDAC driver seems rather similar to the existing driver that is linked below. If you have indeed based your driver on this one, can you please provide the appropriate attribution? https://www.codeaurora.org/cgit/quic/la/kernel/msm-3.14/tree/drivers/edac/cortex_arm64_edac.c?h=LA.HB.1.1.1_rb1.10 Thank you Steve -- The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] mm: Introduce kernelcore=reliable option
First part of each memory controller. I have two memory controllers on each node Sent from my iPhone > On Oct 22, 2015, at 18:01, Izumi, Taku wrote: > > Dear Tony, > >> -Original Message- >> From: Luck, Tony [mailto:tony.l...@intel.com] >> Sent: Friday, October 23, 2015 8:27 AM >> To: Kamezawa, Hiroyuki/亀澤 寛之; Izumi, Taku/泉 拓; linux-kernel@vger.kernel.org; >> linux...@kvack.org >> Cc: qiuxi...@huawei.com; m...@csn.ul.ie; a...@linux-foundation.org; Hansen, >> Dave; m...@codeblueprint.co.uk >> Subject: RE: [PATCH] mm: Introduce kernelcore=reliable option >> >>> I think /proc/zoneinfo can show detailed numbers per zone. Do we need some >>> for meminfo ? >> >> I wrote a little script (attached) to summarize /proc/zoneinfo ... on my >> system it says >> >> $ zoneinfo >> Node Normal Movable DMA DMA32 >> 00.00 103020.078.94 1554.46 >> 1 9284.5489870.43 >> 2 9626.3394050.09 >> 3 9602.8293650.04 >> >> Not sure why I have zero Normal memory free on node0. The sum of all those >> free counts is 410667.72 MB ... which is close enough to the boot time >> message >> showing the amount of mirror/total memory: >> >> [0.00] efi: Memory: 80979/420096M mirrored memory >> >> but a fair amount of the 80G of mirrored memory seems to have been miscounted >> as Movable instead of Normal. Perhaps this is because I have two blocks of >> mirrored >> memory on each node and the movable zone code doesn't expect that? > > You were saying that OS view of memory of node is something like the > following ? > >Node X: |MM--MM| > (legend) M: mirrored -: not mirrrored > > If so, is this a real Box's configuration? > Sorry, I haven't got a real Address Range Mirror capable boxes yet ... > I thought mirroring range is concatenated at the first part of each node. > > Sincerely, > Taku Izumi > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] EDAC: Add ARM64 EDAC
Hi Brijesh,
On 2015/10/22 22:46, Brijesh Singh wrote:
> Hi Andre,
>
> On 10/21/2015 06:52 PM, Andre Przywara wrote:
>> On 21/10/15 21:41, Brijesh Singh wrote:
>>> Add support for Cortex A57 and A53 EDAC driver.
>> Hi Brijesh,
>>
>> thanks for the quick update! Some comments below.
>>
>>> Signed-off-by: Brijesh Singh
>>> CC: robh...@kernel.org
>>> CC: pawel.m...@arm.com
>>> CC: mark.rutl...@arm.com
>>> CC: ijc+devicet...@hellion.org.uk
>>> CC: ga...@codeaurora.org
>>> CC: dougthomp...@xmission.com
>>> CC: b...@alien8.de
>>> CC: mche...@osg.samsung.com
>>> CC: devicet...@vger.kernel.org
>>> CC: guohan...@huawei.com
>>> CC: andre.przyw...@arm.com
>>> CC: a...@arndb.de
>>> CC: linux-kernel@vger.kernel.org
>>> CC: linux-e...@vger.kernel.org
>>> ---
>>>
>>> v2:
>>> * convert into generic arm64 edac driver
>>> * remove AMD specific references from dt binding
>>> * remove poll_msec property from dt binding
>>> * add poll_msec as a module param, default is 100ms
>>> * update copyright text
>>> * define macro mnemonics for L1 and L2 RAMID
>>> * check L2 error per-cluster instead of per core
>>> * update function names
>>> * use get_online_cpus() and put_online_cpus() to make L1 and L2 register
>>> read hotplug-safe
>>> * add error check in probe routine
>>>
>>> .../devicetree/bindings/edac/armv8-edac.txt| 15 +
>>> drivers/edac/Kconfig | 6 +
>>> drivers/edac/Makefile | 1 +
>>> drivers/edac/cortex_arm64_edac.c | 457
>>> +
>>> 4 files changed, 479 insertions(+)
>>> create mode 100644 Documentation/devicetree/bindings/edac/armv8-edac.txt
>>> create mode 100644 drivers/edac/cortex_arm64_edac.c
>>>
>>> diff --git a/Documentation/devicetree/bindings/edac/armv8-edac.txt
>>> b/Documentation/devicetree/bindings/edac/armv8-edac.txt
>>> new file mode 100644
>>> index 000..dfd128f
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/edac/armv8-edac.txt
>>> @@ -0,0 +1,15 @@
>>> +* ARMv8 L1/L2 cache error reporting
>>> +
>>> +On ARMv8, CPU Memory Error Syndrome Register and L2 Memory Error Syndrome
>>> +Register can be used for checking L1 and L2 memory errors.
>>> +
>>> +The following section describes the ARMv8 EDAC DT node binding.
>>> +
>>> +Required properties:
>>> +- compatible: Should be "arm,armv8-edac"
>>> +
>>> +Example:
>>> + edac {
>>> + compatible = "arm,armv8-edac";
>>> + };
>>> +
>> So if there is nothing in here, why do we need the DT binding at all (I
>> think Mark hinted at that already)?
>> Can't we just use the MIDR as already suggested by others?
>> Secondly, armv8-edac is wrong here, as this feature is ARM-Cortex
>> specific and not architectural.
>>
> Yes, I was going with Mark suggestion to remove DT binding but then came
> across these cases which kind of hinted to keep DT binding:
>
> * Without DT binding, the driver will always be loaded on arm64 unless its
> blacklisted.
> * Its possible that other SoC's might handle single-bit and double-bit errors
> differently compare to
> Seattle platform. In Seattle platform both errors are handled by firmware
> but if other SoC
> wants OS to handle these errors then they might need DT binding to provide
> the irq numbers etc.
I totally agree with you here, thanks for putting them together.
Different SoCs may handle the error in different ways, we need
bindings to specialize them, irq number is a good example :)
Thanks
Hanjun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [v3, 3/3] MIPS: VDSO: Add implementations of gettimeofday() and clock_gettime()
You can not use R4K CP0_count in SMP (multicore) without core-specific adjustment. After first power-saving with core clock off or core down the values in CP0_count in different cores are absolutely different. Until you include in system a patch like http://patchwork.linux-mips.org/patch/10871/ "MIPS: Setup an instruction emulation in VDSO protected page instead of user stack" which creates a per-thread memory and put into that memory an adjustment value (which can be changed during re-schedule to another core), the use of R4K counter is incorrect in SMP environment. Note: It is also possible to setup and maintain a per-core page with that value too as an alternative variant for adjustment. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] EDAC: Add AMD Seattle SoC EDAC
On 2015/10/21 17:35, Borislav Petkov wrote: > On Wed, Oct 21, 2015 at 09:55:43AM +0800, Hanjun Guo wrote: >> So I think the meaning of those error register is the same, but the way >> of handle it may different from SoCs, for single bit error: >> >> - SoC may trigger a interrupt; >> - SoC may just keep silent so we need to scan the registers using poll >>mechanism. >> >> For Double bit error: >> - SoC may also keep silent >> - Trigger a interrupt >> - Trigger a SEI (system error) >> >> Any suggestion to cover those cases? > Well, I guess we can implement all those and have them configurable > in the sense that a single driver loads, it has all functionality and > dependent on the vendor detection, it does only what the vendor wants > like trigger an interrupt or remain silent or ... Hmm, so we need to keep the DT bindings for different SoCs which have different ways of handling the errors. Thanks Hanjun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] dt-bindings: Consolidate Exynos SoC bindings
Exynos SoC Device Tree bindings are spread over arm/exynos/ and
arm/samsung/ directories. There is no need for that separation and it
actually confuses. Put power domain bindings under power/ and
remaining samsung-boards.txt under arm/samsung/.
Signed-off-by: Krzysztof Kozlowski
Cc: Kukjin Kim
Reviewed-by: Javier Martinez Canillas
---
Changes since v2:
1. Update path pointing to pd-samsung.txt in samsung,sysmmu.txt.
Changes since v1:
1. Move power_domain.txt to power/pd-samsung.txt.
2. The smp-sysram.txt is moved in previous patch to sram/ directory
(Suggested by Rob Herring).
3. Added Javier's reviewed-by. Although there are some differences since
v1 but this is merely re-organization. Please let me know if the
review tag is no longer valid.
---
Documentation/devicetree/bindings/arm/{ => samsung}/samsung-boards.txt | 0
Documentation/devicetree/bindings/iommu/samsung,sysmmu.txt | 2 +-
.../bindings/{arm/exynos/power_domain.txt => power/pd-samsung.txt} | 0
3 files changed, 1 insertion(+), 1 deletion(-)
rename Documentation/devicetree/bindings/arm/{ => samsung}/samsung-boards.txt
(100%)
rename Documentation/devicetree/bindings/{arm/exynos/power_domain.txt =>
power/pd-samsung.txt} (100%)
diff --git a/Documentation/devicetree/bindings/arm/samsung-boards.txt
b/Documentation/devicetree/bindings/arm/samsung/samsung-boards.txt
similarity index 100%
rename from Documentation/devicetree/bindings/arm/samsung-boards.txt
rename to Documentation/devicetree/bindings/arm/samsung/samsung-boards.txt
diff --git a/Documentation/devicetree/bindings/iommu/samsung,sysmmu.txt
b/Documentation/devicetree/bindings/iommu/samsung,sysmmu.txt
index 729543c47046..bc620fe32a70 100644
--- a/Documentation/devicetree/bindings/iommu/samsung,sysmmu.txt
+++ b/Documentation/devicetree/bindings/iommu/samsung,sysmmu.txt
@@ -47,7 +47,7 @@ Required properties:
- clocks: Required if the System MMU is needed to gate its clock.
- power-domains: Required if the System MMU is needed to gate its power.
Please refer to the following document:
- Documentation/devicetree/bindings/arm/exynos/power_domain.txt
+ Documentation/devicetree/bindings/power/pd-samsung.txt
Examples:
gsc_0: gsc@13e0 {
diff --git a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
b/Documentation/devicetree/bindings/power/pd-samsung.txt
similarity index 100%
rename from Documentation/devicetree/bindings/arm/exynos/power_domain.txt
rename to Documentation/devicetree/bindings/power/pd-samsung.txt
--
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 v3 3/3] dt-bindings: EXYNOS: Document compatibles from other vendors
Document compatibles used on other Exynos-based boards (non-Samsung): FriendlyARM, Google, Hardkernel and Insignal. Signed-off-by: Krzysztof Kozlowski Cc: Kukjin Kim Cc: Javier Martinez Canillas Cc: Hakjoo Kim Reviewed-by: Javier Martinez Canillas --- Changes since v2: 1. None Changes since v1: 1. Added Javier's reviewed-by --- .../bindings/arm/samsung/samsung-boards.txt| 44 +- 1 file changed, 43 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/arm/samsung/samsung-boards.txt b/Documentation/devicetree/bindings/arm/samsung/samsung-boards.txt index 43589d2466a7..da078702ae73 100644 --- a/Documentation/devicetree/bindings/arm/samsung/samsung-boards.txt +++ b/Documentation/devicetree/bindings/arm/samsung/samsung-boards.txt @@ -16,7 +16,49 @@ Required root node properties: - "samsung,sd5v1" - for Exynos5440-based Samsung board. - "samsung,ssdk5440"- for Exynos5440-based Samsung board. -Optional: +* Other companies Exynos SoC based + * FriendlyARM +- "friendlyarm,tiny4412" - for Exynos4412-based FriendlyARM +TINY4412 board. + + * Google +- "google,pi" - for Exynos5800-based Google Peach Pi +Rev 10+ board, + also: "google,pi-rev16", "google,pi-rev15", "google,pi-rev14", + "google,pi-rev13", "google,pi-rev12", "google,pi-rev11", +"google,pi-rev10", "google,peach". + +- "google,pit"- for Exynos5420-based Google Peach Pit +Rev 6+ (Exynos5420), + also: "google,pit-rev16", "google,pit-rev15", "google,pit-rev14", +"google,pit-rev13", "google,pit-rev12", "google,pit-rev11", +"google,pit-rev10", "google,pit-rev9", "google,pit-rev8", +"google,pit-rev7", "google,pit-rev6", "google,peach". + +- "google,snow-rev4" - for Exynos5250-based Google Snow board, + also: "google,snow" +- "google,snow-rev5" - for Exynos5250-based Google Snow +Rev 5+ board. +- "google,spring" - for Exynos5250-based Google Spring board. + + * Hardkernel +- "hardkernel,odroid-u3" - for Exynos4412-based Hardkernel Odroid U3. +- "hardkernel,odroid-x" - for Exynos4412-based Hardkernel Odroid X. +- "hardkernel,odroid-x2" - for Exynos4412-based Hardkernel Odroid X2. +- "hardkernel,odroid-xu3" - for Exynos5422-based Hardkernel Odroid XU3. +- "hardkernel,odroid-xu3-lite" - for Exynos5422-based Hardkernel + Odroid XU3 Lite board. +- "hardkernel,odroid-xu4" - for Exynos5422-based Hardkernel Odroid XU4. + + * Insignal +- "insignal,arndale" - for Exynos5250-based Insignal Arndale board. +- "insignal,arndale-octa" - for Exynos5420-based Insignal Arndale +Octa board. +- "insignal,origen" - for Exynos4210-based Insignal Origen board. +- "insignal,origen4412- for Exynos4412-based Insignal Origen board. + + +Optional nodes: - firmware node, specifying presence and type of secure firmware: - compatible: only "samsung,secure-firmware" is currently supported - reg: address of non-secure SYSRAM used for communication with firmware -- 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 v3 1/3] dt-bindings: Consolidate SRAM bindings from all vendors
SRAM bindings for various SoCs, using the mmio-sram genalloc
API, are spread over different places - per SoC vendor. Since all of
these are quite similar (they depend on mmio-sram) move them to a common
place.
Signed-off-by: Krzysztof Kozlowski
Cc: Heiko Stuebner
Cc: Maxime Ripard
Cc: Chen-Yu Tsai
Cc: Kukjin Kim
Suggested-by: Rob Herring
---
Changes since v2:
1. Update paths to sram.txt.
Changes since v1:
1. New patch. Extended suggestion from Rob.
---
Documentation/devicetree/bindings/arm/arm,scpi.txt | 2 +-
.../bindings/{arm/rockchip/pmu-sram.txt => sram/rockchip-pmu-sram.txt} | 0
.../bindings/{arm/rockchip/smp-sram.txt => sram/rockchip-smp-sram.txt} | 2 +-
.../bindings/{arm/exynos/smp-sysram.txt => sram/samsung-sram.txt} | 2 +-
Documentation/devicetree/bindings/{misc => sram}/sram.txt | 0
.../devicetree/bindings/{soc/sunxi/sram.txt => sram/sunxi-sram.txt} | 2 +-
6 files changed, 4 insertions(+), 4 deletions(-)
rename Documentation/devicetree/bindings/{arm/rockchip/pmu-sram.txt =>
sram/rockchip-pmu-sram.txt} (100%)
rename Documentation/devicetree/bindings/{arm/rockchip/smp-sram.txt =>
sram/rockchip-smp-sram.txt} (92%)
rename Documentation/devicetree/bindings/{arm/exynos/smp-sysram.txt =>
sram/samsung-sram.txt} (95%)
rename Documentation/devicetree/bindings/{misc => sram}/sram.txt (100%)
rename Documentation/devicetree/bindings/{soc/sunxi/sram.txt =>
sram/sunxi-sram.txt} (97%)
diff --git a/Documentation/devicetree/bindings/arm/arm,scpi.txt
b/Documentation/devicetree/bindings/arm/arm,scpi.txt
index 86302de67c2c..313dabdc14f9 100644
--- a/Documentation/devicetree/bindings/arm/arm,scpi.txt
+++ b/Documentation/devicetree/bindings/arm/arm,scpi.txt
@@ -63,7 +63,7 @@ Required properties:
- compatible : should be "arm,juno-sram-ns" for Non-secure SRAM on Juno
The rest of the properties should follow the generic mmio-sram description
-found in ../../misc/sysram.txt
+found in ../../sram/sram.txt
Each sub-node represents the reserved area for SCPI.
diff --git a/Documentation/devicetree/bindings/arm/rockchip/pmu-sram.txt
b/Documentation/devicetree/bindings/sram/rockchip-pmu-sram.txt
similarity index 100%
rename from Documentation/devicetree/bindings/arm/rockchip/pmu-sram.txt
rename to Documentation/devicetree/bindings/sram/rockchip-pmu-sram.txt
diff --git a/Documentation/devicetree/bindings/arm/rockchip/smp-sram.txt
b/Documentation/devicetree/bindings/sram/rockchip-smp-sram.txt
similarity index 92%
rename from Documentation/devicetree/bindings/arm/rockchip/smp-sram.txt
rename to Documentation/devicetree/bindings/sram/rockchip-smp-sram.txt
index d9416fb8db6f..800701ecffca 100644
--- a/Documentation/devicetree/bindings/arm/rockchip/smp-sram.txt
+++ b/Documentation/devicetree/bindings/sram/rockchip-smp-sram.txt
@@ -12,7 +12,7 @@ Required sub-node properties:
- compatible : should be "rockchip,rk3066-smp-sram"
The rest of the properties should follow the generic mmio-sram discription
-found in ../../misc/sram.txt
+found in Documentation/devicetree/bindings/sram/sram.txt
Example:
diff --git a/Documentation/devicetree/bindings/arm/exynos/smp-sysram.txt
b/Documentation/devicetree/bindings/sram/samsung-sram.txt
similarity index 95%
rename from Documentation/devicetree/bindings/arm/exynos/smp-sysram.txt
rename to Documentation/devicetree/bindings/sram/samsung-sram.txt
index 4a0a4f70a0ce..6bc474b2b885 100644
--- a/Documentation/devicetree/bindings/arm/exynos/smp-sysram.txt
+++ b/Documentation/devicetree/bindings/sram/samsung-sram.txt
@@ -15,7 +15,7 @@ Required sub-node properties:
"samsung,exynos4210-sysram-ns" : for Non-secure SYSRAM
The rest of the properties should follow the generic mmio-sram discription
-found in ../../misc/sysram.txt
+found in Documentation/devicetree/bindings/sram/sram.txt
Example:
diff --git a/Documentation/devicetree/bindings/misc/sram.txt
b/Documentation/devicetree/bindings/sram/sram.txt
similarity index 100%
rename from Documentation/devicetree/bindings/misc/sram.txt
rename to Documentation/devicetree/bindings/sram/sram.txt
diff --git a/Documentation/devicetree/bindings/soc/sunxi/sram.txt
b/Documentation/devicetree/bindings/sram/sunxi-sram.txt
similarity index 97%
rename from Documentation/devicetree/bindings/soc/sunxi/sram.txt
rename to Documentation/devicetree/bindings/sram/sunxi-sram.txt
index 067698112f5f..8d5665468fe7 100644
--- a/Documentation/devicetree/bindings/soc/sunxi/sram.txt
+++ b/Documentation/devicetree/bindings/sram/sunxi-sram.txt
@@ -16,7 +16,7 @@ SRAM nodes
--
Each SRAM is described using the mmio-sram bindings documented in
-Documentation/devicetree/bindings/misc/sram.txt
+Documentation/devicetree/bindings/sram/sram.txt
Each SRAM will have SRAM sections that are going to be handled by the
SRAM controller as subnodes. These sections are represented following
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Re: [PATCH v2 1/3] ARM: sunxi: Introduce Allwinner for A83T support
On Fri, Oct 23, 2015 at 7:46 AM, Vishnu Patekar wrote: > Allwinner A83T is octa-core cortex-a7 based SoC. > It's clock control unit and prcm, pinmux are different from previous sun8i > series. > Its processor cores are arragned in two clusters 4 cores each, > similar to A80. > > Signed-off-by: Vishnu Patekar Could you also update Documentation/arm/sunxi/README, so it says A83T is supported? Otherwise, Acked-by: Chen-Yu Tsai -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/19] staging/wilc1000 cleanups
On 2015년 10월 22일 21:23, Arnd Bergmann wrote: On Wednesday 21 October 2015 19:06:52 glen lee wrote: Hi arnd, Thanks for the all the patches. About the patch ( use proper naming for global symbols ), We are planning to use this driver not only for wilc1000 but also for other atmel wireless driver. I'd appreciate if you could use wl instead of wilc1000. And the global variable g_linux_wlan will be placed in netdevice private data and finally it will be removed. I already posted some of those patches. I couldn't find the patches anywhere, but I've updated my series now to rename the symbols to wilc_* and to remove most but not all references to g_linux_wlan (or wilc_dev after my rename). Do you want me to post those so you can integrate them, or should I have a look at what you sent first (please send me a copy then). Hi arnd, I have tested with all the patches you have posted but it does not works. firmware start timed out in the function wilc1000_start_firmware. I also have tested with all the patched without last one, [RFC] one, but it shows Segmentation fault when insmod driver. For now, I can't rebase the patches. I'd appreciate if you could help us. The title of my first patch is, [PATCH 01/13] staging: wilc1000: add wilc to netdev private data structure and also refer to [PATCH 00/12] WILC1000 V2 for the g_linux_wlan ( The patches posted by tony@atmel.com ) By the way, deleting feature COMPLEMENT_BOOT patch already posted but not yet accepted. Thank you. Glen. 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/
[PATCH v3 0/2] simplefb: Add regulator handling support
Hi everyone, This is v3 of the simplefb regulator support series. This series adds regulator claiming and enabling support for simplefb. Changes since v3: - Dropped extra "if" which is always true, leftover from v1. - Updated commit message of patch 1 Sometimes the simplefb display output path consits of external conversion chips and/or LCD drivers and backlights. These devices normally have GPIOs to turn them on and/or bring them out of reset, and regulators supplying power to them. While the kernel does not touch unclaimed GPIOs, the regulator core happily disables unused regulators. Thus we need simplefb to claim and enable the regulators used throughout the display pipeline. The binding supports any named regulator supplies under its device node. The driver will look through its properties, and claim any regulators by matching "*-supply", as Mark suggested. I've not done a generic helper in the regulator core yet, instead doing the regulator property handling in the simplefb code for now. Patch 1 adds the regulator properties to the DT binding. Patch 2 adds code to the simplefb driver to claim and enable regulators. Regards ChenYu Chen-Yu Tsai (2): dt-bindings: simplefb: Support regulator supply properties simplefb: Claim and enable regulators .../bindings/video/simple-framebuffer.txt | 13 ++- drivers/video/fbdev/simplefb.c | 120 - 2 files changed, 128 insertions(+), 5 deletions(-) -- 2.6.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 v3 1/2] dt-bindings: simplefb: Support regulator supply properties
The physical display tied to the framebuffer may have regulators
providing power to it, such as power for LCDs or interface conversion
chips.
The number of regulators in use may vary, but the regulator supply
binding can not be a list. Instead just support any named regulator
supply properties under the device node. These should be properly
named to match the device schematics / design. The driver should
take care to go through them all.
Signed-off-by: Chen-Yu Tsai
Reviewed-by: Hans de Goede
Acked-by: Mark Brown
---
.../devicetree/bindings/video/simple-framebuffer.txt| 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/video/simple-framebuffer.txt
b/Documentation/devicetree/bindings/video/simple-framebuffer.txt
index 4474ef6e0b95..8c9e9f515c87 100644
--- a/Documentation/devicetree/bindings/video/simple-framebuffer.txt
+++ b/Documentation/devicetree/bindings/video/simple-framebuffer.txt
@@ -47,10 +47,14 @@ Required properties:
- a8b8g8r8 (32-bit pixels, d[31:24]=a, d[23:16]=b, d[15:8]=g, d[7:0]=r).
Optional properties:
-- clocks : List of clocks used by the framebuffer. Clocks listed here
- are expected to already be configured correctly. The OS must
- ensure these clocks are not modified or disabled while the
- simple framebuffer remains active.
+- clocks : List of clocks used by the framebuffer.
+- *-supply : Any number of regulators used by the framebuffer. These should
+be named according to the names in the device's design.
+
+ The above resources are expected to already be configured correctly.
+ The OS must ensure they are not modified or disabled while the simple
+ framebuffer remains active.
+
- display : phandle pointing to the primary display hardware node
Example:
@@ -68,6 +72,7 @@ chosen {
stride = <(1600 * 2)>;
format = "r5g6b5";
clocks = <_gates 36>, <_gates 43>, <_gates 44>;
+ lcd-supply = <_dc1sw>;
display = <>;
};
stdout-path = "display0";
--
2.6.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 v3 2/2] simplefb: Claim and enable regulators
This claims and enables regulators listed in the simple framebuffer dt
node. This is needed so that regulators powering the display pipeline
and external hardware, described in the device node and known by the
kernel code, will remain properly enabled.
Signed-off-by: Chen-Yu Tsai
Reviewed-by: Hans de Goede
Acked-by: Mark Brown
---
drivers/video/fbdev/simplefb.c | 120 -
1 file changed, 119 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/simplefb.c b/drivers/video/fbdev/simplefb.c
index 52c5c7e63b52..9de34ee15ac0 100644
--- a/drivers/video/fbdev/simplefb.c
+++ b/drivers/video/fbdev/simplefb.c
@@ -28,7 +28,10 @@
#include
#include
#include
+#include
#include
+#include
+#include
static struct fb_fix_screeninfo simplefb_fix = {
.id = "simple",
@@ -174,6 +177,10 @@ struct simplefb_par {
int clk_count;
struct clk **clks;
#endif
+#if defined CONFIG_OF && defined CONFIG_REGULATOR
+ u32 regulator_count;
+ struct regulator **regulators;
+#endif
};
#if defined CONFIG_OF && defined CONFIG_COMMON_CLK
@@ -269,6 +276,110 @@ static int simplefb_clocks_init(struct simplefb_par *par,
static void simplefb_clocks_destroy(struct simplefb_par *par) { }
#endif
+#if defined CONFIG_OF && defined CONFIG_REGULATOR
+
+#define SUPPLY_SUFFIX "-supply"
+
+/*
+ * Regulator handling code.
+ *
+ * Here we handle the num-supplies and vin*-supply properties of our
+ * "simple-framebuffer" dt node. This is necessary so that we can make sure
+ * that any regulators needed by the display hardware that the bootloader
+ * set up for us (and for which it provided a simplefb dt node), stay up,
+ * for the life of the simplefb driver.
+ *
+ * When the driver unloads, we cleanly disable, and then release the
+ * regulators.
+ *
+ * We only complain about errors here, no action is taken as the most likely
+ * error can only happen due to a mismatch between the bootloader which set
+ * up simplefb, and the regulator definitions in the device tree. Chances are
+ * that there are no adverse effects, and if there are, a clean teardown of
+ * the fb probe will not help us much either. So just complain and carry on,
+ * and hope that the user actually gets a working fb at the end of things.
+ */
+static int simplefb_regulators_init(struct simplefb_par *par,
+ struct platform_device *pdev)
+{
+ struct device_node *np = pdev->dev.of_node;
+ struct property *prop;
+ struct regulator *regulator;
+ const char *p;
+ int count = 0, i = 0, ret;
+
+ if (dev_get_platdata(>dev) || !np)
+ return 0;
+
+ /* Count the number of regulator supplies */
+ for_each_property_of_node(np, prop) {
+ p = strstr(prop->name, SUPPLY_SUFFIX);
+ if (p && p != prop->name)
+ count++;
+ }
+
+ if (!count)
+ return 0;
+
+ par->regulators = devm_kcalloc(>dev, count,
+ sizeof(struct regulator *), GFP_KERNEL);
+ if (!par->regulators)
+ return -ENOMEM;
+
+ /* Get all the regulators */
+ for_each_property_of_node(np, prop) {
+ char name[32]; /* 32 is max size of property name */
+
+ p = strstr(prop->name, SUPPLY_SUFFIX);
+ if (p && p != prop->name)
+ continue;
+
+ strlcpy(name, prop->name,
+ strlen(prop->name) - sizeof(SUPPLY_SUFFIX) + 1);
+ regulator = devm_regulator_get_optional(>dev, name);
+ if (IS_ERR(regulator)) {
+ if (PTR_ERR(regulator) == -EPROBE_DEFER)
+ return -EPROBE_DEFER;
+ dev_err(>dev, "regulator %s not found: %ld\n",
+ name, PTR_ERR(regulator));
+ continue;
+ }
+ par->regulators[i++] = regulator;
+ }
+ par->regulator_count = i;
+
+ /* Enable all the regulators */
+ for (i = 0; i < par->regulator_count; i++) {
+ ret = regulator_enable(par->regulators[i]);
+ if (ret) {
+ dev_err(>dev,
+ "failed to enable regulator %d: %d\n",
+ i, ret);
+ devm_regulator_put(par->regulators[i]);
+ par->regulators[i] = NULL;
+ }
+ }
+
+ return 0;
+}
+
+static void simplefb_regulators_destroy(struct simplefb_par *par)
+{
+ int i;
+
+ if (!par->regulators)
+ return;
+
+ for (i = 0; i < par->regulator_count; i++)
+ if (par->regulators[i])
+ regulator_disable(par->regulators[i]);
+}
+#else
+static int simplefb_regulators_init(struct simplefb_par *par,
+ struct platform_device *pdev) { return 0; }
+static void
Re: [GIT PULL] USB patches for v4.4 merge window
On Tue, Oct 20, 2015 at 01:44:05PM -0500, Felipe Balbi wrote: > Hi Greg, > > Here's the large gadget pull request for v4.4. All patches have been > in next for a while and should be safe to apply. > > Let me know if you want any changes to this pull request. > > cheers > > The following changes since commit 9ffecb10283508260936b96022d4ee43a7798b4c: > > Linux 4.3-rc3 (2015-09-27 07:50:08 -0400) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git > tags/usb-for-v4.4 Pulled and pushed out, 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/
[PATCH v2 cgroup/for-4.4 3/3] cgroup: replace unified-hierarchy.txt with a proper cgroup v2 documentation
>From 10d158783de74ad28454ff54556abf89bd85c756 Mon Sep 17 00:00:00 2001 From: Tejun Heo Date: Fri, 23 Oct 2015 10:13:35 +0900 Now that cgroup v2 is almost out of the door, replace the development documentation unified-hierarchy.txt with Documentation/cgroup.txt which is a superset of unified-hierarchy.txt and authoritatively describes all userland-visible aspects of cgroup. v2: Updated to include all information from blkio-controller.txt and list filesystems which support cgroup writeback as suggested by Vivek. Signed-off-by: Tejun Heo Cc: Vivek Goyal --- Documentation/cgroup-legacy/blkio-controller.txt | 79 -- Documentation/cgroup-legacy/unified-hierarchy.txt | 645 -- Documentation/cgroup.txt | 1293 + 3 files changed, 1293 insertions(+), 724 deletions(-) delete mode 100644 Documentation/cgroup-legacy/unified-hierarchy.txt create mode 100644 Documentation/cgroup.txt diff --git a/Documentation/cgroup-legacy/blkio-controller.txt b/Documentation/cgroup-legacy/blkio-controller.txt index 12686be..79cc3f4 100644 --- a/Documentation/cgroup-legacy/blkio-controller.txt +++ b/Documentation/cgroup-legacy/blkio-controller.txt @@ -374,82 +374,3 @@ One can experience an overall throughput drop if you have created multiple groups and put applications in that group which are not driving enough IO to keep disk busy. In that case set group_idle=0, and CFQ will not idle on individual groups and throughput should improve. - -Writeback -= - -Page cache is dirtied through buffered writes and shared mmaps and -written asynchronously to the backing filesystem by the writeback -mechanism. Writeback sits between the memory and IO domains and -regulates the proportion of dirty memory by balancing dirtying and -write IOs. - -On traditional cgroup hierarchies, relationships between different -controllers cannot be established making it impossible for writeback -to operate accounting for cgroup resource restrictions and all -writeback IOs are attributed to the root cgroup. - -If both the blkio and memory controllers are used on the v2 hierarchy -and the filesystem supports cgroup writeback, writeback operations -correctly follow the resource restrictions imposed by both memory and -blkio controllers. - -Writeback examines both system-wide and per-cgroup dirty memory status -and enforces the more restrictive of the two. Also, writeback control -parameters which are absolute values - vm.dirty_bytes and -vm.dirty_background_bytes - are distributed across cgroups according -to their current writeback bandwidth. - -There's a peculiarity stemming from the discrepancy in ownership -granularity between memory controller and writeback. While memory -controller tracks ownership per page, writeback operates on inode -basis. cgroup writeback bridges the gap by tracking ownership by -inode but migrating ownership if too many foreign pages, pages which -don't match the current inode ownership, have been encountered while -writing back the inode. - -This is a conscious design choice as writeback operations are -inherently tied to inodes making strictly following page ownership -complicated and inefficient. The only use case which suffers from -this compromise is multiple cgroups concurrently dirtying disjoint -regions of the same inode, which is an unlikely use case and decided -to be unsupported. Note that as memory controller assigns page -ownership on the first use and doesn't update it until the page is -released, even if cgroup writeback strictly follows page ownership, -multiple cgroups dirtying overlapping areas wouldn't work as expected. -In general, write-sharing an inode across multiple cgroups is not well -supported. - -Filesystem support for cgroup writeback - -A filesystem can make writeback IOs cgroup-aware by updating -address_space_operations->writepage[s]() to annotate bio's using the -following two functions. - -* wbc_init_bio(@wbc, @bio) - - Should be called for each bio carrying writeback data and associates - the bio with the inode's owner cgroup. Can be called anytime - between bio allocation and submission. - -* wbc_account_io(@wbc, @page, @bytes) - - Should be called for each data segment being written out. While - this function doesn't care exactly when it's called during the - writeback session, it's the easiest and most natural to call it as - data segments are added to a bio. - -With writeback bio's annotated, cgroup support can be enabled per -super_block by setting MS_CGROUPWB in ->s_flags. This allows for -selective disabling of cgroup writeback support which is helpful when -certain filesystem features, e.g. journaled data mode, are -incompatible. - -wbc_init_bio() binds the specified bio to its cgroup. Depending on -the configuration, the bio may be executed at a lower priority and if -the writeback session is holding shared resources, e.g. a journal -entry, may lead to
Re: [PATCH cgroup/for-4.4 3/3] cgroup: replace unified-hierarchy.txt with a proper cgroup v2 documentation
Hello, On Thu, Oct 22, 2015 at 11:36:05PM +0900, Tejun Heo wrote: > It works with ext2 and 4 and btrfs. Will document it. Thanks. Updated to include all writeback information from blkio-controller.txt. 5-3-2. Writeback Page cache is dirtied through buffered writes and shared mmaps and written asynchronously to the backing filesystem by the writeback mechanism. Writeback sits between the memory and IO domains and regulates the proportion of dirty memory by balancing dirtying and write IOs. The io controller, in conjunction with the memory controller, implements control of page cache writeback IOs. The memory controller defines the memory domain that dirty memory ratio is calculated and maintained for and the io controller defines the io domain which writes out dirty pages for the memory domain. Both system-wide and per-cgroup dirty memory states are examined and the more restrictive of the two is enforced. cgroup writeback requires explicit support from the underlying filesystem. Currently, cgroup writeback is implemented on ext2, ext4 and btrfs. On other filesystems, all writeback IOs are attributed to the root cgroup. There are inherent differences in memory and writeback management which affects how cgroup ownership is tracked. Memory is tracked per page while writeback per inode. For the purpose of writeback, an inode is assigned to a cgroup and all IO requests to write dirty pages from the inode are attributed to that cgroup. As cgroup ownership for memory is tracked per page, there can be pages which are associated with different cgroups than the one the inode is associated with. These are called foreign pages. The writeback constantly keeps track of foreign pages and, if a particular foreign cgroup becomes the majority over a certain period of time, switches the ownership of the inode to that cgroup. While this model is enough for most use cases where a given inode is mostly dirtied by a single cgroup even when the main writing cgroup changes over time, use cases where multiple cgroups write to a single inode simultaneously are not supported well. In such circumstances, a significant portion of IOs are likely to be attributed incorrectly. As memory controller assigns page ownership on the first use and doesn't update it until the page is released, even if writeback strictly follows page ownership, multiple cgroups dirtying overlapping areas wouldn't work as expected. It's recommended to avoid such usage patterns. The sysctl knobs which affect writeback behavior are applied to cgroup writeback as follows. vm.dirty_background_ratio vm.dirty_ratio These ratios apply the same to cgroup writeback with the amount of available memory capped by limits imposed by the memory controller and system-wide clean memory. vm.dirty_background_bytes vm.dirty_bytes For cgroup writeback, this is calculated into ratio against total available memory and applied the same way as vm.dirty[_background]_ratio. P. Information on Kernel Programming This section contains kernel programming information in the areas where interacting with cgroup is necessary. cgroup core and controllers are not covered. P-1. Filesystem Support for Writeback A filesystem can support cgroup writeback by updating address_space_operations->writepage[s]() to annotate bio's using the following two functions. wbc_init_bio(@wbc, @bio) Should be called for each bio carrying writeback data and associates the bio with the inode's owner cgroup. Can be called anytime between bio allocation and submission. wbc_account_io(@wbc, @page, @bytes) Should be called for each data segment being written out. While this function doesn't care exactly when it's called during the writeback session, it's the easiest and most natural to call it as data segments are added to a bio. With writeback bio's annotated, cgroup support can be enabled per super_block by setting SB_I_CGROUPWB in ->s_iflags. This allows for selective disabling of cgroup writeback support which is helpful when certain filesystem features, e.g. journaled data mode, are incompatible. wbc_init_bio() binds the specified bio to its cgroup. Depending on the configuration, the bio may be executed at a lower priority and if the writeback session is holding shared resources, e.g. a journal entry, may lead to priority inversion. There is no one easy solution for the problem. Filesystems can try to work around specific problem cases by skipping wbc_init_bio() or using bio_associate_blkcg() directly. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -next] mtd: fsl-quadspi: Never build on SPARC
On 10/22/2015 06:07 PM, Brian Norris wrote:
+ Han
On Wed, Oct 21, 2015 at 07:31:46AM -0700, Guenter Roeck wrote:
Attempts to build fsl-quadspi on SPARC fail with
drivers/mtd/spi-nor/fsl-quadspi.c: In function 'fsl_qspi_init_lut':
drivers/mtd/spi-nor/fsl-quadspi.c:369:1: error:
'LUT_0' undeclared (first use in this function)
drivers/mtd/spi-nor/fsl-quadspi.c:418:1: error:
pasting "LUT_" and "(" does not give a valid preprocessing token
drivers/mtd/spi-nor/fsl-quadspi.c:418:2: error:
implicit declaration of function 'LUT_'
I don't think this is only a SPARC problem. The macro concatenation is
generally suspect.
I see that READ and WRITE are problems at least. If something like
gets included somehow, then these tokens resolve to
integers or expressions before they fall through to literal
concatentation, so we get 'LUT_0' or 'LUT_(1ULL << __REQ_WRITE)' instead
of 'LUT_READ' and 'LUT_WRITE'.
You are right, that deserves a better fix. I'll leave it up to you.
Thanks,
Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Ksummit-discuss] Linux Foundation Technical Advisory Board Elections and Nomination process
Darren Hart writes: > > Is there a good description of what is expected of a TAB member? How much time > is involved? What makes a great TAB member? > > I've found: http://www.linuxfoundation.org/programs/advisory-councils/tab > > I've read the charter and scanned some of the minutes, but I'd still like to > hear from some of the "incumbants". Specifically, what makes you successful > as a > member of the TAB? Also on the topic of the TAB and elections, I cannot figure out what: "Only one vote per candidate will be counted." means in: Voting: --- Each person present at the time of the election shall be handed a printed ballot. Voters may vote for as many candidates as they wish. Only one vote per candidate will be counted. A space will be provided where they can fill out the ballot in private and place it into a box to be counted in private. in http://www.linuxfoundation.org/collaborate/workgroups/technical-advisory-board-tab/minutes-july-2015-tab-meeting Is it "Only one vote per candidate per voter will be counted"? NeilBrown signature.asc Description: PGP signature
Re: [PATCH -next] mtd: fsl-quadspi: Never build on SPARC
+ Han
On Wed, Oct 21, 2015 at 07:31:46AM -0700, Guenter Roeck wrote:
> Attempts to build fsl-quadspi on SPARC fail with
>
> drivers/mtd/spi-nor/fsl-quadspi.c: In function 'fsl_qspi_init_lut':
> drivers/mtd/spi-nor/fsl-quadspi.c:369:1: error:
> 'LUT_0' undeclared (first use in this function)
> drivers/mtd/spi-nor/fsl-quadspi.c:418:1: error:
> pasting "LUT_" and "(" does not give a valid preprocessing token
> drivers/mtd/spi-nor/fsl-quadspi.c:418:2: error:
> implicit declaration of function 'LUT_'
I don't think this is only a SPARC problem. The macro concatenation is
generally suspect.
I see that READ and WRITE are problems at least. If something like
gets included somehow, then these tokens resolve to
integers or expressions before they fall through to literal
concatentation, so we get 'LUT_0' or 'LUT_(1ULL << __REQ_WRITE)' instead
of 'LUT_READ' and 'LUT_WRITE'.
Han, are you up for fixing, or should I?
Brian
> Never build it on SPARC, even if COMPILE_TEST is enabled.
>
> Fixes: d26a22d06708 ("mtd: fsl-quadspi: allow building for other ARCHes
> with COMPILE_TEST")
> Cc: Brian Norris
> Signed-off-by: Guenter Roeck
> ---
> drivers/mtd/spi-nor/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mtd/spi-nor/Kconfig b/drivers/mtd/spi-nor/Kconfig
> index 2fe2a7e90fa9..fceb2886bfd1 100644
> --- a/drivers/mtd/spi-nor/Kconfig
> +++ b/drivers/mtd/spi-nor/Kconfig
> @@ -23,7 +23,7 @@ config MTD_SPI_NOR_USE_4K_SECTORS
>
> config SPI_FSL_QUADSPI
> tristate "Freescale Quad SPI controller"
> - depends on ARCH_MXC || COMPILE_TEST
> + depends on ARCH_MXC || (COMPILE_TEST && !SPARC)
> depends on HAS_IOMEM
> help
> This enables support for the Quad SPI controller in master mode.
> --
> 2.1.4
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] mm: Introduce kernelcore=reliable option
Dear Tony, > -Original Message- > From: Luck, Tony [mailto:tony.l...@intel.com] > Sent: Friday, October 23, 2015 8:27 AM > To: Kamezawa, Hiroyuki/亀澤 寛之; Izumi, Taku/泉 拓; linux-kernel@vger.kernel.org; > linux...@kvack.org > Cc: qiuxi...@huawei.com; m...@csn.ul.ie; a...@linux-foundation.org; Hansen, > Dave; m...@codeblueprint.co.uk > Subject: RE: [PATCH] mm: Introduce kernelcore=reliable option > > > I think /proc/zoneinfo can show detailed numbers per zone. Do we need some > > for meminfo ? > > I wrote a little script (attached) to summarize /proc/zoneinfo ... on my > system it says > > $ zoneinfo > Node Normal Movable DMA DMA32 >00.00 103020.078.94 1554.46 >1 9284.5489870.43 >2 9626.3394050.09 >3 9602.8293650.04 > > Not sure why I have zero Normal memory free on node0. The sum of all those > free counts is 410667.72 MB ... which is close enough to the boot time message > showing the amount of mirror/total memory: > > [0.00] efi: Memory: 80979/420096M mirrored memory > > but a fair amount of the 80G of mirrored memory seems to have been miscounted > as Movable instead of Normal. Perhaps this is because I have two blocks of > mirrored > memory on each node and the movable zone code doesn't expect that? You were saying that OS view of memory of node is something like the following ? Node X: |MM--MM| (legend) M: mirrored -: not mirrrored If so, is this a real Box's configuration? Sorry, I haven't got a real Address Range Mirror capable boxes yet ... I thought mirroring range is concatenated at the first part of each node. Sincerely, Taku Izumi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: blk-mq: takes hours for scsi scanning finish when thousands of LUNs
On Thu, Oct 22, 2015 at 5:15 PM, jason wrote: > > > On Thursday, October 22, 2015 04:47 PM, Tejun Heo wrote: >> >> Hello, >> >> On Mon, Oct 19, 2015 at 07:40:13AM -0700, Zhangqing Luo wrote: >> >> > So every time blk_mq_freeze_queue_start, it runs in this way >> > >> > blk_mq_freeze_queue_start >> > ->percpu_ref_kill->percpu_ref_kill_and_confirm >> > ->__percpu_ref_switch_to_atomic >> > ->call_rcu_sched(>rcu,percpu_ref_switch_to_atomic_rcu) >> > >> > and blk_mq_freeze_queue_wait blocks on queue->mq_usage_counter >> > as it is not zero, and wake up by percpu_ref_switch_to_atomic_rcu >> > after a grace period >> > >> > >> > My question here is why should we change ref to PERCPU at >> > blk_mq_finish_init? >> > because of this changing, delay appears. >> >> Because percpu operation is way cheaper than atomic ones and we want >> to optimize hot paths (request issue and completion) over cold paths >> (init and config changes). That's the whole point of percpu >> refcnting. >> >> The reason why percpu ref starts in atomic mode is to avoid expensive >> percpu freezing if the queue is created and abandoned in quick >> succession as SCSI does during LUN scanning. If percpu freezing is >> happening during that, the right solution is moving finish_init to >> late enough point so that percpu switching happens only after it's >> known that the queue won't be abandoned. >> >> Thanks. >> > I agree with the optimizing hot paths by cheaper percpu operation, > but how much does it affect the performance? > > as you know the switching causes delay, when the the LUN number is > increasing > the delay is becoming higher, so do you have any idea > about the problem? For a normal SCSI disk, add_disk() is called in sd probe path, during that time, the reuquest queue should have been initialized completely, that said blk_mq_add_queue_tag_set() should be run in atomic mode of the usage ref counter. Not sure how can you observe the ref counter is running at percpu mode during queue initialization. Care to share what your disk/driver is? I doubt it might be one SCSI LLD's issue. Thanks, > > /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/ -- Ming Lei -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 15/25] x86, pkeys: check VMAs and PTEs for protection keys
On 10/22/2015 03:25 PM, Jerome Glisse wrote:
> On Thu, Oct 22, 2015 at 02:23:08PM -0700, Dave Hansen wrote:
...
>> Can you give an example of where a process might be doing a gup and it
>> is completely separate from the CPU context that it's being executed under?
>
> In drivers/iommu/amd_iommu_v2.c thought this is on AMD platform. I also
> believe that in infiniband one can have GUP call from workqueue that can
> run at any time. In GPU driver we also use GUP thought at this point we
> do not allow another process from accessing a buffer that is populated
> by GUP from another process.
>From quick grepping, there are only a couple of callers that do
get_user_pages() on something that isn't current->mm.
We can fairly easily introduce something new, like
get_foreign_user_pages()
That sets a flag to tell us to ignore the current PKRU state.
I've attached a patch that at creates a variant of get_user_pages() for
when you're going after another process's mm. This even makes a few of
the gup call sites look nicer because they're not passing 'current,
current->mm'.
>>> So as first i would just allow GUP to always work and then come up with
>>> syscall to allow to set pkey on device file. This obviously is a lot more
>>> work as you need to go over all device driver using GUP.
>>
>> I wouldn't be opposed to adding some context to the thread (like
>> pagefault_disable()) that indicates whether we should enforce protection
>> keys. If we are in some asynchronous context, disassociated from the
>> running CPU's protection keys, we could set a flag.
>
> I was simply thinking of having a global set of pkeys against the process
> mm struct which would be the default global setting for all device GUP
> access. This global set could be override by userspace on a per device
> basis allowing some device to have more access than others.
For now, I think leaving it permissive by default is probably OK. A
device's access to memory is permissive after a gup anyway.
As you note, doing this is going to require another whole set of user
interfaces, so I'd rather revisit it later once we have a more concrete
need for it.
1. Store a common PKRU value somewhere and activate when servicing work
outside of the context of the actual process. Set this PKRU value
with input from userspace and new user APIs.
2. When work is queued, copy the PKRU value and use it while servicing
the work.
3. Do all out-of-context work with PKRU=0, or by disabling the PKRU
checks conditionally.
>> I'd really appreciate if you could point to some concrete examples here
>> which could actually cause a problem, like workqueues doing gups.
>
> Well i could grep for all current user of GUP, but i can tell you that this
> is gonna be the model for GPU thread ie a kernel workqueue gonna handle
> page fault on behalf of GPU and will perform equivalent of GUP. Also apply
> for infiniband ODP thing which is upstream.
---
b/arch/x86/mm/mpx.c |4 +-
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c |4 +-
b/drivers/gpu/drm/i915/i915_gem_userptr.c |2 -
b/drivers/gpu/drm/radeon/radeon_ttm.c |4 +-
b/drivers/gpu/drm/via/via_dmablit.c |3 --
b/drivers/infiniband/core/umem.c |2 -
b/drivers/infiniband/core/umem_odp.c |8 ++---
b/drivers/infiniband/hw/mthca/mthca_memfree.c |3 --
b/drivers/infiniband/hw/qib/qib_user_pages.c |3 --
b/drivers/infiniband/hw/usnic/usnic_uiom.c|2 -
b/drivers/media/pci/ivtv/ivtv-yuv.c |8 ++---
b/drivers/media/v4l2-core/videobuf-dma-sg.c |3 --
b/drivers/virt/fsl_hypervisor.c |5 +--
b/fs/exec.c |8 -
b/include/linux/mm.h | 14 +
b/mm/frame_vector.c |2 -
b/mm/gup.c| 39 --
b/mm/mempolicy.c |6 ++--
b/security/tomoyo/domain.c|9 +-
19 files changed, 79 insertions(+), 50 deletions(-)
diff -puN mm/gup.c~get_current_user_pages mm/gup.c
--- a/mm/gup.c~get_current_user_pages 2015-10-22 16:03:24.957026355 -0700
+++ b/mm/gup.c 2015-10-22 16:46:58.181109179 -0700
@@ -752,11 +752,12 @@ EXPORT_SYMBOL(get_user_pages_locked);
* according to the parameters "pages", "write", "force"
* respectively.
*/
-__always_inline long __get_user_pages_unlocked(struct task_struct *tsk, struct mm_struct *mm,
- unsigned long start, unsigned long nr_pages,
+__always_inline long __get_user_pages_unlocked(unsigned long start, unsigned long nr_pages,
int write, int force, struct page **pages,
unsigned int gup_flags)
{
+ struct task_struct *tsk = curent;
+ struct mm_struct *mm = tsk->mm
long ret;
int locked = 1;
down_read(>mmap_sem);
@@ -795,7 +796,7 @@ long get_user_pages_unlocked(struct task
