[PATCH net-next] wireless: test sscanf return values
At some point, it'd be good to make sscanf use __must_check
so make sure the net/ uses of sscanf use the return value.
Signed-off-by: Joe Perches j...@perches.com
---
Compiled, untested.
net/mac80211/debugfs.c | 4 ++--
net/wireless/core.c| 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/net/mac80211/debugfs.c b/net/mac80211/debugfs.c
index eeb0bbd..0e44be7 100644
--- a/net/mac80211/debugfs.c
+++ b/net/mac80211/debugfs.c
@@ -160,9 +160,9 @@ static ssize_t sta_tx_latency_stat_write(struct file *file,
tx_latency-n_ranges = n_ranges;
for (i = 0; i n_ranges; i++) { /* setting bin ranges */
token = strsep(bins, TX_LATENCY_BIN_DELIMTER_S);
- sscanf(token, %d, tx_latency-ranges[i]);
/* bins values should be in ascending order */
- if (prev_bin = tx_latency-ranges[i]) {
+ if (sscanf(token, %d, tx_latency-ranges[i]) != 1 ||
+ prev_bin = tx_latency-ranges[i]) {
ret = -EINVAL;
kfree(tx_latency);
goto unlock;
diff --git a/net/wireless/core.c b/net/wireless/core.c
index 3af0ecf..69a350e 100644
--- a/net/wireless/core.c
+++ b/net/wireless/core.c
@@ -95,8 +95,8 @@ static int cfg80211_dev_check_name(struct
cfg80211_registered_device *rdev,
ASSERT_RTNL();
/* prohibit calling the thing phy%d when %d is not its number */
- sscanf(newname, PHY_NAME %d%n, wiphy_idx, taken);
- if (taken == strlen(newname) wiphy_idx != rdev-wiphy_idx) {
+ if (sscanf(newname, PHY_NAME %d%n, wiphy_idx, taken) == 1
+ taken == strlen(newname) wiphy_idx != rdev-wiphy_idx) {
/* count number of places needed to print wiphy_idx */
digits = 1;
while (wiphy_idx /= 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/
[PATCH v11 1/6] mfd: Add support for Skyworks SKY81452 driver
From: Gyungoh Yoo jack@skyworksinc.com
Signed-off-by: Gyungoh Yoo jack@skyworksinc.com
Acked-by: Lee Jones lee.jo...@linaro.org
---
Changes v11:
Nothing
Changes v10:
Nothing
Changes v9:
Nothing
Changes v8:
Nothing
Changes v7:
Modified licensing text to GPLv2
Changes v6:
Added new line character at the end of line of dev_err()
Changes v5:
Move sky81452-backlight.h to include/linux/platform_data
Changes v4:
Removed MODULE_VERSION()
Modified license to GPLv2
Changes v3:
Fixed the backlight name from 'sky81452-bl' to 'sky81452-backlight'
Assigned mfd_cell.of_compatible for binding device node
Modified error messages
Changes v2:
Renamed CONFIG_SKY81452 to CONFIG_MFD_SKY81452
Changed the dependency from I2C=y to I2C, for CONFIG_MFD_SKY81452
Added message for exception or errors
drivers/mfd/Kconfig | 12 +
drivers/mfd/Makefile | 1 +
drivers/mfd/sky81452.c | 108 +++
include/linux/mfd/sky81452.h | 31 +
4 files changed, 152 insertions(+)
create mode 100644 drivers/mfd/sky81452.c
create mode 100644 include/linux/mfd/sky81452.h
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 38356e3..bc3b540 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -753,6 +753,18 @@ config MFD_SM501_GPIO
lines on the SM501. The platform data is used to supply the
base number for the first GPIO line to register.
+config MFD_SKY81452
+ tristate Skyworks Solutions SKY81452
+ select MFD_CORE
+ select REGMAP_I2C
+ depends on I2C
+ help
+ This is the core driver for the Skyworks SKY81452 backlight and
+ voltage regulator device.
+
+ This driver can also be built as a module. If so, the module
+ will be called sky81452.
+
config MFD_SMSC
bool SMSC ECE1099 series chips
depends on I2C=y
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 19f3d74..75b3ffb 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -178,6 +178,7 @@ obj-$(CONFIG_MFD_MENF21BMC) += menf21bmc.o
obj-$(CONFIG_MFD_HI6421_PMIC) += hi6421-pmic-core.o
obj-$(CONFIG_MFD_DLN2) += dln2.o
obj-$(CONFIG_MFD_RT5033) += rt5033.o
+obj-$(CONFIG_MFD_SKY81452) += sky81452.o
intel-soc-pmic-objs:= intel_soc_pmic_core.o intel_soc_pmic_crc.o
obj-$(CONFIG_INTEL_SOC_PMIC) += intel-soc-pmic.o
diff --git a/drivers/mfd/sky81452.c b/drivers/mfd/sky81452.c
new file mode 100644
index 000..b0c9b04
--- /dev/null
+++ b/drivers/mfd/sky81452.c
@@ -0,0 +1,108 @@
+/*
+ * sky81452.c SKY81452 MFD driver
+ *
+ * Copyright 2014 Skyworks Solutions Inc.
+ * Author : Gyungoh Yoo jack@skyworksinc.com
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, see http://www.gnu.org/licenses/.
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/init.h
+#include linux/err.h
+#include linux/slab.h
+#include linux/i2c.h
+#include linux/regmap.h
+#include linux/mfd/core.h
+#include linux/mfd/sky81452.h
+
+static const struct regmap_config sky81452_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+};
+
+static int sky81452_probe(struct i2c_client *client,
+ const struct i2c_device_id *id)
+{
+ struct device *dev = client-dev;
+ const struct sky81452_platform_data *pdata = dev_get_platdata(dev);
+ struct mfd_cell cells[2];
+ struct regmap *regmap;
+ int ret;
+
+ if (!pdata) {
+ pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata)
+ return -ENOMEM;
+ }
+
+ regmap = devm_regmap_init_i2c(client, sky81452_config);
+ if (IS_ERR(regmap)) {
+ dev_err(dev, failed to initialize.err=%ld\n, PTR_ERR(regmap));
+ return PTR_ERR(regmap);
+ }
+
+ i2c_set_clientdata(client, regmap);
+
+ memset(cells, 0, sizeof(cells));
+ cells[0].name = sky81452-backlight;
+ cells[0].of_compatible = skyworks,sky81452-backlight;
+ cells[0].platform_data = pdata-bl_pdata;
+ cells[0].pdata_size = sizeof(*pdata-bl_pdata);
+ cells[1].name = sky81452-regulator;
+ cells[1].platform_data = pdata-regulator_init_data;
+ cells[1].pdata_size = sizeof(*pdata-regulator_init_data);
+
+ ret = mfd_add_devices(dev, -1, cells, ARRAY_SIZE(cells), NULL, 0, NULL);
+ if (ret)
+ dev_err(dev, failed to add child
[PATCH v11 0/6] Add Skyworks SKY81452 device drivers
From: Gyungoh Yoo jack@skyworksinc.com This patch set includes regulator and backlight driver for SKY81452. Also it includes documents for device tree and module. sky81452-regulator was already applied. So this series doesn't include it. v11: Renamed 'skyworks,en-channels' property to led-sources. Removed unused property 'skyworks,ovp-level'. v10: Removed trivial get_brightness implementations for sky81452-backlight v9: Removed the change to remove MODULE_VERSION() for sky81452-regulator v8: Renamed property names for backlight with vendor prefix Modified gpio-enable property to generic property for GPIO Made up the example for backlight DT Changed the DT parsing of regulator using regulator_node and of_match v7: Modified licensing text to GPLv2 Split Kconfig renaming from DT patch v6: Added new line character at the end of line of dev_err() v5: Changed DT for regulator : 'lout' node should be defined under 'regulator' Removed compatible string from sky81452-regulator driver Modified sky81452-regulator to return EINVAL when of_node is NULL Move sky81452-backlight.h to include/linux/platform_data v4: Removed MODULE_VERSION() Modified license to GPLv2 Removed calling to backlight_device_unregister() in sky81452-backlight v3: Cleaned-up DBG messages Cleaned-up DT Fixed the backlight name from 'sky81452-bl' to 'sky81452-backlight' Assigned mfd_cell.of_compatible for binding device node Modified error messages Modified sky81452-regulator to return ENODATA when of_node is NULL v2: Split the patches for each sub-system Added 'reg' attribute for I2C address in device tree documents Added 'compatible' attribute in child drivers Renamed CONFIG_SKY81452 to CONFIG_MFD_SKY81452 Changed the dependency from I2C=y to I2C, for CONFIG_MFD_SKY81452 Added message for exception or errors. Added vendor prefix for Skyworks Solutions, Inc. Add SKY81452 to the Trivial Devices list Gyungoh Yoo (6): mfd: Add support for Skyworks SKY81452 driver backlight: Add support Skyworks SKY81452 backlight driver devicetree: Add new SKY81452 mfd binding devicetree: Add new SKY81452 backlight binding devicetree: Add vendor prefix for Skyworks Solutions, Inc. devicetree: Add SKY81452 to the Trivial Devices list .../devicetree/bindings/i2c/trivial-devices.txt| 1 + Documentation/devicetree/bindings/mfd/sky81452.txt | 35 ++ .../devicetree/bindings/vendor-prefixes.txt| 1 + .../video/backlight/sky81452-backlight.txt | 29 ++ drivers/mfd/Kconfig| 12 + drivers/mfd/Makefile | 1 + drivers/mfd/sky81452.c | 108 +++ drivers/video/backlight/Kconfig| 10 + drivers/video/backlight/Makefile | 1 + drivers/video/backlight/sky81452-backlight.c | 353 + include/linux/mfd/sky81452.h | 31 ++ include/linux/platform_data/sky81452-backlight.h | 46 +++ 12 files changed, 628 insertions(+) create mode 100644 Documentation/devicetree/bindings/mfd/sky81452.txt create mode 100644 Documentation/devicetree/bindings/video/backlight/sky81452-backlight.txt create mode 100644 drivers/mfd/sky81452.c create mode 100644 drivers/video/backlight/sky81452-backlight.c create mode 100644 include/linux/mfd/sky81452.h create mode 100644 include/linux/platform_data/sky81452-backlight.h -- 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 v11 3/6] devicetree: Add new SKY81452 mfd binding
From: Gyungoh Yoo jack@skyworksinc.com
Signed-off-by: Gyungoh Yoo jack@skyworksinc.com
Acked-by: Lee Jones lee.jo...@linaro.org
---
Changes v11:
Renamed 'skyworks,en-channels' property to led-sources.
Removed unused property 'skyworks,ovp-level'.
Changes v10:
Nothing
Changes v9:
Nothing
Changes v8:
Made up the example for backlight DT
Changes v7:
Nothing
Changes v6:
Nothing
Changes v5:
Changed DT for regulator : 'lout' node should be defined under 'regulator'
Removed compatible string from sky81452-regulator driver
Changes v4:
Nothing
Changes v3:
Nothing
Changes v2:
Added reg attribute for I2C slave address
Documentation/devicetree/bindings/mfd/sky81452.txt | 35 ++
1 file changed, 35 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/sky81452.txt
diff --git a/Documentation/devicetree/bindings/mfd/sky81452.txt
b/Documentation/devicetree/bindings/mfd/sky81452.txt
new file mode 100644
index 000..3518179
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/sky81452.txt
@@ -0,0 +1,35 @@
+SKY81452 bindings
+
+Required properties:
+- compatible : Must be skyworks,sky81452
+- reg : I2C slave address
+
+Required child nodes:
+- backlight: container node for backlight following the binding
+ in video/backlight/sky81452-backlight.txt
+- regulator: container node for regulators following the binding
+ in regulator/sky81452-regulator.txt
+
+Example:
+
+ sky81452@2c {
+ compatible = skyworks,sky81452;
+ reg = 0x2c;
+
+ backlight {
+ compatible = skyworks,sky81452-backlight;
+ name = pwm-backlight;
+ led-sources = 0 1 2 3 6;
+ skyworks,ignore-pwm;
+ skyworks,phase-shift;
+ skyworks,current-limit = 2300;
+ };
+
+ regulator {
+ lout {
+ regulator-name = sky81452-lout;
+ regulator-min-microvolt = 450;
+ regulator-max-microvolt = 800;
+ };
+ };
+ };
--
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 2/2] ACPI / EC: Add GPE reference counting debugging messages.
This patch enhances debugging with the GPE reference count messages added.
This kind of log entries can be used by the platform validators to validate
if there is an EC transaction broken because of firmware/driver bugs.
No functional changes.
Signed-off-by: Lv Zheng lv.zh...@intel.com
---
drivers/acpi/ec.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
index 07426c8..a362f20 100644
--- a/drivers/acpi/ec.c
+++ b/drivers/acpi/ec.c
@@ -177,6 +177,8 @@ static int EC_FLAGS_QUERY_HANDSHAKE; /* Needs QR_EC issued
when SCI_EVT set */
ec_dbg(EC_DBG_REQ, fmt, ##__VA_ARGS__)
#define ec_dbg_evt(fmt, ...) \
ec_dbg(EC_DBG_EVT, fmt, ##__VA_ARGS__)
+#define ec_dbg_ref(ec, fmt, ...) \
+ ec_dbg_raw(%lu: fmt, ec-reference_count, ## __VA_ARGS__)
/* --
* Device Flags
@@ -544,6 +546,7 @@ static int acpi_ec_transaction_unlocked(struct acpi_ec *ec,
ret = -EINVAL;
goto unlock;
}
+ ec_dbg_ref(ec, Increase command);
/* following two actions should be kept atomic */
ec-curr = t;
ec_dbg_req(Command(%s) started, acpi_ec_cmd_string(t-command));
@@ -557,6 +560,7 @@ static int acpi_ec_transaction_unlocked(struct acpi_ec *ec,
ec-curr = NULL;
/* Disable GPE for command processing (IBF=0/OBF=1) */
acpi_ec_complete_request(ec);
+ ec_dbg_ref(ec, Decrease command);
unlock:
spin_unlock_irqrestore(ec-lock, tmp);
return ret;
@@ -718,8 +722,10 @@ static void acpi_ec_start(struct acpi_ec *ec, bool
resuming)
if (!test_and_set_bit(EC_FLAGS_STARTED, ec-flags)) {
ec_dbg_drv(Starting EC);
/* Enable GPE for event processing (SCI_EVT=1) */
- if (!resuming)
+ if (!resuming) {
acpi_ec_submit_request(ec);
+ ec_dbg_ref(ec, Increase driver);
+ }
ec_log_drv(EC started);
}
spin_unlock_irqrestore(ec-lock, flags);
@@ -748,8 +754,10 @@ static void acpi_ec_stop(struct acpi_ec *ec, bool
suspending)
wait_event(ec-wait, acpi_ec_stopped(ec));
spin_lock_irqsave(ec-lock, flags);
/* Disable GPE for event processing (SCI_EVT=1) */
- if (!suspending)
+ if (!suspending) {
acpi_ec_complete_request(ec);
+ ec_dbg_ref(ec, Decrease driver);
+ }
clear_bit(EC_FLAGS_STARTED, ec-flags);
clear_bit(EC_FLAGS_STOPPED, ec-flags);
ec_log_drv(EC stopped);
--
1.7.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/
[PATCH 1/2] ACPI / EC: Cleanup logging/debugging splitter support.
This patch refines logging/debugging splitter support so that when DEBUG is
disabled, splitters won't be visible in the kernel logs while they are
still available for developers when DEBUG is enabled.
This patch also refines the splitters to mark the following handling
process boundaries:
+: boundary of driver starting/stopping
boundary of IRQ storming
=: boundary of transaction advancement
*: boundary of EC command
boundary of EC query
#: boundary of EC _Qxx evaluation
The following 2 log entries are originally logged using pr_info() in order
to be used as the boot/suspend/resume log entries for the EC device, this
patch also restores them to pr_info() logging level:
ACPI : EC: EC started
ACPI : EC: EC stopped
In this patch, one log entry around Polling quirk is converted into
ec_dbg_raw() which doesn't contain the boundary marker.
Signed-off-by: Lv Zheng lv.zh...@intel.com
---
drivers/acpi/ec.c | 108 -
1 file changed, 74 insertions(+), 34 deletions(-)
diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
index a8dd2f7..07426c8 100644
--- a/drivers/acpi/ec.c
+++ b/drivers/acpi/ec.c
@@ -137,6 +137,48 @@ static int EC_FLAGS_CLEAR_ON_RESUME; /* Needs
acpi_ec_clear() on boot/resume */
static int EC_FLAGS_QUERY_HANDSHAKE; /* Needs QR_EC issued when SCI_EVT set */
/* --
+ * Logging/Debugging
+ * --
*/
+
+/*
+ * Splitters used by the developers to track the boundary of the EC
+ * handling processes.
+ */
+#ifdef DEBUG
+#define EC_DBG_SEP
+#define EC_DBG_DRV +
+#define EC_DBG_STM =
+#define EC_DBG_REQ *
+#define EC_DBG_EVT #
+#else
+#define EC_DBG_SEP
+#define EC_DBG_DRV
+#define EC_DBG_STM
+#define EC_DBG_REQ
+#define EC_DBG_EVT
+#endif
+
+#define ec_log_raw(fmt, ...) \
+ pr_info(fmt \n, ##__VA_ARGS__)
+#define ec_dbg_raw(fmt, ...) \
+ pr_debug(fmt \n, ##__VA_ARGS__)
+#define ec_log(filter, fmt, ...) \
+ ec_log_raw(filter EC_DBG_SEP fmt EC_DBG_SEP filter, ##__VA_ARGS__)
+#define ec_dbg(filter, fmt, ...) \
+ ec_dbg_raw(filter EC_DBG_SEP fmt EC_DBG_SEP filter, ##__VA_ARGS__)
+
+#define ec_log_drv(fmt, ...) \
+ ec_log(EC_DBG_DRV, fmt, ##__VA_ARGS__)
+#define ec_dbg_drv(fmt, ...) \
+ ec_dbg(EC_DBG_DRV, fmt, ##__VA_ARGS__)
+#define ec_dbg_stm(fmt, ...) \
+ ec_dbg(EC_DBG_STM, fmt, ##__VA_ARGS__)
+#define ec_dbg_req(fmt, ...) \
+ ec_dbg(EC_DBG_REQ, fmt, ##__VA_ARGS__)
+#define ec_dbg_evt(fmt, ...) \
+ ec_dbg(EC_DBG_EVT, fmt, ##__VA_ARGS__)
+
+/* --
* Device Flags
* --
*/
@@ -159,14 +201,14 @@ static inline u8 acpi_ec_read_status(struct acpi_ec *ec)
{
u8 x = inb(ec-command_addr);
- pr_debug(EC_SC(R) = 0x%2.2x
-SCI_EVT=%d BURST=%d CMD=%d IBF=%d OBF=%d\n,
-x,
-!!(x ACPI_EC_FLAG_SCI),
-!!(x ACPI_EC_FLAG_BURST),
-!!(x ACPI_EC_FLAG_CMD),
-!!(x ACPI_EC_FLAG_IBF),
-!!(x ACPI_EC_FLAG_OBF));
+ ec_dbg_raw(EC_SC(R) = 0x%2.2x
+ SCI_EVT=%d BURST=%d CMD=%d IBF=%d OBF=%d,
+ x,
+ !!(x ACPI_EC_FLAG_SCI),
+ !!(x ACPI_EC_FLAG_BURST),
+ !!(x ACPI_EC_FLAG_CMD),
+ !!(x ACPI_EC_FLAG_IBF),
+ !!(x ACPI_EC_FLAG_OBF));
return x;
}
@@ -175,20 +217,20 @@ static inline u8 acpi_ec_read_data(struct acpi_ec *ec)
u8 x = inb(ec-data_addr);
ec-curr-timestamp = jiffies;
- pr_debug(EC_DATA(R) = 0x%2.2x\n, x);
+ ec_dbg_raw(EC_DATA(R) = 0x%2.2x, x);
return x;
}
static inline void acpi_ec_write_cmd(struct acpi_ec *ec, u8 command)
{
- pr_debug(EC_SC(W) = 0x%2.2x\n, command);
+ ec_dbg_raw(EC_SC(W) = 0x%2.2x, command);
outb(command, ec-command_addr);
ec-curr-timestamp = jiffies;
}
static inline void acpi_ec_write_data(struct acpi_ec *ec, u8 data)
{
- pr_debug(EC_DATA(W) = 0x%2.2x\n, data);
+ ec_dbg_raw(EC_DATA(W) = 0x%2.2x, data);
outb(data, ec-data_addr);
ec-curr-timestamp = jiffies;
}
@@ -240,7 +282,7 @@ static inline void acpi_ec_enable_gpe(struct acpi_ec *ec,
bool open)
* software need to manually trigger a pseudo GPE event on
* EN=1 writes.
*/
- pr_debug(* Polling quirk *\n);
+ ec_dbg_raw(Polling quirk);
advance_transaction(ec);
}
}
@@ -299,7 +341,7 @@ static void acpi_ec_set_storm(struct acpi_ec *ec, u8 flag)
{
if
[PATCH 0/2] ACPI / EC: Enhance logging/debugging.
This patchset enhances logging/debugging support in EC driver. Lv Zheng (2): ACPI / EC: Cleanup logging/debugging splitter support. ACPI / EC: Add GPE reference counting debugging messages. drivers/acpi/ec.c | 120 + 1 file changed, 84 insertions(+), 36 deletions(-) -- 1.7.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 3/3] leds: Add ktd2692 flash LED driver
hi
On 2015년 02월 27일 12:36, Varka Bhadram wrote:
On 02/27/2015 06:31 AM, Ingi Kim wrote:
This patch adds a driver to support the ktd2692 flash LEDs.
ktd2692 can control flash current by ExpressWire interface.
Signed-off-by: Ingi Kim ingi2@samsung.com
---
drivers/leds/Kconfig|8 ++
drivers/leds/Makefile |1 +
drivers/leds/leds-ktd2692.c | 245
+++
3 files changed, 254 insertions(+)
create mode 100644 drivers/leds/leds-ktd2692.c
(...)
+static struct ktd2692_context *ktd2692_parse_dt(struct device *dev)
+{
+ struct device_node *np = dev-of_node;
+ struct ktd2692_context *led;
+
+ led = devm_kzalloc(dev, sizeof(struct ktd2692_context), GFP_KERNEL);
+ if (!led)
+ return ERR_PTR((long)led);
What about using sizeof(*led) in place of sizeof(struct ktd2692_context)..?
Also the error return for devm_kzalloc() should be -ENOMEM.
Thanks, I'll check and change sizeof() and error return style.
+
+ led-strobe_gpio = of_get_named_gpio(np, strobe-gpio, 0);
+ if (!gpio_is_valid(led-strobe_gpio)) {
+ dev_err(dev, no strobe_gpio property found\n);
+ return ERR_PTR(led-strobe_gpio);
+ }
+
+ return led;
+}
+
+static int ktd2692_probe(struct platform_device *pdev)
+{
+ struct device *dev = pdev-dev;
+ struct ktd2692_context *led;
+ int ret;
+
+ if (!dev-of_node)
+ return -ENODEV;
+
+ led = ktd2692_parse_dt(dev);
+ if (IS_ERR(led))
+ return PTR_ERR(led);
+
+ led-cdev.name = KTD2692_DEFAULT_NAME;
+ led-cdev.brightness = LED_OFF;
+ led-cdev.max_brightness = LED_FULL;
+ led-cdev.flags |= LED_CORE_SUSPENDRESUME;
+ led-cdev.brightness_set = ktd2692_brightness_set;
+ led-cdev.brightness_get = ktd2692_brightness_get;
+ led-mode = KTD2692_REG_MODE_BASE | KTD2692_MODE_DISABLE;
+
+ platform_set_drvdata(pdev, led);
+
+ ret = led_classdev_register(pdev-dev, led-cdev);
+ if (ret) {
+ dev_err(dev, couldn't register LED %s\n, led-cdev.name);
+ return ret;
+ }
+
+ ret = ktd2692_brightness_set_gpio(led);
+ if (ret) {
+ led_classdev_unregister(led-cdev);
+ return ret;
+ }
+
+ ktd2692_expresswire_reset(led);
+
+ return ret;
return 0 instead of ret...?
I'll check and try
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 v2] mmc: dw_mmc: fix bug that cause mmc_test failture
Hi, I will apply into my-tree after change the subject and fix typo. Acked-by: Jaehoon Chung jh80.ch...@samsung.com Best Regards, Jaehoon Chung On 02/26/2015 03:17 AM, Javier Martinez Canillas wrote: Hello Addy, On 02/20/2015 03:55 AM, Addy Ke wrote: The STOP command can terminate a data transfer between a memory card and mmc controller. As show in Synopsys DesignWare Cores Mobile Stroage Host Databook: s/Stroage/Storage but maybe Ulf can amend the typo when applying? Data timeout and Data end-bit error will terminate further data transfer by mmc controller. So we should not send abort command to terminate a data transfer again if we got DRTO and EBE interrupt. After this patch, all mmc_test cases can pass on RK3288-Pink2 board. Signed-off-by: Addy Ke addy...@rock-chips.com I did not run all the tests listed in /sys/kernel/debug/mmc*/*/testlist because some of them will overwrite the data in my card but at least the read ones completed successfully and $subject does not cause a regression in the Exynos5250 Snow, Exynos5420 Peach Pit and Exynos5800 Peach Pi Chromebooks where I tested it. Tested-by: Javier Martinez Canillas javier.marti...@collabora.co.uk Best regards, Javier -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/7] kprobes: Propagate error from arm_kprobe_ftrace()
(2015/02/27 1:13), Petr Mladek wrote:
arm_kprobe_ftrace() could fail, especially after introducing ftrace IPMODIFY
flag and LifePatching.
registry_kprobe() and registry_aggr_kprobe() do not mind about the error
because the kprobe gets disabled and they keep it registered.
But enable_kprobe() should propagate the error because its tasks
fails if ftrace fails.
Also arm_all_kprobes() should return error if it happens. The behavior
is a bit questionable here. This patch keeps the existing behavior and does
the best effort. It tries to enable as many Kprobes as possible. It returns
only the last error code if any. kprobes_all_disarmed is always cleared and
the message about finished action is always printed. There is going to be
a separate patch that will improve the behavior.
When I applied it on -tip/master, there is a hunk which is not cleanly applied.
Please rebase it on the latest tip/master, since some logic are changed.
Here I have some comments on it.
Signed-off-by: Petr Mladek pmla...@suse.cz
---
kernel/kprobes.c | 47 ---
1 file changed, 32 insertions(+), 15 deletions(-)
diff --git a/kernel/kprobes.c b/kernel/kprobes.c
index d1b9db690b9c..a69d23add983 100644
--- a/kernel/kprobes.c
+++ b/kernel/kprobes.c
@@ -929,7 +929,7 @@ static int prepare_kprobe(struct kprobe *p)
}
/* Caller must lock kprobe_mutex */
-static void arm_kprobe_ftrace(struct kprobe *p)
+static int arm_kprobe_ftrace(struct kprobe *p)
{
struct kprobe *kp;
int ret;
@@ -949,7 +949,7 @@ static void arm_kprobe_ftrace(struct kprobe *p)
goto err_function;
}
kprobe_ftrace_enabled++;
- return;
+ return ret;
err_function:
ftrace_set_filter_ip(kprobe_ftrace_ops, (unsigned long)p-addr, 1, 0);
@@ -958,6 +958,7 @@ err_filter:
if (kprobe_aggrprobe(p))
list_for_each_entry_rcu(kp, p-list, list)
kp-flags |= KPROBE_FLAG_DISABLED;
+ return ret;
}
/* Caller must lock kprobe_mutex */
@@ -976,17 +977,15 @@ static void disarm_kprobe_ftrace(struct kprobe *p)
}
#else/* !CONFIG_KPROBES_ON_FTRACE */
#define prepare_kprobe(p)arch_prepare_kprobe(p)
-#define arm_kprobe_ftrace(p) do {} while (0)
+#define arm_kprobe_ftrace(p) (0)
#define disarm_kprobe_ftrace(p) do {} while (0)
#endif
/* Arm a kprobe with text_mutex */
-static void arm_kprobe(struct kprobe *kp)
+static int arm_kprobe(struct kprobe *kp)
{
- if (unlikely(kprobe_ftrace(kp))) {
- arm_kprobe_ftrace(kp);
- return;
- }
+ if (unlikely(kprobe_ftrace(kp)))
+ return arm_kprobe_ftrace(kp);
/*
* Here, since __arm_kprobe() doesn't use stop_machine(),
* this doesn't cause deadlock on text_mutex. So, we don't
@@ -995,6 +994,7 @@ static void arm_kprobe(struct kprobe *kp)
mutex_lock(text_mutex);
__arm_kprobe(kp);
mutex_unlock(text_mutex);
+ return 0;
}
/* Disarm a kprobe with text_mutex */
@@ -1332,10 +1332,15 @@ out:
put_online_cpus();
jump_label_unlock();
+ /* Arm when this is the first enabled kprobe at this address */
if (ret == 0 kprobe_disabled(ap) !kprobe_disabled(p)) {
ap-flags = ~KPROBE_FLAG_DISABLED;
if (!kprobes_all_disarmed)
- /* Arm the breakpoint again. */
+ /*
+ * The kprobe is disabled and warning is printed
+ * on error. But we ignore the error code here
+ * because we keep it registered.
+ */
Why? if we can't arm it, we'd better make it fail.
arm_kprobe(ap);
}
return ret;
@@ -1540,6 +1545,11 @@ int register_kprobe(struct kprobe *p)
kprobe_table[hash_ptr(p-addr, KPROBE_HASH_BITS)]);
if (!kprobes_all_disarmed !kprobe_disabled(p))
+ /*
+ * The kprobe is disabled and warning is printed on error.
+ * But we ignore the error code here because we keep it
+ * registered.
+ */
arm_kprobe(p);
Ditto. If we failed to enable it. We should make it fail and report an error
to caller.
Thank you,
/* Try to optimize kprobe */
@@ -2040,7 +2050,7 @@ int enable_kprobe(struct kprobe *kp)
if (!kprobes_all_disarmed kprobe_disabled(p)) {
p-flags = ~KPROBE_FLAG_DISABLED;
- arm_kprobe(p);
+ ret = arm_kprobe(p);
}
out:
mutex_unlock(kprobe_mutex);
@@ -2325,11 +2335,12 @@ static const struct file_operations
debugfs_kprobe_blacklist_ops = {
.release= seq_release,
};
-static void arm_all_kprobes(void)
+static int arm_all_kprobes(void)
{
struct hlist_head *head;
struct kprobe *p;
unsigned int i;
+
Re: [PATCH v3] brcmfmac: avoid duplicated suspend/resume operation
On 2015/2/16 17:50, David Laight wrote:
WiFi chip has 2 SDIO functions, and PM core will trigger
twice suspend/resume operations for one WiFi chip to do
the same things. This patch avoid this case.
Do you want to suspend on the first or last request?
In general it might be that one function is in use and
something wants to suspend the other (as inactive).
If they suspend together you might need to pretend the
first function is suspended but only do the real power-saving
device suspend when all the functions have been suspended.
I was in Chinese new-year vacation these few days. So sorry for late response.
Suspend/Resume entry functions of brcmfmac driver does not differentiate
between two functions, performs the same operations instead.
Thanks,
Zhonghui
David
N�r��y���b�X��ǧv�^�){.n�+{��*ޕ�,�{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj��!tml=
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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] qla2xxx: Fix trivial typos in ql_log message
Acked-by: Saurav Kashyap saurav.kash...@qlogic.com
Change 'Fimware' to 'Firmware'
Change 'enalbled' to 'enabled'
Signed-off-by: Yannick Guerrini yguerr...@tomshardware.fr
---
drivers/scsi/qla2xxx/qla_init.c | 4 ++--
drivers/scsi/qla2xxx/qla_mid.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi/qla2xxx/qla_init.c
b/drivers/scsi/qla2xxx/qla_init.c
index e59f25b..5bb57c5 100644
--- a/drivers/scsi/qla2xxx/qla_init.c
+++ b/drivers/scsi/qla2xxx/qla_init.c
@@ -5364,7 +5364,7 @@ qla2x00_load_risc(scsi_qla_host_t *vha, uint32_t
*srisc_addr)
blob = qla2x00_request_firmware(vha);
if (!blob) {
ql_log(ql_log_info, vha, 0x0083,
- Fimware image unavailable.\n);
+ Firmware image unavailable.\n);
ql_log(ql_log_info, vha, 0x0084,
Firmware images can be retrieved from: QLA_FW_URL .\n);
return QLA_FUNCTION_FAILED;
@@ -5467,7 +5467,7 @@ qla24xx_load_risc_blob(scsi_qla_host_t *vha,
uint32_t *srisc_addr)
blob = qla2x00_request_firmware(vha);
if (!blob) {
ql_log(ql_log_warn, vha, 0x0090,
- Fimware image unavailable.\n);
+ Firmware image unavailable.\n);
ql_log(ql_log_warn, vha, 0x0091,
Firmware images can be retrieved from:
QLA_FW_URL .\n);
diff --git a/drivers/scsi/qla2xxx/qla_mid.c
b/drivers/scsi/qla2xxx/qla_mid.c
index 5c2e031..ca3804e 100644
--- a/drivers/scsi/qla2xxx/qla_mid.c
+++ b/drivers/scsi/qla2xxx/qla_mid.c
@@ -788,7 +788,7 @@ qla25xx_create_rsp_que(struct qla_hw_data *ha,
uint16_t options,
rsp-msix = ha-msix_entries[que_id + 1];
else
ql_log(ql_log_warn, base_vha, 0x00e3,
- MSIX not enalbled.\n);
+ MSIX not enabled.\n);
ha-rsp_q_map[que_id] = rsp;
rsp-rid = rid;
--
1.9.5.msysgit.0
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/3] platform/chrome: cros_ec_lpc - Build fixes
Hello Olof, This series adds a set of trivial fixes for build issues with the cros_ec_lpc driver that were reported by Fengguang Wu's build bot. It is composed of the following patches: Javier Martinez Canillas (3): platform/chrome: cros_ec_lpc - Include linux/io.h header file platform/chrome: cros_ec_lpc - Depend on X86 || COMPILE_TEST platform/chrome: cros_ec_lpc - Drop owner assignment drivers/platform/chrome/Kconfig | 2 +- drivers/platform/chrome/cros_ec_lpc.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) Best regards, Javier -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] platform/chrome: cros_ec_lpc - Depend on X86 || COMPILE_TEST
The Low Pin Count bus was introduced by Intel and is only used in x86 computers so it should depend on the X86 Kconfig option. But also build the driver if the COMPILE_TEST option is enabled to have build coverage in other architectures. Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk --- drivers/platform/chrome/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/platform/chrome/Kconfig b/drivers/platform/chrome/Kconfig index d4befbffae85..2a6531a5fde8 100644 --- a/drivers/platform/chrome/Kconfig +++ b/drivers/platform/chrome/Kconfig @@ -49,7 +49,7 @@ config CROS_EC_CHARDEV config CROS_EC_LPC tristate ChromeOS Embedded Controller (LPC) -depends on MFD_CROS_EC +depends on MFD_CROS_EC (X86 || COMPILE_TEST) help If you say Y here, you get support for talking to the ChromeOS EC over an LPC bus. This uses a simple byte-level protocol with a -- 2.1.3 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] platform/chrome: cros_ec_lpc - Include linux/io.h header file
The driver uses the inb() and outb() I/O functions so should include the header file that has these functions definitions. This patch fixes the following error when the header is not explicitly included: drivers/platform/chrome//cros_ec_lpc.c: In function ‘ec_response_timed_out’: drivers/platform/chrome//cros_ec_lpc.c:40:3: error: implicit declaration of function ‘inb’ [-Werror=implicit-function-declaration] drivers/platform/chrome//cros_ec_lpc.c: In function ‘cros_ec_cmd_xfer_lpc’: drivers/platform/chrome//cros_ec_lpc.c:75:3: error: implicit declaration of function ‘outb’ [-Werror=implicit-function-declaration] Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk --- drivers/platform/chrome/cros_ec_lpc.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/platform/chrome/cros_ec_lpc.c b/drivers/platform/chrome/cros_ec_lpc.c index 822fdb36ded9..f00bf4d246a1 100644 --- a/drivers/platform/chrome/cros_ec_lpc.c +++ b/drivers/platform/chrome/cros_ec_lpc.c @@ -23,6 +23,7 @@ #include linux/dmi.h #include linux/delay.h +#include linux/io.h #include linux/mfd/cros_ec.h #include linux/mfd/cros_ec_commands.h #include linux/module.h -- 2.1.3 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] platform/chrome: cros_ec_lpc - Drop owner assignment
Platform drivers don't need to set an owner
since it will be populated by the driver core.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
drivers/platform/chrome/cros_ec_lpc.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/platform/chrome/cros_ec_lpc.c
b/drivers/platform/chrome/cros_ec_lpc.c
index f00bf4d246a1..8f9ac4d7bbd0 100644
--- a/drivers/platform/chrome/cros_ec_lpc.c
+++ b/drivers/platform/chrome/cros_ec_lpc.c
@@ -270,7 +270,6 @@ MODULE_DEVICE_TABLE(dmi, cros_ec_lpc_dmi_table);
static struct platform_driver cros_ec_lpc_driver = {
.driver = {
.name = DRV_NAME,
- .owner = THIS_MODULE,
},
.probe = cros_ec_lpc_probe,
.remove = cros_ec_lpc_remove,
--
2.1.3
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [RFC] mm: change mm_advise_free to clear page dirty
-Original Message-
From: Minchan Kim [mailto:minchan@gmail.com] On Behalf Of Minchan Kim
Sent: Friday, February 27, 2015 1:28 PM
To: Wang, Yalin
Cc: Michal Hocko; Andrew Morton; linux-kernel@vger.kernel.org; linux-
m...@kvack.org; Rik van Riel; Johannes Weiner; Mel Gorman; Shaohua Li
Subject: Re: [RFC] mm: change mm_advise_free to clear page dirty
Hello,
On Fri, Feb 27, 2015 at 11:37:18AM +0800, Wang, Yalin wrote:
This patch add ClearPageDirty() to clear AnonPage dirty flag,
the Anonpage mapcount must be 1, so that this page is only used by
the current process, not shared by other process like fork().
if not clear page dirty for this anon page, the page will never be
treated as freeable.
In case of anonymous page, it has PG_dirty when VM adds it to
swap cache and clear it in clear_page_dirty_for_io. That's why
I added ClearPageDirty if we found it in swapcache.
What case am I missing? It would be better to understand if you
describe specific scenario.
Thanks.
Signed-off-by: Yalin Wang yalin.w...@sonymobile.com
---
mm/madvise.c | 15 +--
1 file changed, 5 insertions(+), 10 deletions(-)
diff --git a/mm/madvise.c b/mm/madvise.c
index 6d0fcb8..257925a 100644
--- a/mm/madvise.c
+++ b/mm/madvise.c
@@ -297,22 +297,17 @@ static int madvise_free_pte_range(pmd_t *pmd,
unsigned long addr,
continue;
page = vm_normal_page(vma, addr, ptent);
- if (!page)
+ if (!page || !PageAnon(page) || !trylock_page(page))
continue;
if (PageSwapCache(page)) {
- if (!trylock_page(page))
+ if (!try_to_free_swap(page))
continue;
-
- if (!try_to_free_swap(page)) {
- unlock_page(page);
- continue;
- }
-
- ClearPageDirty(page);
- unlock_page(page);
}
+ if (page_mapcount(page) == 1)
+ ClearPageDirty(page);
+ unlock_page(page);
/*
* Some of architecture(ex, PPC) don't update TLB
* with set_pte_at and tlb_remove_tlb_entry so for
--
Yes, for page which is in SwapCache, it is correct,
But for anon page which is not in SwapCache, it is always
PageDirty(), so we should also clear dirty bit to make it freeable,
Another problem is that if an anon page is shared by more than one process,
This happened when fork(), the anon page will be copy on write,
In this case, we should not clear page dirty,
Otherwise, other process will get zero page if the page is freed by reclaim
path,
This is not correct for other process which don't call MADV_FREE syscall.
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: 0001-media-vb2-Fill-vb2_buffer-with-bytesused-from-user.patch; kernel version 3.10.69
Thanks for your feedback. I will improve my patch submission. BR, Sudip From: Jeremiah Mahler [jmmah...@gmail.com] Sent: Thursday, February 26, 2015 10:39 PM To: Sudip JAIN Cc: linux-me...@vger.kernel.org; linux-kernel@vger.kernel.org Subject: Re: 0001-media-vb2-Fill-vb2_buffer-with-bytesused-from-user.patch; kernel version 3.10.69 Sudip, On Thu, Feb 26, 2015 at 01:18:31PM +0800, Sudip JAIN wrote: Hello Jeremiah, Please find the patch inline There are more problems than just not being inline. - The subject line wrong. - The log message is formatted wrong. - This patch is not in a form that can be applied. - And there are probably more problems as well... I would review how to submit patches and then try again. I recommend watching the video by Greg Kroah-Hartman on how to submit your first kernel patch [1]. [1]: https://www.youtube.com/watch?v=LLBrBBImJt4 [...] -- - Jeremiah Mahler -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/7] kprobes: Disable Kprobe when ftrace arming fails
(2015/02/27 1:13), Petr Mladek wrote:
arm_kprobe_ftrace() could fail, especially after introducing ftrace IPMODIFY
flag and LifePatching. But this situation is not properly handled.
This patch adds the most important changes.
Hmm, as you know, I actually working on it to drop IPMODIFY from kprobes except
jprobe.
however, yes, that is not enough. We might better set DISABLED flag as
this does.
First, it does not make sense to register kprobe_ftrace_ops if the filter
was
not set.
Second, we should remove the filter if the registration of kprobe_ftrace_ops
fails. The failure might be caused by conflict between the Kprobe and
a life patch via the IPMODIFY flag. If we remove the filter, we will allow
to register kprobe_ftrace_ops for another non-conflicting Kprobe later.
Third, we need to make sure that kprobe_ftrace_enabled is incremented only
when kprobe_ftrace_ops is successfully registered. Otherwise, another
Kprobe will not try to register it again. Note that we could move the
manipulation with this counter because it is accessed only under
kprobe_mutex.
Four, we should mark the probe as disabled if the ftrace stuff is not usable.
It will be the correct status. Also it will prevent the unregistration code
from producing another failure.
It looks more safe to disable the Kprobe directly in kprobe_ftrace_ops. Note
that we need to disable also all listed Kprobes in case of an aggregated
probe.
It would be enough to disable only the new one but we do not know which one it
was. They should be in sync anyway.
Acked-by: Masami Hiramatsu masami.hiramatsu...@hitachi.com
Thank you!
Signed-off-by: Petr Mladek pmla...@suse.cz
---
kernel/kprobes.c | 25 +
1 file changed, 21 insertions(+), 4 deletions(-)
diff --git a/kernel/kprobes.c b/kernel/kprobes.c
index ee619929cf90..d1b9db690b9c 100644
--- a/kernel/kprobes.c
+++ b/kernel/kprobes.c
@@ -931,16 +931,33 @@ static int prepare_kprobe(struct kprobe *p)
/* Caller must lock kprobe_mutex */
static void arm_kprobe_ftrace(struct kprobe *p)
{
+ struct kprobe *kp;
int ret;
ret = ftrace_set_filter_ip(kprobe_ftrace_ops,
(unsigned long)p-addr, 0, 0);
- WARN(ret 0, Failed to arm kprobe-ftrace at %p (%d)\n, p-addr, ret);
- kprobe_ftrace_enabled++;
- if (kprobe_ftrace_enabled == 1) {
+ if (WARN(ret 0,
+ Failed to arm kprobe-ftrace at %p (%d). The kprobe gets
disabled.\n,
+ p-addr, ret))
+ goto err_filter;
+
+ if (!kprobe_ftrace_enabled) {
ret = register_ftrace_function(kprobe_ftrace_ops);
- WARN(ret 0, Failed to init kprobe-ftrace (%d)\n, ret);
+ if (WARN(ret 0,
+ Failed to init kprobe-ftrace (%d). The probe at %p
gets disabled\n,
+ ret, p-addr))
+ goto err_function;
}
+ kprobe_ftrace_enabled++;
+ return;
+
+err_function:
+ ftrace_set_filter_ip(kprobe_ftrace_ops, (unsigned long)p-addr, 1, 0);
+err_filter:
+ p-flags |= KPROBE_FLAG_DISABLED;
+ if (kprobe_aggrprobe(p))
+ list_for_each_entry_rcu(kp, p-list, list)
+ kp-flags |= KPROBE_FLAG_DISABLED;
}
/* Caller must lock kprobe_mutex */
--
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Research Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu...@hitachi.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 3/6] arm64: Kprobes with single stepping support
On 02/18/15 09:59, Masami Hiramatsu wrote:
Hi,
(2015/02/18 8:11), David Long wrote:
From: Sandeepa Prabhu sandeepa.pra...@linaro.org
Add support for basic kernel probes(kprobes) and jump probes
(jprobes) for ARM64.
Kprobes will utilize software breakpoint and single step debug
exceptions supported on ARM v8.
Software breakpoint is placed at the probe address to trap the
kernel execution into kprobe handler.
ARM v8 supports single stepping to be enabled while exception return
(ERET) with next PC in exception return address (ELR_EL1). The
kprobe handler prepares an executable memory slot for out-of-line
execution with a copy of the original instruction being probed, and
enables single stepping from the instruction slot. With this scheme,
the instruction is executed with the exact same register context
'except PC' that points to instruction slot.
Debug mask(PSTATE.D) is enabled only when single stepping a recursive
Is that same as debug flag in the code commment?
Yes. The description in the commit might benefit from a little rewording.
kprobe, e.g.: during kprobes reenter so that probed instruction can be
single stepped within the kprobe handler -exception- context.
The recursion depth of kprobe is always 2, i.e. upon probe re-entry,
any further re-entry is prevented by not calling handlers and the case
counted as a missed kprobe).
So, would this mean the debug mask is required for single-stepping
in exception context by specification?
Not positive I exactly understand the question but:
1) We can't single-step at all until we've both set the SS mode bit
(PSTATE.SS) and unmasked debug exceptions (PSTATE.D). The debug
exception is normally masked.
2) PSTATE.D will be set at exception entry.
3) We can't single-step again until we RTE from the current single-step.
Single stepping from slot has a drawback on PC-relative accesses
like branching and symbolic literals access as offset from new PC
(slot address) may not be ensured to fit in immediate value of
opcode. Such instructions needs simulation, so reject
probing such instructions.
BTW, since while the single stepping IRQs are disabled, does that
also requires fixups for irq-mask loading instruction or something
like that? (sorry, I'm not good at aarch64 ISA...)
No, we disable interrupts and reject probing of the special instructions
that could reenable them *or* read the current status (since the
single-step environment will likely see a different value for that bit).
In previous patches I did not reject the reading of this bit.
Instructions generating exceptions or cpu mode change are rejected,
and not allowed to insert probe for these instructions.
Instructions using Exclusive Monitor are rejected too.
System instructions are mostly enabled for stepping, except MSR
immediate that updates daif flags in PSTATE, which are not safe
for probing.
Thanks to Steve Capper and Pratyush Anand for several suggested
Changes.
Ok, I have some comments on the code.
[...]
diff --git a/arch/arm64/kernel/kprobes.c b/arch/arm64/kernel/kprobes.c
new file mode 100644
index 000..1ead41f
--- /dev/null
+++ b/arch/arm64/kernel/kprobes.c
@@ -0,0 +1,551 @@
+/*
+ * arch/arm64/kernel/kprobes.c
+ *
+ * Kprobes support for ARM64
+ *
+ * Copyright (C) 2013 Linaro Limited.
+ * Author: Sandeepa Prabhu sandeepa.pra...@linaro.org
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ */
+#include linux/kernel.h
+#include linux/kprobes.h
+#include linux/module.h
+#include linux/slab.h
+#include linux/stop_machine.h
+#include linux/stringify.h
+#include asm/traps.h
+#include asm/ptrace.h
+#include asm/cacheflush.h
+#include asm/debug-monitors.h
+#include asm/system_misc.h
+#include asm/insn.h
+
+#include kprobes.h
+#include kprobes-arm64.h
+
+#define MIN_STACK_SIZE(addr)min((unsigned long)MAX_STACK_SIZE,
\
+(unsigned long)current_thread_info() + THREAD_START_SP - (addr))
+
+DEFINE_PER_CPU(struct kprobe *, current_kprobe) = NULL;
+DEFINE_PER_CPU(struct kprobe_ctlblk, kprobe_ctlblk);
+
+static void __kprobes arch_prepare_ss_slot(struct kprobe *p)
+{
+/* prepare insn slot */
+p-ainsn.insn[0] = p-opcode;
+
+flush_icache_range((uintptr_t) (p-ainsn.insn),
+ (uintptr_t) (p-ainsn.insn) + MAX_INSN_SIZE);
+
+/*
+ * Needs restoring of return address after stepping xol.
+ */
+p-ainsn.restore.addr = (unsigned long) p-addr +
+ sizeof(kprobe_opcode_t);
+p-ainsn.restore.type = RESTORE_PC;
+}
+
+int
Re: + ocfs2-remove-unneeded-rc-for-kfree.patch added to -mm tree
We can only free conn-cc_private if error occurs. Otherwise it will
trigger a bug in o2cb_cluster_disconnect since conn-cc_private has
already been freed.
So please drop this patch, thanks.
On 2015/2/18 7:32, a...@linux-foundation.org wrote:
The patch titled
Subject: ocfs2: remove unneeded 'rc' for kfree()
has been added to the -mm tree. Its filename is
ocfs2-remove-unneeded-rc-for-kfree.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/ocfs2-remove-unneeded-rc-for-kfree.patch
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/ocfs2-remove-unneeded-rc-for-kfree.patch
Before you just go and hit reply, please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
--
From: Daeseok Youn daeseok.y...@gmail.com
Subject: ocfs2: remove unneeded 'rc' for kfree()
If kzalloc() failed, just goto 'out' label and 'out_free' label doesn't
need to check 'rc' variable.
Signed-off-by: Daeseok Youn daeseok.y...@gmail.com
Cc: Mark Fasheh mfas...@suse.com
Cc: Joel Becker jl...@evilplan.org
Signed-off-by: Andrew Morton a...@linux-foundation.org
---
fs/ocfs2/stack_o2cb.c |5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff -puN fs/ocfs2/stack_o2cb.c~ocfs2-remove-unneeded-rc-for-kfree
fs/ocfs2/stack_o2cb.c
--- a/fs/ocfs2/stack_o2cb.c~ocfs2-remove-unneeded-rc-for-kfree
+++ a/fs/ocfs2/stack_o2cb.c
@@ -347,7 +347,7 @@ static int o2cb_cluster_connect(struct o
priv = kzalloc(sizeof(struct o2dlm_private), GFP_KERNEL);
if (!priv) {
rc = -ENOMEM;
- goto out_free;
+ goto out;
}
/* This just fills the structure in. It is safe to pass conn. */
@@ -376,8 +376,7 @@ static int o2cb_cluster_connect(struct o
dlm_register_eviction_cb(dlm, priv-op_eviction_cb);
out_free:
- if (rc)
- kfree(conn-cc_private);
+ kfree(conn-cc_private);
out:
return rc;
_
Patches currently in -mm which might be from daeseok.y...@gmail.com are
origin.patch
ocfs2-remove-unneeded-rc-for-kfree.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 http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 0/3] powerpc: Enable seccomp filter support
Ping? On 18.02.2015 10:16, Bogdan Purcareata wrote: Add the missing pieces in order to enable SECCOMP_FILTER on PowerPC architectures, and enable this support. Testing has been pursued using libseccomp with the latest ppc support patches [1][2], on Freescale platforms for both ppc and ppc64. Support on ppc64le has also been tested, courtesy of Mike Strosaker. [1] https://groups.google.com/forum/#!topic/libseccomp/oz42LfMDsxg [2] https://groups.google.com/forum/#!topic/libseccomp/TQWfCt_nD7c v4: - rebased on top of 3.19 v3: - keep setting ENOSYS in syscall entry assembly when syscall tracing is disabled v2: - move setting ENOSYS from syscall entry assembly to do_syscall_trace_enter Bogdan Purcareata (3): powerpc: Don't force ENOSYS as error on syscall fail powerpc: Relax secure computing on syscall entry trace powerpc: Enable HAVE_ARCH_SECCOMP_FILTER arch/powerpc/Kconfig | 1 + arch/powerpc/kernel/entry_32.S | 7 ++- arch/powerpc/kernel/entry_64.S | 5 +++-- arch/powerpc/kernel/ptrace.c | 8 ++-- 4 files changed, 16 insertions(+), 5 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] ixgbe: make VLAN filter conditional
From: Hiroshi Shimamoto h-shimam...@ct.jp.nec.com
Disable hardware VLAN filtering if netdev-features VLAN flag is dropped.
In SR-IOV case, there is a use case which needs to disable VLAN filter.
For example, we need to make a network function with VF in virtualized
environment. That network function may be a software switch, a router
or etc. It means that that network function will be an end point which
terminates many VLANs.
In the current implementation, VLAN filtering always be turned on and
VF can receive only 63 VLANs. It means that only 63 VLANs can be terminated
in one NIC.
With this patch, if the user turns VLAN filtering off on the host, VF
can receive every VLAN packet.
This VLAN filtering can be turned on or off when SR-IOV is disabled, if not
the operation is rejected.
Signed-off-by: Hiroshi Shimamoto h-shimam...@ct.jp.nec.com
Reviewed-by: Hayato Momma h-mo...@ce.jp.nec.com
CC: Choi, Sy Jong sy.jong.c...@intel.com
---
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 23 +++
drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c | 4
2 files changed, 27 insertions(+)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index f690f5d..9593366 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -4081,6 +4081,10 @@ void ixgbe_set_rx_mode(struct net_device *netdev)
hw-addr_ctrl.user_set_promisc = false;
}
+ /* Disable hardware VLAN filter if the feature flag is dropped */
+ if (!(netdev-features NETIF_F_HW_VLAN_CTAG_FILTER))
+ vlnctrl = ~(IXGBE_VLNCTRL_VFE | IXGBE_VLNCTRL_CFIEN);
+
/*
* Write addresses to available RAR registers, if there is not
* sufficient space to store all the addresses then enable
@@ -7734,6 +7738,26 @@ static int ixgbe_set_features(struct net_device *netdev,
netdev_features_t changed = netdev-features ^ features;
bool need_reset = false;
+ if (changed NETIF_F_HW_VLAN_CTAG_FILTER) {
+ int vlan_filter = features NETIF_F_HW_VLAN_CTAG_FILTER;
+
+ /* Prevent controlling VLAN filter if VFs exist */
+ if (adapter-num_vfs 0) {
+ e_dev_info(%s HW VLAN filter is not allowed when
+ SR-IOV enabled.\n,
+ vlan_filter ? Enabling : Disabling);
+ return -EINVAL;
+ }
+ if (!vlan_filter) {
+ e_dev_warn(Disabling HW VLAN filter. All VFs cannot
+ set VLAN filter from VF driver.\n);
+ e_dev_warn(All VLAN packets are delivered to
+ every VF.\n);
+ }
+ /* reset if HW VLAN filter is changed */
+ need_reset = true;
+ }
+
/* Make sure RSC matches LRO, reset if change */
if (!(features NETIF_F_LRO)) {
if (adapter-flags2 IXGBE_FLAG2_RSC_ENABLED)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
index 288f39f..9ad45738 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
@@ -839,6 +839,10 @@ static int ixgbe_set_vf_vlan_msg(struct ixgbe_adapter
*adapter,
u32 bits;
u8 tcs = netdev_get_num_tc(adapter-netdev);
+ /* Ignore if VLAN filter is disabled */
+ if (!(adapter-netdev-features NETIF_F_HW_VLAN_CTAG_FILTER))
+ return 0;
+
if (adapter-vfinfo[vf].pf_vlan || tcs) {
e_warn(drv,
VF %d attempted to override administratively set VLAN
configuration\n
--
2.1.0
Re: [PATCH v2 0/2] HID: wacom: add support of Bamboo PAD
On Wed, 25 Feb 2015, Benjamin Tissoires wrote: So here is the v2 of the patch set to support the Bamboo PAD. It has been tested by Josep (thanks!) on the wired version and I developped it on the wireless version. I guess it should be good to go if the reviews goes well. Cheers, Benjamin Benjamin Tissoires (2): HID: wacom: store the hid_device pointers of the sibling devices HID: wacom: add full support of the Wacom Bamboo PAD The series is now queued in for-4.1/wacom. Thanks, -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 0/7] platform/chrome: Add user-space dev inferface support
Hello, On 02/27/2015 01:11 AM, Olof Johansson wrote: On Thu, Feb 26, 2015 at 3:35 PM, Gwendal Grignou gwen...@chromium.org wrote: Tested-by: Gwendal Grignou gwen...@chromium.org Reviewed-by: Gwendal Grignou gwen...@chromium.org Tested on a chromebook pixel with kernel 4.0.0-rc1 and ectool using the enclosed patch in chromiumos platform/ec tree. I checked the lightbar is working, check the calls with strace ectool ..., check the sysfs interface calls. Thanks Gwendal. Thanks a lot Gwendal for testing Series has been applied and pushed out to for-next now. Thanks all. Bring on the next batch. Javier! Thanks, Fengguang's build bot found a couple of issues though so I'll post the fixes for those now. -Olof Best regards, Javier -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] mm: change mm_advise_free to clear page dirty
Hello,
On Fri, Feb 27, 2015 at 11:37:18AM +0800, Wang, Yalin wrote:
This patch add ClearPageDirty() to clear AnonPage dirty flag,
the Anonpage mapcount must be 1, so that this page is only used by
the current process, not shared by other process like fork().
if not clear page dirty for this anon page, the page will never be
treated as freeable.
In case of anonymous page, it has PG_dirty when VM adds it to
swap cache and clear it in clear_page_dirty_for_io. That's why
I added ClearPageDirty if we found it in swapcache.
What case am I missing? It would be better to understand if you
describe specific scenario.
Thanks.
Signed-off-by: Yalin Wang yalin.w...@sonymobile.com
---
mm/madvise.c | 15 +--
1 file changed, 5 insertions(+), 10 deletions(-)
diff --git a/mm/madvise.c b/mm/madvise.c
index 6d0fcb8..257925a 100644
--- a/mm/madvise.c
+++ b/mm/madvise.c
@@ -297,22 +297,17 @@ static int madvise_free_pte_range(pmd_t *pmd, unsigned
long addr,
continue;
page = vm_normal_page(vma, addr, ptent);
- if (!page)
+ if (!page || !PageAnon(page) || !trylock_page(page))
continue;
if (PageSwapCache(page)) {
- if (!trylock_page(page))
+ if (!try_to_free_swap(page))
continue;
-
- if (!try_to_free_swap(page)) {
- unlock_page(page);
- continue;
- }
-
- ClearPageDirty(page);
- unlock_page(page);
}
+ if (page_mapcount(page) == 1)
+ ClearPageDirty(page);
+ unlock_page(page);
/*
* Some of architecture(ex, PPC) don't update TLB
* with set_pte_at and tlb_remove_tlb_entry so for
--
2.2.2
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majord...@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: a href=mailto:d...@kvack.org; em...@kvack.org /a
--
Kind regards,
Minchan Kim
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH] ARM64: cmpxchg.h: Clear the exclusive access bit on fail
In cmpxchg(), we do a load exclusive on an address and upon a comparison fail, we skip the store exclusive instruction. This can result in the exclusive bit still set. If there was a store exclusive after this to the same address, that will see the exclusive bit set. This should not happen. We need to clear the exclusive bit in these cases. Signed-off-by: Pranith Kumar bobby.pr...@gmail.com --- arch/arm64/include/asm/cmpxchg.h | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/arch/arm64/include/asm/cmpxchg.h b/arch/arm64/include/asm/cmpxchg.h index cb95930..ed2cf90 100644 --- a/arch/arm64/include/asm/cmpxchg.h +++ b/arch/arm64/include/asm/cmpxchg.h @@ -94,7 +94,7 @@ static inline unsigned long __cmpxchg(volatile void *ptr, unsigned long old, cmp %w1, %w3\n b.ne1f\n stxrb %w0, %w4, %2\n - 1:\n + 1: clrex\n : =r (res), =r (oldval), +Q (*(u8 *)ptr) : Ir (old), r (new) : cc); @@ -109,7 +109,7 @@ static inline unsigned long __cmpxchg(volatile void *ptr, unsigned long old, cmp %w1, %w3\n b.ne1f\n stxrh %w0, %w4, %2\n - 1:\n + 1: clrex\n : =r (res), =r (oldval), +Q (*(u16 *)ptr) : Ir (old), r (new) : cc); @@ -124,7 +124,7 @@ static inline unsigned long __cmpxchg(volatile void *ptr, unsigned long old, cmp %w1, %w3\n b.ne1f\n stxr%w0, %w4, %2\n - 1:\n + 1: clrex\n : =r (res), =r (oldval), +Q (*(u32 *)ptr) : Ir (old), r (new) : cc); @@ -139,7 +139,7 @@ static inline unsigned long __cmpxchg(volatile void *ptr, unsigned long old, cmp %1, %3\n b.ne1f\n stxr%w0, %4, %2\n - 1:\n + 1: clrex\n : =r (res), =r (oldval), +Q (*(u64 *)ptr) : Ir (old), r (new) : cc); @@ -173,7 +173,7 @@ static inline int __cmpxchg_double(volatile void *ptr1, volatile void *ptr2, mov %w0, #0\n cbnz%1, 1f\n stxp%w0, %5, %6, %2\n - 1:\n + 1: clrex\n : =r(loop), =r(lost), +Q (*(u64 *)ptr1) : r (old1), r(old2), r(new1), r(new2)); } while (loop); -- 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: linux-next: build failure after merge of the rcu tree
On Fri, Feb 27, 2015 at 01:18:56PM +1100, Stephen Rothwell wrote: Hi Paul, After merging the rcu tree, today's linux-next build (x86_64 allmodconfig) failed like this: arch/x86/xen/smp.c: In function 'xen_cpu_up': arch/x86/xen/smp.c:460:6: error: 'err' undeclared (first use in this function) if (err) ^ Caused by commit b92c23b083d6 (x86: Use common outgoing-CPU-notification code). I have used the rcu tree from next-20150226 for today. Apologies for the hassle! I have fixed this. Thanx, Paul -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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, mempolicy: migrate_to_node should only migrate to node
On Tue, Feb 24, 2015 at 03:18:06PM -0800, David Rientjes wrote: migrate_to_node() is intended to migrate a page from one source node to a target node. Today, migrate_to_node() could end up migrating to any node, not only the target node. This is because the page migration allocator, new_node_page() does not pass __GFP_THISNODE to alloc_pages_exact_node(). This causes the target node to be preferred but allows fallback to any other node in order of affinity. Prevent this by allocating with __GFP_THISNODE. If memory is not available, -ENOMEM will be returned as appropriate. Signed-off-by: David Rientjes rient...@google.com Make sense to me. Reviewed-by: Naoya Horiguchi n-horigu...@ah.jp.nec.com-- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] ARM: exynos_defconfig: Disable IOMMU support
Hello Kukjin, On 02/17/2015 12:38 PM, Javier Martinez Canillas wrote: Enabling Exynos DRM IOMMU support for Exynos is currently broken and causes a BUG on exynos-iommu driver. This was not an issue since the options was disabled in exynos_defconfig but after commit 8dcc14f82f06 (drm/exynos: IOMMU support should not be selectable by user), it is selected if EXYNOS_IOMMU is enabled which is in exynos_defconfig. So a kernel built using exynos_defconfig after the mentioned commit fails to boot [0]. Disable IOMMU support in Exynos defconfig until things get sorted out. [0]: [1.242183] [ cut here ] [1.246191] kernel BUG at drivers/iommu/exynos-iommu.c:481! [1.251747] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM [1.257561] Modules linked in: [1.260603] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 3.19.0-07478-g796e1c55717e #490 [1.268412] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) [1.274489] task: ee06c000 ti: ee05a000 task.ti: ee05a000 [1.279874] PC is at __exynos_sysmmu_enable+0x184/0x190 [1.285080] LR is at exynos_iommu_attach_device+0x44/0xb0 [1.290461] pc : [c0254a14]lr : [c0254a64]psr: 6193 [1.290461] sp : ee05bcf8 ip : fp : ed84aa40 [1.301916] r10: ed84a890 r9 : a113 r8 : 6db3 [1.307125] r7 : ed84aa40 r6 : r5 : r4 : ee174e10 [1.313635] r3 : 6db3 r2 : ed84aa40 r1 : 6db3 r0 : ee174e10 [1.320147] Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel [1.327524] Control: 10c5387d Table: 4000406a DAC: 0015 [1.333252] Process swapper/0 (pid: 1, stack limit = 0xee05a210) [1.339241] Stack: (0xee05bcf8 to 0xee05c000) [1.343581] bce0: 6db3 ee174e10 [1.351741] bd00: ed84a880 ed84aa40 ee174e10 a113 ed84a890 c0254a64 [1.359900] bd20: 6db3 ee174e10 ed84adc0 0005 0034 0001 c0692c1c [1.368059] bd40: 0097 c02526c8 ee29f050 c0017210 ee29f050 ee174e10 edab6810 c0282558 [1.376219] bd60: edab6a10 ee1cb000 0005 c0283520 ee29f240 c028f210 edab6810 ee2ef280 [1.384378] bd80: edb24680 ed84a680 ee1cb000 c02883f8 edab6810 ee1cb000 ee1cb000 [1.392537] bda0: ed84a680 ee2ef450 c027e968 ee1cb000 c0268fd4 [1.400696] bdc0: edab6800 c06b0de4 ee1cb000 c026a8bc ee2ef0c0 c028f210 0002 ee2ef460 [1.408855] bde0: ee2ef460 0002 ee2ef280 c0288728 c04af5d0 edab6810 ee2ef280 [1.417014] be00: c06b1348 c0288918 c06b0f00 c06b0f00 edab6810 0001 c06b0da0 c027eaf4 [1.425173] be20: c070334c edaee190 edab6810 ffed c06b0da0 c028da1c [1.42] be40: edab6810 c070334c c028c5f8 edab6810 c06b0da0 edab6844 [1.441492] be60: eda3c740 c028c7a4 c06b0da0 c028c718 c028af74 ee005274 ee3b7b40 [1.449652] be80: c06b0da0 ee3b7680 c06b1540 c028bde4 c05b6990 c06b0da0 c0703324 c06b0da0 [1.457811] bea0: c0703324 c069ab18 c028cdc4 c0703324 c027ebd8 [1.465970] bec0: c05b6990 c00c4574 [1.474129] bee0: c069ab18 c027eb1c c069ab18 c069ab18 c0008944 [1.482288] bf00: 0036 c04770e8 ee049800 c06eace0 ee06c000 6113 c069eab0 [1.490447] bf20: c069eab0 6113 ef7fcabc ef7fcaae c061c594 c0038640 [1.498607] bf40: c05cb1d0 c061bc24 0006 0006 c069ea50 c06724d4 0006 c06724b4 [1.506766] bf60: c06c7600 c0647588 c0692c1c 0097 c0647d40 0006 0006 [1.514925] bf80: c0647588 c003d2d8 c046921c [1.523084] bfa0: c0469224 c000e680 [1.531243] bfc0: [1.539402] bfe0: 0013 [1.547567] [c0254a14] (__exynos_sysmmu_enable) from [c0254a64] (exynos_iommu_attach_device+0x44/0xb0) [1.557199] [c0254a64] (exynos_iommu_attach_device) from [c02526c8] (iommu_attach_device+0x18/0x24) [1.566576] [c02526c8] (iommu_attach_device) from [c0017210] (arm_iommu_attach_device+0x18/0x50) [1.575690] [c0017210] (arm_iommu_attach_device) from [c0282558] (drm_iommu_attach_device+0x50/0xb4) [1.585150] [c0282558] (drm_iommu_attach_device) from [c0283520] (fimd_bind+0x94/0x1b8) [1.593483] [c0283520] (fimd_bind) from [c02883f8] (component_bind_all+0xb4/0x214) [1.601380] [c02883f8] (component_bind_all) from [c027e968] (exynos_drm_load+0x9c/0x13c) [1.609802] [c027e968] (exynos_drm_load) from [c0268fd4] (drm_dev_register+0xa0/0xf4) [1.617960] [c0268fd4]
Re: [PATCH v6 1/3] dmaengine: Add support for APM X-Gene SoC DMA engine driver
Hi On Fri, Feb 27, 2015 at 9:39 AM, Rameshwar Sahu rs...@apm.com wrote: Hi, On Thu, Feb 26, 2015 at 7:55 PM, Ben Dooks ben.do...@codethink.co.uk wrote: On 26/02/15 12:31, Rameshwar Sahu wrote: Hi Vinod, On Tue, Feb 24, 2015 at 6:23 PM, Rameshwar Prasad Sahu rs...@apm.com wrote: This patch implements the APM X-Gene SoC DMA engine driver. The APM X-Gene SoC DMA engine consists of 4 DMA channels for performing DMA operations. These DMA operations include memory copy and scatter-gather memory copy offloading. Signed-off-by: Rameshwar Prasad Sahu rs...@apm.com Signed-off-by: Loc Ho l...@apm.com --- drivers/dma/Kconfig |8 + drivers/dma/Makefile|1 + drivers/dma/xgene-dma.c | 1738 +++ 3 files changed, 1747 insertions(+) create mode 100755 drivers/dma/xgene-dma.c diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig index a874b6e..0e05831 100644 --- a/drivers/dma/Kconfig +++ b/drivers/dma/Kconfig @@ -425,6 +425,14 @@ config IMG_MDC_DMA help Enable support for the IMG multi-threaded DMA controller (MDC). +config XGENE_DMA + tristate APM X-Gene DMA support + depends on ARCH_XGENE + select DMA_ENGINE + select ASYNC_TX_ENABLE_CHANNEL_SWITCH + help + Enable support for the APM X-Gene SoC DMA engine. + config DMA_ENGINE bool diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile index f915f61..06c1576 100644 --- a/drivers/dma/Makefile +++ b/drivers/dma/Makefile @@ -51,3 +51,4 @@ obj-$(CONFIG_INTEL_MIC_X100_DMA) += mic_x100_dma.o obj-$(CONFIG_NBPFAXI_DMA) += nbpfaxi.o obj-$(CONFIG_DMA_SUN6I) += sun6i-dma.o obj-$(CONFIG_IMG_MDC_DMA) += img-mdc-dma.o +obj-$(CONFIG_XGENE_DMA) += xgene-dma.o diff --git a/drivers/dma/xgene-dma.c b/drivers/dma/xgene-dma.c new file mode 100755 index 000..e736c2e --- /dev/null +++ b/drivers/dma/xgene-dma.c @@ -0,0 +1,1738 @@ +/* + * Applied Micro X-Gene SoC DMA engine Driver + * + * Copyright (c) 2015, Applied Micro Circuits Corporation + * Authors: Rameshwar Prasad Sahu rs...@apm.com + * Loc Ho l...@apm.com + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the + * Free Software Foundation; either version 2 of the License, or (at your + * option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program. If not, see http://www.gnu.org/licenses/. + * + * NOTE: PM support is currently not available. + */ + +#include linux/clk.h +#include linux/delay.h +#include linux/dma-mapping.h +#include linux/dmaengine.h +#include linux/dmapool.h +#include linux/interrupt.h +#include linux/io.h +#include linux/module.h +#include linux/of_device.h + +#include dmaengine.h + +/* DMA ring csr registers and bit definations */ +#define DMA_RING_CONFIG0x04 +#define DMA_RING_ENABLEBIT(31) +#define DMA_RING_ID0x08 +#define DMA_RING_ID_SETUP(v) ((v) | BIT(31)) +#define DMA_RING_ID_BUF0x0C +#define DMA_RING_ID_BUF_SETUP(v) (((v) 9) | BIT(21)) +#define DMA_RING_THRESLD0_SET1 0x30 +#define DMA_RING_THRESLD0_SET1_VAL 0X64 +#define DMA_RING_THRESLD1_SET1 0x34 +#define DMA_RING_THRESLD1_SET1_VAL 0xC8 +#define DMA_RING_HYSTERESIS0x68 +#define DMA_RING_HYSTERESIS_VAL0x +#define DMA_RING_STATE 0x6C +#define DMA_RING_STATE_WR_BASE 0x70 +#define DMA_RING_NE_INT_MODE 0x017C +#define DMA_RING_NE_INT_MODE_SET(m, v) \ + ((m) = ((m) ~BIT(31 - (v))) | BIT(31 - (v))) +#define DMA_RING_NE_INT_MODE_RESET(m, v) \ + ((m) = (~BIT(31 - (v +#define DMA_RING_CLKEN 0xC208 +#define DMA_RING_SRST 0xC200 +#define DMA_RING_MEM_RAM_SHUTDOWN 0xD070 +#define DMA_RING_BLK_MEM_RDY 0xD074 +#define DMA_RING_BLK_MEM_RDY_VAL 0x +#define DMA_RING_DESC_CNT(v) (((v) 0x0001FFFE) 1) +#define DMA_RING_ID_GET(owner, num)(((owner) 6) | (num)) +#define DMA_RING_DST_ID(v) ((1 10) | (v)) +#define DMA_RING_CMD_OFFSET0x2C +#define DMA_RING_CMD_BASE_OFFSET(v)((v) 6) +#define DMA_RING_COHERENT_SET(m) (((u32 *)(m))[2] |= BIT(4)) +#define DMA_RING_ADDRL_SET(m, v) (((u32 *)(m))[2] |= (((v) 8) 5)) +#define DMA_RING_ADDRH_SET(m, v) (((u32 *)(m))[3] |= ((v) 35)) +#define DMA_RING_ACCEPTLERR_SET(m) (((u32 *)(m))[3] |= BIT(19))
Re: [ANNOUNCE] 3.18.7-rt1
Hi Sebastian
On 02/26/2015 09:48 AM, Sebastian Andrzej Siewior wrote:
* Sebastian Andrzej Siewior | 2015-02-25 14:55:01 [+0100]:
+
+static int thermal_notify_work_init(void)
+{
+ int err;
+
+ err = swork_get();
+ if (!err)
+ return err;
It think this should be:
if (err)
return err;
cheers,
daniel
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[LKP] [mm] 3484b2de949: -46.2% aim7.jobs-per-min
FYI, we noticed the below changes on git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master commit 3484b2de9499df23c4604a513b36f96326ae81ad (mm: rearrange zone fields into read-only, page alloc, statistics and page reclaim lines) The perf cpu-cycles for spinlock (zone-lock) increased a lot. I suspect there are some cache ping-pong or false sharing. testbox/testcase/testparams: brickland1/aim7/performance-6000-page_test 24b7e5819ad5cbef 3484b2de9499df23c4604a513b -- %stddev %change %stddev \ |\ 152288 ± 0% -46.2% 81911 ± 0% aim7.jobs-per-min 237 ± 0% +85.6%440 ± 0% aim7.time.elapsed_time 237 ± 0% +85.6%440 ± 0% aim7.time.elapsed_time.max 25026 ± 0% +70.7% 42712 ± 0% aim7.time.system_time 2186645 ± 5% +32.0%2885949 ± 4% aim7.time.voluntary_context_switches 4576561 ± 1% +24.9%5715773 ± 0% aim7.time.involuntary_context_switches 695 ± 0% -3.7%669 ± 1% aim7.time.user_time 5.37 ± 8%+303.5% 21.67 ± 2% perf-profile.cpu-cycles._raw_spin_lock.get_page_from_freelist.__alloc_pages_nodemask.alloc_pages_vma.handle_mm_fault 13.53 ± 18%+244.5% 46.61 ± 2% perf-profile.cpu-cycles._raw_spin_lock.free_pcppages_bulk.free_hot_cold_page.free_hot_cold_page_list.release_pages 7.88 ± 24%+495.3% 46.89 ± 3% perf-profile.cpu-cycles.free_pcppages_bulk.free_hot_cold_page.free_hot_cold_page_list.release_pages.free_pages_and_swap_cache 362 ± 14%+621.7% 2617 ± 8% numa-vmstat.node2.nr_inactive_anon 0.22 ± 38% +8387.7% 18.39 ± 4% perf-profile.cpu-cycles.get_page_from_freelist.__alloc_pages_nodemask.alloc_pages_vma.handle_mm_fault.__do_page_fault 7.99 ± 5% -98.5% 0.12 ± 27% perf-profile.cpu-cycles.do_brk.sys_brk.system_call_fastpath 12 ± 29%+352.8% 54 ± 38% sched_debug.cfs_rq[86]:/.tg_load_contrib 2 ± 40% +2133.3% 44 ± 27% sched_debug.cfs_rq[52]:/.nr_spread_over 2 ± 46% +1337.5% 38 ± 25% sched_debug.cfs_rq[87]:/.nr_spread_over 2 ± 40% +2533.3% 52 ± 14% sched_debug.cfs_rq[53]:/.nr_spread_over 3 ± 0% +1377.8% 44 ± 29% sched_debug.cfs_rq[48]:/.nr_spread_over 1 ± 28% +2620.0% 45 ± 30% sched_debug.cfs_rq[47]:/.nr_spread_over 4 ± 28% +1276.9% 59 ± 12% sched_debug.cfs_rq[117]:/.load 4 ± 28% +1276.9% 59 ± 12% sched_debug.cpu#117.load 2685 ± 19%+348.6% 12046 ± 48% sched_debug.cpu#116.ttwu_count 1 ± 28% +2240.0% 39 ± 10% sched_debug.cfs_rq[63]:/.nr_spread_over 5 ± 8%+912.5% 54 ± 24% sched_debug.cpu#65.load 2 ± 40% +1950.0% 41 ± 13% sched_debug.cfs_rq[113]:/.nr_spread_over 1508 ± 11%+581.1% 10271 ± 6% numa-meminfo.node2.Inactive(anon) 2 ± 35% +1512.5% 43 ± 21% sched_debug.cfs_rq[112]:/.nr_spread_over 5 ± 8%+912.5% 54 ± 24% sched_debug.cfs_rq[65]:/.load 6 ± 41% +2036.8%135 ± 20% sched_debug.cpu#0.load 1 ± 28% +3220.0% 55 ± 22% sched_debug.cfs_rq[66]:/.nr_spread_over 5 ± 48% +1093.3% 59 ± 23% sched_debug.cfs_rq[0]:/.nr_spread_over 0 ± 0% +Inf% 1 ± 0% sched_debug.cfs_rq[0]:/.nr_running 6 ± 41% +2036.8%135 ± 20% sched_debug.cfs_rq[0]:/.load 14 ± 37%+563.6% 97 ± 43% sched_debug.cfs_rq[0]:/.blocked_load_avg 20 ± 20%+437.7%109 ± 40% sched_debug.cfs_rq[0]:/.tg_load_contrib 5 ± 29% +1752.9%105 ± 48% sched_debug.cpu#1.load 7 ± 34%+672.7% 56 ± 7% sched_debug.cfs_rq[110]:/.blocked_load_avg 5 ± 29% +1752.9%105 ± 48% sched_debug.cfs_rq[1]:/.load 5 ± 28% +1286.7% 69 ± 32% sched_debug.cpu#2.load 1 ± 35% +2975.0% 41 ± 8% sched_debug.cfs_rq[68]:/.nr_spread_over 2 ± 20% +1685.7% 41 ± 15% sched_debug.cfs_rq[109]:/.nr_spread_over 16 ± 49%+446.0% 91 ± 32% sched_debug.cfs_rq[68]:/.tg_load_contrib 5 ± 28% +1280.0% 69 ± 33% sched_debug.cfs_rq[2]:/.load 5 ± 16%+860.0% 48 ± 35% sched_debug.cpu#3.load 8 ± 34%+428.0% 44 ± 25% sched_debug.cfs_rq[22]:/.blocked_load_avg 5 ± 31% +1912.5%107 ± 27% sched_debug.cfs_rq[39]:/.load 5 ± 31% +1912.5%107 ± 27% sched_debug.cpu#39.load 5 ± 16%+680.0% 39 ± 7% sched_debug.cfs_rq[3]:/.load 4 ± 20% +1933.3% 81 ± 14% sched_debug.cfs_rq[38]:/.load 0.00 ± 0% +7.2e+14% 7171133.21 ± 29% sched_debug.cfs_rq[38]:/.max_vruntime 0.00 ±
Re: [PATCH 0/7] kprobe: Handle error when Kprobe ftrace arming fails
Hi Petr, (2015/02/27 1:13), Petr Mladek wrote: arm_kprobe_ftrace() could fail, especially after introducing ftrace IPMODIFY flag and LifePatching. This patch set adds the error handling and also some related fixes. Hmm, I'd like to drop IPMODIFY from kprobes except for jprobes, since it actually doesn't change regs-ip which was sent before. It seems that this series partly covers that work. 1st patch includes the most important change. It helps to keep Kprobes in a sane state. 2nd and 3rd patch allows to propagate the error where needed. OK, I think the 1st one could be merged. 2nd and 3rd one still have some issues as far as I reviewed. The other patches fix problems with the global kprobes_all_disarmed flag. They were there even before but they become more visible and critical after the arming errors became propagated. Could you separate the series? And also I doubt we need to show global disable status, since we can check it via debugfs too (and looks redundant). Thank you, The first patch looks rather safe and might be suitable even for 4.0. However, I would feel more comfortable if the other patches get some testing in linux-next. I did quite some testing and did my best. But I started with the three patches and was surprised by the effect of the propagated errors. They triggered that BUG_ON() in __unregister_kprobe_top() are required the other patches to get it working. I wonder if there is any other scenario that I have missed. Of course, I also wait for feedback how to make things better. Petr Mladek (7): kprobes: Disable Kprobe when ftrace arming fails kprobes: Propagate error from arm_kprobe_ftrace() kprobes: Propagate error from disarm_kprobe_ftrace() kprobes: Keep consistent state of kprobes_all_disarmed kprobes: Do not try to disarm already disarmed Kprobe kprobes: Check kprobes_all_disarmed in kprobe_disarmed() kprobes: Mark globally disabled Kprobes in debugfs interface Documentation/kprobes.txt | 5 +- kernel/kprobes.c | 279 ++ 2 files changed, 213 insertions(+), 71 deletions(-) -- Masami HIRAMATSU Software Platform Research Dept. Linux Technology Research Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu...@hitachi.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 1/5] tty/serial: at91: correct check of buf used in DMA
Thanks Best Regards Zhao Leilei -Original Message- From: Jiri Slaby [mailto:jirisl...@gmail.com] On Behalf Of Jiri Slaby Sent: Thursday, February 26, 2015 17:30 To: Zhao, Leilei; Ferre, Nicolas; gre...@linuxfoundation.org; linux-ser...@vger.kernel.org Cc: linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org Subject: Re: [PATCH 1/5] tty/serial: at91: correct check of buf used in DMA On 02/26/2015, 07:55 AM, Leilei Zhao wrote: We only use buf of ring In DMA rx function while using buf of xmit in DMA tx function. So here we need definitively to check the buf of ring which is corresponding to DMA rx function. Signed-off-by: Leilei Zhao leilei.z...@atmel.com Acked-by: Nicolas Ferre nicolas.fe...@atmel.com --- drivers/tty/serial/atmel_serial.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c index 846552b..460903c 100644 --- a/drivers/tty/serial/atmel_serial.c +++ b/drivers/tty/serial/atmel_serial.c @@ -1027,7 +1027,7 @@ static int atmel_prepare_rx_dma(struct uart_port *port) spin_lock_init(atmel_port-lock_rx); sg_init_table(atmel_port-sg_rx, 1); /* UART circular rx buffer is an aligned page. */ - BUG_ON((int)port-state-xmit.buf ~PAGE_MASK); + BUG_ON((int)ring-buf ~PAGE_MASK); Please use PAGE_ALIGNED. This will also make the bad (int) cast to dismiss. thanks, -- js suse labs -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] lib/vsprintf: Doc improvements and clock support
Hi Stephen,
On Fri, Feb 27, 2015 at 1:02 AM, Stephen Boyd sb...@codeaurora.org wrote:
On 02/26/15 03:13, Geert Uytterhoeven wrote:
From: Geert Uytterhoeven geert+rene...@glider.be
This patch series improves the documentation for printk() formats, and
adds support for printing clocks. The latter has always been a hassle if
you wanted to support both the common and legacy clock frameworks.
Would the hassle go away if everyone moved to the common framework? I'm
Not anymore, now clk-name is gone ;-)
mostly trying to understand the justification.
As a driver writer, once in a while I need to print out names and rates for
clocks and their parents from driver debug code.
As before this involved including clk_private.h and having #ifdefs to
support both
legacy and CCF, that debug code was alwas stripped from drivers before
submission, and never went upstream.
Also, I wonder why we wouldn't want to add formats for all the other
handle based frameworks that we have nowdays (gpio, regulator, pinctrl,
etc.).
If someone feels the need to print those, support can be added.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] brcmfmac: avoid duplicated suspend/resume operation
On 2015/2/16 17:35, Arend van Spriel wrote: On 02/16/15 08:34, Fu, Zhonghui wrote: On 2015/2/15 22:54, Kalle Valo wrote: Arend van Sprielar...@broadcom.com writes: On 02/15/15 04:27, Pat Erley wrote: On 02/14/2015 08:40 PM, Fu, Zhonghui wrote: Any comments to this patch? Can it be accepted? I assume that patches are queued up until after the merge window that we are currently in. That's right. In the future I will most likely apply patches also during the merge window, but as I'm still a greenhorn I'll be on the safe and wait for the merge window to end. I am very glad to see this. Could you please tell which release candidate this patch will be likely merged into now? For which tree are you asking this? When the merge window ends and linus' tree has moved to 3.20-rc1, the wireless-drivers-next will move to that -rc1 as well and pending/accepted patches will be applied for the next kernel release. If you are asking when they will be in linus' tree than the answer is 3.21-rc1. Now if you say this patch solves a real problem for you (providing usual proof like log with stack trace) you can request it to go on the wireless-drivers tree to be fixed for 3.20. I was in Chinese new-year vacation these few days. So sorry for late response. Many thanks for your explanation first. Now that there is not 3.20 version. My understanding is that this patch will be in linus' tree 4.1-rc1, right? Thanks, Zhonghui Regards, Arend -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] 3.18.7-rt1
On 02/27/2015 07:40 AM, Daniel Wagner wrote:
Hi Sebastian
Hi Daniel,
On 02/26/2015 09:48 AM, Sebastian Andrzej Siewior wrote:
* Sebastian Andrzej Siewior | 2015-02-25 14:55:01 [+0100]:
+
+static int thermal_notify_work_init(void)
+{
+int err;
+
+err = swork_get();
+if (!err)
+return err;
It think this should be:
if (err)
return err;
Makes sense.
cheers,
daniel
Sebastian
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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 1/1] proc: introduce /proc/pid/lbr_stack
On Mon, Feb 23, 2015 at 09:44:48AM -0800, Andi Kleen wrote: On Mon, Feb 23, 2015 at 05:49:57PM +0100, Peter Zijlstra wrote: On Mon, Feb 23, 2015 at 03:43:41AM +, kan.li...@intel.com wrote: From: Kan Liang kan.li...@intel.com Haswell has a new feature that utilizes the existing Last Branch Record facility to record call chains. It has been implemented in perf. The call chains information is saved during perf event context. This patch exposes a /proc/pid/lbr_stack file that shows the saved LBR call chain information. But why? I mean, this thing is only useful if you have a concurrently running perf record that selects the LBR-stack stuff. And if you have that, you might as well look at its output instead. Why add this unconditional proc file that doesn't function on its own? perf record doesn't show where you're currently blocked. Of course it does; look at perf inject -s. http://article.gmane.org/gmane.linux.kernel/1225774 http://article.gmane.org/gmane.linux.kernel/1225775 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86, traps: maps all IDTs to fixmap area.
On 2015/2/27 2:31, Andy Lutomirski wrote:
On Thu, Feb 26, 2015 at 8:45 AM, Kees Cook keesc...@chromium.org wrote:
On Thu, Feb 26, 2015 at 7:17 AM, Andy Lutomirski l...@amacapital.net wrote:
On Wed, Feb 25, 2015 at 11:06 PM, Wang Nan wangn...@huawei.com wrote:
The reason why mapping idt_table to fixmap area should also be applied
to debug_idt_table and trace_idt_table. This patch does same thing for
all IDTs.
Signed-off-by: Wang Nan wangn...@huawei.com
---
I believe trace_idt_table and debug_idt_table should be symmetrical with
idt_table. However, Like my previous patch 'x86, traps: install gates
using IST after cpu_init()', I'm not sure whether this is a practical
fix.
It shouldn't matter, since we should never enter userspace with these
IDTs loaded.
--Andy
[patch kept below for Kees' benefit]
Is there a reason to use fixmap entries for these IDTs? Or rather, is
there a situation where these IDTs are ever visible to userspace? (The
reason to use the fixmap is to hide their true location from
userspace.)
There's also the F00F workaround, which IIRC we get for free by using
the fixmap, but that also shouldn't matter here.
What about a flaw module triggering the F00F bug in kernel space? Instead of
kernel panic, the system will hang. I think tis should be a case for which
my patch can help. However, the trigger condition is critical.
-Kees
---
arch/x86/include/asm/fixmap.h | 6 ++
arch/x86/kernel/tracepoint.c | 2 +-
arch/x86/kernel/traps.c | 13 +++--
arch/x86/xen/mmu.c| 6 ++
4 files changed, 24 insertions(+), 3 deletions(-)
diff --git a/arch/x86/include/asm/fixmap.h b/arch/x86/include/asm/fixmap.h
index f80d700..79550f4 100644
--- a/arch/x86/include/asm/fixmap.h
+++ b/arch/x86/include/asm/fixmap.h
@@ -90,6 +90,12 @@ enum fixed_addresses {
FIX_IO_APIC_BASE_END = FIX_IO_APIC_BASE_0 + MAX_IO_APICS - 1,
#endif
FIX_RO_IDT, /* Virtual mapping for read-only IDT */
+#ifdef CONFIG_X86_64
+ FIX_RO_DEBUG_IDT, /* Virtual mapping for read-only
debug_idt_table */
+#endif
+#ifdef CONFIG_TRACING
+ FIX_RO_TRACE_IDT, /* Virtual mapping for read-only
trace_idt_table */
+#endif
#ifdef CONFIG_X86_32
FIX_KMAP_BEGIN, /* reserved pte's for temporary kernel mappings */
FIX_KMAP_END = FIX_KMAP_BEGIN+(KM_TYPE_NR*NR_CPUS)-1,
diff --git a/arch/x86/kernel/tracepoint.c b/arch/x86/kernel/tracepoint.c
index 1c113db..296e130 100644
--- a/arch/x86/kernel/tracepoint.c
+++ b/arch/x86/kernel/tracepoint.c
@@ -12,7 +12,7 @@ atomic_t trace_idt_ctr = ATOMIC_INIT(0);
struct desc_ptr trace_idt_descr = { NR_VECTORS * 16 - 1,
(unsigned long) trace_idt_table };
-/* No need to be aligned, but done to keep all IDTs defined the same way.
*/
+/* Must be page-aligned because the real IDT is used in a fixmap. */
gate_desc trace_idt_table[NR_VECTORS] __page_aligned_bss;
static int trace_irq_vector_refcount;
diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
index cf7898e..6d88c37 100644
--- a/arch/x86/kernel/traps.c
+++ b/arch/x86/kernel/traps.c
@@ -67,7 +67,7 @@
#include asm/pgalloc.h
#include asm/proto.h
-/* No need to be aligned, but done to keep all IDTs defined the same way.
*/
+/* Must be page-aligned because the real IDT is used in a fixmap. */
gate_desc debug_idt_table[NR_VECTORS] __page_aligned_bss;
#else
#include asm/processor-flags.h
@@ -998,9 +998,18 @@ void __init trap_init(void)
* Set the IDT descriptor to a fixed read-only location, so that
the
* sidt instruction will not leak the location of the kernel, and
* to defend the IDT against arbitrary memory write
vulnerabilities.
-* It will be reloaded in cpu_init() */
+* It will be reloaded in cpu_init()
+*/
__set_fixmap(FIX_RO_IDT, __pa_symbol(idt_table), PAGE_KERNEL_RO);
idt_descr.address = fix_to_virt(FIX_RO_IDT);
+#ifdef CONFIG_X86_64
+ __set_fixmap(FIX_RO_DEBUG_IDT, __pa_symbol(debug_idt_table),
PAGE_KERNEL_RO);
+ debug_idt_descr.address = fix_to_virt(FIX_RO_DEBUG_IDT);
+#endif
+#ifdef CONFIG_TRACING
+ __set_fixmap(FIX_RO_TRACE_IDT, __pa_symbol(trace_idt_table),
PAGE_KERNEL_RO);
+ trace_idt_descr.address = fix_to_virt(FIX_RO_TRACE_IDT);
+#endif
/*
* Should be a barrier for any external CPU state:
diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index adca9e2..1fd4a4c 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -1984,6 +1984,12 @@ static void xen_set_fixmap(unsigned idx,
phys_addr_t phys, pgprot_t prot)
switch (idx) {
case FIX_BTMAP_END ... FIX_BTMAP_BEGIN:
case FIX_RO_IDT:
+#ifdef CONFIG_X86_64
+ case FIX_RO_DEBUG_IDT:
+#endif
+#ifdef CONFIG_TRACING
+ case FIX_RO_TRACE_IDT:
+#endif
#ifdef CONFIG_X86_32
case FIX_WP_TEST:
# ifdef
Re: [PATCH 0/5] split ET_DYN ASLR from mmap ASLR
* Kees Cook keesc...@chromium.org wrote: This separates ET_DYN ASLR from mmap ASLR, as already done on s390. The various architectures that are already randomizing mmap (arm, arm64, mips, powerpc, s390, and x86), have their various forms of arch_mmap_rnd() made available via the new CONFIG_ARCH_HAS_ELF_RANDOMIZE. For these architectures, arch_randomize_brk() is collapsed as well. This is an alternative to the solutions in: https://lkml.org/lkml/2015/2/23/442 Nice! Acked-by: Ingo Molnar mi...@kernel.org Thanks, Ingo -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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 v11 2/6] backlight: Add support Skyworks SKY81452 backlight driver
From: Gyungoh Yoo jack@skyworksinc.com
Signed-off-by: Gyungoh Yoo jack@skyworksinc.com
Acked-by: Jingoo Han jg1@samsung.com
Acked-by: Bryan Wu coolo...@gmail.com
---
Changes v11:
Renamed 'skyworks,en-channels' property to led-sources.
Changes v10:
Removed trivial get_brightness implementations
Changes v9:
Nothing
Changes v8:
Renamed property names for backlight with vendor prefix
Modified gpio-enable property to generic property for GPIO
Changes v7:
Modified licensing text to GPLv2
Changes v6:
Added new line character at the end of line of dev_err()
Changes v5:
Move sky81452-backlight.h to include/linux/platform_data
Changes v4:
Reordering header files for readability
Removed calling to backlight_device_unregister()
Removed MODULE_VERSION()
Modified license to GPLv2
Changes v3:
Modified DBG messages
Changes v2:
Added 'compatible' attribute in the driver
Added message for exception or errors
drivers/video/backlight/Kconfig | 10 +
drivers/video/backlight/Makefile | 1 +
drivers/video/backlight/sky81452-backlight.c | 353 +++
include/linux/platform_data/sky81452-backlight.h | 46 +++
4 files changed, 410 insertions(+)
create mode 100644 drivers/video/backlight/sky81452-backlight.c
create mode 100644 include/linux/platform_data/sky81452-backlight.h
diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
index efb0904..2d9923a 100644
--- a/drivers/video/backlight/Kconfig
+++ b/drivers/video/backlight/Kconfig
@@ -408,6 +408,16 @@ config BACKLIGHT_PANDORA
If you have a Pandora console, say Y to enable the
backlight driver.
+config BACKLIGHT_SKY81452
+ tristate Backlight driver for SKY81452
+ depends on BACKLIGHT_CLASS_DEVICE MFD_SKY81452
+ help
+ If you have a Skyworks SKY81452, say Y to enable the
+ backlight driver.
+
+ To compile this driver as a module, choose M here: the module will
+ be called sky81452-backlight
+
config BACKLIGHT_TPS65217
tristate TPS65217 Backlight
depends on BACKLIGHT_CLASS_DEVICE MFD_TPS65217
diff --git a/drivers/video/backlight/Makefile b/drivers/video/backlight/Makefile
index fcd50b73..d67073f 100644
--- a/drivers/video/backlight/Makefile
+++ b/drivers/video/backlight/Makefile
@@ -50,6 +50,7 @@ obj-$(CONFIG_BACKLIGHT_PANDORA) += pandora_bl.o
obj-$(CONFIG_BACKLIGHT_PCF50633) += pcf50633-backlight.o
obj-$(CONFIG_BACKLIGHT_PWM)+= pwm_bl.o
obj-$(CONFIG_BACKLIGHT_SAHARA) += kb3886_bl.o
+obj-$(CONFIG_BACKLIGHT_SKY81452) += sky81452-backlight.o
obj-$(CONFIG_BACKLIGHT_TOSA) += tosa_bl.o
obj-$(CONFIG_BACKLIGHT_TPS65217) += tps65217_bl.o
obj-$(CONFIG_BACKLIGHT_WM831X) += wm831x_bl.o
diff --git a/drivers/video/backlight/sky81452-backlight.c
b/drivers/video/backlight/sky81452-backlight.c
new file mode 100644
index 000..052fa1b
--- /dev/null
+++ b/drivers/video/backlight/sky81452-backlight.c
@@ -0,0 +1,353 @@
+/*
+ * sky81452-backlight.cSKY81452 backlight driver
+ *
+ * Copyright 2014 Skyworks Solutions Inc.
+ * Author : Gyungoh Yoo jack@skyworksinc.com
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, see http://www.gnu.org/licenses/.
+ */
+
+#include linux/backlight.h
+#include linux/err.h
+#include linux/gpio.h
+#include linux/init.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/of.h
+#include linux/of_gpio.h
+#include linux/platform_device.h
+#include linux/regmap.h
+#include linux/platform_data/sky81452-backlight.h
+#include linux/slab.h
+
+/* registers */
+#define SKY81452_REG0 0x00
+#define SKY81452_REG1 0x01
+#define SKY81452_REG2 0x02
+#define SKY81452_REG4 0x04
+#define SKY81452_REG5 0x05
+
+/* bit mask */
+#define SKY81452_CS0xFF
+#define SKY81452_EN0x3F
+#define SKY81452_IGPW 0x20
+#define SKY81452_PWMMD 0x10
+#define SKY81452_PHASE 0x08
+#define SKY81452_ILIM 0x04
+#define SKY81452_VSHRT 0x03
+#define SKY81452_OCP 0x80
+#define SKY81452_OTMP 0x40
+#define SKY81452_SHRT 0x3F
+#define SKY81452_OPN 0x3F
+
+#define SKY81452_DEFAULT_NAME lcd-backlight
+#define SKY81452_MAX_BRIGHTNESS(SKY81452_CS + 1)
+
+#define CTZ(b) __builtin_ctz(b)
+
+static int sky81452_bl_update_status(struct backlight_device *bd)
+{
+ const struct sky81452_bl_platform_data *pdata =
+ dev_get_platdata(bd-dev.parent);
+ const unsigned int
[PATCH v11 4/6] devicetree: Add new SKY81452 backlight binding
From: Gyungoh Yoo jack@skyworksinc.com
Signed-off-by: Gyungoh Yoo jack@skyworksinc.com
Acked-by: Bryan Wu coolo...@gmail.com
---
Changes v11:
Renamed 'skyworks,en-channels' property to led-sources.
Removed unused property 'skyworks,ovp-level'.
Changes v10:
Nothing
Changes v9:
Nothing
Changes v8:
Renamed property names for backlight with vendor prefix
Modified gpio-enable property to generic property for GPIO
Made up the example for backlight DT
Changes v7:
Nothing
Changes v6:
Nothing
Changes v5:
Nothing
Changes v4:
Nothing
Changes v3:
Nothing
Changes v2:
Added reg attribute for I2C slave address
.../video/backlight/sky81452-backlight.txt | 29 ++
1 file changed, 29 insertions(+)
create mode 100644
Documentation/devicetree/bindings/video/backlight/sky81452-backlight.txt
diff --git
a/Documentation/devicetree/bindings/video/backlight/sky81452-backlight.txt
b/Documentation/devicetree/bindings/video/backlight/sky81452-backlight.txt
new file mode 100644
index 000..8bf2940
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/backlight/sky81452-backlight.txt
@@ -0,0 +1,29 @@
+SKY81452-backlight bindings
+
+Required properties:
+- compatible : Must be skyworks,sky81452-backlight
+
+Optional properties:
+- name : Name of backlight device. Default is 'lcd-backlight'.
+- gpios: GPIO to use to EN pin.
+ See Documentation/devicetree/bindings/gpio/gpio.txt
+- led-sources : List of enabled channels from 0 to 5.
+ See Documentation/devicetree/bindings/leds/common.txt
+- skyworks,ignore-pwm : Ignore both PWM input
+- skyworks,dpwm-mode : Enable DPWM dimming mode, otherwise Analog dimming.
+- skyworks,phase-shift : Enable phase shift mode
+- skyworks,short-detection-threshold-volt
+ : It should be one of 4, 5, 6 and 7V.
+- skyworks,current-limit-mA
+ : It should be 2300mA or 2750mA.
+
+Example:
+
+ backlight {
+ compatible = skyworks,sky81452-backlight;
+ name = pwm-backlight;
+ led-sources = 0 1 2 5;
+ skyworks,ignore-pwm;
+ skyworks,phase-shift;
+ skyworks,current-limit-mA = 2300;
+ };
--
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 v11 5/6] devicetree: Add vendor prefix for Skyworks Solutions, Inc.
From: Gyungoh Yoo jack@skyworksinc.com Signed-off-by: Gyungoh Yoo jack@skyworksinc.com Acked-by: Lee Jones lee.jo...@linaro.org --- Changes v11: Nothing Changes v10: Nothing Changes v9: Nothing Changes v8: Nothing Changes v7: Nothing Changes v6: Nothing Changes v5: Nothing Changes v4: Nothing Changes v3: Nothing Changes v2: Added vendor prefix for Skyworks Solutions, Inc. Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 389ca13..c4fe9cc 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -165,6 +165,7 @@ sii Seiko Instruments, Inc. silergySilergy Corp. sirf SiRF Technology, Inc. sitronix Sitronix Technology Corporation +skyworks Skyworks Solutions, Inc. smsc Standard Microsystems Corporation snps Synopsys, Inc. solidrun SolidRun -- 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: [RFC] mm: change mm_advise_free to clear page dirty
On Fri, Feb 27, 2015 at 01:48:48PM +0800, Wang, Yalin wrote:
-Original Message-
From: Minchan Kim [mailto:minchan@gmail.com] On Behalf Of Minchan Kim
Sent: Friday, February 27, 2015 1:28 PM
To: Wang, Yalin
Cc: Michal Hocko; Andrew Morton; linux-kernel@vger.kernel.org; linux-
m...@kvack.org; Rik van Riel; Johannes Weiner; Mel Gorman; Shaohua Li
Subject: Re: [RFC] mm: change mm_advise_free to clear page dirty
Hello,
On Fri, Feb 27, 2015 at 11:37:18AM +0800, Wang, Yalin wrote:
This patch add ClearPageDirty() to clear AnonPage dirty flag,
the Anonpage mapcount must be 1, so that this page is only used by
the current process, not shared by other process like fork().
if not clear page dirty for this anon page, the page will never be
treated as freeable.
In case of anonymous page, it has PG_dirty when VM adds it to
swap cache and clear it in clear_page_dirty_for_io. That's why
I added ClearPageDirty if we found it in swapcache.
What case am I missing? It would be better to understand if you
describe specific scenario.
Thanks.
Signed-off-by: Yalin Wang yalin.w...@sonymobile.com
---
mm/madvise.c | 15 +--
1 file changed, 5 insertions(+), 10 deletions(-)
diff --git a/mm/madvise.c b/mm/madvise.c
index 6d0fcb8..257925a 100644
--- a/mm/madvise.c
+++ b/mm/madvise.c
@@ -297,22 +297,17 @@ static int madvise_free_pte_range(pmd_t *pmd,
unsigned long addr,
continue;
page = vm_normal_page(vma, addr, ptent);
- if (!page)
+ if (!page || !PageAnon(page) || !trylock_page(page))
continue;
if (PageSwapCache(page)) {
- if (!trylock_page(page))
+ if (!try_to_free_swap(page))
continue;
-
- if (!try_to_free_swap(page)) {
- unlock_page(page);
- continue;
- }
-
- ClearPageDirty(page);
- unlock_page(page);
}
+ if (page_mapcount(page) == 1)
+ ClearPageDirty(page);
+ unlock_page(page);
/*
* Some of architecture(ex, PPC) don't update TLB
* with set_pte_at and tlb_remove_tlb_entry so for
--
Yes, for page which is in SwapCache, it is correct,
But for anon page which is not in SwapCache, it is always
PageDirty(), so we should also clear dirty bit to make it freeable,
No. Every anon page starts from !PageDirty and it has PG_dirty
only when it's addeded into swap cache. If vm_swap_full turns on,
a page in swap cache could have PG_dirty via try_to_free_swap again.
So, Do you have concern about swapped-out pages when MADV_FREE is
called? If so, please look at my patch.
https://lkml.org/lkml/2015/2/25/43
It will zap the swapped out page. So, this is not a issue any more?
Another problem is that if an anon page is shared by more than one process,
This happened when fork(), the anon page will be copy on write,
In this case, we should not clear page dirty,
This is not correct for other process which don't call MADV_FREE syscall.
You mean we shouldn't inherit MADV_FREE attribute?
Why?
parent:
ptr1 = malloc(len);
- allocator calls mmap(len);
memset(ptr1, 'a', len);
free(ptr1);
- allocator calss madvise_free(ptr1, len);
..
..
- VM discard hinted pages
fork();
child:
ptr2 = malloc(len)
- allocator reuses the chunk allocated from parent.
so, child will see zero pages from ptr2 but he doesn't write
anything so garbage|zero page anything is okay to him.
Thanks
--
Kind regards,
Minchan Kim
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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 v11 6/6] devicetree: Add SKY81452 to the Trivial Devices list
From: Gyungoh Yoo jack@skyworksinc.com Signed-off-by: Gyungoh Yoo jack@skyworksinc.com --- Changes v11: Nothing Changes v10: Nothing Changes v9: Nothing Changes v8: Nothing Changes v7: Nothing Changes v6: Nothing Changes v5: Nothing Changes v4: Nothing Changes v3: Nothing Changes v2: Add SKY81452 to the Trivial Devices list Documentation/devicetree/bindings/i2c/trivial-devices.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/i2c/trivial-devices.txt b/Documentation/devicetree/bindings/i2c/trivial-devices.txt index aaa8325..003bd77 100644 --- a/Documentation/devicetree/bindings/i2c/trivial-devices.txt +++ b/Documentation/devicetree/bindings/i2c/trivial-devices.txt @@ -89,6 +89,7 @@ ricoh,rv5c386 I2C bus SERIAL INTERFACE REAL-TIME CLOCK IC ricoh,rv5c387a I2C bus SERIAL INTERFACE REAL-TIME CLOCK IC samsung,24ad0xd1 S524AD0XF1 (128K/256K-bit Serial EEPROM for Low Power) sii,s35390a2-wire CMOS real-time clock +skyworks,sky81452 Skyworks SKY81452: Six-Channel White LED Driver with Touch Panel Bias Supply st-micro,24c256i2c serial eeprom (24cxx) stm,m41t00 Serial Access TIMEKEEPER stm,m41t62 Serial real-time clock (RTC) with alarm -- 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] f2fs: fix max orphan inodes calculation
cp_payload is introduced for sit bitmap to support large volume, and it is just after the block of f2fs_checkpoint + nat bitmap, so the first segment should include F2FS_CP_PACKS + NR_CURSEG_TYPE + cp_payload + orphan blocks. However, current max orphan inodes calculation don't consider cp_payload, this patch fix it by reducing the number of cp_payload from total blocks of the first segment when calculate max orphan inodes. Signed-off-by: Wanpeng Li wanpeng...@linux.intel.com --- fs/f2fs/checkpoint.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c index db82e09..3c9d677 100644 --- a/fs/f2fs/checkpoint.c +++ b/fs/f2fs/checkpoint.c @@ -1109,7 +1109,7 @@ void init_ino_entry_info(struct f2fs_sb_info *sbi) * for cp pack we can have max 1020*504 orphan entries */ sbi-max_orphans = (sbi-blocks_per_seg - F2FS_CP_PACKS - - NR_CURSEG_TYPE) * F2FS_ORPHANS_PER_BLOCK; + NR_CURSEG_TYPE - __cp_payload(sbi)) * F2FS_ORPHANS_PER_BLOCK; } int __init create_checkpoint_caches(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 1/2] mm: remove GFP_THISNODE
On 02/27/2015 04:09 AM, David Rientjes wrote: On Thu, 26 Feb 2015, Vlastimil Babka wrote: to restrict an allocation to a local node, but remove GFP_TRANSHUGE and it's obscurity. Instead, we require that a caller clear __GFP_WAIT if it wants to avoid reclaim. This allows the aforementioned functions to actually reclaim as they should. It also enables any future callers that want to do __GFP_THISNODE but also __GFP_NORETRY __GFP_NOWARN to reclaim. The rule is simple: if you don't want to reclaim, then don't set __GFP_WAIT. So, I agree with the intention, but this has some subtle implications that should be mentioned/decided. The check for GFP_THISNODE in __alloc_pages_slowpath() comes earlier than the check for __GFP_WAIT. So the differences will be: 1) We will now call wake_all_kswapds(), unless __GFP_NO_KSWAPD is passed, which is only done for hugepages and some type of i915 allocation. Do we want the opportunistic attempts from slab to wake up kswapds or do we pass the flag? 2) There will be another attempt on get_page_from_freelist() with different alloc_flags than in the fast path attempt. Without __GFP_WAIT (and also, again, __GFP_KSWAPD, since your commit b104a35d32, which is another subtle check for hugepage allocations btw), it will consider the allocation atomic and add ALLOC_HARDER flag, unless __GFP_NOMEMALLOC is in __gfp_flags - it seems it's generally not. It will also clear ALLOC_CPUSET, which was the concern of b104a35d32. However, if I look at __cpuset_node_allowed(), I see that it's always true for __GFP_THISNODE, which makes me question commit b104a35d32 in light of your patch 2/2 and generally the sanity of all these flags and my career choice. Do we do either of these? gfp_exact_node() sets __GFP_THISNODE and clears __GFP_WAIT which will make the new conditional trigger immediately for NUMA configs. Oh, right. I missed the new trigger. My sanity and career is saved! Well, no... the flags are still a mess. Aren't GFP_TRANSHUGE | __GFP_THISNODE allocations still problematic after this patch and 2/2? Those do include __GFP_WAIT (unless !defrag). So with only patch 2/2 without 1/2 they would match GFP_THISNODE and bail out (not good for khugepaged at least...). With both patches they won't bail out and __GFP_NO_KSWAPD will prevent most of the stuff described above, including clearing ALLOC_CPUSET. But __cpuset_node_allowed() will allow it to allocate anywhere anyway thanks to the newly passed __GFP_THISNODE, which would be a regression of what b104a35d32 fixed... unless I'm missing something else that prevents it, which wouldn't surprise me at all. There's this outdated comment: * The __GFP_THISNODE placement logic is really handled elsewhere, * by forcibly using a zonelist starting at a specified node, and by * (in get_page_from_freelist()) refusing to consider the zones for * any node on the zonelist except the first. By the time any such * calls get to this routine, we should just shut up and say 'yes'. AFAIK the __GFP_THISNODE zonelist contains *only* zones from the single node and there's no other refusing. And I don't really see why __GFP_THISNODE should have this exception, it feels to me like well we shouldn't reach this but we are not sure, so let's play it safe. So maybe we could just remove this exception? I don't think any other user of __GFP_THISNODE | __GFP_WAIT user relies on this allowed memset violation? Existing callers of GFP_KERNEL | __GFP_THISNODE aren't impacted and net/openvswitch/flow.c is mentioned in the changelog as actually wanting GFP_NOWAIT | __GFP_THISNODE so that this early check still fails. Ugh :) Ugh indeed. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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] mm: change mm_advise_free to clear page dirty
-Original Message-
From: Minchan Kim [mailto:minchan@gmail.com] On Behalf Of Minchan Kim
Sent: Friday, February 27, 2015 2:44 PM
To: Wang, Yalin
Cc: Michal Hocko; Andrew Morton; linux-kernel@vger.kernel.org; linux-
m...@kvack.org; Rik van Riel; Johannes Weiner; Mel Gorman; Shaohua Li
Subject: Re: [RFC] mm: change mm_advise_free to clear page dirty
On Fri, Feb 27, 2015 at 01:48:48PM +0800, Wang, Yalin wrote:
-Original Message-
From: Minchan Kim [mailto:minchan@gmail.com] On Behalf Of Minchan
Kim
Sent: Friday, February 27, 2015 1:28 PM
To: Wang, Yalin
Cc: Michal Hocko; Andrew Morton; linux-kernel@vger.kernel.org; linux-
m...@kvack.org; Rik van Riel; Johannes Weiner; Mel Gorman; Shaohua Li
Subject: Re: [RFC] mm: change mm_advise_free to clear page dirty
Hello,
On Fri, Feb 27, 2015 at 11:37:18AM +0800, Wang, Yalin wrote:
This patch add ClearPageDirty() to clear AnonPage dirty flag,
the Anonpage mapcount must be 1, so that this page is only used by
the current process, not shared by other process like fork().
if not clear page dirty for this anon page, the page will never be
treated as freeable.
In case of anonymous page, it has PG_dirty when VM adds it to
swap cache and clear it in clear_page_dirty_for_io. That's why
I added ClearPageDirty if we found it in swapcache.
What case am I missing? It would be better to understand if you
describe specific scenario.
Thanks.
Signed-off-by: Yalin Wang yalin.w...@sonymobile.com
---
mm/madvise.c | 15 +--
1 file changed, 5 insertions(+), 10 deletions(-)
diff --git a/mm/madvise.c b/mm/madvise.c
index 6d0fcb8..257925a 100644
--- a/mm/madvise.c
+++ b/mm/madvise.c
@@ -297,22 +297,17 @@ static int madvise_free_pte_range(pmd_t *pmd,
unsigned long addr,
continue;
page = vm_normal_page(vma, addr, ptent);
- if (!page)
+ if (!page || !PageAnon(page) || !trylock_page(page))
continue;
if (PageSwapCache(page)) {
- if (!trylock_page(page))
+ if (!try_to_free_swap(page))
continue;
-
- if (!try_to_free_swap(page)) {
- unlock_page(page);
- continue;
- }
-
- ClearPageDirty(page);
- unlock_page(page);
}
+ if (page_mapcount(page) == 1)
+ ClearPageDirty(page);
+ unlock_page(page);
/*
* Some of architecture(ex, PPC) don't update TLB
* with set_pte_at and tlb_remove_tlb_entry so for
--
Yes, for page which is in SwapCache, it is correct,
But for anon page which is not in SwapCache, it is always
PageDirty(), so we should also clear dirty bit to make it freeable,
No. Every anon page starts from !PageDirty and it has PG_dirty
only when it's addeded into swap cache. If vm_swap_full turns on,
a page in swap cache could have PG_dirty via try_to_free_swap again.
mmm..
sometimes you can see an anon page PageDirty(), but it is not in swapcache,
for example, handle_pte_fault()--do_swap_page()--try_to_free_swap(),
at this time, the page is deleted from swapcache and is marked PageDirty(),
So, Do you have concern about swapped-out pages when MADV_FREE is
called? If so, please look at my patch.
https://lkml.org/lkml/2015/2/25/43
It will zap the swapped out page. So, this is not a issue any more?
Another problem is that if an anon page is shared by more than one
process,
This happened when fork(), the anon page will be copy on write,
In this case, we should not clear page dirty,
This is not correct for other process which don't call MADV_FREE syscall.
You mean we shouldn't inherit MADV_FREE attribute?
Why?
Is it correct behavior if code like this:
Parent:
ptr1 = malloc(len);
memset(ptr1, 'a', len);
fork();
if (I am parent)
madvise_free(ptr1, len);
child:
sleep(10);
parse_data(ptr1, len); // child may see zero, not 'a',
// is it the right behavior that the programer want?
Because child don't call madvise_free(), so it should see 'a', not zero page.
Isn't it ?
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] qla2xxx: Fix trivial typos in ql_log message
Change 'Fimware' to 'Firmware'
Change 'enalbled' to 'enabled'
Signed-off-by: Yannick Guerrini yguerr...@tomshardware.fr
---
drivers/scsi/qla2xxx/qla_init.c | 4 ++--
drivers/scsi/qla2xxx/qla_mid.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi/qla2xxx/qla_init.c b/drivers/scsi/qla2xxx/qla_init.c
index e59f25b..5bb57c5 100644
--- a/drivers/scsi/qla2xxx/qla_init.c
+++ b/drivers/scsi/qla2xxx/qla_init.c
@@ -5364,7 +5364,7 @@ qla2x00_load_risc(scsi_qla_host_t *vha, uint32_t
*srisc_addr)
blob = qla2x00_request_firmware(vha);
if (!blob) {
ql_log(ql_log_info, vha, 0x0083,
- Fimware image unavailable.\n);
+ Firmware image unavailable.\n);
ql_log(ql_log_info, vha, 0x0084,
Firmware images can be retrieved from: QLA_FW_URL .\n);
return QLA_FUNCTION_FAILED;
@@ -5467,7 +5467,7 @@ qla24xx_load_risc_blob(scsi_qla_host_t *vha, uint32_t
*srisc_addr)
blob = qla2x00_request_firmware(vha);
if (!blob) {
ql_log(ql_log_warn, vha, 0x0090,
- Fimware image unavailable.\n);
+ Firmware image unavailable.\n);
ql_log(ql_log_warn, vha, 0x0091,
Firmware images can be retrieved from:
QLA_FW_URL .\n);
diff --git a/drivers/scsi/qla2xxx/qla_mid.c b/drivers/scsi/qla2xxx/qla_mid.c
index 5c2e031..ca3804e 100644
--- a/drivers/scsi/qla2xxx/qla_mid.c
+++ b/drivers/scsi/qla2xxx/qla_mid.c
@@ -788,7 +788,7 @@ qla25xx_create_rsp_que(struct qla_hw_data *ha, uint16_t
options,
rsp-msix = ha-msix_entries[que_id + 1];
else
ql_log(ql_log_warn, base_vha, 0x00e3,
- MSIX not enalbled.\n);
+ MSIX not enabled.\n);
ha-rsp_q_map[que_id] = rsp;
rsp-rid = rid;
--
1.9.5.msysgit.0
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/2] hwrng: iproc-rng200 - Add Broadcom IPROC RNG driver
Hi Arnd,
Latency is 32 us for 32bits of data - commented inline. What delay call
do you recommend in this case?
On 15-02-26 12:15 PM, Arnd Bergmann wrote:
On Thursday 26 February 2015 11:37:20 Scott Branden wrote:
Response inline.
On 15-02-25 11:17 AM, Arnd Bergmann wrote:
On Wednesday 25 February 2015 10:16:24 Scott Branden wrote:
This adds a driver for random number generator present on Broadcom
IPROC devices.
Reviewed-by: Ray Jui r...@broadcom.com
Signed-off-by: Scott Branden sbran...@broadcom.com
The driver looks reasonable overall, I have just one question about
something that sticks out:
+while ((num_remaining 0) time_before(jiffies, idle_endtime)) {
...
+
+/* Are there any random numbers available? */
+if ((ioread32(rng_base + RNG_FIFO_COUNT_OFFSET)
+RNG_FIFO_COUNT_RNG_FIFO_COUNT_MASK) 0) {
...
+} else {
+if (!wait)
+/* Cannot wait, return immediately */
+return max - num_remaining;
+
+/* Can wait, give others chance to run */
+cpu_relax();
+}
+}
+
It looks like you do a busy-loop around cpu_relax here if asked to wait.
Is this intentional? I would normally expect either cond_resched() or
some msleep() instead.
This code was following examples of other open source drivers - bcm2835
and exynos both use cpu_relax. I'll have to look into this more to
understand.
The majority of the driver apparently use udelay(10) to wait, which is
not much better but at least consistent. The cpu_relax() call probably
gives better throughput.
I don't understand why none of the drivers actually attempts to
msleep(), but that may be because the delay is much too long.
Can you find out what the expected latency is for new data to
become available on your hardware?
RNG generates at a nominal 1 Mbps. So to generate 32 bits of data takes
approximately 32 us.
Arnd
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] coresight-stm: adding driver for CoreSight STM component
Adding Will D...
On Wed, Feb 25, 2015 at 5:32 PM, Mathieu Poirier
mathieu.poir...@linaro.org wrote:
From: Pratik Patel prat...@codeaurora.org
This driver adds support for the STM CoreSight IP block,
allowing any system compoment (HW or SW) to log and
aggregate messages via a single entity.
The STM exposes an application defined number of channels
called stimulus port. Configuration is done using entries
in sysfs and channels made available to userspace via devfs.
Signed-off-by: Pratik Patel prat...@codeaurora.org
Signed-off-by: Mathieu Poirier mathieu.poir...@linaro.org
---
Changes for v2:
- Fixed typo in struct stm_node documentation
- Added CPU_32v3 to list of architecture STM can't work with
Is this because of no strd instr only?
+#ifndef CONFIG_64BIT
+static inline void __raw_writeq(u64 val, volatile void __iomem *addr)
+{
+ asm volatile(strd %1, %0
+: +Qo (*(volatile u64 __force *)addr)
+: r (val));
+}
+#undef writeq_relaxed
+#define writeq_relaxed(v, c) __raw_writeq((__force u64) cpu_to_le64(v), c)
+#endif
We really shouldn't do private implementation here. It there really
any reason not to allow readq/writeq generically for 32-bit or just
for arm32?
Rob
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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 04/16] x86: entry_64.S: always allocate complete struct pt_regs
From: Denys Vlasenko dvlas...@redhat.com 64-bit code was using six stack slots less by not saving/restoring registers which are callee-preserved according to C ABI, and not allocating space for them. Only when syscall needed a complete struct pt_regs, the complete area was allocated and filled in. As an additional twist, on interrupt entry a slightly less truncated pt_regs trick is used, to make nested interrupt stacks easier to unwind. This proved to be a source of significant obfuscation and subtle bugs. For example, stub_fork had to pop the return address, extend the struct, save registers, and push return address back. Ugly. ia32_ptregs_common pops return address and returns via jmp insn, throwing a wrench into CPU return stack cache. This patch changes code to always allocate a complete struct pt_regs. The saving of registers is still done lazily. Partial pt_regs trick on interrupt stack is retained. Macros which manipulate struct pt_regs on stack are reworked: ALLOC_PT_GPREGS_ON_STACK allocates the structure. SAVE_C_REGS saves to it those registers which are clobbered by C code. SAVE_EXTRA_REGS saves to it all other registers. Corresponding RESTORE_* and REMOVE_PT_GPREGS_FROM_STACK macros reverse it. ia32_ptregs_common, stub_fork and friends lost their ugly dance with return pointer. LOAD_ARGS32 in ia32entry.S now uses symbolic stack offsets instead of magic numbers. error_entry and save_paranoid now use SAVE_C_REGS + SAVE_EXTRA_REGS instead of having it open-coded yet again. Patch was run-tested: 64-bit executables, 32-bit executables, strace works. Timing tests did not show measurable difference in 32-bit and 64-bit syscalls. Link: http://lkml.kernel.org/r/1423778052-21038-2-git-send-email-dvlas...@redhat.com Signed-off-by: Denys Vlasenko dvlas...@redhat.com CC: Linus Torvalds torva...@linux-foundation.org CC: Oleg Nesterov o...@redhat.com CC: Borislav Petkov b...@alien8.de CC: H. Peter Anvin h...@zytor.com CC: Andy Lutomirski l...@amacapital.net CC: Frederic Weisbecker fweis...@gmail.com CC: X86 ML x...@kernel.org CC: Alexei Starovoitov a...@plumgrid.com CC: Will Drewry w...@chromium.org CC: Kees Cook keesc...@chromium.org CC: linux-kernel@vger.kernel.org Signed-off-by: Andy Lutomirski l...@amacapital.net --- arch/x86/ia32/ia32entry.S | 47 +++ arch/x86/include/asm/calling.h | 222 - arch/x86/include/asm/irqflags.h| 4 +- arch/x86/include/uapi/asm/ptrace-abi.h | 1 - arch/x86/kernel/entry_64.S | 196 +++-- 5 files changed, 210 insertions(+), 260 deletions(-) diff --git a/arch/x86/ia32/ia32entry.S b/arch/x86/ia32/ia32entry.S index 156ebcab4ada..f4bed4971673 100644 --- a/arch/x86/ia32/ia32entry.S +++ b/arch/x86/ia32/ia32entry.S @@ -62,12 +62,12 @@ */ .macro LOAD_ARGS32 offset, _r9=0 .if \_r9 - movl \offset+16(%rsp),%r9d + movl \offset+R9(%rsp),%r9d .endif - movl \offset+40(%rsp),%ecx - movl \offset+48(%rsp),%edx - movl \offset+56(%rsp),%esi - movl \offset+64(%rsp),%edi + movl \offset+RCX(%rsp),%ecx + movl \offset+RDX(%rsp),%edx + movl \offset+RSI(%rsp),%esi + movl \offset+RDI(%rsp),%edi movl %eax,%eax /* zero extension */ .endm @@ -144,7 +144,8 @@ ENTRY(ia32_sysenter_target) CFI_REL_OFFSET rip,0 pushq_cfi %rax cld - SAVE_ARGS 0,1,0 + ALLOC_PT_GPREGS_ON_STACK + SAVE_C_REGS_EXCEPT_R891011 /* no need to do an access_ok check here because rbp has been 32bit zero extended */ ASM_STAC @@ -182,7 +183,8 @@ sysexit_from_sys_call: andl$~0x200,EFLAGS-ARGOFFSET(%rsp) movlRIP-ARGOFFSET(%rsp),%edx/* User %eip */ CFI_REGISTER rip,rdx - RESTORE_ARGS 0,24,0,0,0,0 + RESTORE_RSI_RDI + REMOVE_PT_GPREGS_FROM_STACK 3*8 xorq%r8,%r8 xorq%r9,%r9 xorq%r10,%r10 @@ -256,13 +258,13 @@ sysenter_tracesys: testl $(_TIF_WORK_SYSCALL_ENTRY ~_TIF_SYSCALL_AUDIT),TI_flags+THREAD_INFO(%rsp,RIP-ARGOFFSET) jz sysenter_auditsys #endif - SAVE_REST + SAVE_EXTRA_REGS CLEAR_RREGS movq$-ENOSYS,RAX(%rsp)/* ptrace can change this for a bad syscall */ movq%rsp,%rdi/* pt_regs - arg1 */ callsyscall_trace_enter LOAD_ARGS32 ARGOFFSET /* reload args from stack in case ptrace changed it */ - RESTORE_REST + RESTORE_EXTRA_REGS cmpq$(IA32_NR_syscalls-1),%rax ja int_ret_from_sys_call /* sysenter_tracesys has set RAX(%rsp) */ jmp sysenter_do_call @@ -304,7 +306,8 @@ ENTRY(ia32_cstar_target) * disabled irqs and here we enable it straight after entry: */ ENABLE_INTERRUPTS(CLBR_NONE) - SAVE_ARGS 8,0,0 + ALLOC_PT_GPREGS_ON_STACK 8 +
[PATCH 08/16] x86, entry: Remove int_check_syscall_exit_work
Nothing references it any more. Fixes: 96b6352c1271 x86_64, entry: Remove the syscall exit audit and schedule optimizations Reported-by: Denys Vlasenko vda.li...@googlemail.com Signed-off-by: Andy Lutomirski l...@amacapital.net --- arch/x86/kernel/entry_64.S | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S index 5fe186e12cf1..990793a811f4 100644 --- a/arch/x86/kernel/entry_64.S +++ b/arch/x86/kernel/entry_64.S @@ -431,7 +431,6 @@ int_careful: int_very_careful: TRACE_IRQS_ON ENABLE_INTERRUPTS(CLBR_NONE) -int_check_syscall_exit_work: SAVE_EXTRA_REGS /* Check for syscall exit trace */ testl $_TIF_WORK_SYSCALL_EXIT,%edx -- 2.1.0 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 16/16] x86_64, entry: Remove a bogus ret_from_fork optimization
ret_from_fork checks TIF_IA32 to determine whether pt_regs and the related state make sense for ret_from_sys_call. This is entirely the wrong check. TS_COMPAT would make a little more sense, but there's really no point in keeping this optimization at all. This fixes a return to the wrong user CS if we came from int 0x80 in a 64-bit task. Acked-by: Ingo Molnar mi...@kernel.org Signed-off-by: Andy Lutomirski l...@amacapital.net --- arch/x86/kernel/entry_64.S | 13 - 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S index 4670fcdb5150..519498d1c8ec 100644 --- a/arch/x86/kernel/entry_64.S +++ b/arch/x86/kernel/entry_64.S @@ -550,11 +550,14 @@ ENTRY(ret_from_fork) testl $3,CS(%rsp) # from kernel_thread? jz 1f - testl $_TIF_IA32, TI_flags(%rcx)# 32-bit compat task needs IRET - jnz int_ret_from_sys_call - - RESTORE_TOP_OF_STACK %rdi - jmp ret_from_sys_call # go to the SYSRET fastpath + /* +* By the time we get here, we have no idea whether our pt_regs, +* ti flags, and ti status came from the 64-bit SYSCALL fast path, +* the slow path, or one of the ia32entry paths. +* Use int_ret_from_sys_call to return, since it can safely handle +* all of the above. +*/ + jmp int_ret_from_sys_call 1: movq %rbp, %rdi -- 2.1.0 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 09/16] x86: add comments about various syscall instructions, no code changes
From: Denys Vlasenko dvlas...@redhat.com SYSCALL/SYSRET and SYSENTER/SYSEXIT have weird semantics. Moreover, they differ in 32- and 64-bit mode. What is saved? What is not? Is rsp set? Are interrupts disabled? People tend to not remember these details well enough. This patch adds comments which explain in detail what registers are modified by each of these instructions. The comments are placed immediately before corresponding entry and exit points. Signed-off-by: Denys Vlasenko dvlas...@redhat.com CC: Linus Torvalds torva...@linux-foundation.org CC: Oleg Nesterov o...@redhat.com CC: Borislav Petkov b...@alien8.de CC: H. Peter Anvin h...@zytor.com CC: Andy Lutomirski l...@amacapital.net CC: Frederic Weisbecker fweis...@gmail.com CC: X86 ML x...@kernel.org CC: Alexei Starovoitov a...@plumgrid.com CC: Will Drewry w...@chromium.org CC: Kees Cook keesc...@chromium.org CC: linux-kernel@vger.kernel.org Message-Id: 1424736744-13414-1-git-send-email-dvlas...@redhat.com Signed-off-by: Andy Lutomirski l...@amacapital.net --- arch/x86/ia32/ia32entry.S | 133 - arch/x86/kernel/entry_64.S | 32 ++- 2 files changed, 102 insertions(+), 63 deletions(-) diff --git a/arch/x86/ia32/ia32entry.S b/arch/x86/ia32/ia32entry.S index e99f8a5be2df..b5670564a1fb 100644 --- a/arch/x86/ia32/ia32entry.S +++ b/arch/x86/ia32/ia32entry.S @@ -99,22 +99,25 @@ ENDPROC(native_irq_enable_sysexit) /* * 32bit SYSENTER instruction entry. * + * SYSENTER loads ss, rsp, cs, and rip from previously programmed MSRs. + * IF and VM in rflags are cleared (IOW: interrupts are off). + * SYSENTER does not save anything on the stack, + * and does not save old rip (!!!) and rflags. + * * Arguments: - * %eaxSystem call number. - * %ebx Arg1 - * %ecx Arg2 - * %edx Arg3 - * %esi Arg4 - * %edi Arg5 - * %ebp user stack - * 0(%ebp) Arg6 - * - * Interrupts off. - * + * eax system call number + * ebx arg1 + * ecx arg2 + * edx arg3 + * esi arg4 + * edi arg5 + * ebp user stack + * 0(%ebp) arg6 + * * This is purely a fast path. For anything complicated we use the int 0x80 - * path below. Set up a complete hardware stack frame to share code + * path below. We set up a complete hardware stack frame to share code * with the int 0x80 path. - */ + */ ENTRY(ia32_sysenter_target) CFI_STARTPROC32 simple CFI_SIGNAL_FRAME @@ -128,6 +131,7 @@ ENTRY(ia32_sysenter_target) * disabled irqs, here we enable it straight after entry: */ ENABLE_INTERRUPTS(CLBR_NONE) + /* Construct iret frame (ss,rsp,rflags,cs,rip) */ movl%ebp,%ebp /* zero extension */ pushq_cfi $__USER32_DS /*CFI_REL_OFFSET ss,0*/ @@ -140,14 +144,19 @@ ENTRY(ia32_sysenter_target) pushq_cfi $__USER32_CS /*CFI_REL_OFFSET cs,0*/ movl%eax, %eax + /* Store thread_info-sysenter_return in rip stack slot */ pushq_cfi %r10 CFI_REL_OFFSET rip,0 + /* Store orig_ax */ pushq_cfi %rax + /* Construct the rest of struct pt_regs */ cld ALLOC_PT_GPREGS_ON_STACK SAVE_C_REGS_EXCEPT_R891011 - /* no need to do an access_ok check here because rbp has been - 32bit zero extended */ + /* +* no need to do an access_ok check here because rbp has been +* 32bit zero extended +*/ ASM_STAC 1: movl(%rbp),%ebp _ASM_EXTABLE(1b,ia32_badarg) @@ -184,6 +193,7 @@ sysexit_from_sys_call: movlRIP(%rsp),%edx /* User %eip */ CFI_REGISTER rip,rdx RESTORE_RSI_RDI + /* pop everything except ss,rsp,rflags slots */ REMOVE_PT_GPREGS_FROM_STACK 3*8 xorq%r8,%r8 xorq%r9,%r9 @@ -194,6 +204,10 @@ sysexit_from_sys_call: popq_cfi %rcx /* User %esp */ CFI_REGISTER rsp,rcx TRACE_IRQS_ON + /* +* 32bit SYSEXIT restores eip from edx, esp from ecx. +* cs and ss are loaded from MSRs. +*/ ENABLE_INTERRUPTS_SYSEXIT32 CFI_RESTORE_STATE @@ -274,23 +288,33 @@ ENDPROC(ia32_sysenter_target) /* * 32bit SYSCALL instruction entry. * + * 32bit SYSCALL saves rip to rcx, clears rflags.RF, then saves rflags to r11, + * then loads new ss, cs, and rip from previously programmed MSRs. + * rflags gets masked by a value from another MSR (so CLD and CLAC + * are not needed). SYSCALL does not save anything on the stack + * and does not change rsp. + * + * Note: rflags saving+masking-with-MSR happens only in Long mode + * (in legacy 32bit mode, IF, RF and VM bits are cleared and that's it). + * Don't get confused: rflags saving+masking depends on Long Mode Active bit + * (EFER.LMA=1), NOT on bitness of userspace where SYSCALL executes + * or target CS descriptor's L bit (SYSCALL does not read segment descriptors). + * * Arguments: - * %eaxSystem call number. - * %ebx
[PATCH 14/16] x86: ia32entry.S: use more understandable constant
From: Denys Vlasenko dvlas...@redhat.com The last instance of mysterious SS+8 constant is replaced by SIZEOF_PTREGS. Signed-off-by: Denys Vlasenko dvlas...@redhat.com CC: Linus Torvalds torva...@linux-foundation.org CC: Steven Rostedt rost...@goodmis.org CC: Ingo Molnar mi...@kernel.org CC: Borislav Petkov b...@alien8.de CC: H. Peter Anvin h...@zytor.com CC: Andy Lutomirski l...@amacapital.net CC: Oleg Nesterov o...@redhat.com CC: Frederic Weisbecker fweis...@gmail.com CC: Alexei Starovoitov a...@plumgrid.com CC: Will Drewry w...@chromium.org CC: Kees Cook keesc...@chromium.org CC: x...@kernel.org CC: linux-kernel@vger.kernel.org Message-Id: 1424822419-10267-1-git-send-email-dvlas...@redhat.com Signed-off-by: Andy Lutomirski l...@amacapital.net --- arch/x86/ia32/ia32entry.S | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/ia32/ia32entry.S b/arch/x86/ia32/ia32entry.S index 6dcd37256979..ed9746340363 100644 --- a/arch/x86/ia32/ia32entry.S +++ b/arch/x86/ia32/ia32entry.S @@ -536,7 +536,7 @@ ia32_ptregs_common: CFI_ENDPROC CFI_STARTPROC32 simple CFI_SIGNAL_FRAME - CFI_DEF_CFA rsp,SS+8 + CFI_DEF_CFA rsp,SIZEOF_PTREGS CFI_REL_OFFSET rax,RAX CFI_REL_OFFSET rcx,RCX CFI_REL_OFFSET rdx,RDX -- 2.1.0 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 15/16] x86: entry.S: simplify optimistic SYSRET
From: Denys Vlasenko dvlas...@redhat.com Avoid redundant load of %r11 (it is already loaded a few instructions before). Do not needlessly increment %rsp - we are going to return to userspace via SYSRET, this insn doesn't use stack for return. Changes since v1: added a comment Signed-off-by: Denys Vlasenko dvlas...@redhat.com CC: Linus Torvalds torva...@linux-foundation.org CC: Steven Rostedt rost...@goodmis.org CC: Ingo Molnar mi...@kernel.org CC: Borislav Petkov b...@alien8.de CC: H. Peter Anvin h...@zytor.com CC: Andy Lutomirski l...@amacapital.net CC: Oleg Nesterov o...@redhat.com CC: Frederic Weisbecker fweis...@gmail.com CC: Alexei Starovoitov a...@plumgrid.com CC: Will Drewry w...@chromium.org CC: Kees Cook keesc...@chromium.org CC: x...@kernel.org CC: linux-kernel@vger.kernel.org Message-Id: 1424824222-10856-1-git-send-email-dvlas...@redhat.com Signed-off-by: Andy Lutomirski l...@amacapital.net --- arch/x86/include/asm/calling.h | 3 +++ arch/x86/kernel/entry_64.S | 6 +++--- 2 files changed, 6 insertions(+), 3 deletions(-) diff --git a/arch/x86/include/asm/calling.h b/arch/x86/include/asm/calling.h index 337423590b08..f1a962ff7ddf 100644 --- a/arch/x86/include/asm/calling.h +++ b/arch/x86/include/asm/calling.h @@ -176,6 +176,9 @@ For 32-bit we have the following conventions - kernel is built with .macro RESTORE_C_REGS_EXCEPT_RCX RESTORE_C_REGS_HELPER 1,0,1,1,1 .endm + .macro RESTORE_C_REGS_EXCEPT_R11 + RESTORE_C_REGS_HELPER 1,1,0,1,1 + .endm .macro RESTORE_RSI_RDI RESTORE_C_REGS_HELPER 0,0,0,0,0 .endm diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S index 6fcf5d1e36c9..4670fcdb5150 100644 --- a/arch/x86/kernel/entry_64.S +++ b/arch/x86/kernel/entry_64.S @@ -757,9 +757,9 @@ retint_swapgs: /* return to user-space */ */ irq_return_via_sysret: CFI_REMEMBER_STATE - RESTORE_C_REGS - REMOVE_PT_GPREGS_FROM_STACK 8 - movq (RSP-RIP)(%rsp),%rsp + /* r11 is already restored (see code above) */ + RESTORE_C_REGS_EXCEPT_R11 + movq RSP(%rsp),%rsp USERGS_SYSRET64 CFI_RESTORE_STATE -- 2.1.0 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fork: report pid reservation failure properly
On Mon, 23 Feb 2015 21:17:01 +0100 Michal Hocko mho...@suse.cz wrote: ping on this one? Should I just resend (your way Andrew)? Or are there any objections to the patch as is. Were Eric's concerns all addressed? Oleg: wake up ;) Overall it looks like a pretty minor issue? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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] block: drop extra (and bogus) printk
When setting an invalid scheduler through sysfs, two log entries will be added. Also, when running 'echo foo /sys/block/DISK/queue/scheduler' the second one will includes the extra '\n': [10465.216944] elevator: type foo not found [10465.216953] elevator: switch to foo failed This patch simply drops the second printk(). Signed-off-by: Luis Henriques luis.henriq...@canonical.com --- block/elevator.c | 1 - 1 file changed, 1 deletion(-) diff --git a/block/elevator.c b/block/elevator.c index 59794d0d38e3..0ac9ea519201 100644 --- a/block/elevator.c +++ b/block/elevator.c @@ -997,7 +997,6 @@ ssize_t elv_iosched_store(struct request_queue *q, const char *name, if (!ret) return count; - printk(KERN_ERR elevator: switch to %s failed\n, name); return ret; } -- 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/
[PATCH] block: ioprio: drop useless free_uid label
This goto statement can simply be replaced by a break, and the label can be dropped. Signed-off-by: Luis Henriques luis.henriq...@canonical.com --- block/ioprio.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/block/ioprio.c b/block/ioprio.c index 42c680a17be4..cad43c832cc3 100644 --- a/block/ioprio.c +++ b/block/ioprio.c @@ -127,9 +127,8 @@ SYSCALL_DEFINE3(ioprio_set, int, which, int, who, int, ioprio) continue; ret = set_task_ioprio(p, ioprio); if (ret) - goto free_uid; + break; } while_each_thread(g, p); -free_uid: if (who) free_uid(user); break; -- 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] Fix offset2lib issue for x86*, ARM*, PowerPC and MIPS
On Thu, 26 Feb 2015 23:00:52 + Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Thu, Feb 26, 2015 at 02:38:15PM -0800, Andrew Morton wrote: diff -puN arch/arm64/Kconfig~fix-offset2lib-issue-for-x86-arm-powerpc-and-mips-fix arch/arm64/Kconfig --- a/arch/arm64/Kconfig~fix-offset2lib-issue-for-x86-arm-powerpc-and-mips-fix +++ a/arch/arm64/Kconfig @@ -1,4 +1,4 @@ -config ARM64 +qconfig ARM64 Is this a typo? yup. But the coffee's nice and strong. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 00/30] Refine PCI scan interfaces and make generic pci host bridge
On Thu, Feb 26, 2015 at 04:11:54PM +0800, Yijing Wang wrote: v3-v4: Fix the rebase issue. This did apply on v4.0-rc1, but with many whitespace complaints: Importing patch pci-pass-pci-domain-number ... stdin:29: trailing whitespace. bus = pci_scan_root_bus(NULL, stdin:44: trailing whitespace. bus = pci_scan_bus_legacy(PCI_DOMBUS(hose-index, 0), stdin:59: trailing whitespace. pbus = pci_create_root_bus(NULL, PCI_DOMBUS(domain, bus), stdin:74: trailing whitespace. bus = pci_scan_root_bus(NULL, stdin:75: trailing whitespace. PCI_DOMBUS(controller-segment, busnum), warning: squelched 15 whitespace errors warning: 20 lines add whitespace errors. done Importing patch pci-introduce ... done Importing patch pci-separate-pci_host_bridge ... stdin:50: trailing whitespace. dev_set_name(host-dev, pci%04x:%02x, host-domain, stdin:181: trailing whitespace. dev_set_name(b-dev, %04x:%02x, bridge-domain, stdin:225: trailing whitespace. warning: 3 lines add whitespace errors. I'll fix them myself this time because I want to make progress on this and I need something to do on the plane tomorrow, but please try to fix them yourself in the future. 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/
[RFC 3/3] x86, asm: Change the 32-bit sysenter code to use sp0
The ia32 sysenter code loaded the top of the kernel stack into rsp by loading kernel_stack and then adjusting it. It can be simplified to just read sp0 directly. This requires the addition of a new asm-offsets entry for sp0. Signed-off-by: Andy Lutomirski l...@amacapital.net --- arch/x86/ia32/ia32entry.S| 3 +-- arch/x86/kernel/asm-offsets_64.c | 1 + 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/x86/ia32/ia32entry.S b/arch/x86/ia32/ia32entry.S index ed9746340363..719db63b35c4 100644 --- a/arch/x86/ia32/ia32entry.S +++ b/arch/x86/ia32/ia32entry.S @@ -113,8 +113,7 @@ ENTRY(ia32_sysenter_target) CFI_DEF_CFA rsp,0 CFI_REGISTERrsp,rbp SWAPGS_UNSAFE_STACK - movqPER_CPU_VAR(kernel_stack), %rsp - addq$(KERNEL_STACK_OFFSET),%rsp + movqPER_CPU_VAR(init_tss + TSS_sp0), %rsp /* * No need to follow this irqs on/off section: the syscall * disabled irqs, here we enable it straight after entry: diff --git a/arch/x86/kernel/asm-offsets_64.c b/arch/x86/kernel/asm-offsets_64.c index fdcbb4d27c9f..5ce6f2da8763 100644 --- a/arch/x86/kernel/asm-offsets_64.c +++ b/arch/x86/kernel/asm-offsets_64.c @@ -81,6 +81,7 @@ int main(void) #undef ENTRY OFFSET(TSS_ist, tss_struct, x86_tss.ist); + OFFSET(TSS_sp0, tss_struct, x86_tss.sp0); BLANK(); DEFINE(__NR_syscall_max, sizeof(syscalls_64) - 1); -- 2.1.0 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC 2/3] x86: Switch all C consumers of kernel_stack to this_cpu_sp0
This will make modifying the semantics of kernel_stack easier.
Cc: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Cc: Boris Ostrovsky boris.ostrov...@oracle.com
Cc: Rusty Russell ru...@rustcorp.com.au
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
arch/x86/include/asm/thread_info.h | 3 +--
arch/x86/kernel/traps.c| 2 +-
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/x86/include/asm/thread_info.h
b/arch/x86/include/asm/thread_info.h
index e82e95abc92b..92549053d86d 100644
--- a/arch/x86/include/asm/thread_info.h
+++ b/arch/x86/include/asm/thread_info.h
@@ -163,8 +163,7 @@ DECLARE_PER_CPU(unsigned long, kernel_stack);
static inline struct thread_info *current_thread_info(void)
{
struct thread_info *ti;
- ti = (void *)(this_cpu_read_stable(kernel_stack) +
- KERNEL_STACK_OFFSET - THREAD_SIZE);
+ ti = (void *)(this_cpu_sp0() - THREAD_SIZE);
return ti;
}
diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
index c74f2f5652da..d287ea779728 100644
--- a/arch/x86/kernel/traps.c
+++ b/arch/x86/kernel/traps.c
@@ -174,7 +174,7 @@ void ist_begin_non_atomic(struct pt_regs *regs)
* will catch asm bugs and any attempt to use ist_preempt_enable
* from double_fault.
*/
- BUG_ON(((current_stack_pointer() ^ this_cpu_read_stable(kernel_stack))
+ BUG_ON(((current_stack_pointer() ^ (this_cpu_sp0() - 1))
~(THREAD_SIZE - 1)) != 0);
preempt_count_sub(HARDIRQ_OFFSET);
--
2.1.0
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 5/7] thermal: add trace events to the power allocator governor
On Thu, 26 Feb 2015 17:18:25 -0400 Eduardo Valentin edubez...@gmail.com wrote: Steve, On Thu, Feb 26, 2015 at 05:52:59PM -0500, Steven Rostedt wrote: On Thu, 26 Feb 2015 15:46:34 -0400 Eduardo Valentin edubez...@gmail.com wrote: I am planing to apply this series to my thermal soc tree. Do you have any concerns if I send this patch, which touches the tracing files, via my tree? Which tracing files? I am referring to: include/trace/events/thermal.h | 58 + include/trace/events/thermal_power_allocator.h | 87 ++ I know they are new files anyway, but just checking if those can go altogether via the thermal tree. The individual files in include/trace/events belong more to the maintainers of where the tracepoints are located. I just monitor them to make sure they are not too whacky ;-) Feel free to incorporate them in your tree. If you want... Acked-by: Steven Rostedt rost...@goodmis.org -- Steve -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix offset2lib issue for x86*, ARM*, PowerPC and MIPS
On Thu, Feb 26, 2015 at 4:11 PM, Kees Cook keesc...@chromium.org wrote: On Thu, Feb 26, 2015 at 4:06 PM, Andrew Morton a...@linux-foundation.org wrote: On Thu, 26 Feb 2015 15:37:37 -0800 Kees Cook keesc...@chromium.org wrote: Agh, no, please let's avoid the CONFIG addition. That is precisely how we do this. Hector mentioned in private mail that he was looking at an alternative that adds exec_base to struct mm which would avoid all this insanity. Can't we do something like: #ifndef mmap_rnd # define mmap_rnd 0 #endif Sure, and sprinkle #define mmap_rnd mmap_rnd in five arch header files where nobody thinks to look. For better or for worse, we are consolidating such things into arch/*/Kconfig. Okay, fair enough. Even with your configs (though shouldn't they be ARCH_HAS or just HAVE?) I've now stumbled over the issue that we can't put randomize_et_dyn in binfmt_elf because it conflicts with linking against compat_binfmt_elf. Instead of all this, how about we rework the existing CONFIG and just change around how s390 does this to match the other architectures and remove the ifdef in binfmt_elf.c at the same time? Let me work something up... -Kees -- Kees Cook Chrome OS Security -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH net-next] hyperv: Implement netvsc_get_channels() ethool op
This adds support for reporting the actual and maximum combined channels
count of the hv_netvsc driver via 'ethtool --show-channels'.
This required adding 'max_chn' to 'struct netvsc_device', and assigning
it 'rsscap.num_recv_que' in 'rndis_filter_device_add'. Now we can access
the combined maximum channel count via 'struct netvsc_device' in the
ethtool callback.
Signed-off-by: Andrew Schwartzmeyer and...@schwartzmeyer.com
---
drivers/net/hyperv/hyperv_net.h | 1 +
drivers/net/hyperv/netvsc_drv.c | 14 ++
drivers/net/hyperv/rndis_filter.c | 6 +-
3 files changed, 20 insertions(+), 1 deletion(-)
diff --git a/drivers/net/hyperv/hyperv_net.h b/drivers/net/hyperv/hyperv_net.h
index 384ca4f4de4a..4815843a6019 100644
--- a/drivers/net/hyperv/hyperv_net.h
+++ b/drivers/net/hyperv/hyperv_net.h
@@ -634,6 +634,7 @@ struct netvsc_device {
struct vmbus_channel *chn_table[NR_CPUS];
u32 send_table[VRSS_SEND_TAB_SIZE];
+ u32 max_chn;
u32 num_chn;
atomic_t queue_sends[NR_CPUS];
diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
index 15d82eda0baf..a06bd6614007 100644
--- a/drivers/net/hyperv/netvsc_drv.c
+++ b/drivers/net/hyperv/netvsc_drv.c
@@ -687,6 +687,19 @@ static void netvsc_get_drvinfo(struct net_device *net,
strlcpy(info-fw_version, N/A, sizeof(info-fw_version));
}
+static void netvsc_get_channels(struct net_device *net,
+ struct ethtool_channels *channel)
+{
+ struct net_device_context *net_device_ctx = netdev_priv(net);
+ struct hv_device *dev = net_device_ctx-device_ctx;
+ struct netvsc_device *nvdev = hv_get_drvdata(dev);
+
+ if (nvdev) {
+ channel-max_combined = nvdev-max_chn;
+ channel-combined_count = nvdev-num_chn;
+ }
+}
+
static int netvsc_change_mtu(struct net_device *ndev, int mtu)
{
struct net_device_context *ndevctx = netdev_priv(ndev);
@@ -760,6 +773,7 @@ static void netvsc_poll_controller(struct net_device *net)
static const struct ethtool_ops ethtool_ops = {
.get_drvinfo= netvsc_get_drvinfo,
.get_link = ethtool_op_get_link,
+ .get_channels = netvsc_get_channels,
};
static const struct net_device_ops device_ops = {
diff --git a/drivers/net/hyperv/rndis_filter.c
b/drivers/net/hyperv/rndis_filter.c
index 7816d98bdddc..ca81de04bc76 100644
--- a/drivers/net/hyperv/rndis_filter.c
+++ b/drivers/net/hyperv/rndis_filter.c
@@ -1027,6 +1027,7 @@ int rndis_filter_device_add(struct hv_device *dev,
/* Initialize the rndis device */
net_device = hv_get_drvdata(dev);
+ net_device-max_chn = 1;
net_device-num_chn = 1;
net_device-extension = rndis_device;
@@ -1094,6 +1095,7 @@ int rndis_filter_device_add(struct hv_device *dev,
if (ret || rsscap.num_recv_que 2)
goto out;
+ net_device-max_chn = rsscap.num_recv_que;
net_device-num_chn = (num_online_cpus() rsscap.num_recv_que) ?
num_online_cpus() : rsscap.num_recv_que;
if (net_device-num_chn == 1)
@@ -1140,8 +1142,10 @@ int rndis_filter_device_add(struct hv_device *dev,
ret = rndis_filter_set_rss_param(rndis_device, net_device-num_chn);
out:
- if (ret)
+ if (ret) {
+ net_device-max_chn = 1;
net_device-num_chn = 1;
+ }
return 0; /* return 0 because primary channel can be used alone */
err_dev_remv:
--
2.3.0
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH perf/core ] [BUGFIX] perf-probe: Fix get_real_path to free allocated memory in error path
(2015/02/26 23:46), Arnaldo Carvalho de Melo wrote:
Em Thu, Feb 26, 2015 at 05:25:04PM +0900, Masami Hiramatsu escreveu:
Fix get_real_path to free allocated memory when comp_dir
is used for complementing path and getting an error.
While reviewing this patch I noticed this is needed, ack?
Ah, right!
Acked-by: Masami Hiramatsu masami.hiramatsu...@hitachi.com
Thank you,
- Arnaldo
diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
index 4a93bf433344..9526cf37682e 100644
--- a/tools/perf/util/probe-event.c
+++ b/tools/perf/util/probe-event.c
@@ -533,7 +533,7 @@ static int get_real_path(const char *raw_path, const char
*comp_dir,
else {
if (access(raw_path, R_OK) == 0) {
*new_path = strdup(raw_path);
- return 0;
+ return *new_path ? 0 : -ENOMEM;
} else
return -errno;
}
--
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Research Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu...@hitachi.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/4] x86: entry.S: tidy up several suboptimal insns
On Thu, 26 Feb 2015 12:47:03 +0100 Ingo Molnar mi...@kernel.org wrote: So the main question here is not whether it's worth doing it, the question is the cost of the removal: - the change in syscall number overflow handling behavior. (We might not want the new behavior) - the increase in the syscall table size. Yep, totally agree. -- Steve -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 1/3] drivers/bus: Added Freescale Management Complex APIs
On 24.02.15 23:21, J. German Rivera wrote:
APIs to access the Management Complex (MC) hardware
module of Freescale LS2 SoCs. This patch includes
APIs to check the MC firmware version and to manipulate
DPRC objects in the MC.
Signed-off-by: J. German Rivera german.riv...@freescale.com
Signed-off-by: Stuart Yoder stuart.yo...@freescale.com
Only 2 minor nits.
[...]
+int mc_get_version(struct fsl_mc_io *mc_io, struct mc_version *mc_ver_info)
+{
+ struct mc_command cmd = { 0 };
+ int err;
+
+ /* prepare command */
+ cmd.header = mc_encode_cmd_header(DPMNG_CMDID_GET_VERSION,
+ MC_CMD_PRI_LOW, 0);
+
+ /* send command to mc*/
Either my mail client is broken or this is a copypaste error throughout
the file :).
+ err = mc_send_command(mc_io, cmd);
+ if (err)
+ return err;
+
+ /* retrieve response parameters */
+ mc_ver_info-revision = mc_dec(cmd.params[0], 0, 32);
+ mc_ver_info-major = mc_dec(cmd.params[0], 32, 32);
+ mc_ver_info-minor = mc_dec(cmd.params[1], 0, 32);
+
+ return 0;
+}
[...]
+
+struct mc_command {
+ uint64_t header;
+ uint64_t params[MC_CMD_NUM_OF_PARAMS];
+};
+
+enum mc_cmd_status {
+ MC_CMD_STATUS_OK = 0x0, /*! Completed successfully */
What is /*! supposed to be? Can't this just be /*?
+ MC_CMD_STATUS_READY = 0x1, /*! Ready to be processed */
+ MC_CMD_STATUS_AUTH_ERR = 0x3, /*! Authentication error */
+ MC_CMD_STATUS_NO_PRIVILEGE = 0x4, /*! No privilege */
+ MC_CMD_STATUS_DMA_ERR = 0x5, /*! DMA or I/O error */
+ MC_CMD_STATUS_CONFIG_ERR = 0x6, /*! Configuration error */
+ MC_CMD_STATUS_TIMEOUT = 0x7, /*! Operation timed out */
+ MC_CMD_STATUS_NO_RESOURCE = 0x8, /*! No resources */
+ MC_CMD_STATUS_NO_MEMORY = 0x9, /*! No memory available */
+ MC_CMD_STATUS_BUSY = 0xA, /*! Device is busy */
+ MC_CMD_STATUS_UNSUPPORTED_OP = 0xB, /*! Unsupported operation */
+ MC_CMD_STATUS_INVALID_STATE = 0xC /*! Invalid state */
+};
Alex
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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: brcm80211: drop unreachable else case
the if/elseif/else is exhaustive - there is no 4th case given the rssi_ctrl_mask = RADIO_2055_NBRSSI_SEL | RADIO_2055_WBRSSI_G1_SEL | RADIO_2055_WBRSSI_G2_SEL; so this unreachable else case (dead code) can be dropped. Signed-off-by: Nicholas Mc Guire hof...@osadl.org Thanks, applied to wireless-drivers-next.git. Kalle Valo -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] drm: atmel-hlcdc: remove clock polarity from crtc driver
On Wed, 25 Feb 2015 18:44:51 +0100 Nicolas Ferre nicolas.fe...@atmel.com wrote: Remove this configuration bit in crtc driver as the rising edge clock is widely used. Applied to drm-atmel-hlcdc-fixes. Thanks, Boris Signed-off-by: Boris BREZILLON boris.brezil...@free-electrons.com Signed-off-by: Nicolas Ferre nicolas.fe...@atmel.com --- drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c index 0409b907de5d..b3e3068c6ec0 100644 --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c @@ -153,7 +153,7 @@ static int atmel_hlcdc_crtc_mode_set(struct drm_crtc *c, (adj-crtc_hdisplay - 1) | ((adj-crtc_vdisplay - 1) 16)); - cfg = ATMEL_HLCDC_CLKPOL; + cfg = 0; prate = clk_get_rate(crtc-dc-hlcdc-sys_clk); mode_rate = mode-crtc_clock * 1000; -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pinctrl: at91: move lock/unlock_as_irq calls into request/release resources methods
Le 08/02/2015 19:23, Boris Brezillon a écrit :
The gpiochip_lock_as_irq call can fail and return an error, while the
irq_startup is not expected to fail (returns an unsigned int which is not
checked by irq core code).
irq_request/release_resources functions have been created to address this
problem.
Move gpiochip_lock/unlock_as_irq calls into
irq_request/release_resources functions to prevent using a gpio as an irq
if the gpiochip_lock_as_irq call failed.
Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
If it can speed up things:
Acked-by: Nicolas Ferre nicolas.fe...@atmel.com
Linus,
can we schedule this fix during the 4.0-rc phase?
Bye,
---
drivers/pinctrl/pinctrl-at91.c | 17 +++--
1 file changed, 7 insertions(+), 10 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-at91.c b/drivers/pinctrl/pinctrl-at91.c
index f4cd0b9..a481406 100644
--- a/drivers/pinctrl/pinctrl-at91.c
+++ b/drivers/pinctrl/pinctrl-at91.c
@@ -1477,28 +1477,25 @@ static void gpio_irq_ack(struct irq_data *d)
/* the interrupt is already cleared before by reading ISR */
}
-static unsigned int gpio_irq_startup(struct irq_data *d)
+static int gpio_irq_request_res(struct irq_data *d)
{
struct at91_gpio_chip *at91_gpio = irq_data_get_irq_chip_data(d);
unsignedpin = d-hwirq;
int ret;
ret = gpiochip_lock_as_irq(at91_gpio-chip, pin);
- if (ret) {
+ if (ret)
dev_err(at91_gpio-chip.dev, unable to lock pind %lu IRQ\n,
d-hwirq);
- return ret;
- }
- gpio_irq_unmask(d);
- return 0;
+
+ return ret;
}
-static void gpio_irq_shutdown(struct irq_data *d)
+static void gpio_irq_release_res(struct irq_data *d)
{
struct at91_gpio_chip *at91_gpio = irq_data_get_irq_chip_data(d);
unsignedpin = d-hwirq;
- gpio_irq_mask(d);
gpiochip_unlock_as_irq(at91_gpio-chip, pin);
}
@@ -1577,8 +1574,8 @@ void at91_pinctrl_gpio_resume(void)
static struct irq_chip gpio_irqchip = {
.name = GPIO,
.irq_ack= gpio_irq_ack,
- .irq_startup= gpio_irq_startup,
- .irq_shutdown = gpio_irq_shutdown,
+ .irq_request_resources = gpio_irq_request_res,
+ .irq_release_resources = gpio_irq_release_res,
.irq_disable= gpio_irq_mask,
.irq_mask = gpio_irq_mask,
.irq_unmask = gpio_irq_unmask,
--
Nicolas Ferre
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] regulator: wm8350: remove unused variable
On Thu, Feb 26, 2015 at 11:29 AM, Arnd Bergmann a...@arndb.de wrote:
After the only user of the variable has been removed, we get a valid gcc
warning about it:
regulator/wm8350-regulator.c:1154:17: warning: unused variable 'wm8350'
[-Wunused-variable]
The obvious fix is to remove the variable as well.
Signed-off-by: Arnd Bergmann a...@arndb.de
Fixes: 8f45acb5f9f34 (regulator: wm8350: Pass NULL data with REGULATION_OUT
and UNDER_VOLTAGE events)
Acked-by: Geert Uytterhoeven geert+rene...@glider.be
Mea culpa. Second ack on the same patch today...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/4] usb: Add Xen pvUSB protocol description
Add the definition of pvUSB protocol used between the pvUSB frontend in
a Xen domU and the pvUSB backend in a Xen driver domain (usually Dom0).
This header was originally provided by Fujitsu for Xen based on Linux
2.6.18.
Changes are:
- adapt to Linux style guide
Signed-off-by: Juergen Gross jgr...@suse.com
---
include/xen/interface/io/usbif.h | 220 +++
1 file changed, 220 insertions(+)
create mode 100644 include/xen/interface/io/usbif.h
diff --git a/include/xen/interface/io/usbif.h b/include/xen/interface/io/usbif.h
new file mode 100644
index 000..29815e2
--- /dev/null
+++ b/include/xen/interface/io/usbif.h
@@ -0,0 +1,220 @@
+/*
+ * usbif.h
+ *
+ * USB I/O interface for Xen guest OSes.
+ *
+ * Copyright (C) 2009, FUJITSU LABORATORIES LTD.
+ * Author: Noboru Iwamatsu n_iwama...@jp.fujitsu.com
+ *
+ * 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.
+ */
+
+#ifndef __XEN_PUBLIC_IO_USBIF_H__
+#define __XEN_PUBLIC_IO_USBIF_H__
+
+#include ring.h
+#include ../grant_table.h
+
+/*
+ * Feature and Parameter Negotiation
+ * =
+ * The two halves of a Xen pvUSB driver utilize nodes within the XenStore to
+ * communicate capabilities and to negotiate operating parameters. This
+ * section enumerates these nodes which reside in the respective front and
+ * backend portions of the XenStore, following the XenBus convention.
+ *
+ * Any specified default value is in effect if the corresponding XenBus node
+ * is not present in the XenStore.
+ *
+ * XenStore nodes in sections marked PRIVATE are solely for use by the
+ * driver side whose XenBus tree contains them.
+ *
+ *
+ *Backend XenBus Nodes
+ *
+ *
+ *-- Backend Device Identification (PRIVATE) --
+ *
+ * num-ports
+ * Values: unsigned [1...31]
+ *
+ * Number of ports for this (virtual) USB host connector.
+ *
+ * usb-ver
+ * Values: unsigned [1...2]
+ *
+ * USB version of this host connector: 1 = USB 1.1, 2 = USB 2.0.
+ *
+ * port/[1...31]
+ * Values: string
+ *
+ * Physical USB device connected to the given port, e.g. 3-1.5.
+ *
+ *
+ *Frontend XenBus Nodes
+ *
+ *
+ *--- Request Transport Parameters ---
+ *
+ * event-channel
+ * Values: unsigned
+ *
+ * The identifier of the Xen event channel used to signal activity
+ * in the ring buffer.
+ *
+ * urb-ring-ref
+ * Values: unsigned
+ *
+ * The Xen grant reference granting permission for the backend to map
+ * the sole page in a single page sized ring buffer. This is the ring
+ * buffer for urb requests.
+ *
+ * conn-ring-ref
+ * Values: unsigned
+ *
+ * The Xen grant reference granting permission for the backend to map
+ * the sole page in a single page sized ring buffer. This is the ring
+ * buffer for connection/disconnection requests.
+ *
+ * protocol
+ * Values: string (XEN_IO_PROTO_ABI_*)
+ * Default Value: XEN_IO_PROTO_ABI_NATIVE
+ *
+ * The machine ABI rules governing the format of all ring request and
+ * response structures.
+ *
+ */
+
+enum usb_spec_version {
+ USB_VER_UNKNOWN = 0,
+ USB_VER_USB11,
+ USB_VER_USB20,
+ USB_VER_USB30, /* not supported yet */
+};
+
+/*
+ * USB pipe in usbif_request
+ *
+ * bits 0-5 are specific bits for virtual USB driver.
+ * bits 7-31 are standard urb pipe.
+ *
+ * - port number(NEW):bits 0-4
+ * (USB_MAXCHILDREN is 31)
+ *
+ * -
Re: [PATCH 2/3 v3] x86: entry_64.S: always allocate complete struct pt_regs
On Thu, Feb 26, 2015 at 1:11 PM, Denys Vlasenko vda.li...@googlemail.com wrote: On Thu, Feb 26, 2015 at 10:55 AM, Denys Vlasenko vda.li...@googlemail.com wrote: On Wed, Feb 25, 2015 at 10:59 PM, Andy Lutomirski l...@amacapital.net wrote: In addition to my previous tests, I ran my home machine with patched kernel. Unfortunately, it works for me :( Will try on yet another machine. And voila, it does happen on another machine :) I'm debugging it right now. Looks like 64-bit syscalls just stop working at some point in new processes. That is, existing process is alive and well, but children get SEGV after fork (most likely on any syscall64 they do, not after fork per se. They eventually manage to kill themselves - not trivial when exit syscall isn't working either - by tripping on HLT insn). 32-bit syscalls (int 80) continue to work. Fork, exec, whatever you want. I have static 32-bit busybox binary and everything works there. Also, any 64-bit process which was under strace continues to work correctly, including forks and execs. This points towards some bug on fast path sysret64 code. Looking for it. audit=0 makes crashes disappear. I found the problem. If syscall_trace_enter_phase1 returns 0, I restore %rax from pt_regs-ax, but should restore it from pt_regs-orig_ax: call syscall_trace_enter_phase1 test %rax, %rax jnz tracesys_phase2 /* if needed, run the slow path */ - RESTORE_C_REGS /* else restore clobbered regs */ + RESTORE_C_REGS_EXCEPT_RAX /* else restore clobbered regs */ + movq ORIG_RAX-ARGOFFSET(%rsp),%rax jmp system_call_fastpath/* and return to the fast path */ -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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 02/10] ARM: OMAP3: Fix crypto support for HS devices
Register crypto hwmod links only if they are not disabled in DT.
If DT information is missing, enable them only for GP devices.
Before this patch crypto hwmod links were always disabled for all HS devices
and it was not possible to use omap-aes and omap-sham linux drivers.
Signed-off-by: Pali Rohár pali.ro...@gmail.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 79 +++-
1 file changed, 66 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 4e8e93c..de13a06 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -3744,29 +3744,54 @@ static struct omap_hwmod_ocp_if
*omap3xxx_hwmod_ocp_ifs[] __initdata = {
/* GP-only hwmod links */
static struct omap_hwmod_ocp_if *omap34xx_gp_hwmod_ocp_ifs[] __initdata = {
omap3xxx_l4_sec__timer12,
- omap3xxx_l4_core__sham,
- omap3xxx_l4_core__aes,
NULL
};
static struct omap_hwmod_ocp_if *omap36xx_gp_hwmod_ocp_ifs[] __initdata = {
omap3xxx_l4_sec__timer12,
- omap3xxx_l4_core__sham,
- omap3xxx_l4_core__aes,
NULL
};
static struct omap_hwmod_ocp_if *am35xx_gp_hwmod_ocp_ifs[] __initdata = {
omap3xxx_l4_sec__timer12,
- /*
-* Apparently the SHA/MD5 and AES accelerator IP blocks are
-* only present on some AM35xx chips, and no one knows which
-* ones. See
-* http://www.spinics.net/lists/arm-kernel/msg215466.html So
-* if you need these IP blocks on an AM35xx, try uncommenting
-* the following lines.
-*/
+ NULL
+};
+
+/* crypto hwmod links */
+static struct omap_hwmod_ocp_if *omap34xx_sham_hwmod_ocp_ifs[] __initdata = {
+ omap3xxx_l4_core__sham,
+ NULL
+};
+
+static struct omap_hwmod_ocp_if *omap34xx_aes_hwmod_ocp_ifs[] __initdata = {
+ omap3xxx_l4_core__aes,
+ NULL
+};
+
+static struct omap_hwmod_ocp_if *omap36xx_sham_hwmod_ocp_ifs[] __initdata = {
+ omap3xxx_l4_core__sham,
+ NULL
+};
+
+static struct omap_hwmod_ocp_if *omap36xx_aes_hwmod_ocp_ifs[] __initdata = {
+ omap3xxx_l4_core__aes,
+ NULL
+};
+
+/*
+ * Apparently the SHA/MD5 and AES accelerator IP blocks are
+ * only present on some AM35xx chips, and no one knows which
+ * ones. See
+ * http://www.spinics.net/lists/arm-kernel/msg215466.html So
+ * if you need these IP blocks on an AM35xx, try uncommenting
+ * the following lines.
+ */
+static struct omap_hwmod_ocp_if *am35xx_sham_hwmod_ocp_ifs[] __initdata = {
/* omap3xxx_l4_core__sham, */
+ NULL
+};
+
+static struct omap_hwmod_ocp_if *am35xx_aes_hwmod_ocp_ifs[] __initdata = {
/* omap3xxx_l4_core__aes, */
NULL
};
@@ -3871,7 +3896,8 @@ static struct omap_hwmod_ocp_if
*omap3xxx_dss_hwmod_ocp_ifs[] __initdata = {
int __init omap3xxx_hwmod_init(void)
{
int r;
- struct omap_hwmod_ocp_if **h = NULL, **h_gp = NULL;
+ struct omap_hwmod_ocp_if **h = NULL, **h_gp = NULL, **h_sham = NULL,
**h_aes = NULL;
+ struct device_node *bus = NULL;
unsigned int rev;
omap_hwmod_init();
@@ -3893,13 +3919,19 @@ int __init omap3xxx_hwmod_init(void)
rev == OMAP3430_REV_ES3_1 || rev == OMAP3430_REV_ES3_1_2) {
h = omap34xx_hwmod_ocp_ifs;
h_gp = omap34xx_gp_hwmod_ocp_ifs;
+ h_sham = omap34xx_sham_hwmod_ocp_ifs;
+ h_aes = omap34xx_aes_hwmod_ocp_ifs;
} else if (rev == AM35XX_REV_ES1_0 || rev == AM35XX_REV_ES1_1) {
h = am35xx_hwmod_ocp_ifs;
h_gp = am35xx_gp_hwmod_ocp_ifs;
+ h_sham = am35xx_sham_hwmod_ocp_ifs;
+ h_aes = am35xx_aes_hwmod_ocp_ifs;
} else if (rev == OMAP3630_REV_ES1_0 || rev == OMAP3630_REV_ES1_1 ||
rev == OMAP3630_REV_ES1_2) {
h = omap36xx_hwmod_ocp_ifs;
h_gp = omap36xx_gp_hwmod_ocp_ifs;
+ h_sham = omap36xx_sham_hwmod_ocp_ifs;
+ h_aes = omap36xx_aes_hwmod_ocp_ifs;
} else {
WARN(1, OMAP3 hwmod family init: unknown chip type\n);
return -EINVAL;
@@ -3916,6 +3948,27 @@ int __init omap3xxx_hwmod_init(void)
return r;
}
+ /*
+* Register crypto hwmod links only if they are not disabled in DT.
+* If DT information is missing, enable them only for GP devices.
+*/
+
+ if (of_have_populated_dt())
+ bus = of_find_node_by_name(NULL, ocp);
+
+ if (h_sham ((!bus omap_type() == OMAP2_DEVICE_TYPE_GP) ||
+ (bus of_device_is_available(of_find_node_by_name(bus,
sham) {
+ r = omap_hwmod_register_links(h_sham);
+ if (r 0)
+ return r;
+ }
+
+ if (h_aes ((!bus omap_type() == OMAP2_DEVICE_TYPE_GP) ||
+ (bus
[PATCH 03/10] crypto: omap-sham: Add support for omap3 devices
omap3 support is same as omap2, just with different IO address (specified in DT)
Signed-off-by: Pali Rohár pali.ro...@gmail.com
---
drivers/crypto/omap-sham.c |4
1 file changed, 4 insertions(+)
diff --git a/drivers/crypto/omap-sham.c b/drivers/crypto/omap-sham.c
index 3c76696..b20e374 100644
--- a/drivers/crypto/omap-sham.c
+++ b/drivers/crypto/omap-sham.c
@@ -1792,6 +1792,10 @@ static const struct of_device_id omap_sham_of_match[] = {
.data = omap_sham_pdata_omap2,
},
{
+ .compatible = ti,omap3-sham,
+ .data = omap_sham_pdata_omap2,
+ },
+ {
.compatible = ti,omap4-sham,
.data = omap_sham_pdata_omap4,
},
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 10/13] FS-Cache: Fix cancellation of in-progress operation
Cancellation of an in-progress operation needs to update the relevant counters
and start any operations that are pending waiting on this one.
Signed-off-by: David Howells dhowe...@redhat.com
---
fs/fscache/operation.c |7 +++
1 file changed, 7 insertions(+)
diff --git a/fs/fscache/operation.c b/fs/fscache/operation.c
index 9761df4fc2ab..b6bf5f399d70 100644
--- a/fs/fscache/operation.c
+++ b/fs/fscache/operation.c
@@ -365,6 +365,13 @@ int fscache_cancel_op(struct fscache_operation *op,
wake_up_bit(op-flags, FSCACHE_OP_WAITING);
ret = 0;
} else if (op-state == FSCACHE_OP_ST_IN_PROGRESS
cancel_in_progress_op) {
+ ASSERTCMP(object-n_in_progress, , 0);
+ if (test_bit(FSCACHE_OP_EXCLUSIVE, op-flags))
+ object-n_exclusive--;
+ object-n_in_progress--;
+ if (object-n_in_progress == 0)
+ fscache_start_operations(object);
+
fscache_stat(fscache_n_op_cancelled);
if (do_cancel)
do_cancel(op);
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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 00/13] FS-Cache: Fix a number of bugs that occur when the cache runs out of space
Attached are a bunch of patches that progressively fix bugs that can occur when the cache hits the hard must maintain X free space limit and starts rejecting requests. The commit ensubjected FS-Cache: Synchronise object death state change vs operation submission is the main bug I was looking for. Some of the other patches fix other bugs I found along the way and the remaining patches are changes pulled out of the bugfixes to make the bugfix commits more narrowly targeted. Note that I added some new stats: Ops: ini=836360 dfr=19 rel=836360 gc=19 The ini=N field here indicates the number of fscache_operation structs that were initialised and should match the rel=M value. CacheEv: nsp=3425 stl=0 rtr=0 cul=0 Indicates counts of certain cache backend events: nsp=N shows how many objects were rejected due to lack of space in the cache, stl=N shows how many objects were found to be stale upon reuse and thus discarded, rtr=N how many objects were retired and cul=N shows how many inactive objects were culled. These can also be found here: http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=fscache-fixes tagged with: fscache-fixes-20150226 David --- David Howells (13): FS-Cache: Count culled objects and objects rejected due to lack of space FS-Cache: Move fscache_report_unexpected_submission() to make it more available FS-Cache: When submitting an op, cancel it if the target object is dying FS-Cache: Handle a new operation submitted against a killed object FS-Cache: Synchronise object death state change vs operation submission FS-Cache: fscache_object_is_dead() has wrong logic, kill it FS-Cache: Permit fscache_cancel_op() to cancel in-progress operations too FS-Cache: Out of line fscache_operation_init() FS-Cache: Count the number of initialised operations FS-Cache: Fix cancellation of in-progress operation FS-Cache: Put an aborted initialised op so that it is accounted correctly FS-Cache: The operation cancellation method needs calling in more places FS-Cache: Retain the netfs context in the retrieval op earlier Documentation/filesystems/caching/backend-api.txt | 23 ++ Documentation/filesystems/caching/fscache.txt |7 - fs/cachefiles/internal.h |1 fs/cachefiles/namei.c | 33 ++- fs/fscache/cookie.c |8 - fs/fscache/internal.h | 12 + fs/fscache/object.c | 69 +- fs/fscache/operation.c| 254 ++--- fs/fscache/page.c | 86 --- fs/fscache/stats.c| 14 + include/linux/fscache-cache.h | 55 ++--- 11 files changed, 378 insertions(+), 184 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/8] zram: cosmetic ZRAM_ATTR_RO code formatting tweak
Signed-off-by: Sergey Senozhatsky sergey.senozhat...@gmail.com
---
drivers/block/zram/zram_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index 8e233ed..56c9e21 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -44,7 +44,7 @@ static const char *default_compressor = lzo;
static unsigned int num_devices = 1;
#define ZRAM_ATTR_RO(name) \
-static ssize_t name##_show(struct device *d, \
+static ssize_t name##_show(struct device *d, \
struct device_attribute *attr, char *b) \
{ \
struct zram *zram = dev_to_zram(d); \
--
2.3.1.167.g7f4ba4b
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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 v6 2/6] ARM: dts: Add pwm-fan node to the Odroid-U3 board
From: Kamil Debski k.deb...@samsung.com
Add pwm-fan node to the Odroid-U3 board file to enable PWM control of the
cooling fan. In addition, add the pwm label to the pwm@139D node
in the exynos4412.dtsi.
Signed-off-by: Kamil Debski k.deb...@samsung.com
Signed-off-by: Lukasz Majewski l.majew...@samsung.com
---
Changes since v1:
- added pwm label to the pwm@139D node in exynos4.dtsi
- use the pwm label in the exynos4412-odroidu3.dts
- change order or properties in the pwn-fan node, to be sorted
in alphabetical order
Changes for v5:
- Adding Signed-off-by: Lukasz Majewski l.majew...@samsung.com
- status = okay; dropped from the patch
Changes for v6:
- None
---
arch/arm/boot/dts/exynos4.dtsi| 2 +-
arch/arm/boot/dts/exynos4412-odroidu3.dts | 12
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index 690f56c..a93f5ca5 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -599,7 +599,7 @@
status = disabled;
};
- pwm@139D {
+ pwm: pwm@139D {
compatible = samsung,exynos4210-pwm;
reg = 0x139D 0x1000;
interrupts = 0 37 0, 0 38 0, 0 39 0, 0 40 0, 0 41 0;
diff --git a/arch/arm/boot/dts/exynos4412-odroidu3.dts
b/arch/arm/boot/dts/exynos4412-odroidu3.dts
index 44684e5..4c04837 100644
--- a/arch/arm/boot/dts/exynos4412-odroidu3.dts
+++ b/arch/arm/boot/dts/exynos4412-odroidu3.dts
@@ -31,6 +31,18 @@
linux,default-trigger = heartbeat;
};
};
+
+ pwm-fan {
+ compatible = pwm-fan;
+ pwms = pwm 0 1 0;
+ };
+};
+
+pwm {
+ pinctrl-0 = pwm0_out;
+ pinctrl-names = default;
+ samsung,pwm-outputs = 0;
+ status = okay;
};
usb3503 {
--
2.0.0.rc2
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.14.25-rt22 1/2] rtmutex Real-Time Linux: Fixing kernel BUG at kernel/locking/rtmutex.c:997!
On Thu, 26 Feb 2015 14:56:30 +0100 Sebastian Andrzej Siewior bige...@linutronix.de wrote: I am not sure if we want keep doing that. The only reason why we grab the lock in the first place was to check if there is a timer pending and we run on the isolated CPU. It should not matter for the other CPUs, right? So instead going further that road, what about storing base-next_timer someplace so it can be obtained via atomic_read() for the isolated CPUs? If we can pull that off and remove all rtmutex trylocks from hardirq context, I would much rather do that. This hocus pocus coding is just going to lead us down the path of the black arts. I already have a black cat, so I'm good to go. -- Steve -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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 7/8] zram: remove max_num_devices limitation
Limiting the number of zram devices to 32 (default max_num_devices value)
is confusing, let's drop it. A user with 2TB or 4TB of RAM, for example,
can request as many devices as he can handle.
Signed-off-by: Sergey Senozhatsky sergey.senozhat...@gmail.com
---
drivers/block/zram/zram_drv.c | 6 --
drivers/block/zram/zram_drv.h | 6 --
2 files changed, 12 deletions(-)
diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index 5804dda..1436970 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -1290,12 +1290,6 @@ static int __init zram_init(void)
{
int ret, dev_id;
- if (num_devices max_num_devices) {
- pr_warn(Invalid value for num_devices: %u\n,
- num_devices);
- return -EINVAL;
- }
-
ret = misc_register(zram_misc);
if (ret 0) {
pr_warn(Unable to register zram-control\n);
diff --git a/drivers/block/zram/zram_drv.h b/drivers/block/zram/zram_drv.h
index 17056e5..60d14bc 100644
--- a/drivers/block/zram/zram_drv.h
+++ b/drivers/block/zram/zram_drv.h
@@ -20,12 +20,6 @@
#include zcomp.h
-/*
- * Some arbitrary value. This is just to catch
- * invalid value for num_devices module parameter.
- */
-static const unsigned max_num_devices = 32;
-
/*-- Configurable parameters */
/*
--
2.3.1.167.g7f4ba4b
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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] x86: fix a bug introduced by allocate full pt_regs commit
If syscall_trace_enter_phase1 returns 0, code restores %rax from pt_regs-ax, but should restore it from pt_regs-orig_ax. The bug crept in because LOAD_ARGS macro was very sublty different from RESTORE_ARGS, it had only two callsites and only this one was using that difference. Signed-off-by: Denys Vlasenko dvlas...@redhat.com CC: Linus Torvalds torva...@linux-foundation.org CC: Steven Rostedt rost...@goodmis.org CC: Ingo Molnar mi...@kernel.org CC: Borislav Petkov b...@alien8.de CC: H. Peter Anvin h...@zytor.com CC: Andy Lutomirski l...@amacapital.net CC: Oleg Nesterov o...@redhat.com CC: Frederic Weisbecker fweis...@gmail.com CC: Alexei Starovoitov a...@plumgrid.com CC: Will Drewry w...@chromium.org CC: Kees Cook keesc...@chromium.org CC: x...@kernel.org CC: linux-kernel@vger.kernel.org --- arch/x86/kernel/entry_64.S | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S index da61974..519498d 100644 --- a/arch/x86/kernel/entry_64.S +++ b/arch/x86/kernel/entry_64.S @@ -316,7 +316,8 @@ tracesys: call syscall_trace_enter_phase1 test %rax, %rax jnz tracesys_phase2 /* if needed, run the slow path */ - RESTORE_C_REGS /* else restore clobbered regs */ + RESTORE_C_REGS_EXCEPT_RAX /* else restore clobbered regs */ + movq ORIG_RAX(%rsp), %rax jmp system_call_fastpath/* and return to the fast path */ tracesys_phase2: -- 1.8.1.4 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/8] zram: factor out device reset from reset_store()
Device reset currently consists of two steps:
a) holding -bd_mutex we ensure that there are no device users
(bdev-bd_openers)
b) and internal part (executed under bdev-bd_mutex and partially
under zram-init_lock) that resets the device - frees allocated
memory and returns the device back to its initial (un-init) state.
Dynamic device removal requires the same amount of work and checks.
We can reuse internal cleanup part (b) zram_reset_device(), but step (a)
is done in sysfs ATTR reset_store() handler.
Rename step (b) from zram_reset_device() to zram_reset_device_internal()
and factor out step (a) to zram_reset_device(). Both reset_store() and
dynamic device removal will use zram_reset_device().
For readability let's keep them separated.
Signed-off-by: Sergey Senozhatsky sergey.senozhat...@gmail.com
---
drivers/block/zram/zram_drv.c | 135 +-
1 file changed, 67 insertions(+), 68 deletions(-)
diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index d5e502b..92087da 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -729,48 +729,6 @@ static void zram_bio_discard(struct zram *zram, u32 index,
}
}
-static void zram_reset_device(struct zram *zram)
-{
- struct zram_meta *meta;
- struct zcomp *comp;
- u64 disksize;
-
- down_write(zram-init_lock);
-
- zram-limit_pages = 0;
-
- if (!init_done(zram)) {
- up_write(zram-init_lock);
- return;
- }
-
- meta = zram-meta;
- comp = zram-comp;
- disksize = zram-disksize;
- /*
-* Refcount will go down to 0 eventually and r/w handler
-* cannot handle further I/O so it will bail out by
-* check zram_meta_get.
-*/
- zram_meta_put(zram);
- /*
-* We want to free zram_meta in process context to avoid
-* deadlock between reclaim path and any other locks.
-*/
- wait_event(zram-io_done, atomic_read(zram-refcount) == 0);
-
- /* Reset stats */
- memset(zram-stats, 0, sizeof(zram-stats));
- zram-disksize = 0;
- zram-max_comp_streams = 1;
- set_capacity(zram-disk, 0);
-
- up_write(zram-init_lock);
- /* I/O operation under all of CPU are done so let's free */
- zram_meta_free(meta, disksize);
- zcomp_destroy(comp);
-}
-
static ssize_t disksize_store(struct device *dev,
struct device_attribute *attr, const char *buf, size_t len)
{
@@ -829,16 +787,54 @@ out_free_meta:
return err;
}
-static ssize_t reset_store(struct device *dev,
- struct device_attribute *attr, const char *buf, size_t len)
+/* internal device reset part -- cleanup allocated memory and
+ * return back to initial state */
+static void zram_reset_device_internal(struct zram *zram)
{
- int ret;
- unsigned short do_reset;
- struct zram *zram;
- struct block_device *bdev;
+ struct zram_meta *meta;
+ struct zcomp *comp;
+ u64 disksize;
- zram = dev_to_zram(dev);
- bdev = bdget_disk(zram-disk, 0);
+ down_write(zram-init_lock);
+
+ zram-limit_pages = 0;
+
+ if (!init_done(zram)) {
+ up_write(zram-init_lock);
+ return;
+ }
+
+ meta = zram-meta;
+ comp = zram-comp;
+ disksize = zram-disksize;
+ /*
+* Refcount will go down to 0 eventually and r/w handler
+* cannot handle further I/O so it will bail out by
+* check zram_meta_get.
+*/
+ zram_meta_put(zram);
+ /*
+* We want to free zram_meta in process context to avoid
+* deadlock between reclaim path and any other locks.
+*/
+ wait_event(zram-io_done, atomic_read(zram-refcount) == 0);
+
+ /* Reset stats */
+ memset(zram-stats, 0, sizeof(zram-stats));
+ zram-disksize = 0;
+ zram-max_comp_streams = 1;
+ set_capacity(zram-disk, 0);
+
+ up_write(zram-init_lock);
+ /* I/O operation under all of CPU are done so let's free */
+ zram_meta_free(meta, disksize);
+ zcomp_destroy(comp);
+}
+
+static int zram_reset_device(struct zram *zram)
+{
+ int ret = 0;
+ struct block_device *bdev = bdget_disk(zram-disk, 0);
if (!bdev)
return -ENOMEM;
@@ -850,31 +846,34 @@ static ssize_t reset_store(struct device *dev,
goto out;
}
- ret = kstrtou16(buf, 10, do_reset);
- if (ret)
- goto out;
-
- if (!do_reset) {
- ret = -EINVAL;
- goto out;
- }
-
/* Make sure all pending I/O is finished */
fsync_bdev(bdev);
- zram_reset_device(zram);
-
- mutex_unlock(bdev-bd_mutex);
- revalidate_disk(zram-disk);
- bdput(bdev);
-
- return len;
-
+ zram_reset_device_internal(zram);
out:
mutex_unlock(bdev-bd_mutex);
[PATCH 6/8] zram: allow automatic new zram device_id assignment
If no particular device_id was requested (passed -1 to zram_add()) during new
zram
device creation, generate one automatically and return it back. So,
schematically,
device creation can be done as:
dev_id = ioctl ZRAM_CTL_ADD -1
# dev_id == 1 or error code
init device zram1
dev_id = ioctl ZRAM_CTL_ADD -1
# dev_id == 2 or error code
init device zram2
...
Signed-off-by: Sergey Senozhatsky sergey.senozhat...@gmail.com
---
drivers/block/zram/zram_drv.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index 0154c2d4..5804dda 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -1090,8 +1090,15 @@ static int zram_add(int device_id)
if (!zram)
return ret;
- ret = idr_alloc(zram_index_idr, zram, device_id,
+ if (device_id 0) {
+ /* generate new device_id */
+ ret = idr_alloc(zram_index_idr, zram, 0, 0, GFP_KERNEL);
+ device_id = ret;
+ } else {
+ /* use specific device_id */
+ ret = idr_alloc(zram_index_idr, zram, device_id,
device_id + 1, GFP_KERNEL);
+ }
if (ret 0)
goto out_free_dev;
--
2.3.1.167.g7f4ba4b
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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 3/3] drivers/bus: Device driver for FSL-MC DPRC devices
On 24.02.15 23:21, J. German Rivera wrote:
A DPRC (Data Path Resource Container) is an isolation device
that contains a set of DPAA networking devices to be
assigned to an isolation domain (e.g., a virtual machine).
Signed-off-by: J. German Rivera german.riv...@freescale.com
Signed-off-by: Stuart Yoder stuart.yo...@freescale.com
---
Changes in v7:
- Create fsl_mc_io object in dprc_probe()
Changes in v6:
- Fixed new checkpatch warnings
Changes in v5:
None
Changes in v4:
- Addressed comments from Alex Graf:
* Fixed typo in comment
Changes in v3:
- Addressed comments from Kim Phillips:
* Renamed files:
drivers/bus/fsl-mc/fsl_mc_dprc.c - drivers/bus/fsl-mc/dprc-driver.c
- Addressed comments from Timur Tabi:
* Changed dprc_scan_container() to just return dprc_scan_objects()
* Changed all functions that had goto out/error when no common cleanup
was done, to just have multiple return points.
* Replaced error cleanup boolean flags with multiple exit points.
* REmoved __must_chewck from dprc_scan_*() functions
Changes in v2:
- Addressed comments from Kim Phillips:
* Fix warning in drivers/bus/fsl-mc/fsl_mc_dprc.c:173
* Fixed linker errors when MC bus driver built as module
drivers/bus/fsl-mc/Makefile | 3 +-
drivers/bus/fsl-mc/dprc-driver.c | 384
+++
drivers/bus/fsl-mc/mc-bus.c | 8 +
include/linux/fsl/mc-private.h | 10 +
4 files changed, 404 insertions(+), 1 deletion(-)
create mode 100644 drivers/bus/fsl-mc/dprc-driver.c
diff --git a/drivers/bus/fsl-mc/Makefile b/drivers/bus/fsl-mc/Makefile
index decd339..424e58e 100644
--- a/drivers/bus/fsl-mc/Makefile
+++ b/drivers/bus/fsl-mc/Makefile
@@ -10,5 +10,6 @@ obj-$(CONFIG_FSL_MC_BUS) += mc-bus-driver.o
mc-bus-driver-objs := mc-bus.o \
mc-sys.o \
dprc.o \
- dpmng.o
+ dpmng.o \
+ dprc-driver.o
diff --git a/drivers/bus/fsl-mc/dprc-driver.c
b/drivers/bus/fsl-mc/dprc-driver.c
new file mode 100644
index 000..a231d00
--- /dev/null
+++ b/drivers/bus/fsl-mc/dprc-driver.c
@@ -0,0 +1,384 @@
+/*
+ * Freescale data path resource container (DPRC) driver
+ *
+ * Copyright (C) 2014 Freescale Semiconductor, Inc.
+ * Author: German Rivera german.riv...@freescale.com
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed as is without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include linux/fsl/mc-private.h
+#include linux/fsl/mc-sys.h
+#include linux/module.h
+#include linux/slab.h
+#include dprc-cmd.h
+
+struct dprc_child_objs {
+ int child_count;
+ struct dprc_obj_desc *child_array;
+};
+
+static int __fsl_mc_device_remove_if_not_in_mc(struct device *dev, void
*data)
+{
+ int i;
+ struct dprc_child_objs *objs;
+ struct fsl_mc_device *mc_dev;
+
+ WARN_ON(!dev);
+ WARN_ON(!data);
+ mc_dev = to_fsl_mc_device(dev);
+ objs = data;
+
+ for (i = 0; i objs-child_count; i++) {
+ struct dprc_obj_desc *obj_desc = objs-child_array[i];
+
+ if (strlen(obj_desc-type) != 0
+ FSL_MC_DEVICE_MATCH(mc_dev, obj_desc))
+ break;
+ }
+
+ if (i == objs-child_count)
+ fsl_mc_device_remove(mc_dev);
+
+ return 0;
+}
+
+static int __fsl_mc_device_remove(struct device *dev, void *data)
+{
+ WARN_ON(!dev);
+ WARN_ON(data);
+ fsl_mc_device_remove(to_fsl_mc_device(dev));
+ return 0;
+}
+
+/**
+ * dprc_remove_devices - Removes devices for objects removed from a DPRC
+ *
+ * @mc_bus_dev: pointer to the fsl-mc device that represents a DPRC object
+ * @obj_desc_array: array of object descriptors for child objects currently
+ * present in the DPRC in the MC.
+ * @num_child_objects_in_mc: number of entries in obj_desc_array
+ *
+ * Synchronizes the state of the Linux bus driver with the actual state of
+ * the MC by removing devices that represent MC objects that have
+ * been dynamically removed in the physical DPRC.
+ */
+static void dprc_remove_devices(struct fsl_mc_device *mc_bus_dev,
+ struct dprc_obj_desc *obj_desc_array,
+ int num_child_objects_in_mc)
+{
+ if (num_child_objects_in_mc != 0) {
+ /*
+ * Remove child objects that are in the DPRC in Linux,
+ * but not in the MC:
+ */
+ struct dprc_child_objs objs;
+
+ objs.child_count = num_child_objects_in_mc;
+ objs.child_array = obj_desc_array;
+ device_for_each_child(mc_bus_dev-dev, objs,
+ __fsl_mc_device_remove_if_not_in_mc);
+ } else {
+ /*
+ * There are no child objects for this
Re: [PATCH v6 6/6] hwmon: pwm-fan: Code for using PWM FAN as a cooling device
On 02/26/2015 05:59 AM, Lukasz Majewski wrote:
The PWM FAN device can now be used as a thermal cooling device. Necessary
infrastructure has been added in this commit.
Signed-off-by: Lukasz Majewski l.majew...@samsung.com
Acked-by: Eduardo Valentin edubez...@gmail.com
---
Changes for v2:
- Replace pwm_fan_cooling_states with pwm_fan_cooling_levels
- Update ctx-pwm_fan_state when correct data from device tree is available
- Using therma_cdev_update() when thermal is ready for controlling the fan
Changes for v3:
- Rename patch heading
- pwm_fan_of_get_cooling_data() now returns -EINVAL when no cooling-levels
property defined
- register of cooling device only when proper cooling data is present
Changes for v4:
- None
Changes for v5:
- Check for IS_ENABLED(CONFIG_THERMAL) has been added to prevent from
executing thermal_* specific functions
Changes for v6:
- Adding missing ctx == NULL check in pwm_fan_get_max_state()
- Call to thermal_cooling_device_unregister(ctx-cdev); at pwm_fan_remove()
- struct thermal_cooling_device *cdev; added to struct pwm_fan_ctx
---
drivers/hwmon/pwm-fan.c | 89 -
1 file changed, 88 insertions(+), 1 deletion(-)
[ ... ]
@@ -200,6 +286,7 @@ static int pwm_fan_remove(struct platform_device *pdev)
{
struct pwm_fan_ctx *ctx = platform_get_drvdata(pdev);
+ thermal_cooling_device_unregister(ctx-cdev);
Unfortunately there is still no prototype for this if CONFIG_THERMAL
is not configured.
Two options: Yet another revision, or wait a week until the prototypes
are (hopefully) available and submit a patch without the conditionals.
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/
[PATCH 2/7] kprobes: Propagate error from arm_kprobe_ftrace()
arm_kprobe_ftrace() could fail, especially after introducing ftrace IPMODIFY
flag and LifePatching.
registry_kprobe() and registry_aggr_kprobe() do not mind about the error
because the kprobe gets disabled and they keep it registered.
But enable_kprobe() should propagate the error because its tasks
fails if ftrace fails.
Also arm_all_kprobes() should return error if it happens. The behavior
is a bit questionable here. This patch keeps the existing behavior and does
the best effort. It tries to enable as many Kprobes as possible. It returns
only the last error code if any. kprobes_all_disarmed is always cleared and
the message about finished action is always printed. There is going to be
a separate patch that will improve the behavior.
Signed-off-by: Petr Mladek pmla...@suse.cz
---
kernel/kprobes.c | 47 ---
1 file changed, 32 insertions(+), 15 deletions(-)
diff --git a/kernel/kprobes.c b/kernel/kprobes.c
index d1b9db690b9c..a69d23add983 100644
--- a/kernel/kprobes.c
+++ b/kernel/kprobes.c
@@ -929,7 +929,7 @@ static int prepare_kprobe(struct kprobe *p)
}
/* Caller must lock kprobe_mutex */
-static void arm_kprobe_ftrace(struct kprobe *p)
+static int arm_kprobe_ftrace(struct kprobe *p)
{
struct kprobe *kp;
int ret;
@@ -949,7 +949,7 @@ static void arm_kprobe_ftrace(struct kprobe *p)
goto err_function;
}
kprobe_ftrace_enabled++;
- return;
+ return ret;
err_function:
ftrace_set_filter_ip(kprobe_ftrace_ops, (unsigned long)p-addr, 1, 0);
@@ -958,6 +958,7 @@ err_filter:
if (kprobe_aggrprobe(p))
list_for_each_entry_rcu(kp, p-list, list)
kp-flags |= KPROBE_FLAG_DISABLED;
+ return ret;
}
/* Caller must lock kprobe_mutex */
@@ -976,17 +977,15 @@ static void disarm_kprobe_ftrace(struct kprobe *p)
}
#else /* !CONFIG_KPROBES_ON_FTRACE */
#define prepare_kprobe(p) arch_prepare_kprobe(p)
-#define arm_kprobe_ftrace(p) do {} while (0)
+#define arm_kprobe_ftrace(p) (0)
#define disarm_kprobe_ftrace(p)do {} while (0)
#endif
/* Arm a kprobe with text_mutex */
-static void arm_kprobe(struct kprobe *kp)
+static int arm_kprobe(struct kprobe *kp)
{
- if (unlikely(kprobe_ftrace(kp))) {
- arm_kprobe_ftrace(kp);
- return;
- }
+ if (unlikely(kprobe_ftrace(kp)))
+ return arm_kprobe_ftrace(kp);
/*
* Here, since __arm_kprobe() doesn't use stop_machine(),
* this doesn't cause deadlock on text_mutex. So, we don't
@@ -995,6 +994,7 @@ static void arm_kprobe(struct kprobe *kp)
mutex_lock(text_mutex);
__arm_kprobe(kp);
mutex_unlock(text_mutex);
+ return 0;
}
/* Disarm a kprobe with text_mutex */
@@ -1332,10 +1332,15 @@ out:
put_online_cpus();
jump_label_unlock();
+ /* Arm when this is the first enabled kprobe at this address */
if (ret == 0 kprobe_disabled(ap) !kprobe_disabled(p)) {
ap-flags = ~KPROBE_FLAG_DISABLED;
if (!kprobes_all_disarmed)
- /* Arm the breakpoint again. */
+ /*
+* The kprobe is disabled and warning is printed
+* on error. But we ignore the error code here
+* because we keep it registered.
+*/
arm_kprobe(ap);
}
return ret;
@@ -1540,6 +1545,11 @@ int register_kprobe(struct kprobe *p)
kprobe_table[hash_ptr(p-addr, KPROBE_HASH_BITS)]);
if (!kprobes_all_disarmed !kprobe_disabled(p))
+ /*
+* The kprobe is disabled and warning is printed on error.
+* But we ignore the error code here because we keep it
+* registered.
+*/
arm_kprobe(p);
/* Try to optimize kprobe */
@@ -2040,7 +2050,7 @@ int enable_kprobe(struct kprobe *kp)
if (!kprobes_all_disarmed kprobe_disabled(p)) {
p-flags = ~KPROBE_FLAG_DISABLED;
- arm_kprobe(p);
+ ret = arm_kprobe(p);
}
out:
mutex_unlock(kprobe_mutex);
@@ -2325,11 +2335,12 @@ static const struct file_operations
debugfs_kprobe_blacklist_ops = {
.release= seq_release,
};
-static void arm_all_kprobes(void)
+static int arm_all_kprobes(void)
{
struct hlist_head *head;
struct kprobe *p;
unsigned int i;
+ int err, ret = 0;
mutex_lock(kprobe_mutex);
@@ -2341,8 +2352,11 @@ static void arm_all_kprobes(void)
for (i = 0; i KPROBE_TABLE_SIZE; i++) {
head = kprobe_table[i];
hlist_for_each_entry_rcu(p, head, hlist)
- if (!kprobe_disabled(p))
- arm_kprobe(p);
+ if
Re: [PATCH 4/7] x86: entry.S: use JZ mnemonic after TEST, not JE
On Thu, Feb 26, 2015 at 7:59 AM, Borislav Petkov b...@alien8.de wrote: On Thu, Feb 26, 2015 at 07:16:28AM -0800, Andy Lutomirski wrote: I'm declaring a temporary moratorium on new development here until the already-queued stuff is in -tip, looks okay, and we're in an appropriate part of the cycle. The series is already huge. IOW I'm not applying this or the other pending patches yet. Nicely conservative, good. If you have a branch ready which you'd want tested, let me know. https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/log/?h=x86/entry It was in -next, but that version was broken. I'll put it back -next and email out the series today, unless something changs. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. -- -- Andy Lutomirski AMA Capital Management, LLC -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/7] kprobes: Do not try to disarm already disarmed Kprobe
The global kprobes_all_disarmed flag says that all Kprobes are disarmed
even when they are marked as enabled. This is properly handled in
register_kprobe() but it is ignored in __disable_kprobe().
This problem gets more serious after we started handling errors from
disarm_kprobe(). The second disarming fails and we do not longer
set KPROBE_FLAG_DISABLED. It might trigger BUG_ON(!kprobe_disarmed(ap))
in __unregister_kprobe_top() even when Kprobes were globally
disarmed.
Well, kprobe_disarmed(ap) should return false when the global
kprobes_all_disarmed flag is set. But let's solve this separately.
This patch fixes __disable_kprobe(), so that it does not disarm
when the Kprobe is not armed.
Note that I reverted the condition if (kprobe_disabled(p)) and used goto
out there. It helped to keep the code nesting on a reasonable level.
Signed-off-by: Petr Mladek pmla...@suse.cz
---
kernel/kprobes.c | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/kernel/kprobes.c b/kernel/kprobes.c
index 1fcb19095b43..54bc2a6960b4 100644
--- a/kernel/kprobes.c
+++ b/kernel/kprobes.c
@@ -1594,22 +1594,25 @@ static struct kprobe *__disable_kprobe(struct kprobe *p)
if (unlikely(orig_p == NULL))
return ERR_PTR(-EINVAL);
- if (!kprobe_disabled(p)) {
- /* Disable probe if it is a child probe */
- if (p != orig_p)
- p-flags |= KPROBE_FLAG_DISABLED;
+ if (kprobe_disabled(p))
+ goto out;
+
+ /* Disable probe if it is a child probe */
+ if (p != orig_p)
+ p-flags |= KPROBE_FLAG_DISABLED;
- /* Try to disarm and disable this/parent probe */
- if (p == orig_p || aggr_kprobe_disabled(orig_p)) {
+ /* Try to disarm and disable this/parent probe */
+ if (p == orig_p || aggr_kprobe_disabled(orig_p)) {
+ if (!kprobes_all_disarmed) {
err = disarm_kprobe(orig_p, true);
if (err) {
p-flags = ~KPROBE_FLAG_DISABLED;
return ERR_PTR(err);
}
- orig_p-flags |= KPROBE_FLAG_DISABLED;
}
+ orig_p-flags |= KPROBE_FLAG_DISABLED;
}
-
+out:
return orig_p;
}
--
1.8.5.6
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] Input: bcm-keypad: add device tree bindings
Hi Dmitry, Thanks for the update of no need to change any of dt-binding prefixes. I just sent out a v2 patch addressing all of your other comments. On 15-02-23 09:49 AM, Dmitry Torokhov wrote: Hi Scott, On Sun, Feb 15, 2015 at 09:17:51PM -0800, Dmitry Torokhov wrote: On Sat, Feb 14, 2015 at 08:49:15AM -0800, Scott Branden wrote: On 15-02-09 04:51 PM, Dmitry Torokhov wrote: On Mon, Feb 09, 2015 at 04:07:40PM -0800, Scott Branden wrote: + +- col-debounce-filter-period: The debounce period for the Column filter. + + KEYPAD_DEBOUNCE_1_ms= 0 + KEYPAD_DEBOUNCE_2_ms= 1 + KEYPAD_DEBOUNCE_4_ms= 2 + KEYPAD_DEBOUNCE_8_ms= 3 + KEYPAD_DEBOUNCE_16_ms = 4 + KEYPAD_DEBOUNCE_32_ms = 5 + KEYPAD_DEBOUNCE_64_ms = 6 + KEYPAD_DEBOUNCE_128_ms = 7 + +- status-debounce-filter-period: The debounce period for the Status filter. + + KEYPAD_DEBOUNCE_1_ms= 0 + KEYPAD_DEBOUNCE_2_ms= 1 + KEYPAD_DEBOUNCE_4_ms= 2 + KEYPAD_DEBOUNCE_8_ms= 3 + KEYPAD_DEBOUNCE_16_ms = 4 + KEYPAD_DEBOUNCE_32_ms = 5 + KEYPAD_DEBOUNCE_64_ms = 6 + KEYPAD_DEBOUNCE_128_ms = 7 I could swear device-specific properties should be in form of vendor-prefix,property-name to ensure it won't clash with changes on subsystem level later on. Device-tree folks, what say you? I see examples with and without vendor-prefix. qcom,pm8xxx-keypad.txt does not have prefixes st-keyscan.txt does have a prefix I can't find any documented guidelines for this. As I mentioned I'll try to get clarification on this. I have chatted with a couple of people on this and it is acceptable to omit vendor prefix in bindings when we are using a specific driver like we have here (i.e. when driver's compatible string already includes vendor prefix). Vendor prefixes on properties are required when we augment a generic driver's binding. So the above 2 entries are fine as is. 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 RESEND] coresight-stm: Bindings for System Trace Macrocell
The System Trace Macrocell (STM) is an IP block falling under the
CoreSight umbrella. It's main purpose it so expose stimulus channels
to any system component for the purpose of information logging.
Bindings for this IP block adds a couple of items to the current
mandatory definition for CoreSight components. The driver has been posted
here[1].
[1]. https://lkml.org/lkml/2015/2/25/743
Signed-off-by: Mathieu Poirier mathieu.poir...@linaro.org
---
.../devicetree/bindings/arm/coresight.txt | 25 ++
1 file changed, 25 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/coresight.txt
b/Documentation/devicetree/bindings/arm/coresight.txt
index a3089359aaa6..854127578718 100644
--- a/Documentation/devicetree/bindings/arm/coresight.txt
+++ b/Documentation/devicetree/bindings/arm/coresight.txt
@@ -17,6 +17,7 @@ its hardware characteristcs.
- arm,coresight-tmc, arm,primecell;
- arm,coresight-funnel, arm,primecell;
- arm,coresight-etm3x, arm,primecell;
+ - arm,coresight-stm, arm,primecell;
* reg: physical base address and length of the register
set(s) of the component.
@@ -31,6 +32,14 @@ its hardware characteristcs.
layout using the generic DT graph presentation found in
bindings/graph.txt.
+* Additional required properly for System Trace Macrocells (STM):
+ * reg: along with the physical base address and length of the register
+ set as described above, another entry is required to describe the
+ mapping of the extended stimulus port area.
+
+ * reg-names: the only acceptable values are stm-base and
+ stm-channel-base, each corresponding to the areas defined in reg.
+
* Required properties for devices that don't show up on the AMBA bus, such as
non-configurable replicators:
@@ -198,3 +207,19 @@ Example:
};
};
};
+
+4. STM
+ stm@2010 {
+ compatible = arm,coresight-stm, arm,primecell;
+ reg = 0 0x2010 0 0x1000,
+ 0 0x2800 0 0x18;
+ reg-names = stm-base, stm-channel-base;
+
+ clocks = soc_smc50mhz;
+ clock-names = apb_pclk;
+ port {
+ stm_out_port: endpoint {
+ remote-endpoint = main_funnel_in_port2;
+ };
+ };
+ };
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.2 055/152] x86_64, switch_to(): Load TLS descriptors before switching DS and ES
On Thu, Feb 26, 2015 at 10:32 AM, Andy Lutomirski l...@amacapital.net wrote: On Tue, Feb 24, 2015 at 7:23 PM, Brian Gerst brge...@gmail.com wrote: On Tue, Feb 24, 2015 at 3:08 PM, Denys Vlasenko vda.li...@googlemail.com wrote: On Tue, Feb 24, 2015 at 9:02 PM, Andy Lutomirski l...@amacapital.net wrote: This currently fails in 32-bit kernels (at least in qemu): / # ./es_test Allocated GDT index 7 [FAIL]ES changed from 0x3b to 0x7b [FAIL]ES was corrupted 1000/1000 times / # uname -a Linux (none) 4.0.0-rc1 #1 SMP Tue Feb 24 16:41:58 CET 2015 i686 GNU/Linux Want to send a patch? I'll get it in a few days if no one beats me. I have no patch, sorry (in fact, I failed to find where is the relevant 32-bit counterpart). It's just security people asked me to backport this and I wondered maybe I should wait a bit on this one, since fix for 32-bit ought to appear as well. For 32-bit kernel, userspace DS and ES are saved at syscall/interrupt entry time and reloaded on exit, unlike in 64-bit where they are saved and loaded at context switch time. Therefore 32-bit is not affected by the issue this patch addresses. It looks to me though, that the ES test program doesn't actually test what the patch fixes - the segment attributes, like the base address. It tests just the selector, which shouldn't change across a kernel entry (with a few exceptions, like signals). If the test is failing, then it is a different issue from what this patch addresses. It tests it indirectly. The 64-bit code sets the selector to zero if it fails to reload it. Testing the ES base is awkward because it can't be done in 64-bit code at all. I figured out why Denys got the failure. usleep() makes a syscall via sysenter. The sysenter path saves es/ds, but does not restore them before sysexit like the int80/iret path would. That leaves them as USER_DS that the kernel loaded for itself. I believe this was an intentional optimization, assuming the vdso would only be called from programs conforming to the ELF ABI. -- Brian Gerst -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ARM: dts: am335x-lxm: Use rmii-clock-ext
Use external clock for RMII since the internal clock doesn't meet the
jitter requirements.
Signed-off-by: George McCollister george.mccollis...@gmail.com
---
arch/arm/boot/dts/am335x-lxm.dts | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-lxm.dts b/arch/arm/boot/dts/am335x-lxm.dts
index 7266a00..5c5667a 100644
--- a/arch/arm/boot/dts/am335x-lxm.dts
+++ b/arch/arm/boot/dts/am335x-lxm.dts
@@ -328,6 +328,10 @@
dual_emac_res_vlan = 3;
};
+phy_sel {
+ rmii-clock-ext;
+};
+
mac {
pinctrl-names = default, sleep;
pinctrl-0 = cpsw_default;
--
2.2.2
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/7] kprobes: Propagate error from disarm_kprobe_ftrace()
Also disarm_kprobe_ftrace() could fail, for example if there is an internal
error in the Kprobe code and we try to unregister some Kprobe that is not
registered.
If we fail to unregister the ftrace function, we still could try to disarm
the Kprobe by removing the filter. This is why the first error code is not
fatal and we try to continue.
__disable_kprobe() has to return the error code via ERR_PTR. It allows to
pass -EINVAL instead of NULL for invalid Kprobes. Then the NULL pointer does
not need to be transformed into -EINVAL later.
In addition, __disable_kprobe() should disable the child probe only when
the parent probe has been successfully disabled. Note that we could always
clear KPROBE_FLAG_DISABLED in case of error. It does not harm even when
p == orig_p. It keeps the code nesting on reasonable level.
The error handling is a bit complicated in __unregister_kprobe_top().
It is used in unregister_*probes() that are used in module removal callbacks.
Any error here could not stop the removal of the module and the related Kprobe
handlers. Therefore such an error is fatal. There is already a similar check
in the disarmed: goto target.
The only exception is when we try to unregister an invalid Kprobe. It does not
exist and therefore should not harm the system. This error was weak even before.
disable_kprobe() just passes the error as it did before.
disarm_all_kprobes() uses similar approach like arm_all_kprobes(). It keeps
the current behavior and does the best effort. It tries to disable as many
Kprobes as possible. It always reports success. It returns the last error
code. There is going to be separate patch that will improve this behavior.
Signed-off-by: Petr Mladek pmla...@suse.cz
---
kernel/kprobes.c | 77 +---
1 file changed, 51 insertions(+), 26 deletions(-)
diff --git a/kernel/kprobes.c b/kernel/kprobes.c
index a69d23add983..ba57147bd52c 100644
--- a/kernel/kprobes.c
+++ b/kernel/kprobes.c
@@ -962,23 +962,26 @@ err_filter:
}
/* Caller must lock kprobe_mutex */
-static void disarm_kprobe_ftrace(struct kprobe *p)
+static int disarm_kprobe_ftrace(struct kprobe *p)
{
- int ret;
+ int ret = 0;
- kprobe_ftrace_enabled--;
- if (kprobe_ftrace_enabled == 0) {
+ if (kprobe_ftrace_enabled == 1) {
ret = unregister_ftrace_function(kprobe_ftrace_ops);
- WARN(ret 0, Failed to init kprobe-ftrace (%d)\n, ret);
+ WARN(ret 0, Failed to remove kprobe-ftrace (%d)\n, ret);
}
+ if (!ret)
+ kprobe_ftrace_enabled--;
+
ret = ftrace_set_filter_ip(kprobe_ftrace_ops,
- (unsigned long)p-addr, 1, 0);
+ (unsigned long)p-addr, 1, 0);
WARN(ret 0, Failed to disarm kprobe-ftrace at %p (%d)\n, p-addr,
ret);
+ return ret;
}
#else /* !CONFIG_KPROBES_ON_FTRACE */
#define prepare_kprobe(p) arch_prepare_kprobe(p)
#define arm_kprobe_ftrace(p) (0)
-#define disarm_kprobe_ftrace(p)do {} while (0)
+#define disarm_kprobe_ftrace(p)(0)
#endif
/* Arm a kprobe with text_mutex */
@@ -998,16 +1001,15 @@ static int arm_kprobe(struct kprobe *kp)
}
/* Disarm a kprobe with text_mutex */
-static void disarm_kprobe(struct kprobe *kp, bool reopt)
+static int disarm_kprobe(struct kprobe *kp, bool reopt)
{
- if (unlikely(kprobe_ftrace(kp))) {
- disarm_kprobe_ftrace(kp);
- return;
- }
+ if (unlikely(kprobe_ftrace(kp)))
+ return disarm_kprobe_ftrace(kp);
/* Ditto */
mutex_lock(text_mutex);
__disarm_kprobe(kp, reopt);
mutex_unlock(text_mutex);
+ return 0;
}
/*
@@ -1585,11 +1587,12 @@ static int aggr_kprobe_disabled(struct kprobe *ap)
static struct kprobe *__disable_kprobe(struct kprobe *p)
{
struct kprobe *orig_p;
+ int err;
/* Get an original kprobe for return */
orig_p = __get_valid_kprobe(p);
if (unlikely(orig_p == NULL))
- return NULL;
+ return ERR_PTR(-EINVAL);
if (!kprobe_disabled(p)) {
/* Disable probe if it is a child probe */
@@ -1598,7 +1601,11 @@ static struct kprobe *__disable_kprobe(struct kprobe *p)
/* Try to disarm and disable this/parent probe */
if (p == orig_p || aggr_kprobe_disabled(orig_p)) {
- disarm_kprobe(orig_p, true);
+ err = disarm_kprobe(orig_p, true);
+ if (err) {
+ p-flags = ~KPROBE_FLAG_DISABLED;
+ return ERR_PTR(err);
+ }
orig_p-flags |= KPROBE_FLAG_DISABLED;
}
}
@@ -1615,8 +1622,17 @@ static int __unregister_kprobe_top(struct kprobe *p)
/* Disable kprobe. This will disarm it if needed. */
ap =
[PATCH v2 1/2] Input: bcm-keypad: add device tree bindings
Documents the Broadcom keypad controller device tree bindings.
Reviewed-by: Ray Jui r...@broadcom.com
Signed-off-by: Scott Branden sbran...@broadcom.com
---
.../devicetree/bindings/input/brcm,bcm-keypad.txt | 108 +
1 file changed, 108 insertions(+)
create mode 100644 Documentation/devicetree/bindings/input/brcm,bcm-keypad.txt
diff --git a/Documentation/devicetree/bindings/input/brcm,bcm-keypad.txt
b/Documentation/devicetree/bindings/input/brcm,bcm-keypad.txt
new file mode 100644
index 000..e16bb2d
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/brcm,bcm-keypad.txt
@@ -0,0 +1,108 @@
+* Broadcom Keypad Controller device tree bindings
+
+Broadcom Keypad controller is used to interface a SoC with a matrix-type
+keypad device. The keypad controller supports multiple row and column lines.
+A key can be placed at each intersection of a unique row and a unique column.
+The keypad controller can sense a key-press and key-release and report the
+event using a interrupt to the cpu.
+
+This binding is based on the matrix-keymap binding with the following
+changes:
+
+keypad,num-rows and keypad,num-columns are required.
+
+Required SoC Specific Properties:
+- compatible: should be brcm,bcm-keypad
+
+- reg: physical base address of the controller and length of memory mapped
+ region.
+
+- interrupts: The interrupt number to the cpu.
+
+Board Specific Properties:
+- keypad,num-rows: Number of row lines connected to the keypad
+ controller.
+
+- keypad,num-columns: Number of column lines connected to the
+ keypad controller.
+
+- col-debounce-filter-period: The debounce period for the Column filter.
+
+ KEYPAD_DEBOUNCE_1_ms= 0
+ KEYPAD_DEBOUNCE_2_ms= 1
+ KEYPAD_DEBOUNCE_4_ms= 2
+ KEYPAD_DEBOUNCE_8_ms= 3
+ KEYPAD_DEBOUNCE_16_ms = 4
+ KEYPAD_DEBOUNCE_32_ms = 5
+ KEYPAD_DEBOUNCE_64_ms = 6
+ KEYPAD_DEBOUNCE_128_ms = 7
+
+- status-debounce-filter-period: The debounce period for the Status filter.
+
+ KEYPAD_DEBOUNCE_1_ms= 0
+ KEYPAD_DEBOUNCE_2_ms= 1
+ KEYPAD_DEBOUNCE_4_ms= 2
+ KEYPAD_DEBOUNCE_8_ms= 3
+ KEYPAD_DEBOUNCE_16_ms = 4
+ KEYPAD_DEBOUNCE_32_ms = 5
+ KEYPAD_DEBOUNCE_64_ms = 6
+ KEYPAD_DEBOUNCE_128_ms = 7
+
+- row-output-enabled: An optional property indicating whether the row or
+ column is being used as output. If specified the row is being used
+ as the output. Else defaults to column.
+
+- pull-up-enabled: An optional property indicating the Keypad scan mode.
+ If specified implies the keypad scan pull-up has been enabled.
+
+- linux,keypad-no-autorepeat: An optional property indicating to
+ not enable autorepeat feature.
+
+- linux,keymap: The keymap for keys as described in the binding document
+ devicetree/bindings/input/matrix-keymap.txt.
+
+Example:
+#include dt-bindings/input/input.h
+
+/ {
+ keypad: keypad@180ac000 {
+ /* Required SoC specific properties */
+ compatible = brcm,bcm-keypad;
+
+ /* Required Board specific properties */
+ keypad,num-rows = 5;
+ keypad,num-columns = 5;
+ status = okay;
+
+ linux,keymap = MATRIX_KEY(0x00, 0x02, KEY_F) /* key_forward */
+ MATRIX_KEY(0x00, 0x03, KEY_HOME) /* key_home */
+ MATRIX_KEY(0x00, 0x04, KEY_M) /* key_message */
+ MATRIX_KEY(0x01, 0x00, KEY_A) /* key_contacts */
+ MATRIX_KEY(0x01, 0x01, KEY_1) /* key_1 */
+ MATRIX_KEY(0x01, 0x02, KEY_2) /* key_2 */
+ MATRIX_KEY(0x01, 0x03, KEY_3) /* key_3 */
+ MATRIX_KEY(0x01, 0x04, KEY_S) /* key_speaker */
+ MATRIX_KEY(0x02, 0x00, KEY_P) /* key_phone */
+ MATRIX_KEY(0x02, 0x01, KEY_4) /* key_4 */
+ MATRIX_KEY(0x02, 0x02, KEY_5) /* key_5 */
+ MATRIX_KEY(0x02, 0x03, KEY_6) /* key_6 */
+ MATRIX_KEY(0x02, 0x04, KEY_VOLUMEUP) /* key_vol_up */
+ MATRIX_KEY(0x03, 0x00, KEY_C) /* key_call_log */
+ MATRIX_KEY(0x03, 0x01, KEY_7) /* key_7 */
+ MATRIX_KEY(0x03, 0x02, KEY_8) /* key_8 */
+ MATRIX_KEY(0x03, 0x03, KEY_9) /* key_9 */
+ MATRIX_KEY(0x03, 0x04, KEY_VOLUMEDOWN) /* key_vol_down */
+ MATRIX_KEY(0x04, 0x00, KEY_H) /* key_headset */
+ MATRIX_KEY(0x04, 0x01, KEY_KPASTERISK) /* key_* */
+ MATRIX_KEY(0x04, 0x02, KEY_0) /* key_0 */
+ MATRIX_KEY(0x04, 0x03, KEY_GRAVE) /* key_# */
+ MATRIX_KEY(0x04, 0x04, KEY_MUTE) /* key_mute */
+ ;
+
+ /* Optional board specific properties */
+ col-debounce-filter-period = 5;
+ row-output-enabled;
+ pull-up-enabled;
+
+ };
+};
--
2.3.0
--
[PATCH 4/7] kprobes: Keep consistent state of kprobes_all_disarmed
kprobes_all_disarmed global flag says that Kprobes are disarmed even
when the Kprobe-specific KPROBE_FLAG_DISABLED is not set.
The global flag is currently set by arm_all_probes() and disarm_all_probes()
functions even when they were not able to switch all Kprobes. It might result
in further errors.
This patch tries to restore the consistent state when some particular
Kprobe cannot be (dis)armed. In this case, it reverts the already switched
Kprobes to the previous state.
The implementation splits the cycle modifying all the probes into
separate functions, so that they could be reused to restore the
original state.
The kprobes_all_disarmed flag is modified only when all Kprobes were
successfully switched.
In case of error, we call wait_for_kprobe_optimizer() also in
arm_all_kprobes() to be on the safe side.
Signed-off-by: Petr Mladek pmla...@suse.cz
---
kernel/kprobes.c | 124 ++-
1 file changed, 95 insertions(+), 29 deletions(-)
diff --git a/kernel/kprobes.c b/kernel/kprobes.c
index ba57147bd52c..1fcb19095b43 100644
--- a/kernel/kprobes.c
+++ b/kernel/kprobes.c
@@ -2353,44 +2353,117 @@ static const struct file_operations
debugfs_kprobe_blacklist_ops = {
.release= seq_release,
};
-static int arm_all_kprobes(void)
+static int __disarm_all_kprobes(unsigned int last_table,
+ struct kprobe *last_kprobe);
+
+/*
+ * Arm all enabled Kprobes until you reach the one given by parameters.
+ * It tries to restore the original state on error.
+ *
+ * All Kprobes are handled when @last_table == KPROBE_TABLE_SIZE - 1
+ * and last_kprobe == NULL.
+ *
+ * This function need to be called under kprobe_mutex
+ */
+static int __arm_all_kprobes(unsigned int last_table,
+struct kprobe *last_kprobe)
{
struct hlist_head *head;
struct kprobe *p;
unsigned int i;
int err, ret = 0;
- mutex_lock(kprobe_mutex);
-
- /* If kprobes are armed, just return */
- if (!kprobes_all_disarmed)
- goto already_enabled;
-
/* Arming kprobes doesn't optimize kprobe itself */
- for (i = 0; i KPROBE_TABLE_SIZE; i++) {
+ for (i = 0; i = last_table ; i++) {
head = kprobe_table[i];
- hlist_for_each_entry_rcu(p, head, hlist)
+ hlist_for_each_entry_rcu(p, head, hlist) {
+ if (i == last_table p == last_kprobe)
+ return 0;
if (!kprobe_disabled(p)) {
err = arm_kprobe(p);
- if (err)
- ret = err;
+ if (!err)
+ continue;
+ /*
+* Try to restore the original consistent state.
+* But only when all Kprobes are proceed here
+* to avoid an infinite loop.
+*/
+ if (!last_kprobe)
+ WARN_ON(__disarm_all_kprobes(i, p));
+ return ret;
}
+ }
}
- kprobes_all_disarmed = false;
- printk(KERN_INFO Kprobes globally enabled\n);
+ return 0;
+}
+
+static int arm_all_kprobes(void)
+{
+ int ret = 0;
+
+ mutex_lock(kprobe_mutex);
+
+ /* If kprobes are armed, just return */
+ if (!kprobes_all_disarmed) {
+ mutex_unlock(kprobe_mutex);
+ return 0;
+ }
+
+ ret = __arm_all_kprobes(KPROBE_TABLE_SIZE - 1, NULL);
+ if (!ret) {
+ kprobes_all_disarmed = false;
+ pr_info(Kprobes globally enabled\n);
+ }
-already_enabled:
mutex_unlock(kprobe_mutex);
+
+ /*
+* On error, some Kprobes were armed and disarmed again. Be on the safe
+* side and wait for disarming all kprobes by optimizer in this case.
+*/
+ if (ret)
+ wait_for_kprobe_optimizer();
+
return ret;
}
-static int disarm_all_kprobes(void)
+/* Reverse operation for __arm_all_kprobes(), see above for details */
+static int __disarm_all_kprobes(unsigned int last_table,
+ struct kprobe *last_kprobe)
{
struct hlist_head *head;
struct kprobe *p;
unsigned int i;
- int err, ret = 0;
+ int err;
+
+ for (i = 0; i = last_table; i++) {
+ head = kprobe_table[i];
+ hlist_for_each_entry_rcu(p, head, hlist) {
+ if (i == last_table p == last_kprobe)
+ return 0;
+ if (!arch_trampoline_kprobe(p) !kprobe_disabled(p)) {
+ err = disarm_kprobe(p, false);
+
