Re: [PATCH v4 4/4] drivers/hwmon/menf21bmc_hwmon: introduce MEN14F021P00 BMC HWMON driver
On Thu, Aug 21, 2014 at 11:45:01AM -0700, Guenter Roeck wrote: > On Wed, Aug 13, 2014 at 10:40:37AM +0200, Andreas Werner wrote: > > Added driver to support the 14F021P00 BMC Hardware Monitoring. > > The BMC is a Board Management Controller including monitoring of the > > board voltages. > > > > Signed-off-by: Andreas Werner > > --- > > drivers/hwmon/Kconfig | 7 ++ > > drivers/hwmon/Makefile | 1 + > > drivers/hwmon/menf21bmc_hwmon.c | 238 > > > > Forgot: Please also provide Documentation/hwmon/menf21bmc. > Did not know that i have to do it. But you are right it is good to have one. > Thanks, > Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 4/4] drivers/hwmon/menf21bmc_hwmon: introduce MEN14F021P00 BMC HWMON driver
On Thu, Aug 21, 2014 at 11:37:52AM -0700, Guenter Roeck wrote:
> On Wed, Aug 13, 2014 at 10:40:37AM +0200, Andreas Werner wrote:
> > Added driver to support the 14F021P00 BMC Hardware Monitoring.
> > The BMC is a Board Management Controller including monitoring of the
> > board voltages.
> >
> > Signed-off-by: Andreas Werner
> > ---
> > drivers/hwmon/Kconfig | 7 ++
> > drivers/hwmon/Makefile | 1 +
> > drivers/hwmon/menf21bmc_hwmon.c | 238
> >
> > 3 files changed, 246 insertions(+)
> > create mode 100644 drivers/hwmon/menf21bmc_hwmon.c
> >
> > diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
> > index 37908ff..437c00f 100644
> > --- a/drivers/hwmon/Kconfig
> > +++ b/drivers/hwmon/Kconfig
> > @@ -828,6 +828,13 @@ config SENSORS_MCP3021
> > This driver can also be built as a module. If so, the module
> > will be called mcp3021.
> >
> > +config SENSORS_MENF21BMC_HWMON
> > + tristate "MEN 14F021P00 BMC Hardware Monitoring"
> > + depends on MFD_MENF21BMC && I2C
> > + help
> > + Say Y here to include support for the MEN 14F021P00 BMC
> > + hardware monitoring.
> > +
> > config SENSORS_ADCXX
> > tristate "National Semiconductor ADCxxxSxxx"
> > depends on SPI_MASTER
> > diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
> > index 1362382..56ab872 100644
> > --- a/drivers/hwmon/Makefile
> > +++ b/drivers/hwmon/Makefile
> > @@ -114,6 +114,7 @@ obj-$(CONFIG_SENSORS_MAX6650) += max6650.o
> > obj-$(CONFIG_SENSORS_MAX6697) += max6697.o
> > obj-$(CONFIG_SENSORS_MC13783_ADC)+= mc13783-adc.o
> > obj-$(CONFIG_SENSORS_MCP3021) += mcp3021.o
> > +obj-$(CONFIG_SENSORS_MENF21BMC_HWMON) += menf21bmc_hwmon.o
> > obj-$(CONFIG_SENSORS_NCT6683) += nct6683.o
> > obj-$(CONFIG_SENSORS_NCT6775) += nct6775.o
> > obj-$(CONFIG_SENSORS_NTC_THERMISTOR) += ntc_thermistor.o
> > diff --git a/drivers/hwmon/menf21bmc_hwmon.c
> > b/drivers/hwmon/menf21bmc_hwmon.c
> > new file mode 100644
> > index 000..ecb0ef1
> > --- /dev/null
> > +++ b/drivers/hwmon/menf21bmc_hwmon.c
> > @@ -0,0 +1,238 @@
> > +/*
> > + * MEN 14F021P00 Board Management Controller (BMC) hwmon driver.
> > + *
> > + * This is the core hwmon driver of the MEN 14F021P00 BMC.
> > + * The BMC monitors the board voltages which can be access with this
> > + * driver through sysfs.
> > + *
> > + * Copyright (C) 2014 MEN Mikro Elektronik Nuernberg GmbH
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > it
> > + * under the terms of the GNU General Public License as published by
> > the
> > + * Free Software Foundation; either version 2 of the License, or (at
> > your
> > + * option) any later version.
>
> The license statement below states GPL v2, which contradicts the statement
> here.
> Maybe it should just be GPL below ?
Why dos it contradict? This is both GPLv2, in the header and in the
MODULE_LICENSE
like i have changed it in the other slave devices and the mfd.
>
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#define DEVNAME "menf21bmc_hwmon"
> > +
> While that makes sense for the driver name, it doesn't really for the hwmon
> device. You might want to consider just using "menf21bmc" when you register
> the
> hwmon device.
>
menf21bmc is the name of the MFD driver. This name is to distinguish each of
the slaves. For that the name represent that this device is a slave of
"menf21bmc"
and a "hwmon" of its own.
> > +#define BMC_VOLT_COUNT 5
> > +#define MENF21BMC_V33 0
> > +#define MENF21BMC_V5 1
> > +#define MENF21BMC_V12 2
> > +#define MENF21BMC_V5_SB3
> > +#define MENF21BMC_VBAT 4
> > +
> > +#define BMC_CMD_GET_NUM_VOLT 0x8E
> > +#define IDX_TO_VOLT_MIN_CMD(idx) (0x40 + idx)
> > +#define IDX_TO_VOLT_MAX_CMD(idx) (0x50 + idx)
> > +#define IDX_TO_VOLT_INP_CMD(idx) (0x60 + idx)
> > +
> > +struct menf21bmc_hwmon {
> > + char valid;
> > + struct i2c_client *i2c_client;
> > + unsigned long last_update;
> > + u16 in_val[BMC_VOLT_COUNT];
> > + u16 in_min[BMC_VOLT_COUNT];
> > + u16 in_max[BMC_VOLT_COUNT];
> > +};
> >
Re: [PATCH v4 1/4] drivers/mfd/menf21bmc: introduce MEN 14F021P00 BMC MFD Core driver
On Thu, Aug 21, 2014 at 12:30:46PM +0100, Lee Jones wrote: > On Wed, 13 Aug 2014, Andreas Werner wrote: > > The MEN 14F021P00 Board Management Controller provides an > > I2C interface to the host to access the feature implemented in the BMC. > > The BMC is a PIC Microntroller assembled on CPCI Card from MEN > > Mikroelektronik > > and on a few Box/Display Computer. > > > > Added MFD Core driver, supporting the I2C communication to the device. > > > > The MFD driver currently supports the following features: > > - Watchdog > > - LEDs > > - Hwmon (voltage monitoring) > > > > Signed-off-by: Andreas Werner > > --- > > drivers/mfd/Kconfig | 12 + > > drivers/mfd/Makefile| 1 + > > drivers/mfd/menf21bmc.c | 132 > > > > 3 files changed, 145 insertions(+) > > create mode 100644 drivers/mfd/menf21bmc.c > > > > diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig > > index b8d9ca0..bf155b9 100644 > > --- a/drivers/mfd/Kconfig > > +++ b/drivers/mfd/Kconfig > > @@ -453,6 +453,18 @@ config MFD_MAX8998 > > additional drivers must be enabled in order to use the functionality > > of the device. > > > > +config MFD_MENF21BMC > > + tristate "MEN 14F021P00 Board Management Controller Support" > > + depends on I2C=y > > Why must I2C be built-in? Sorry my mistake, I2C must not be built in. > > > + select MFD_CORE > > + help > > + Say yes here to add support for the MEN 14F021P00 BMC > > + which is a Board Management Controller connected to the I2C bus. > > + The device supports multiple sub-devices like LED, HWMON and WDT. > > + This driver provides common support for accessing the devices; > > + additional drivers must be enabled in order to use the > > + functionality of the BMC device. > > + > > Apart from that the patch looks good to me. > > I'm assuming this can go in via the MFD tree by itself? Yes why not. Do you want to have a single patch for the MFD or is it better to wait for the other Subsystem maintainer that I can resend a patch v5? Regards Andy > > Acked-by: Lee Jones > > -- > Lee Jones > Linaro STMicroelectronics Landing Team Lead > Linaro.org │ Open source software for ARM SoCs > Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 2/4] drivers/watchdog/menf21bmc_wdt: introduce MEN 14F021P00 BMC Watchdog driver
Added driver to support the 14F021P00 BMC Watchdog.
The BMC is a Board Management Controller including watchdog functionality.
Signed-off-by: Andreas Werner
---
drivers/watchdog/Kconfig | 7 ++
drivers/watchdog/Makefile| 1 +
drivers/watchdog/menf21bmc_wdt.c | 203 +++
3 files changed, 211 insertions(+)
create mode 100644 drivers/watchdog/menf21bmc_wdt.c
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 76dd541..f96431d 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -95,6 +95,13 @@ config GPIO_WATCHDOG
If you say yes here you get support for watchdog device
controlled through GPIO-line.
+config MENF21BMC_WATCHDOG
+ tristate "MEN 14F021P00 BMC Watchdog"
+ depends on MFD_MENF21BMC
+ select WATCHDOG_CORE
+ help
+ Say Y here to include support for the MEN 14F021P00 BMC Watchdog.
+
config WM831X_WATCHDOG
tristate "WM831x watchdog"
depends on MFD_WM831X
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 468c320..de17014 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -178,3 +178,4 @@ obj-$(CONFIG_WM831X_WATCHDOG) += wm831x_wdt.o
obj-$(CONFIG_WM8350_WATCHDOG) += wm8350_wdt.o
obj-$(CONFIG_MAX63XX_WATCHDOG) += max63xx_wdt.o
obj-$(CONFIG_SOFT_WATCHDOG) += softdog.o
+obj-$(CONFIG_MENF21BMC_WATCHDOG) += menf21bmc_wdt.o
diff --git a/drivers/watchdog/menf21bmc_wdt.c b/drivers/watchdog/menf21bmc_wdt.c
new file mode 100644
index 000..604824d
--- /dev/null
+++ b/drivers/watchdog/menf21bmc_wdt.c
@@ -0,0 +1,203 @@
+/*
+ * MEN 14F021P00 Board Management Controller (BMC) Watchdog Driver.
+ *
+ * Copyright (C) 2014 MEN Mikro Elektronik Nuernberg GmbH
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define DEVNAME "menf21bmc_wdt"
+
+#define BMC_CMD_WD_ON 0x11
+#define BMC_CMD_WD_OFF 0x12
+#define BMC_CMD_WD_TRIG0x13
+#define BMC_CMD_WD_TIME0x14
+#define BMC_CMD_WD_STATE 0x17
+#define BMC_WD_OFF_VAL 0x69
+#define BMC_CMD_RST_RSN0x92
+
+#define BMC_WD_TIMEOUT_MIN 1 /* in sec */
+#define BMC_WD_TIMEOUT_MAX 6553/* in sec */
+
+static bool nowayout = WATCHDOG_NOWAYOUT;
+module_param(nowayout, bool, 0);
+MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once started (default="
+ __MODULE_STRING(WATCHDOG_NOWAYOUT) ")");
+
+struct menf21bmc_wdt {
+ struct watchdog_device wdt;
+ struct i2c_client *i2c_client;
+};
+
+static int menf21bmc_wdt_set_bootstatus(struct menf21bmc_wdt *data)
+{
+ int rst_rsn;
+
+ rst_rsn = i2c_smbus_read_byte_data(data->i2c_client, BMC_CMD_RST_RSN);
+ if (rst_rsn < 0)
+ return rst_rsn;
+
+ if (rst_rsn == 0x02)
+ data->wdt.bootstatus |= WDIOF_CARDRESET;
+ else if (rst_rsn == 0x05)
+ data->wdt.bootstatus |= WDIOF_EXTERN1;
+ else if (rst_rsn == 0x06)
+ data->wdt.bootstatus |= WDIOF_EXTERN2;
+ else if (rst_rsn == 0x0A)
+ data->wdt.bootstatus |= WDIOF_POWERUNDER;
+
+ return 0;
+}
+
+static int menf21bmc_wdt_start(struct watchdog_device *wdt)
+{
+ struct menf21bmc_wdt *drv_data = watchdog_get_drvdata(wdt);
+
+ return i2c_smbus_write_byte(drv_data->i2c_client, BMC_CMD_WD_ON);
+}
+
+static int menf21bmc_wdt_stop(struct watchdog_device *wdt)
+{
+ struct menf21bmc_wdt *drv_data = watchdog_get_drvdata(wdt);
+
+ return i2c_smbus_write_byte_data(drv_data->i2c_client,
+ BMC_CMD_WD_OFF, BMC_WD_OFF_VAL);
+}
+
+static int
+menf21bmc_wdt_settimeout(struct watchdog_device *wdt, unsigned int timeout)
+{
+ int ret;
+ struct menf21bmc_wdt *drv_data = watchdog_get_drvdata(wdt);
+
+ /*
+* BMC Watchdog does have a resolution of 100ms.
+* Watchdog API defines the timeout in seconds, so we have to
+* multiply the value.
+*/
+ ret = i2c_smbus_write_word_data(drv_data->i2c_client,
+ BMC_CMD_WD_TIME, timeout * 10);
+ if (ret < 0)
+ return ret;
+
+ wdt->timeout = timeout;
+
+ return 0;
+}
+
+static int menf21bmc_wdt_ping(struct watchdog_device *wdt)
+{
+ struct menf21bmc_wdt *drv_data = watchdog_get_drvdata(wdt);
+
+ return i2c_smbus_write_byte(drv_data->i2c_client, BMC_CMD_WD_TRIG);
+}
+
+static const struct watchdog_info menf21bmc_wdt_info = {
+ .options = WD
[PATCH v4 4/4] drivers/hwmon/menf21bmc_hwmon: introduce MEN14F021P00 BMC HWMON driver
Added driver to support the 14F021P00 BMC Hardware Monitoring.
The BMC is a Board Management Controller including monitoring of the
board voltages.
Signed-off-by: Andreas Werner
---
drivers/hwmon/Kconfig | 7 ++
drivers/hwmon/Makefile | 1 +
drivers/hwmon/menf21bmc_hwmon.c | 238
3 files changed, 246 insertions(+)
create mode 100644 drivers/hwmon/menf21bmc_hwmon.c
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 37908ff..437c00f 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -828,6 +828,13 @@ config SENSORS_MCP3021
This driver can also be built as a module. If so, the module
will be called mcp3021.
+config SENSORS_MENF21BMC_HWMON
+ tristate "MEN 14F021P00 BMC Hardware Monitoring"
+ depends on MFD_MENF21BMC && I2C
+ help
+ Say Y here to include support for the MEN 14F021P00 BMC
+ hardware monitoring.
+
config SENSORS_ADCXX
tristate "National Semiconductor ADCxxxSxxx"
depends on SPI_MASTER
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index 1362382..56ab872 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -114,6 +114,7 @@ obj-$(CONFIG_SENSORS_MAX6650) += max6650.o
obj-$(CONFIG_SENSORS_MAX6697) += max6697.o
obj-$(CONFIG_SENSORS_MC13783_ADC)+= mc13783-adc.o
obj-$(CONFIG_SENSORS_MCP3021) += mcp3021.o
+obj-$(CONFIG_SENSORS_MENF21BMC_HWMON) += menf21bmc_hwmon.o
obj-$(CONFIG_SENSORS_NCT6683) += nct6683.o
obj-$(CONFIG_SENSORS_NCT6775) += nct6775.o
obj-$(CONFIG_SENSORS_NTC_THERMISTOR) += ntc_thermistor.o
diff --git a/drivers/hwmon/menf21bmc_hwmon.c b/drivers/hwmon/menf21bmc_hwmon.c
new file mode 100644
index 000..ecb0ef1
--- /dev/null
+++ b/drivers/hwmon/menf21bmc_hwmon.c
@@ -0,0 +1,238 @@
+/*
+ * MEN 14F021P00 Board Management Controller (BMC) hwmon driver.
+ *
+ * This is the core hwmon driver of the MEN 14F021P00 BMC.
+ * The BMC monitors the board voltages which can be access with this
+ * driver through sysfs.
+ *
+ * Copyright (C) 2014 MEN Mikro Elektronik Nuernberg GmbH
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define DEVNAME "menf21bmc_hwmon"
+
+#define BMC_VOLT_COUNT 5
+#define MENF21BMC_V33 0
+#define MENF21BMC_V5 1
+#define MENF21BMC_V12 2
+#define MENF21BMC_V5_SB3
+#define MENF21BMC_VBAT 4
+
+#define BMC_CMD_GET_NUM_VOLT 0x8E
+#define IDX_TO_VOLT_MIN_CMD(idx) (0x40 + idx)
+#define IDX_TO_VOLT_MAX_CMD(idx) (0x50 + idx)
+#define IDX_TO_VOLT_INP_CMD(idx) (0x60 + idx)
+
+struct menf21bmc_hwmon {
+ char valid;
+ struct i2c_client *i2c_client;
+ unsigned long last_update;
+ u16 in_val[BMC_VOLT_COUNT];
+ u16 in_min[BMC_VOLT_COUNT];
+ u16 in_max[BMC_VOLT_COUNT];
+};
+
+static const char *const input_names[] = {
+ [MENF21BMC_V33] = "MON_3,3V",
+ [MENF21BMC_V5] = "MON_5V",
+ [MENF21BMC_V12] = "MON_12V",
+ [MENF21BMC_V5_SB] = "5V_STANDBY",
+ [MENF21BMC_VBAT]= "VBAT"
+};
+
+static struct menf21bmc_hwmon *menf21bmc_hwmon_update(struct device *dev)
+{
+ int i;
+ uint16_t val;
+ struct menf21bmc_hwmon *drv_data = dev_get_drvdata(dev);
+ struct menf21bmc_hwmon *data_ret = drv_data;
+
+ if (time_after(jiffies, drv_data->last_update + HZ) ||
!drv_data->valid) {
+ for (i = 0; i < BMC_VOLT_COUNT; i++) {
+ val = i2c_smbus_read_word_data(drv_data->i2c_client,
+ IDX_TO_VOLT_INP_CMD(i));
+ if (val < 0)
+ goto abort;
+
+ drv_data->in_val[i] = val;
+ }
+ drv_data->last_update = jiffies;
+ drv_data->valid = 1;
+ }
+abort:
+ return data_ret;
+}
+
+static int menf21bmc_hwmon_get_volt_limits(struct menf21bmc_hwmon *drv_data)
+{
+ int i;
+ uint16_t val;
+
+ for (i = 0; i < BMC_VOLT_COUNT; i++) {
+ val = i2c_smbus_read_word_data(drv_data->i2c_client,
+ IDX_TO_VOLT_MIN_CMD(i));
+ if (val < 0)
+ return val;
+
+ drv_data->in_min[i] = val;
+
+ val = i2c_smbus_read_word_data(drv_data->i2c_client,
+ IDX_TO_VOLT_MAX_CMD(i));
+ if (val < 0)
+ return val;
+
+ drv_data-&
[PATCH v4 3/4] drivers/leds/leds-menf21bmc: introduce MEN 14F021P00 BMC LED driver
Added driver to support the 14F021P00 BMC LEDs.
The BMC is a Board Management Controller including four LEDs which
can be switched on and off.
Signed-off-by: Andreas Werner
---
drivers/leds/Kconfig | 6 ++
drivers/leds/Makefile | 1 +
drivers/leds/leds-menf21bmc.c | 131 ++
3 files changed, 138 insertions(+)
create mode 100644 drivers/leds/leds-menf21bmc.c
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 27cf0cd..d38ff3f 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -458,6 +458,12 @@ config LEDS_OT200
This option enables support for the LEDs on the Bachmann OT200.
Say Y to enable LEDs on the Bachmann OT200.
+config LEDS_MENF21BMC
+ tristate "LED support for the MEN 14F021P00 BMC"
+ depends on LEDS_CLASS && MFD_MENF21BMC
+ help
+ Say Y here to include support for the MEN 14F021P00 BMC LEDs.
+
comment "LED driver for blink(1) USB RGB LED is under Special HID drivers
(HID_THINGM)"
config LEDS_BLINKM
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index 3c03666..cadc433 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -53,6 +53,7 @@ obj-$(CONFIG_LEDS_MAX8997)+= leds-max8997.o
obj-$(CONFIG_LEDS_LM355x) += leds-lm355x.o
obj-$(CONFIG_LEDS_BLINKM) += leds-blinkm.o
obj-$(CONFIG_LEDS_VERSATILE) += leds-versatile.o
+obj-$(CONFIG_LEDS_MENF21BMC) += leds-menf21bmc.o
# LED SPI Drivers
obj-$(CONFIG_LEDS_DAC124S085) += leds-dac124s085.o
diff --git a/drivers/leds/leds-menf21bmc.c b/drivers/leds/leds-menf21bmc.c
new file mode 100644
index 000..4621f72
--- /dev/null
+++ b/drivers/leds/leds-menf21bmc.c
@@ -0,0 +1,131 @@
+/*
+ * MEN 14F021P00 Board Management Controller (BMC) LEDs Driver.
+ *
+ * This is the core LED driver of the MEN 14F021P00 BMC.
+ * There are four LEDs available which can be switched on and off.
+ * STATUS LED, HOT SWAP LED, USER LED 1, USER LED 2
+ *
+ * Copyright (C) 2014 MEN Mikro Elektronik Nuernberg GmbH
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#define BMC_CMD_LED_GET_SET0xA0
+#define BMC_BIT_LED_STATUS BIT(0)
+#define BMC_BIT_LED_HOTSWAPBIT(1)
+#define BMC_BIT_LED_USER1 BIT(2)
+#define BMC_BIT_LED_USER2 BIT(3)
+
+struct menf21bmc_led {
+ struct led_classdev cdev;
+ u8 led_bit;
+ const char *name;
+ struct i2c_client *i2c_client;
+};
+
+static struct menf21bmc_led leds[] = {
+ {
+ .name = "menf21bmc:led_status",
+ .led_bit = BMC_BIT_LED_STATUS,
+ },
+ {
+ .name = "menf21bmc:led_hotswap",
+ .led_bit = BMC_BIT_LED_HOTSWAP,
+ },
+ {
+ .name = "menf21bmc:led_user1",
+ .led_bit = BMC_BIT_LED_USER1,
+ },
+ {
+ .name = "menf21bmc:led_user2",
+ .led_bit = BMC_BIT_LED_USER2,
+ }
+};
+
+static DEFINE_MUTEX(led_lock);
+
+static void
+menf21bmc_led_set(struct led_classdev *led_cdev, enum led_brightness value)
+{
+ int led_val;
+ struct menf21bmc_led *led = container_of(led_cdev,
+ struct menf21bmc_led, cdev);
+
+ mutex_lock(&led_lock);
+ led_val = i2c_smbus_read_byte_data(led->i2c_client,
+ BMC_CMD_LED_GET_SET);
+ if (led_val < 0)
+ goto err_out;
+
+ if (value == LED_OFF)
+ led_val &= ~led->led_bit;
+ else
+ led_val |= led->led_bit;
+
+ i2c_smbus_write_byte_data(led->i2c_client,
+ BMC_CMD_LED_GET_SET, led_val);
+err_out:
+ mutex_unlock(&led_lock);
+}
+
+static int menf21bmc_led_probe(struct platform_device *pdev)
+{
+ int i;
+ int ret;
+ struct i2c_client *i2c_client = to_i2c_client(pdev->dev.parent);
+
+ for (i = 0; i < ARRAY_SIZE(leds); i++) {
+ leds[i].cdev.name = leds[i].name;
+ leds[i].cdev.brightness_set = menf21bmc_led_set;
+ leds[i].i2c_client = i2c_client;
+ ret = led_classdev_register(&pdev->dev, &leds[i].cdev);
+ if (ret < 0)
+ goto err_free_leds;
+ }
+ dev_info(&pdev->dev, "MEN 140F21P00 BMC LED device enabled\n");
+
+ return 0;
+
+err_free_leds:
+ dev_err(&pdev->dev, "failed to register LED device\n");
+
+ for (i = i - 1; i >= 0; i--)
+
[PATCH v4 1/4] drivers/mfd/menf21bmc: introduce MEN 14F021P00 BMC MFD Core driver
The MEN 14F021P00 Board Management Controller provides an
I2C interface to the host to access the feature implemented in the BMC.
The BMC is a PIC Microntroller assembled on CPCI Card from MEN Mikroelektronik
and on a few Box/Display Computer.
Added MFD Core driver, supporting the I2C communication to the device.
The MFD driver currently supports the following features:
- Watchdog
- LEDs
- Hwmon (voltage monitoring)
Signed-off-by: Andreas Werner
---
drivers/mfd/Kconfig | 12 +
drivers/mfd/Makefile| 1 +
drivers/mfd/menf21bmc.c | 132
3 files changed, 145 insertions(+)
create mode 100644 drivers/mfd/menf21bmc.c
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index b8d9ca0..bf155b9 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -453,6 +453,18 @@ config MFD_MAX8998
additional drivers must be enabled in order to use the functionality
of the device.
+config MFD_MENF21BMC
+ tristate "MEN 14F021P00 Board Management Controller Support"
+ depends on I2C=y
+ select MFD_CORE
+ help
+ Say yes here to add support for the MEN 14F021P00 BMC
+ which is a Board Management Controller connected to the I2C bus.
+ The device supports multiple sub-devices like LED, HWMON and WDT.
+ This driver provides common support for accessing the devices;
+ additional drivers must be enabled in order to use the
+ functionality of the BMC device.
+
config EZX_PCAP
bool "Motorola EZXPCAP Support"
depends on SPI_MASTER
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 4e2bc25..37bf336 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -169,6 +169,7 @@ obj-$(CONFIG_MFD_AS3711)+= as3711.o
obj-$(CONFIG_MFD_AS3722) += as3722.o
obj-$(CONFIG_MFD_STW481X) += stw481x.o
obj-$(CONFIG_MFD_IPAQ_MICRO) += ipaq-micro.o
+obj-$(CONFIG_MFD_MENF21BMC)+= menf21bmc.o
intel-soc-pmic-objs:= intel_soc_pmic_core.o intel_soc_pmic_crc.o
obj-$(CONFIG_INTEL_SOC_PMIC) += intel-soc-pmic.o
diff --git a/drivers/mfd/menf21bmc.c b/drivers/mfd/menf21bmc.c
new file mode 100644
index 000..a6eb03f
--- /dev/null
+++ b/drivers/mfd/menf21bmc.c
@@ -0,0 +1,132 @@
+/*
+ * MEN 14F021P00 Board Management Controller (BMC) MFD Core Driver.
+ *
+ * Copyright (C) 2014 MEN Mikro Elektronik Nuernberg GmbH
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#define BMC_CMD_WDT_EXIT_PROD 0x18
+#define BMC_CMD_WDT_PROD_STAT 0x19
+#define BMC_CMD_REV_MAJOR 0x80
+#define BMC_CMD_REV_MINOR 0x81
+#define BMC_CMD_REV_MAIN 0x82
+
+static struct mfd_cell menf21bmc_cell[] = {
+ { .name = "menf21bmc_wdt", },
+ { .name = "menf21bmc_led", },
+ { .name = "menf21bmc_hwmon", }
+};
+
+static int menf21bmc_wdt_exit_prod_mode(struct i2c_client *client)
+{
+ int val, ret;
+
+ val = i2c_smbus_read_byte_data(client, BMC_CMD_WDT_PROD_STAT);
+ if (val < 0)
+ return val;
+
+ /*
+* Production mode should be not active after delivery of the Board.
+* To be sure we check it, inform the user and exit the mode
+* if active.
+*/
+ if (val == 0x00) {
+ dev_info(&client->dev,
+ "BMC in production mode. Exit production mode\n");
+
+ ret = i2c_smbus_write_byte(client, BMC_CMD_WDT_EXIT_PROD);
+ if (ret < 0)
+ return ret;
+ }
+
+ return 0;
+}
+
+static int
+menf21bmc_probe(struct i2c_client *client, const struct i2c_device_id *ids)
+{
+ int ret;
+ int rev_major, rev_minor, rev_main;
+
+ ret = i2c_check_functionality(client->adapter,
+ I2C_FUNC_SMBUS_BYTE_DATA |
+ I2C_FUNC_SMBUS_WORD_DATA |
+ I2C_FUNC_SMBUS_BYTE);
+ if (!ret)
+ return -ENODEV;
+
+ rev_major = i2c_smbus_read_word_data(client, BMC_CMD_REV_MAJOR);
+ if (rev_major < 0) {
+ dev_err(&client->dev, "failed to get BMC major revision\n");
+ return rev_major;
+ }
+
+ rev_minor = i2c_smbus_read_word_data(client, BMC_CMD_REV_MINOR);
+ if (rev_minor < 0) {
+ dev_err(&client->dev, "failed to get BMC minor revision\n");
+ return rev_minor;
+ }
+
+ rev_main = i2c_smbus_read_word_data(client, BMC_CMD_REV_MAIN);
+ if (rev_mai
[PATCH v4 0/4] Introduce MEN 14F021P BMC driver series
This patch set add support for the MEN 14F021P00 Board Management called BMC. The BMC is a PIC Mikrocontroller which assembled on almost all of our 3U Compact PCI CPU board and a few Box PCs. main part of the BMC is to start and monitor the board, but there are a lot more features which can be accessed using an I2C Host interface Features supported in this Patchset: - Watchdog - LEDs - HWMON The Patchset includes a MFD Core driver, Watchdog, hwmon and LEDs driver. Changes in v4: - fixed some style issues - fixed GPL license version - added hwmon voltage monitoring slave driver Changes in v3: - deleted i2c_smbus wrapper functions and use native one - some cosmentics and variable renaming to be more clear - renamed "leave production" mode to "exit production mode" Changes in v2: - changed i2c_smbus_read wrapper function to return both, value and error. - moved "leave production mode" from Watchdog driver to mfd core. - fixed some return values in the watchdog driver to return the original error value instead of -EIO. Andreas Werner (4): drivers/mfd/menf21bmc: introduce MEN 14F021P00 BMC MFD Core driver drivers/watchdog/menf21bmc_wdt: introduce MEN 14F021P00 BMC Watchdog driver drivers/leds/leds-menf21bmc: introduce MEN 14F021P00 BMC LED driver drivers/hwmon/menf21bmc_hwmon: introduce MEN14F021P00 BMC HWMON driver drivers/hwmon/Kconfig| 7 ++ drivers/hwmon/Makefile | 1 + drivers/hwmon/menf21bmc_hwmon.c | 238 +++ drivers/leds/Kconfig | 6 + drivers/leds/Makefile| 1 + drivers/leds/leds-menf21bmc.c| 131 + drivers/mfd/Kconfig | 12 ++ drivers/mfd/Makefile | 1 + drivers/mfd/menf21bmc.c | 132 ++ drivers/watchdog/Kconfig | 7 ++ drivers/watchdog/Makefile| 1 + drivers/watchdog/menf21bmc_wdt.c | 203 + 12 files changed, 740 insertions(+) create mode 100644 drivers/hwmon/menf21bmc_hwmon.c create mode 100644 drivers/leds/leds-menf21bmc.c create mode 100644 drivers/mfd/menf21bmc.c create mode 100644 drivers/watchdog/menf21bmc_wdt.c -- 2.0.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 3/3] drivers/leds/leds-menf21bmc: introduce MEN 14F021P00 BMC LED driver
On Fri, Aug 08, 2014 at 04:36:55PM +0200, Wim Van Sebroeck wrote: > > On 08/08/2014 12:49 AM, Andreas Werner wrote: > > >On Wed, Jul 30, 2014 at 06:57:46AM -0700, Guenter Roeck wrote: > > >>On 07/30/2014 01:08 AM, Andreas Werner wrote: > > >>>On Tue, Jul 29, 2014 at 02:47:08PM -0700, Guenter Roeck wrote: > > >>>>On 07/29/2014 02:12 PM, Wim Van Sebroeck wrote: > > >>>>>Hi Andreas, > > >>>>> > > >>>>>>aOn Thu, Jul 24, 2014 at 03:00:09PM -0700, Bryan Wu wrote: > > >>>>>>>On Thu, Jul 17, 2014 at 6:18 AM, Andreas Werner > > >>>>>>> wrote: > > >>>>>>>>Added driver to support the 14F021P00 BMC LEDs. > > >>>>>>>>The BMC is a Board Management Controll include four LEDs which > > >>>>>>>>can be switched on and off. > > >>>>>>>> > > >>>>>>>>This driver use the I2C interface to the BMC using the menf21bmc > > >>>>>>>>MFD Core driver. > > >>>>>>>> > > >>>>>>>>Signed-off-by: Andreas Werner > > >>>>>>>>--- > > >>>>>>>> drivers/leds/Kconfig | 6 ++ > > >>>>>>>> drivers/leds/Makefile | 1 + > > >>>>>>>> drivers/leds/leds-menf21bmc.c | 134 > > >>>>>>>> ++ > > >>>>>>>> 3 files changed, 141 insertions(+) > > >>>>>>>> create mode 100644 drivers/leds/leds-menf21bmc.c > > >>>>>>>> > > >>>>>>>>diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig > > >>>>>>>>index 27cf0cd..d38ff3f 100644 > > >>>>>>>>--- a/drivers/leds/Kconfig > > >>>>>>>>+++ b/drivers/leds/Kconfig > > >>>>>>>>@@ -458,6 +458,12 @@ config LEDS_OT200 > > >>>>>>>> This option enables support for the LEDs on the Bachmann > > >>>>>>>> OT200. > > >>>>>>>> Say Y to enable LEDs on the Bachmann OT200. > > >>>>>>>> > > >>>>>>>>+config LEDS_MENF21BMC > > >>>>>>>>+ tristate "LED support for the MEN 14F021P00 BMC" > > >>>>>>>>+ depends on LEDS_CLASS && MFD_MENF21BMC > > >>>>>>> > > >>>>>>>I think it also depends on I2C. > > >>>>>> > > >>>>>>Yes you are right. > > >>>>>> > > >>>>>>> > > >>>>>>>>+ help > > >>>>>>>>+ Say Y here to include support for the MEN 14F021P00 BMC > > >>>>>>>>LEDs. > > >>>>>>>>+ > > >>>>>>>> comment "LED driver for blink(1) USB RGB LED is under Special HID > > >>>>>>>> drivers (HID_THINGM)" > > >>>>>>>> > > >>>>>>>> config LEDS_BLINKM > > >>>>>>>>diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile > > >>>>>>>>index 3c03666..cadc433 100644 > > >>>>>>>>--- a/drivers/leds/Makefile > > >>>>>>>>+++ b/drivers/leds/Makefile > > >>>>>>>>@@ -53,6 +53,7 @@ obj-$(CONFIG_LEDS_MAX8997)+= > > >>>>>>>>leds-max8997.o > > >>>>>>>> obj-$(CONFIG_LEDS_LM355x) += leds-lm355x.o > > >>>>>>>> obj-$(CONFIG_LEDS_BLINKM) += leds-blinkm.o > > >>>>>>>> obj-$(CONFIG_LEDS_VERSATILE) += leds-versatile.o > > >>>>>>>>+obj-$(CONFIG_LEDS_MENF21BMC) += leds-menf21bmc.o > > >>>>>>>> > > >>>>>>>> # LED SPI Drivers > > >>>>>>>> obj-$(CONFIG_LEDS_DAC124S085) += leds-dac124s085.o > > >>>>>>>>diff --git a/drivers/leds/leds-menf21bmc.c > > >>>>>>>>b/drivers/leds/leds-menf21bmc.c > > &g
Re: [PATCH v3 3/3] drivers/leds/leds-menf21bmc: introduce MEN 14F021P00 BMC LED driver
On Wed, Jul 30, 2014 at 06:57:46AM -0700, Guenter Roeck wrote: > On 07/30/2014 01:08 AM, Andreas Werner wrote: > >On Tue, Jul 29, 2014 at 02:47:08PM -0700, Guenter Roeck wrote: > >>On 07/29/2014 02:12 PM, Wim Van Sebroeck wrote: > >>>Hi Andreas, > >>> > >>>>aOn Thu, Jul 24, 2014 at 03:00:09PM -0700, Bryan Wu wrote: > >>>>>On Thu, Jul 17, 2014 at 6:18 AM, Andreas Werner > >>>>>wrote: > >>>>>>Added driver to support the 14F021P00 BMC LEDs. > >>>>>>The BMC is a Board Management Controll include four LEDs which > >>>>>>can be switched on and off. > >>>>>> > >>>>>>This driver use the I2C interface to the BMC using the menf21bmc MFD > >>>>>>Core driver. > >>>>>> > >>>>>>Signed-off-by: Andreas Werner > >>>>>>--- > >>>>>> drivers/leds/Kconfig | 6 ++ > >>>>>> drivers/leds/Makefile | 1 + > >>>>>> drivers/leds/leds-menf21bmc.c | 134 > >>>>>> ++ > >>>>>> 3 files changed, 141 insertions(+) > >>>>>> create mode 100644 drivers/leds/leds-menf21bmc.c > >>>>>> > >>>>>>diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig > >>>>>>index 27cf0cd..d38ff3f 100644 > >>>>>>--- a/drivers/leds/Kconfig > >>>>>>+++ b/drivers/leds/Kconfig > >>>>>>@@ -458,6 +458,12 @@ config LEDS_OT200 > >>>>>> This option enables support for the LEDs on the Bachmann > >>>>>> OT200. > >>>>>> Say Y to enable LEDs on the Bachmann OT200. > >>>>>> > >>>>>>+config LEDS_MENF21BMC > >>>>>>+ tristate "LED support for the MEN 14F021P00 BMC" > >>>>>>+ depends on LEDS_CLASS && MFD_MENF21BMC > >>>>> > >>>>>I think it also depends on I2C. > >>>> > >>>>Yes you are right. > >>>> > >>>>> > >>>>>>+ help > >>>>>>+ Say Y here to include support for the MEN 14F021P00 BMC LEDs. > >>>>>>+ > >>>>>> comment "LED driver for blink(1) USB RGB LED is under Special HID > >>>>>> drivers (HID_THINGM)" > >>>>>> > >>>>>> config LEDS_BLINKM > >>>>>>diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile > >>>>>>index 3c03666..cadc433 100644 > >>>>>>--- a/drivers/leds/Makefile > >>>>>>+++ b/drivers/leds/Makefile > >>>>>>@@ -53,6 +53,7 @@ obj-$(CONFIG_LEDS_MAX8997)+= > >>>>>>leds-max8997.o > >>>>>> obj-$(CONFIG_LEDS_LM355x) += leds-lm355x.o > >>>>>> obj-$(CONFIG_LEDS_BLINKM) += leds-blinkm.o > >>>>>> obj-$(CONFIG_LEDS_VERSATILE) += leds-versatile.o > >>>>>>+obj-$(CONFIG_LEDS_MENF21BMC) += leds-menf21bmc.o > >>>>>> > >>>>>> # LED SPI Drivers > >>>>>> obj-$(CONFIG_LEDS_DAC124S085) += leds-dac124s085.o > >>>>>>diff --git a/drivers/leds/leds-menf21bmc.c > >>>>>>b/drivers/leds/leds-menf21bmc.c > >>>>>>new file mode 100644 > >>>>>>index 000..5eaa119 > >>>>>>--- /dev/null > >>>>>>+++ b/drivers/leds/leds-menf21bmc.c > >>>>>>@@ -0,0 +1,134 @@ > >>>>>>+/* > >>>>>>+ * MEN 14F021P00 Board Management Controller (BMC) LEDs Driver. > >>>>>>+ * > >>>>>>+ * This is the core LED driver of the MEN 14F021P00 BMC. > >>>>>>+ * There are four LEDs available which can be switched on and off. > >>>>>>+ * STATUS LED, HOT SWAP LED, USER LED 1, USER LED 2 > >>>>>>+ * > >>>>>>+ * Copyright (C) 2014 MEN Mikro Elektronik Nuernberg GmbH > >>>>>>+ * Author: Andreas Werner > >>>>>>+ * All rights reserved. > >>>>>>+ * > >>>>>>+ * This program is free software; you can redistribute it and/or > >>>
Re: [REVERT][v3.16-rc7][STABLE] usb: xhci: Prefer endpoint context dequeue pointer over stopped_trb
Hi Joseph, > Julius, I was hoping to get your feedback, since you are the patch > author. Do you think gathering any additional data will help diagnose > this issue, or would it be best to continue with this revert request? As I understand it, this crash will disappear with Mathias' new rework for finding the cycle state bit in http://www.spinics.net/lists/linux-usb/msg111259.html , so a revert should not be necessary. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 3/3] drivers/leds/leds-menf21bmc: introduce MEN 14F021P00 BMC LED driver
On Tue, Jul 29, 2014 at 02:47:08PM -0700, Guenter Roeck wrote: > On 07/29/2014 02:12 PM, Wim Van Sebroeck wrote: > >Hi Andreas, > > > >>aOn Thu, Jul 24, 2014 at 03:00:09PM -0700, Bryan Wu wrote: > >>>On Thu, Jul 17, 2014 at 6:18 AM, Andreas Werner > >>>wrote: > >>>>Added driver to support the 14F021P00 BMC LEDs. > >>>>The BMC is a Board Management Controll include four LEDs which > >>>>can be switched on and off. > >>>> > >>>>This driver use the I2C interface to the BMC using the menf21bmc MFD Core > >>>>driver. > >>>> > >>>>Signed-off-by: Andreas Werner > >>>>--- > >>>> drivers/leds/Kconfig | 6 ++ > >>>> drivers/leds/Makefile | 1 + > >>>> drivers/leds/leds-menf21bmc.c | 134 > >>>> ++ > >>>> 3 files changed, 141 insertions(+) > >>>> create mode 100644 drivers/leds/leds-menf21bmc.c > >>>> > >>>>diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig > >>>>index 27cf0cd..d38ff3f 100644 > >>>>--- a/drivers/leds/Kconfig > >>>>+++ b/drivers/leds/Kconfig > >>>>@@ -458,6 +458,12 @@ config LEDS_OT200 > >>>> This option enables support for the LEDs on the Bachmann OT200. > >>>> Say Y to enable LEDs on the Bachmann OT200. > >>>> > >>>>+config LEDS_MENF21BMC > >>>>+ tristate "LED support for the MEN 14F021P00 BMC" > >>>>+ depends on LEDS_CLASS && MFD_MENF21BMC > >>> > >>>I think it also depends on I2C. > >> > >>Yes you are right. > >> > >>> > >>>>+ help > >>>>+ Say Y here to include support for the MEN 14F021P00 BMC LEDs. > >>>>+ > >>>> comment "LED driver for blink(1) USB RGB LED is under Special HID > >>>> drivers (HID_THINGM)" > >>>> > >>>> config LEDS_BLINKM > >>>>diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile > >>>>index 3c03666..cadc433 100644 > >>>>--- a/drivers/leds/Makefile > >>>>+++ b/drivers/leds/Makefile > >>>>@@ -53,6 +53,7 @@ obj-$(CONFIG_LEDS_MAX8997)+= leds-max8997.o > >>>> obj-$(CONFIG_LEDS_LM355x) += leds-lm355x.o > >>>> obj-$(CONFIG_LEDS_BLINKM) += leds-blinkm.o > >>>> obj-$(CONFIG_LEDS_VERSATILE) += leds-versatile.o > >>>>+obj-$(CONFIG_LEDS_MENF21BMC) += leds-menf21bmc.o > >>>> > >>>> # LED SPI Drivers > >>>> obj-$(CONFIG_LEDS_DAC124S085) += leds-dac124s085.o > >>>>diff --git a/drivers/leds/leds-menf21bmc.c b/drivers/leds/leds-menf21bmc.c > >>>>new file mode 100644 > >>>>index 000..5eaa119 > >>>>--- /dev/null > >>>>+++ b/drivers/leds/leds-menf21bmc.c > >>>>@@ -0,0 +1,134 @@ > >>>>+/* > >>>>+ * MEN 14F021P00 Board Management Controller (BMC) LEDs Driver. > >>>>+ * > >>>>+ * This is the core LED driver of the MEN 14F021P00 BMC. > >>>>+ * There are four LEDs available which can be switched on and off. > >>>>+ * STATUS LED, HOT SWAP LED, USER LED 1, USER LED 2 > >>>>+ * > >>>>+ * Copyright (C) 2014 MEN Mikro Elektronik Nuernberg GmbH > >>>>+ * Author: Andreas Werner > >>>>+ * All rights reserved. > >>>>+ * > >>>>+ * This program is free software; you can redistribute it and/or > >>>>modify it > >>>>+ * under the terms of the GNU General Public License as published by > >>>>the > >>>>+ * Free Software Foundation; either version 2 of the License, or (at > >>>>your > >>>>+ * option) any later version. > >>>>+ * > >>>>+ */ > >>>>+ > >>>>+#include > >>>>+#include > >>>>+#include > >>>>+#include > >>>>+#include > >>>>+ > >>>>+#define BMC_CMD_LED_GET_SET0xA0 > >>>>+#define BMC_BIT_LED_STATUS BIT(0) > >>>>+#define BMC_BIT_LED_HOTSWAPBIT(1) > >>>>+#define BMC_BIT_LED_USER1 BIT(2) > >>>>+#d
Re: [PATCH v3 3/3] drivers/leds/leds-menf21bmc: introduce MEN 14F021P00 BMC LED driver
aOn Thu, Jul 24, 2014 at 03:00:09PM -0700, Bryan Wu wrote:
> On Thu, Jul 17, 2014 at 6:18 AM, Andreas Werner wrote:
> > Added driver to support the 14F021P00 BMC LEDs.
> > The BMC is a Board Management Controll include four LEDs which
> > can be switched on and off.
> >
> > This driver use the I2C interface to the BMC using the menf21bmc MFD Core
> > driver.
> >
> > Signed-off-by: Andreas Werner
> > ---
> > drivers/leds/Kconfig | 6 ++
> > drivers/leds/Makefile | 1 +
> > drivers/leds/leds-menf21bmc.c | 134
> > ++
> > 3 files changed, 141 insertions(+)
> > create mode 100644 drivers/leds/leds-menf21bmc.c
> >
> > diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
> > index 27cf0cd..d38ff3f 100644
> > --- a/drivers/leds/Kconfig
> > +++ b/drivers/leds/Kconfig
> > @@ -458,6 +458,12 @@ config LEDS_OT200
> > This option enables support for the LEDs on the Bachmann OT200.
> > Say Y to enable LEDs on the Bachmann OT200.
> >
> > +config LEDS_MENF21BMC
> > + tristate "LED support for the MEN 14F021P00 BMC"
> > + depends on LEDS_CLASS && MFD_MENF21BMC
>
> I think it also depends on I2C.
Yes you are right.
>
> > + help
> > + Say Y here to include support for the MEN 14F021P00 BMC LEDs.
> > +
> > comment "LED driver for blink(1) USB RGB LED is under Special HID drivers
> > (HID_THINGM)"
> >
> > config LEDS_BLINKM
> > diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
> > index 3c03666..cadc433 100644
> > --- a/drivers/leds/Makefile
> > +++ b/drivers/leds/Makefile
> > @@ -53,6 +53,7 @@ obj-$(CONFIG_LEDS_MAX8997)+= leds-max8997.o
> > obj-$(CONFIG_LEDS_LM355x) += leds-lm355x.o
> > obj-$(CONFIG_LEDS_BLINKM) += leds-blinkm.o
> > obj-$(CONFIG_LEDS_VERSATILE) += leds-versatile.o
> > +obj-$(CONFIG_LEDS_MENF21BMC) += leds-menf21bmc.o
> >
> > # LED SPI Drivers
> > obj-$(CONFIG_LEDS_DAC124S085) += leds-dac124s085.o
> > diff --git a/drivers/leds/leds-menf21bmc.c b/drivers/leds/leds-menf21bmc.c
> > new file mode 100644
> > index 000..5eaa119
> > --- /dev/null
> > +++ b/drivers/leds/leds-menf21bmc.c
> > @@ -0,0 +1,134 @@
> > +/*
> > + * MEN 14F021P00 Board Management Controller (BMC) LEDs Driver.
> > + *
> > + * This is the core LED driver of the MEN 14F021P00 BMC.
> > + * There are four LEDs available which can be switched on and off.
> > + * STATUS LED, HOT SWAP LED, USER LED 1, USER LED 2
> > + *
> > + * Copyright (C) 2014 MEN Mikro Elektronik Nuernberg GmbH
> > + * Author: Andreas Werner
> > + * All rights reserved.
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > it
> > + * under the terms of the GNU General Public License as published by
> > the
> > + * Free Software Foundation; either version 2 of the License, or (at
> > your
> > + * option) any later version.
> > + *
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#define BMC_CMD_LED_GET_SET0xA0
> > +#define BMC_BIT_LED_STATUS BIT(0)
> > +#define BMC_BIT_LED_HOTSWAPBIT(1)
> > +#define BMC_BIT_LED_USER1 BIT(2)
> > +#define BMC_BIT_LED_USER2 BIT(3)
> > +
> > +struct menf21bmc_led {
> > + struct led_classdev cdev;
> > + u8 led_bit;
> > + const char *name;
> > + struct i2c_client *i2c_client;
> > +};
> > +
> > +static struct menf21bmc_led leds[] = {
> > + {
> > + .name = "menf21bmc:led_status",
> > + .led_bit = BMC_BIT_LED_STATUS,
> > + },
> > + {
> > + .name = "menf21bmc:led_hotswap",
> > + .led_bit = BMC_BIT_LED_HOTSWAP,
> > + },
> > + {
> > + .name = "menf21bmc:led_user1",
> > + .led_bit = BMC_BIT_LED_USER1,
> > + },
> > + {
> > + .name = "menf21bmc:led_user2",
> > + .led_bit = BMC_BIT_LED_USER2,
> > + }
> > +};
> > +
> > +static DEFINE_MUTEX(led_lock);
> > +
> > +static void
> > +menf21bmc_led_set(struct led_classdev *led_cdev, enum led_brightness value)
> > +{
> > +
Re: [PATCH v2 3/3] drivers/leds/leds-menf21bmc: introduce MEN 14F021P00 BMC LED driver
On Wed, Jun 25, 2014 at 04:10:55PM -0700, Bryan Wu wrote:
> On Tue, May 27, 2014 at 2:08 AM, Andreas Werner wrote:
> > Added driver to support the 14F021P00 BMC LEDs.
> > The BMC is a Board Management Controll include four LEDs which
> > can be switched on and off.
> >
> > This driver use the I2C interface to the BMC using the menf21bmc MFD Core
> > driver.
> >
>
> Will you submit v2 patch based on Lee and others' review? I prefer to
> review the new one.
>
Patch v3 is submitted so you can start review it :-)
Thanks
Andy
> Thanks,
> -Bryan
>
> > Signed-off-by: Andreas Werner
> > ---
> > drivers/leds/Kconfig | 6 ++
> > drivers/leds/Makefile | 2 +-
> > drivers/leds/leds-menf21bmc.c | 136
> > ++
> > 3 files changed, 143 insertions(+), 1 deletion(-)
> > create mode 100644 drivers/leds/leds-menf21bmc.c
> >
> > diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
> > index 1e81d7a..8f98e0f 100644
> > --- a/drivers/leds/Kconfig
> > +++ b/drivers/leds/Kconfig
> > @@ -466,6 +466,12 @@ config LEDS_OT200
> > This option enables support for the LEDs on the Bachmann OT200.
> > Say Y to enable LEDs on the Bachmann OT200.
> >
> > +config LEDS_MENF21BMC
> > + tristate "LED support for the MEN 14F021P00 BMC"
> > + depends on LEDS_CLASS && MFD_MENF21BMC
> > + help
> > + Say Y here to include support for the MEN 14F021P00 BMC LEDs.
> > +
> > comment "LED driver for blink(1) USB RGB LED is under Special HID drivers
> > (HID_THINGM)"
> >
> > config LEDS_BLINKM
> > diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
> > index 79c5155..1c465fe 100644
> > --- a/drivers/leds/Makefile
> > +++ b/drivers/leds/Makefile
> > @@ -54,7 +54,7 @@ obj-$(CONFIG_LEDS_MAX8997)+= leds-max8997.o
> > obj-$(CONFIG_LEDS_LM355x) += leds-lm355x.o
> > obj-$(CONFIG_LEDS_BLINKM) += leds-blinkm.o
> > obj-$(CONFIG_LEDS_VERSATILE) += leds-versatile.o
> > -
> > +obj-$(CONFIG_LEDS_MENF21BMC) += leds-menf21bmc.o
> > # LED SPI Drivers
> > obj-$(CONFIG_LEDS_DAC124S085) += leds-dac124s085.o
> >
> > diff --git a/drivers/leds/leds-menf21bmc.c b/drivers/leds/leds-menf21bmc.c
> > new file mode 100644
> > index 000..6099524
> > --- /dev/null
> > +++ b/drivers/leds/leds-menf21bmc.c
> > @@ -0,0 +1,136 @@
> > +/*
> > + * MEN 14F021P00 Board Management Controller (BMC) LEDs Driver.
> > + *
> > + * This is the core LED driver of the MEN 14F021P00 BMC.
> > + * There are four LEDs available which can be switched on and off.
> > + * STATUS LED, HOT SWAP LED, USER LED 1, USER LED 2
> > + *
> > + * Copyright (C) 2014 MEN Mikro Elektronik Nuernberg GmbH
> > + * Author: Andreas Werner
> > + * All rights reserved.
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > it
> > + * under the terms of the GNU General Public License as published by
> > the
> > + * Free Software Foundation; either version 2 of the License, or (at
> > your
> > + * option) any later version.
> > + *
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#define BMC_CMD_LED_GET_SET0xA0
> > +#define BMC_BIT_LED_STATUS BIT(0)
> > +#define BMC_BIT_LED_HOTSWAPBIT(1)
> > +#define BMC_BIT_LED_USER1 BIT(2)
> > +#define BMC_BIT_LED_USER2 BIT(3)
> > +
> > +struct menf21bmc_led_data {
> > + struct led_classdev cdev;
> > + struct menf21bmc *menf21bmc;
> > + u8 led_bit;
> > + const char *name;
> > +};
> > +
> > +static struct menf21bmc_led_data leds[] = {
> > + {
> > + .name = "menf21bmc:led_status",
> > + .led_bit = BMC_BIT_LED_STATUS,
> > + },
> > + {
> > + .name = "menf21bmc:led_hotswap",
> > + .led_bit = BMC_BIT_LED_HOTSWAP,
> > + },
> > + {
> > + .name = "menf21bmc:led_user1",
> > + .led_bit = BMC_BIT_LED_USER1,
> > + },
> > + {
> > + .name = "menf21bmc:led_user2",
> > + .led_bit = BMC_BIT_LED_USER2,
> > + }
> > +};
> > +
> > +static DEFINE_MU
Re: [PATCH] usb: xhci: Fix Set TR Dequeue Pointer cycle state for quirky xHCs
> Hmm. Wouldn't it be safer to have a quirk for this, and only enable > the workaround if the Asmedia controller is detected? This code is so > complicated that it is difficult to see whether this could have a > harmful effect on controllers without the bug. Sorry for making it complicated, but it kinda has been like that before already... I don't think the new patch adds much confusion on its own. I would really advise against making this a quirk: checking for it in every case essentially doesn't cost us anything (just one more register compare that is negligible against all the cache-coherent memory accesses of walking the ring), and hardcoding a quirk would mean that we have to identify and add every host controller that does this individually. I still haven't seen anything in the XHCI spec that actually forbids this behavior, so it might be a perfectly legal interpretation and who knows how many host controllers chose to do it that way. Until we find them all, we would have some really bad and hard to track down bugs on those controllers (we really just got lucky this time that Maciej was able to catch it in a bisect). I think it's better to program the driver defensively and able to deal with unexpected situations in general. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 1/3] drivers/mfd/menf21bmc: introduce MEN 14F021P00 BMC MFD Core driver
On Thu, Jul 17, 2014 at 01:41:56PM +0100, Lee Jones wrote:
> On Thu, 17 Jul 2014, Andreas Werner wrote:
> > The MEN 14F021P00 Board Management Controller provides an
> > I2C interface to the host to access the feature implemented in the BMC.
> > The BMC is a PIC Microntroller assembled on CPCI Card from MEN
> > Mikroelektronik
> > and on a few Box/Display Computer.
> >
> > Added MFD Core driver, supporting the I2C communication to the device.
> >
> > The MFD driver currently supports the following features:
> > - Watchdog
> > - LEDs
> >
> > Signed-off-by: Andreas Werner
> > ---
> > drivers/mfd/Kconfig | 12 +
> > drivers/mfd/Makefile| 1 +
> > drivers/mfd/menf21bmc.c | 136
> >
> > 3 files changed, 149 insertions(+)
> > create mode 100644 drivers/mfd/menf21bmc.c
> >
> > diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> > index b8d9ca0..6e2cd14 100644
> > --- a/drivers/mfd/Kconfig
> > +++ b/drivers/mfd/Kconfig
> > @@ -453,6 +453,18 @@ config MFD_MAX8998
> > additional drivers must be enabled in order to use the functionality
> > of the device.
> >
> > +config MFD_MENF21BMC
> > + tristate "MEN 14F021P00 Board Management Controller Support"
> > + depends on I2C=y
> > + select MFD_CORE
> > + help
> > + Say yes here to add support for the MEN 14F021P00 BMC
> > + which is a Board Management Controller connected to the I2C bus.
> > + The device supports multiple sub-devices like LED and WDT.
> > + This driver provides common support for accessing the devices;
> > + additional drivers must be enabled in order to use the
> > + functionality of the BMC device.
>
> Can you mention what those devices are here in the help text?
>
I've mentioned the sub-devices "LED" and "WDT" but i can also write
the name to the help text like "menf21bmc_wdt" and "leds-menf21bmc".
> > config EZX_PCAP
> > bool "Motorola EZXPCAP Support"
> > depends on SPI_MASTER
> > diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> > index 4e2bc25..37bf336 100644
> > --- a/drivers/mfd/Makefile
> > +++ b/drivers/mfd/Makefile
> > @@ -169,6 +169,7 @@ obj-$(CONFIG_MFD_AS3711)+= as3711.o
> > obj-$(CONFIG_MFD_AS3722) += as3722.o
> > obj-$(CONFIG_MFD_STW481X) += stw481x.o
> > obj-$(CONFIG_MFD_IPAQ_MICRO) += ipaq-micro.o
> > +obj-$(CONFIG_MFD_MENF21BMC)+= menf21bmc.o
> >
> > intel-soc-pmic-objs:= intel_soc_pmic_core.o
> > intel_soc_pmic_crc.o
> > obj-$(CONFIG_INTEL_SOC_PMIC) += intel-soc-pmic.o
> > diff --git a/drivers/mfd/menf21bmc.c b/drivers/mfd/menf21bmc.c
> > new file mode 100644
> > index 000..76f94cd
> > --- /dev/null
> > +++ b/drivers/mfd/menf21bmc.c
> > @@ -0,0 +1,136 @@
> > +/*
> > + * MEN 14F021P00 Board Management Controller (BMC) MFD Core Driver.
> > + *
> > + * Copyright (C) 2014 MEN Mikro Elektronik Nuernberg GmbH
> > + * Author: Andreas Werner
> > + * All rights reserved.
>
> This normally resides wit the company, rather than the author.
Ok, i'wíll the author suff.
>
> > + * 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.
> > + *
>
> Remove this line.
>
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#define BMC_CMD_REV_MAJOR 0x80
> > +#define BMC_CMD_REV_MINOR 0x81
> > +#define BMC_CMD_REV_MAIN 0x82
> > +#define BMC_CMD_WDT_EXIT_PROD 0x18
> > +#define BMC_CMD_WDT_PROD_STAT 0x19
>
> If these are in the same address space, can you order them by number.
No problem, i will order them, they are in the same space.
>
> > +static struct mfd_cell menf21bmc_cell[] = {
> > + { .name = "menf21bmc_wdt", },
> > + { .name = "menf21bmc_led", },
> > +};
> > +
> > +static int menf21bmc_wdt_exit_prod_mode(struct i2c_client *client)
> > +{
> > + int val, ret;
> > +
> > + val = i2c_smbus_read_byte_data(client, BMC_CMD_WDT_PROD_STAT);
> > + if (val < 0)
> > + return val;
> > +
>
[PATCH v3 3/3] drivers/leds/leds-menf21bmc: introduce MEN 14F021P00 BMC LED driver
Added driver to support the 14F021P00 BMC LEDs.
The BMC is a Board Management Controll include four LEDs which
can be switched on and off.
This driver use the I2C interface to the BMC using the menf21bmc MFD Core
driver.
Signed-off-by: Andreas Werner
---
drivers/leds/Kconfig | 6 ++
drivers/leds/Makefile | 1 +
drivers/leds/leds-menf21bmc.c | 134 ++
3 files changed, 141 insertions(+)
create mode 100644 drivers/leds/leds-menf21bmc.c
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 27cf0cd..d38ff3f 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -458,6 +458,12 @@ config LEDS_OT200
This option enables support for the LEDs on the Bachmann OT200.
Say Y to enable LEDs on the Bachmann OT200.
+config LEDS_MENF21BMC
+ tristate "LED support for the MEN 14F021P00 BMC"
+ depends on LEDS_CLASS && MFD_MENF21BMC
+ help
+ Say Y here to include support for the MEN 14F021P00 BMC LEDs.
+
comment "LED driver for blink(1) USB RGB LED is under Special HID drivers
(HID_THINGM)"
config LEDS_BLINKM
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index 3c03666..cadc433 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -53,6 +53,7 @@ obj-$(CONFIG_LEDS_MAX8997)+= leds-max8997.o
obj-$(CONFIG_LEDS_LM355x) += leds-lm355x.o
obj-$(CONFIG_LEDS_BLINKM) += leds-blinkm.o
obj-$(CONFIG_LEDS_VERSATILE) += leds-versatile.o
+obj-$(CONFIG_LEDS_MENF21BMC) += leds-menf21bmc.o
# LED SPI Drivers
obj-$(CONFIG_LEDS_DAC124S085) += leds-dac124s085.o
diff --git a/drivers/leds/leds-menf21bmc.c b/drivers/leds/leds-menf21bmc.c
new file mode 100644
index 000..5eaa119
--- /dev/null
+++ b/drivers/leds/leds-menf21bmc.c
@@ -0,0 +1,134 @@
+/*
+ * MEN 14F021P00 Board Management Controller (BMC) LEDs Driver.
+ *
+ * This is the core LED driver of the MEN 14F021P00 BMC.
+ * There are four LEDs available which can be switched on and off.
+ * STATUS LED, HOT SWAP LED, USER LED 1, USER LED 2
+ *
+ * Copyright (C) 2014 MEN Mikro Elektronik Nuernberg GmbH
+ * Author: Andreas Werner
+ * All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#define BMC_CMD_LED_GET_SET0xA0
+#define BMC_BIT_LED_STATUS BIT(0)
+#define BMC_BIT_LED_HOTSWAPBIT(1)
+#define BMC_BIT_LED_USER1 BIT(2)
+#define BMC_BIT_LED_USER2 BIT(3)
+
+struct menf21bmc_led {
+ struct led_classdev cdev;
+ u8 led_bit;
+ const char *name;
+ struct i2c_client *i2c_client;
+};
+
+static struct menf21bmc_led leds[] = {
+ {
+ .name = "menf21bmc:led_status",
+ .led_bit = BMC_BIT_LED_STATUS,
+ },
+ {
+ .name = "menf21bmc:led_hotswap",
+ .led_bit = BMC_BIT_LED_HOTSWAP,
+ },
+ {
+ .name = "menf21bmc:led_user1",
+ .led_bit = BMC_BIT_LED_USER1,
+ },
+ {
+ .name = "menf21bmc:led_user2",
+ .led_bit = BMC_BIT_LED_USER2,
+ }
+};
+
+static DEFINE_MUTEX(led_lock);
+
+static void
+menf21bmc_led_set(struct led_classdev *led_cdev, enum led_brightness value)
+{
+ int led_val;
+ struct menf21bmc_led *led = container_of(led_cdev,
+ struct menf21bmc_led, cdev);
+
+ mutex_lock(&led_lock);
+ led_val = i2c_smbus_read_byte_data(led->i2c_client,
+ BMC_CMD_LED_GET_SET);
+ if (led_val < 0)
+ goto err_out;
+
+ if (value == LED_OFF)
+ led_val &= ~led->led_bit;
+ else
+ led_val |= led->led_bit;
+
+ i2c_smbus_write_byte_data(led->i2c_client,
+ BMC_CMD_LED_GET_SET, led_val);
+err_out:
+ mutex_unlock(&led_lock);
+}
+
+static int menf21bmc_led_probe(struct platform_device *pdev)
+{
+ int i;
+ int ret;
+ struct i2c_client *i2c_client = to_i2c_client(pdev->dev.parent);
+
+ for (i = 0; i < ARRAY_SIZE(leds); i++) {
+ leds[i].cdev.name = leds[i].name;
+ leds[i].cdev.brightness_set = menf21bmc_led_set;
+ leds[i].i2c_client = i2c_client;
+ ret = led_classdev_register(&pdev->dev, &leds[i].cdev);
+ if (ret < 0)
+ goto err_free_leds;
+ }
+ dev_info(&pdev->dev, "MEN 140F21P00 BMC LED device enabled\n");
+
+
[PATCH v3 1/3] drivers/mfd/menf21bmc: introduce MEN 14F021P00 BMC MFD Core driver
The MEN 14F021P00 Board Management Controller provides an
I2C interface to the host to access the feature implemented in the BMC.
The BMC is a PIC Microntroller assembled on CPCI Card from MEN Mikroelektronik
and on a few Box/Display Computer.
Added MFD Core driver, supporting the I2C communication to the device.
The MFD driver currently supports the following features:
- Watchdog
- LEDs
Signed-off-by: Andreas Werner
---
drivers/mfd/Kconfig | 12 +
drivers/mfd/Makefile| 1 +
drivers/mfd/menf21bmc.c | 136
3 files changed, 149 insertions(+)
create mode 100644 drivers/mfd/menf21bmc.c
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index b8d9ca0..6e2cd14 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -453,6 +453,18 @@ config MFD_MAX8998
additional drivers must be enabled in order to use the functionality
of the device.
+config MFD_MENF21BMC
+ tristate "MEN 14F021P00 Board Management Controller Support"
+ depends on I2C=y
+ select MFD_CORE
+ help
+ Say yes here to add support for the MEN 14F021P00 BMC
+ which is a Board Management Controller connected to the I2C bus.
+ The device supports multiple sub-devices like LED and WDT.
+ This driver provides common support for accessing the devices;
+ additional drivers must be enabled in order to use the
+ functionality of the BMC device.
+
config EZX_PCAP
bool "Motorola EZXPCAP Support"
depends on SPI_MASTER
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 4e2bc25..37bf336 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -169,6 +169,7 @@ obj-$(CONFIG_MFD_AS3711)+= as3711.o
obj-$(CONFIG_MFD_AS3722) += as3722.o
obj-$(CONFIG_MFD_STW481X) += stw481x.o
obj-$(CONFIG_MFD_IPAQ_MICRO) += ipaq-micro.o
+obj-$(CONFIG_MFD_MENF21BMC)+= menf21bmc.o
intel-soc-pmic-objs:= intel_soc_pmic_core.o intel_soc_pmic_crc.o
obj-$(CONFIG_INTEL_SOC_PMIC) += intel-soc-pmic.o
diff --git a/drivers/mfd/menf21bmc.c b/drivers/mfd/menf21bmc.c
new file mode 100644
index 000..76f94cd
--- /dev/null
+++ b/drivers/mfd/menf21bmc.c
@@ -0,0 +1,136 @@
+/*
+ * MEN 14F021P00 Board Management Controller (BMC) MFD Core Driver.
+ *
+ * Copyright (C) 2014 MEN Mikro Elektronik Nuernberg GmbH
+ * Author: Andreas Werner
+ * All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#define BMC_CMD_REV_MAJOR 0x80
+#define BMC_CMD_REV_MINOR 0x81
+#define BMC_CMD_REV_MAIN 0x82
+#define BMC_CMD_WDT_EXIT_PROD 0x18
+#define BMC_CMD_WDT_PROD_STAT 0x19
+
+static struct mfd_cell menf21bmc_cell[] = {
+ { .name = "menf21bmc_wdt", },
+ { .name = "menf21bmc_led", },
+};
+
+static int menf21bmc_wdt_exit_prod_mode(struct i2c_client *client)
+{
+ int val, ret;
+
+ val = i2c_smbus_read_byte_data(client, BMC_CMD_WDT_PROD_STAT);
+ if (val < 0)
+ return val;
+
+ /*
+* Production mode should be not active after delivery of the Board.
+* To be sure we check it, inform the user and exit the mode
+* if active.
+*/
+ if (val == 0x00) {
+ dev_info(&client->dev,
+ "BMC in production mode. Exit production mode\n");
+
+ ret = i2c_smbus_write_byte(client, BMC_CMD_WDT_EXIT_PROD);
+ if (ret < 0)
+ return ret;
+ }
+
+ return 0;
+}
+
+static int
+menf21bmc_probe(struct i2c_client *client, const struct i2c_device_id *ids)
+{
+ int ret;
+ int rev_major, rev_minor, rev_main;
+
+ if (!i2c_check_functionality(client->adapter,
+I2C_FUNC_SMBUS_BYTE_DATA |
+I2C_FUNC_SMBUS_WORD_DATA |
+I2C_FUNC_SMBUS_BYTE))
+ return -ENODEV;
+
+ rev_major = i2c_smbus_read_word_data(client, BMC_CMD_REV_MAJOR);
+ if (rev_major < 0) {
+ dev_err(&client->dev, "failed to get BMC major revision\n");
+ return rev_major;
+ }
+
+ rev_minor = i2c_smbus_read_word_data(client, BMC_CMD_REV_MINOR);
+ if (rev_minor < 0) {
+ dev_err(&client->dev, "failed to get BMC minor revision\n");
+ return rev_minor;
+ }
+
+ rev_main = i2c_smbus_read_word_data(client, BMC_CMD_REV_MAIN);
+ if (rev_main < 0) {
+ dev_err(&client->dev, "failed to
[PATCH v3 2/3] drivers/watchdog/menf21bmc_wdt: introduce MEN 14F021P00 BMC Watchdog driver
Added driver to support the 14F021P00 BMC Watchdog.
The BMC is a Board Management Controller including watchdog functionality.
This driver use the I2C interface to the BMC using the menf21bmc MFD Core
driver.
Signed-off-by: Andreas Werner
---
drivers/watchdog/Kconfig | 7 ++
drivers/watchdog/Makefile| 1 +
drivers/watchdog/menf21bmc_wdt.c | 206 +++
3 files changed, 214 insertions(+)
create mode 100644 drivers/watchdog/menf21bmc_wdt.c
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 76dd541..f96431d 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -95,6 +95,13 @@ config GPIO_WATCHDOG
If you say yes here you get support for watchdog device
controlled through GPIO-line.
+config MENF21BMC_WATCHDOG
+ tristate "MEN 14F021P00 BMC Watchdog"
+ depends on MFD_MENF21BMC
+ select WATCHDOG_CORE
+ help
+ Say Y here to include support for the MEN 14F021P00 BMC Watchdog.
+
config WM831X_WATCHDOG
tristate "WM831x watchdog"
depends on MFD_WM831X
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 468c320..de17014 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -178,3 +178,4 @@ obj-$(CONFIG_WM831X_WATCHDOG) += wm831x_wdt.o
obj-$(CONFIG_WM8350_WATCHDOG) += wm8350_wdt.o
obj-$(CONFIG_MAX63XX_WATCHDOG) += max63xx_wdt.o
obj-$(CONFIG_SOFT_WATCHDOG) += softdog.o
+obj-$(CONFIG_MENF21BMC_WATCHDOG) += menf21bmc_wdt.o
diff --git a/drivers/watchdog/menf21bmc_wdt.c b/drivers/watchdog/menf21bmc_wdt.c
new file mode 100644
index 000..b46ee92
--- /dev/null
+++ b/drivers/watchdog/menf21bmc_wdt.c
@@ -0,0 +1,206 @@
+/*
+ * MEN 14F021P00 Board Management Controller (BMC) Watchdog Driver.
+ *
+ * Copyright (C) 2014 MEN Mikro Elektronik Nuernberg GmbH
+ * Author: Andreas Werner
+ * All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define DEVNAME "menf21bmc_wdt"
+
+#define BMC_CMD_WD_ON 0x11
+#define BMC_CMD_WD_OFF 0x12
+#define BMC_CMD_WD_TRIG0x13
+#define BMC_CMD_WD_TIME0x14
+#define BMC_CMD_WD_STATE 0x17
+#define BMC_WD_OFF_VAL 0x69
+#define BMC_CMD_RST_RSN0x92
+
+#define BMC_WD_TIMEOUT_MIN 1 /* in sec */
+#define BMC_WD_TIMEOUT_MAX 6553/* in sec */
+
+static bool nowayout = WATCHDOG_NOWAYOUT;
+module_param(nowayout, bool, 0);
+MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once started (default="
+ __MODULE_STRING(WATCHDOG_NOWAYOUT) ")");
+
+struct menf21bmc_wdt {
+ struct watchdog_device wdt;
+ struct i2c_client *i2c_client;
+};
+
+static int menf21bmc_wdt_set_bootstatus(struct menf21bmc_wdt *data)
+{
+ int rst_rsn;
+
+ rst_rsn = i2c_smbus_read_byte_data(data->i2c_client, BMC_CMD_RST_RSN);
+ if (rst_rsn < 0)
+ return rst_rsn;
+
+ if (rst_rsn == 0x02)
+ data->wdt.bootstatus |= WDIOF_CARDRESET;
+ else if (rst_rsn == 0x05)
+ data->wdt.bootstatus |= WDIOF_EXTERN1;
+ else if (rst_rsn == 0x06)
+ data->wdt.bootstatus |= WDIOF_EXTERN2;
+ else if (rst_rsn == 0x0A)
+ data->wdt.bootstatus |= WDIOF_POWERUNDER;
+
+ return 0;
+}
+
+static int menf21bmc_wdt_start(struct watchdog_device *wdt)
+{
+ struct menf21bmc_wdt *drv_data = watchdog_get_drvdata(wdt);
+
+ return i2c_smbus_write_byte(drv_data->i2c_client, BMC_CMD_WD_ON);
+}
+
+static int menf21bmc_wdt_stop(struct watchdog_device *wdt)
+{
+ struct menf21bmc_wdt *drv_data = watchdog_get_drvdata(wdt);
+
+ return i2c_smbus_write_byte_data(drv_data->i2c_client,
+ BMC_CMD_WD_OFF, BMC_WD_OFF_VAL);
+}
+
+static int
+menf21bmc_wdt_settimeout(struct watchdog_device *wdt, unsigned int timeout)
+{
+ int ret;
+ struct menf21bmc_wdt *drv_data = watchdog_get_drvdata(wdt);
+
+ /*
+* BMC Watchdog does have a resolution of 100ms.
+* Watchdog API defines the timeout in seconds, so we have to
+* multiply the value.
+*/
+ ret = i2c_smbus_write_word_data(drv_data->i2c_client,
+ BMC_CMD_WD_TIME, timeout * 10);
+ if (ret < 0)
+ return ret;
+
+ wdt->timeout = timeout;
+
+ return 0;
+}
+
+static int menf21bmc_wdt_ping(struct watchdog_device *wdt)
+{
+ struct menf21bmc_wdt *drv_data = watchdog_get_drvdata(wdt);
+
+ return i2c
[PATCH v3 0/3] Introduce MEN 14F021P BMC driver series
This patch set add support for the MEN 14F021P00 Board Management called BMC. The BMC is a PIC Mikrocontroller which assembled on almost all of our 3U Compact PCI CPU board and a few Box PCs. The main part of the BMC is to start and monitor the board, but there are a lot more features which can be accessed using an I2C Host interface Features supported in this Patchset: - Watchdog - LEDs The Patchset includes a MFD Core driver, Watchdog and LEDs driver. Changes in v3: - deleted i2c_smbus wrapper functions and use native one - some cosmentics and variable renaming to be more clear - renamed "leave production" mode to "exit production mode" Changes in v2: - changed i2c_smbus_read wrapper function to return both, value and error. - moved "leave production mode" from Watchdog driver to mfd core. - fixed some return values in the watchdog driver to return the original error value instead of -EIO. Andreas Werner (3): drivers/mfd/menf21bmc: introduce MEN 14F021P00 BMC MFD Core driver drivers/watchdog/menf21bmc_wdt: introduce MEN 14F021P00 BMC Watchdog driver drivers/leds/leds-menf21bmc: introduce MEN 14F021P00 BMC LED driver drivers/leds/Kconfig | 6 ++ drivers/leds/Makefile| 1 + drivers/leds/leds-menf21bmc.c| 134 + drivers/mfd/Kconfig | 12 +++ drivers/mfd/Makefile | 1 + drivers/mfd/menf21bmc.c | 136 ++ drivers/watchdog/Kconfig | 7 ++ drivers/watchdog/Makefile| 1 + drivers/watchdog/menf21bmc_wdt.c | 206 +++ 9 files changed, 504 insertions(+) create mode 100644 drivers/leds/leds-menf21bmc.c create mode 100644 drivers/mfd/menf21bmc.c create mode 100644 drivers/watchdog/menf21bmc_wdt.c -- 2.0.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] xhci: Allow xHCI drivers to be built as separate modules
> Nope - since CONFIG_USB_XHCI_MVEBU can be 'y' or 'm' we need the ifneq > here (which matches against both) to ensure xhci-mvebu.o is built is > part of xhci-plat-hcd.o. Oh... does it make sense to have it tristate at all, then? Looks like was never really buildable as an independent module (and still won't be after this patch), so I bet that was just a mistake when the Kconfig for it was first written that should be fixed. (Ideally, xhci-plat.c should probably go away in favor of dwc3/host.c and xhci-mvebu.c implementing the wrapper to xhci_init_driver() directly, but that is a longer-term goal.) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 2/4] usb: host: xhci-plat: Get PHYs for xhci's hcds
On Mon, Jul 14, 2014 at 5:49 AM, Vivek Gautam wrote:
> The host controller by itself may sometimes need to handle PHY
> and/or calibrate some of the PHY settings to get full support out
> of the PHY controller. The PHY core provides a calibration
> funtionality now to do so.
> Therefore, facilitate getting the two possible PHYs, viz.
> USB 2.0 type (UTMI+) and USB 3.0 type (PIPE3).
>
> Signed-off-by: Vivek Gautam
> ---
> drivers/usb/host/xhci-plat.c | 17 +
> 1 file changed, 17 insertions(+)
>
> diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
> index 1a0cf9f..d097d60 100644
> --- a/drivers/usb/host/xhci-plat.c
> +++ b/drivers/usb/host/xhci-plat.c
> @@ -16,6 +16,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
>
> @@ -180,6 +181,14 @@ static int xhci_plat_probe(struct platform_device *pdev)
> goto put_hcd;
> }
>
> + /* Get possile USB 2.0 type PHY (UTMI+) available with xhci */
> + hcd->gen_phy = devm_phy_get(&pdev->dev, "usb2-phy");
> + if (IS_ERR(hcd->gen_phy)) {
> + ret = PTR_ERR(hcd->gen_phy);
> + if (ret != -ENOSYS && ret != -ENODEV)
> + dev_dbg(&pdev->dev, "no usb2 phy configured\n");
nit: This message is not really accurate anymore, right? If there is
no phy configured, you get ENODEV and (correctly) skip the message
completely. What you probably want is dev_warn(..., "error retrieving
usb2 phy: %d\n"); or something like that.
> + }
> +
> ret = usb_add_hcd(hcd, irq, IRQF_SHARED);
> if (ret)
> goto disable_clk;
> @@ -209,6 +218,14 @@ static int xhci_plat_probe(struct platform_device *pdev)
> if (HCC_MAX_PSA(xhci->hcc_params) >= 4)
> xhci->shared_hcd->can_do_streams = 1;
>
> + /* Get possile USB 3.0 type PHY (PIPE3) available with xhci */
> + xhci->shared_hcd->gen_phy = devm_phy_get(&pdev->dev, "usb3-phy");
> + if (IS_ERR(xhci->shared_hcd->gen_phy)) {
> + ret = PTR_ERR(xhci->shared_hcd->gen_phy);
> + if (ret != -ENOSYS && ret != -ENODEV)
> + dev_dbg(&pdev->dev, "no usb3 phy configured\n");
> + }
> +
> ret = usb_add_hcd(xhci->shared_hcd, irq, IRQF_SHARED);
> if (ret)
> goto put_usb3_hcd;
> --
> 1.7.10.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 4/4] xhci: Allow xHCI drivers to be built as separate modules
> diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile > index af89a90..bafba71 100644 > --- a/drivers/usb/host/Makefile > +++ b/drivers/usb/host/Makefile > @@ -15,19 +15,19 @@ fhci-$(CONFIG_FHCI_DEBUG) += fhci-dbg.o > xhci-hcd-y := xhci.o xhci-mem.o > xhci-hcd-y += xhci-ring.o xhci-hub.o xhci-dbg.o > xhci-hcd-y += xhci-trace.o > -xhci-hcd-$(CONFIG_PCI) += xhci-pci.o > > -ifneq ($(CONFIG_USB_XHCI_PLATFORM), ) > - xhci-hcd-y += xhci-plat.o > +xhci-plat-hcd-y := xhci-plat.o > ifneq ($(CONFIG_USB_XHCI_MVEBU), ) > - xhci-hcd-y += xhci-mvebu.o > -endif nit: Can do this even simpler now, just "xhci-plat-hcd-$(CONFIG_USB_XHCI_MVEBU) += xhci-mvebu.o" without the ifneq. > + xhci-plat-hcd-y += xhci-mvebu.o > endif > > obj-$(CONFIG_USB_WHCI_HCD) += whci/ > > obj-$(CONFIG_PCI) += pci-quirks.o > > +obj-$(CONFIG_USB_XHCI_PCI) += xhci-pci.o > +obj-$(CONFIG_USB_XHCI_PLATFORM) += xhci-plat-hcd.o > + > obj-$(CONFIG_USB_EHCI_HCD) += ehci-hcd.o > obj-$(CONFIG_USB_EHCI_PCI) += ehci-pci.o > obj-$(CONFIG_USB_EHCI_HCD_PLATFORM)+= ehci-platform.o Great patch series, thank you! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 3/4] usb: host: xhci-plat: Caibrate PHY post host reset
On Wed, Jul 9, 2014 at 3:01 AM, Vivek Gautam wrote:
> Some quirky PHYs may require to be calibrated post the host
> controller initialization.
> The USB 3.0 DRD PHY on Exynos5420/5800 systems, coming along with
> Synopsys's DWC3 controller, is one such PHY which needs to be
> calibrated post xhci's reset at initialization time and at
> resume time, to get the controller work at SuperSpeed.
>
> Signed-off-by: Vivek Gautam
> ---
> drivers/usb/host/xhci-plat.c | 39 +--
> 1 file changed, 37 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
> index e50bd7d..decf349 100644
> --- a/drivers/usb/host/xhci-plat.c
> +++ b/drivers/usb/host/xhci-plat.c
> @@ -35,7 +35,27 @@ static void xhci_plat_quirks(struct device *dev, struct
> xhci_hcd *xhci)
> /* called during probe() after chip reset completes */
> static int xhci_plat_setup(struct usb_hcd *hcd)
> {
> - return xhci_gen_setup(hcd, xhci_plat_quirks);
> + struct device *parent;
> + int ret;
> +
> + ret = xhci_gen_setup(hcd, xhci_plat_quirks);
> + if (ret) {
> + dev_err(hcd->self.controller, "xhci setup failed\n");
> + return ret;
> + }
> +
> + parent = hcd->self.controller->parent;
> + if (of_device_is_compatible(parent->of_node, "synopsys,dwc3") ||
> + of_device_is_compatible(parent->of_node, "snps,dwc3")) {
> + if (!IS_ERR(hcd->gen_phy)) {
> + ret = phy_calibrate(hcd->gen_phy);
> + if (ret < 0 && ret != -ENOTSUPP)
> + dev_err(hcd->self.controller,
> + "failed to calibrate USB PHY\n");
> + }
> + }
Here as well, is it really necessary to special-case it so much? I'd
say if there is a PHY and it has a calibrate function bound we call
it, and if not we just go ahead.
I also think that this would fit better in core/hcd.c since it's not
really XHCI specific... it's conceivable that an EHCI controller might
also need to tune some PHY settings after reset (in fact Tegra does
something similar, although it already has another hack for that now),
so if we introduce this general facility why not offer it to
everyone?.
> +
> + return ret;
> }
>
> static int xhci_plat_start(struct usb_hcd *hcd)
> @@ -288,8 +308,23 @@ static int xhci_plat_resume(struct device *dev)
> {
> struct usb_hcd *hcd = dev_get_drvdata(dev);
> struct xhci_hcd *xhci = hcd_to_xhci(hcd);
> + int ret;
> +
> + ret = xhci_resume(xhci, 0);
> + if (ret)
> + return ret;
>
> - return xhci_resume(xhci, 0);
> + if (of_device_is_compatible(dev->parent->of_node, "synopsys,dwc3") ||
> + of_device_is_compatible(dev->parent->of_node, "snps,dwc3")) {
> + if (!IS_ERR(hcd->gen_phy)) {
> + ret = phy_calibrate(hcd->gen_phy);
> + if (ret < 0 && ret != -ENOTSUPP)
> + dev_err(hcd->self.controller,
> + "failed to calibrate USB PHY\n");
> + }
> + }
> +
> + return ret;
> }
>
> static const struct dev_pm_ops xhci_plat_pm_ops = {
> --
> 1.7.10.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 v2 2/4] usb: host: xhci-plat: Get PHYs for xhci's hcds
On Wed, Jul 9, 2014 at 3:01 AM, Vivek Gautam wrote:
> The host controller by itself may sometimes need to handle PHY
> and/or calibrate some of the PHY settings to get full support out
> of the PHY controller. The PHY core provides a calibration
> funtionality now to do so.
> Therefore, facilitate getting the two possible PHYs, viz.
> USB 2.0 type (UTMI+) and USB 3.0 type (PIPE3), provided
> by the parent - Synopsys's DWC3 controller
>
> Signed-off-by: Vivek Gautam
> ---
> drivers/usb/host/xhci-plat.c | 36
> 1 file changed, 36 insertions(+)
>
> diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
> index 29d8adb..e50bd7d 100644
> --- a/drivers/usb/host/xhci-plat.c
> +++ b/drivers/usb/host/xhci-plat.c
> @@ -16,6 +16,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> #include "xhci.h"
> @@ -101,6 +102,7 @@ static int xhci_plat_probe(struct platform_device *pdev)
> struct clk *clk;
> int ret;
> int irq;
> + struct device *parent;
>
> if (usb_disabled())
> return -ENODEV;
> @@ -165,6 +167,23 @@ static int xhci_plat_probe(struct platform_device *pdev)
> goto unmap_registers;
> }
>
> + parent = pdev->dev.parent;
> + /*
> +* Get possile USB 2.0 type PHY (UTMI+) registered by xhci's parent:
> +* Synopsys-dwc3
> +*/
> + if (of_device_is_compatible(parent->of_node, "synopsys,dwc3") ||
> + of_device_is_compatible(parent->of_node, "snps,dwc3")) {
> + hcd->gen_phy = devm_phy_get(&pdev->dev, "usb2-phy");
> + if (IS_ERR(hcd->gen_phy)) {
> + ret = PTR_ERR(hcd->gen_phy);
> + if (ret != -ENOSYS && ret != -ENODEV) {
> + dev_err(&pdev->dev, "no usb2 phy
> configured\n");
> + return ret;
> + }
> + }
> + }
Why does this need to check for DWC3? I think this code should be as
generic as possible. Can't you just devm_phy_get("usb2-phy"), and keep
going with a dev_dbg() message if it fails? If the platform has a phy
it will find it, if not that's fine too.
Looks like Heikki's patch assigns the phy names in DWC3-specific code,
so I'm not sure if they are supposed to be specific to that
controller... but DWC3 is the only merged XHCI controller this applys
to right now, so why not make that a general convention? The concept
of having one "usb2-phy" and one "usb3-phy" is probably common across
most xHC implementations (unless they share a single phy in which case
they could just leave one of them unset), so it will be much easier to
handle if they all chose the same two names for those (and we can
avoid a big list of special cases here).
> +
> ret = usb_add_hcd(hcd, irq, IRQF_SHARED);
> if (ret)
> goto disable_clk;
> @@ -191,6 +210,23 @@ static int xhci_plat_probe(struct platform_device *pdev)
> if (HCC_MAX_PSA(xhci->hcc_params) >= 4)
> xhci->shared_hcd->can_do_streams = 1;
>
> + /*
> +* Get possile USB 3.0 type PHY (PIPE3) registered by xhci's parent:
> +* Synopsys-dwc3
> +*/
> + if (of_device_is_compatible(parent->of_node, "synopsys,dwc3") ||
> + of_device_is_compatible(parent->of_node, "snps,dwc3")) {
> + xhci->shared_hcd->gen_phy = devm_phy_get(&pdev->dev,
> +"usb3-phy");
> + if (IS_ERR(xhci->shared_hcd->gen_phy)) {
> + ret = PTR_ERR(xhci->shared_hcd->gen_phy);
> + if (ret != -ENOSYS && ret != -ENODEV) {
> + dev_err(&pdev->dev, "no usb3 phy
> configured\n");
> + return ret;
> + }
> + }
> + }
> +
> ret = usb_add_hcd(xhci->shared_hcd, irq, IRQF_SHARED);
> if (ret)
> goto put_usb3_hcd;
> --
> 1.7.10.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] usb: xhci: Fix Set TR Dequeue Pointer cycle state for quirky xHCs
Commit 1f81b6d22 "usb: xhci: Prefer endpoint context dequeue pointer
over stopped_trb" changed the logic in xhci_find_new_dequeue_state() to
only use the Endpoint Context's TR Dequeue Pointer instead of the last
Event TRB's TRB Pointer as a basis from which to infer the host
controller state. This has uncovered a bug with certain Asmedia xHCs
which seem to advance their TR Dequeue Pointer one TRB behind the one
that caused a Stall Error.
This confuses the cycle state calculation since cur_td->last_trb is now
behind hw_dequeue (which the algorithm interprets as a single huge TD
that wraps around the whole transfer ring). This patch counteracts that
by explicitly looking for last_trb when searching for hw_dequeue from
the old software dequeue pointer. If it is found, we toggle the cycle
state once more to balance out the incorrect toggle that will happen
later.
In order to make this work for both single and multi segment rings, this
patch also expands the detection of wrap-around TDs to work on the
latter ones (which cannot normally happen because the kernel prevents
that case to allow for ring expansion, but it's how things appear to be
in the quirky case and allowing the code to handle it makes it easier to
generalize this fix across all kernels). The code will now toggle the
cycle state whenever last_trb is before hw_dequeue on the same segment,
regardless of how many segments there are in the ring.
This patch should be backported to kernels as old as 2.6.31 that contain
the commit ae636747146ea97efa18e04576acd3416e2514f5 "USB: xhci: URB
cancellation support."
Cc: sta...@vger.kernel.org
Signed-off-by: Julius Werner
---
drivers/usb/host/xhci-ring.c | 18 +-
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 749fc68..50abc68 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -489,8 +489,17 @@ void xhci_find_new_dequeue_state(struct xhci_hcd *xhci,
/* Find virtual address and segment of hardware dequeue pointer */
state->new_deq_seg = ep_ring->deq_seg;
state->new_deq_ptr = ep_ring->dequeue;
+ state->new_cycle_state = hw_dequeue & 0x1;
while (xhci_trb_virt_to_dma(state->new_deq_seg, state->new_deq_ptr)
!= (dma_addr_t)(hw_dequeue & ~0xf)) {
+ /*
+* Quirky HCs can advance hw_dequeue behind cur_td->last_trb.
+* That violates the assumptions of the TD wrap around check
+* below, so toggle the cycle state once more to cancel it out.
+*/
+ if (state->new_deq_ptr == cur_td->last_trb)
+ state->new_cycle_state ^= 1;
+
next_trb(xhci, ep_ring, &state->new_deq_seg,
&state->new_deq_ptr);
if (state->new_deq_ptr == ep_ring->dequeue) {
@@ -500,12 +509,11 @@ void xhci_find_new_dequeue_state(struct xhci_hcd *xhci,
}
/*
* Find cycle state for last_trb, starting at old cycle state of
-* hw_dequeue. If there is only one segment ring, find_trb_seg() will
-* return immediately and cannot toggle the cycle state if this search
-* wraps around, so add one more toggle manually in that case.
+* hw_dequeue. If last_trb is on the current segment before hw_dequeue,
+* that means we wrap around the whole ring, but find_trb_seq() will
+* return immediately. Toggle the cycle state manually in that case.
*/
- state->new_cycle_state = hw_dequeue & 0x1;
- if (ep_ring->first_seg == ep_ring->first_seg->next &&
+ if (state->new_deq_seg->trbs < cur_td->last_trb &&
cur_td->last_trb < state->new_deq_ptr)
state->new_cycle_state ^= 0x1;
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v1 6/9] usb: xhci: Add NVIDIA Tegra XHCI host-controller driver
> +static const struct hc_driver tegra_xhci_hc_driver = {
> + .description = "tegra-xhci-hcd",
> + .product_desc = "Tegra xHCI Host Controller",
> + .hcd_priv_size =sizeof(struct xhci_hcd *),
> +
> + /*
> +* generic hardware linkage
> +*/
> + .irq = xhci_irq,
> + .flags =HCD_MEMORY | HCD_USB3 | HCD_SHARED,
> +
> + /*
> +* basic lifecycle operations
> +*/
> + .reset =tegra_xhci_setup,
> + .start =xhci_run,
> + .stop = xhci_stop,
> + .shutdown = xhci_shutdown,
> +
> + /*
> +* managing i/o requests and associated device resources
> +*/
> + .urb_enqueue = xhci_urb_enqueue,
> + .urb_dequeue = xhci_urb_dequeue,
> + .alloc_dev =xhci_alloc_dev,
> + .free_dev = xhci_free_dev,
> + .alloc_streams =xhci_alloc_streams,
> + .free_streams = xhci_free_streams,
> + .add_endpoint = xhci_add_endpoint,
> + .drop_endpoint =xhci_drop_endpoint,
> + .endpoint_reset = xhci_endpoint_reset,
> + .check_bandwidth = xhci_check_bandwidth,
> + .reset_bandwidth = xhci_reset_bandwidth,
> + .address_device = xhci_address_device,
> + .enable_device =xhci_enable_device,
> + .update_hub_device =xhci_update_hub_device,
> + .reset_device = xhci_discover_or_reset_device,
> +
> + /*
> +* scheduling support
> +*/
> + .get_frame_number = xhci_get_frame,
> +
> + /* Root hub support */
> + .hub_control = xhci_hub_control,
> + .hub_status_data = xhci_hub_status_data,
> + .bus_suspend = xhci_bus_suspend,
> + .bus_resume = xhci_bus_resume,
> +};
I know I missed the first round of discussion where this was
suggested, but I don't think it's a good idea to pull the whole
hc_driver structure out into every platform implementation. It will
lead to duplication, then to future additions only being applied to
some of the implementations and everything getting out of sync. This
is already a problem with the PCI/plat split (e.g. the LPM functions
were only added to xhci-pci even though they should apply to both).
Also, if I'm not mistaken this code would fail to compile as a module
(you are referencing lots of symbols that are internal to the xhci-hcd
module).
I think at the very least you should add a function
"xhci_default_driver(struct hc_driver *driver)" to xhci-plat.c (or
even better to xhci.c and use it for PCI as well) that initializes all
function pointers to the default (internal) symbols, and can then be
overridden afterwards.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] firmware: Add device tree binding for coreboot
This patch adds documentation describing a device tree binding for the
coreboot firmware. It is meant to be dynamically added during boot and
contains address definitions for the coreboot table (a list of
variable-sized descriptors providing information about various compile-
and run-time generated firmware parameters) and the CBMEM area (the
structure containing most run-time resident memory regions set up by
coreboot).
These definitions allow kernel drivers to easily access data contained
in and pointed to by these regions (such as coreboot's in-memory log).
(An example implementation can be seen at http://crosreview.com/203371,
which will be submitted at a later point.)
Change-Id: I97609d461d306f85851e5efc26c675ca1e2d7e9d
Signed-off-by: Julius Werner
---
.../devicetree/bindings/firmware/coreboot.txt | 32 ++
1 file changed, 32 insertions(+)
create mode 100644 Documentation/devicetree/bindings/firmware/coreboot.txt
diff --git a/Documentation/devicetree/bindings/firmware/coreboot.txt
b/Documentation/devicetree/bindings/firmware/coreboot.txt
new file mode 100644
index 000..5055f0e
--- /dev/null
+++ b/Documentation/devicetree/bindings/firmware/coreboot.txt
@@ -0,0 +1,32 @@
+COREBOOT firmware information
+
+The device tree node to communicate the location of coreboot's memory-resident
+bookkeeping structures to the kernel. Since coreboot itself cannot boot a
+device-tree-based kernel (yet), this node needs to be inserted by a
+second-stage bootloader (a coreboot "payload").
+
+Required properties:
+ - compatible: Should be "coreboot"
+ - reg: Address and length of the following two memory regions, in order:
+ 1.) The coreboot table. This is a list of variable-sized descriptors
+ that contain various compile- and run-time generated firmware
+ parameters. It is identified by the magic string "LBIO" in its first
+ four bytes. See coreboot's src/include/boot/coreboot_tables.h for
+ details.
+ 2.) The CBMEM area. This is a downward-growing memory region used by
+ coreboot to dynamically allocate data structures that remain resident.
+ It may or may not include the coreboot table as one of its members. It
+ is identified by a root node descriptor with the magic number
+ 0xc0389479 that resides in the topmost 8 bytes of the area. See
+ coreboot's src/lib/dynamic_cbmem.c for details.
+
+Example:
+ firmware {
+ ranges;
+
+ coreboot {
+ compatible = "coreboot";
+ reg = <0xfdfea000 0x264>,
+ <0xfdfea000 0x16000>;
+ }
+ };
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] firmware: Add device tree binding for coreboot
On Mon, Jun 16, 2014 at 6:30 AM, Rob Herring wrote:
> On Fri, Jun 13, 2014 at 4:58 PM, Julius Werner wrote:
>>> This is just to export a fixed log to userspace (like a DMI table) or
>>> the kernel will actually use the data in some way? Based on the link,
>>> it looks like the former to me.
>>
>> I could imagine both. The link is an in-kernel driver that exposes a
>> log through a sysfs node (in a way that has already been established
>> on x86 systems, which find the location through EBDA or ACPI entries
>> instead). We are also using a user-space tool that reads the address
>> from /proc/device-tree and accesses it through /dev/mem. The areas can
>> contain many interesting entries (like the location of an early
>> framebuffer set up by the firmware), so I could also imagine use cases
>> where the kernel makes use of it directly.
>
> I can be argued that the boot interface is DT and any configuration
> data should be put there in a common way. We don't really need yet
> another boot mechanism as we already have:
>
> UEFI + FDT
> UEFI + ACPI
> "standard" bootloaders (e.g. u-boot, grub, barebox, etc.) + FDT
>
> Allowing every bootloader to define its own boot interfaces would only
> result in a mess for both code and testing. I don't want to get into a
> debate about this now as it is not too relevant to this patch, but
> just want to highlight the resistance you will face going down this
> path.
>
>>> Don't you need need to keep the kernel from allocating this memory by
>>> using one of the reserved memory mechanisms? The recently added one
>>> should be able to specific what the memory is reserved for IIRC.
>>
>> Our bootloader is carving the location out of the /memory node and
>> adding it to the device tree reserve map. As far as I know, that only
>> contains a list of raw start and size entries. At any rate, I think
>> it's useful (and in line with other bindings) to add a more explicit
>> node like this (if only to make it easier accessible through
>> /proc/device-tree).
>
> Understand there are 3 different memory reservation bindings. The
> original "/memreserve/" method is indeed limited. What I think you
> should use is the binding documented in
> Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt.
> So you could do something like this:
>
>reserved-memory {
>#address-cells = <1>;
>#size-cells = <1>;
>ranges;
>
>/* global autoconfigured region for contiguous allocations */
>linux,cma {
>compatible = "shared-dma-pool";
>reusable;
>size = <0x400>;
>alignment = <0x2000>;
>linux,cma-default;
>};
>
>coreboot_reserved: coreboot@fdfea000 {
> compatible = "coreboot";
> reg = <0xfdfea000 0x264>,
> <0xfdfea000 0x16000>;
>};
>
>
Okay, I see. But do you really think this is the best way to specify
that interface? Bindings for other firmware also seems to prefer some
form of /firmware, so I think putting it there or under there is more
consistent. Especially if we later find a need to add more properties
to the coreboot node (maybe a version number, feature availability, or
things like that), a reserved-memory node would feel like the wrong
place for it to me.
>>> /firmware is already used IIRC. What if you have other firmware such
>>> as Trustzone?
>>
>> I'm not quite sure how Trusted Foundations works and whether it would
>> even make sense to use it in parallel to coreboot, but it seems to be
>> using the /firmware/trusted-foundations subnode so that should be
>> fine. "firmware" seems to be used by other firmware implementations
>> (like "samsung,secure-firmware") which are similar in nature to and
>> mutually exclusive with coreboot, so I thought the node makes sense.
>> (The kernel should use the compatible string to find it anyway, so a
>> future name clash would not be world-ending.)
>
> They are not mutually exclusive. What runs in secure world or not is
> entirely independent of non-secure boot. You may not care about it,
> but other platforms could.
On Mon, Jun 16, 2014 at 9:39 AM, Olof Johansson wrote:
> 2014-06-13 14:58 GMT-07:00 Julius Werner :
>>> This is just to export a fixed log to userspace (like a DMI table) or
>>> the kernel will actually use
Re: [PATCH] firmware: Add device tree binding for coreboot
> This is just to export a fixed log to userspace (like a DMI table) or > the kernel will actually use the data in some way? Based on the link, > it looks like the former to me. I could imagine both. The link is an in-kernel driver that exposes a log through a sysfs node (in a way that has already been established on x86 systems, which find the location through EBDA or ACPI entries instead). We are also using a user-space tool that reads the address from /proc/device-tree and accesses it through /dev/mem. The areas can contain many interesting entries (like the location of an early framebuffer set up by the firmware), so I could also imagine use cases where the kernel makes use of it directly. > Don't you need need to keep the kernel from allocating this memory by > using one of the reserved memory mechanisms? The recently added one > should be able to specific what the memory is reserved for IIRC. Our bootloader is carving the location out of the /memory node and adding it to the device tree reserve map. As far as I know, that only contains a list of raw start and size entries. At any rate, I think it's useful (and in line with other bindings) to add a more explicit node like this (if only to make it easier accessible through /proc/device-tree). > /firmware is already used IIRC. What if you have other firmware such > as Trustzone? I'm not quite sure how Trusted Foundations works and whether it would even make sense to use it in parallel to coreboot, but it seems to be using the /firmware/trusted-foundations subnode so that should be fine. "firmware" seems to be used by other firmware implementations (like "samsung,secure-firmware") which are similar in nature to and mutually exclusive with coreboot, so I thought the node makes sense. (The kernel should use the compatible string to find it anyway, so a future name clash would not be world-ending.) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] firmware: Add device tree binding for coreboot
This patch adds documentation describing a device tree binding for the
coreboot firmware project (www.coreboot.org). It is meant to be
dynamically added during boot and contains address definitions for the
coreboot table (a list of variable-sized descriptors providing
information about various compile- and run-time generated firmware
parameters) and the CBMEM area (the structure containing most run-time
resident memory regions set up by coreboot).
These definitions allow kernel drivers to easily access data contained
in and pointed to by these regions (such as coreboot's in-memory log).
(An example implementation can be seen at http://crosreview.com/203371,
which will be submitted at a later point.)
Signed-off-by: Julius Werner
---
.../devicetree/bindings/firmware/coreboot.txt | 28 ++
1 file changed, 28 insertions(+)
create mode 100644 Documentation/devicetree/bindings/firmware/coreboot.txt
diff --git a/Documentation/devicetree/bindings/firmware/coreboot.txt
b/Documentation/devicetree/bindings/firmware/coreboot.txt
new file mode 100644
index 000..89d7bf3
--- /dev/null
+++ b/Documentation/devicetree/bindings/firmware/coreboot.txt
@@ -0,0 +1,28 @@
+COREBOOT firmware information
+
+The device tree node to communicate the location of coreboot's memory-resident
+bookkeeping structures to the kernel. Since coreboot itself cannot boot a
+device-tree-based kernel (yet), this node needs to be inserted by a
+second-stage bootloader (a coreboot "payload").
+
+Required properties:
+ - compatible: Should be "coreboot"
+ - reg: Address and length of the following two memory regions, in order:
+ 1.) The coreboot table. This is a list of variable-sized descriptors
+ that contain various compile- and run-time generated firmware
+ parameters. It is identified by the magic string "LBIO" in its first
+ four bytes. See coreboot's src/include/boot/coreboot_tables.h for
+ details.
+ 2.) The CBMEM area. This is a downward-growing memory region used by
+ coreboot to dynamically allocate data structures that remain resident.
+ It may or may not include the coreboot table as one of its members. It
+ is identified by a root node descriptor with the magic number
+ 0xc0389479 that resides in the topmost 8 bytes of the area. See
+ coreboot's src/lib/dynamic_cbmem.c for details.
+
+Example:
+ firmware {
+ compatible = "coreboot";
+ reg = <0xfdfea000 0x264>,
+ <0xfdfea000 0x16000>;
+ };
--
1.8.3.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/
So l ös en Sie Ihr akutes Fin anzpr obl em
Wir wünschen Ihnen einen schönen guten Tag, ich habe eine gute Nachricht für Sie. Süd-amerikanische Banken drängen ins deutsche Kreditgeschäft, bspw. mit solchen Konditionen: Weniger als 3 Prozent Zinsen für Firmen und unter 3,5 Prozent für PrivatKredite. Auch bei laufenden Verpflichtungen und bereits von Ihrer eigenen Hausbank abgelehntem Antrag können wir für Privat und Selbständige zu niedrigen Zinsen einen Kredit vermitteln. Also ideal für Firmeninhaber, Angestellte und Rentner. Wenn Sie neugierig geworden sind, dann geht es hier weiter ... OKAYKREDIT und ergänzen Sie co m Bis bald A. Koch -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] usb: host: xhci-plat: Add support to get PHYs
> diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
> index 9ffecd5..453d89e 100644
> --- a/drivers/usb/host/xhci.h
> +++ b/drivers/usb/host/xhci.h
> @@ -1582,6 +1582,9 @@ struct xhci_hcd {
> u32 port_status_u0;
> /* Compliance Mode Timer Triggered every 2 seconds */
> #define COMP_MODE_RCVRY_MSECS 2000
> + /* phys for the controller */
> + struct phy *phy2_gen;
> + struct phy *phy3_gen;
> };
I don't think adding new variables here and restricting most of this
logic to xhci-plat.c (in the next patch) is the best way to do it.
There's no conceptual reason why other host controllers (e.g. xhci-pci
or even EHCI) could not have a similar need to tune their PHY after
reset. PHYs are universal to all host controllers.
There is already a 'phy' member in struct usb_hcd which I think is
mostly unused right now. I think it would be much less
confusing/redundant to reuse that member for this purpose (you could
still set it up from xhci_plat_probe(), and then call it from
hcd_bus_resume() or something like that). Since XHCI host controllers
already conveniently have two struct usb_hcd (one for 2.0 and one for
3.0), you can cleanly store references to your two PHYs in there.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/3] drivers/mfd/menf21bmc: introduce MEN 14F021P00 BMC MFD Core driver
On Tue, May 27, 2014 at 04:05:47PM +0100, Lee Jones wrote:
> > The MEN 14F021P00 Board Management Controller provides an
> > I2C interface to the host to access the feature implemented in the BMC.
> > The BMC is a PIC Microntroller assembled on CPCI Card from MEN
> > Mikroelektronik
> > and on a few Box/Display Computer.
> >
> > Added MFD Core driver, supporting the I2C communication to the device.
> >
> > The MFD driver currently supports the following features:
> > - Watchdog
> > - LEDs
> >
> > Signed-off-by: Andreas Werner
> > ---
> > drivers/mfd/Kconfig | 12 +++
> > drivers/mfd/Makefile | 1 +
> > drivers/mfd/menf21bmc.c | 220
> > ++
> > include/linux/mfd/menf21bmc.h | 31 ++
> > 4 files changed, 264 insertions(+)
> > create mode 100644 drivers/mfd/menf21bmc.c
> > create mode 100644 include/linux/mfd/menf21bmc.h
> >
> > diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> > index ab5a43c..7c2e8d2 100644
> > --- a/drivers/mfd/Kconfig
> > +++ b/drivers/mfd/Kconfig
> > @@ -427,6 +427,18 @@ config MFD_MAX8998
> > additional drivers must be enabled in order to use the functionality
> > of the device.
> >
> > +config MFD_MENF21BMC
> > + tristate "MEN 14F021P00 Board Management Controller Support"
> > + depends on I2C=y
> > + select MFD_CORE
> > + help
> > + Say yes here to add support for the MEN 14F021P00 BMC
> > + which is a Board Management Controller connected to the I2C bus.
> > + This driver provides common support for accessing the devices;
> > + additional drivers must be enabled in order to use the
> > + functionality of the BMC device.
>
> Would be good if you mention the WD and LED devices here too.
>
> > +
> > +
>
> To many '\n's here.
I will ad WD and LED and fix the \n.
>
> > config EZX_PCAP
> > bool "Motorola EZXPCAP Support"
> > depends on SPI_MASTER
> > diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> > index 5913208..8f2be38 100644
> > --- a/drivers/mfd/Makefile
> > +++ b/drivers/mfd/Makefile
> > @@ -167,3 +167,4 @@ obj-$(CONFIG_MFD_AS3711)+= as3711.o
> > obj-$(CONFIG_MFD_AS3722) += as3722.o
> > obj-$(CONFIG_MFD_STW481X) += stw481x.o
> > obj-$(CONFIG_MFD_IPAQ_MICRO) += ipaq-micro.o
> > +obj-$(CONFIG_MFD_MENF21BMC)+= menf21bmc.o
> > diff --git a/drivers/mfd/menf21bmc.c b/drivers/mfd/menf21bmc.c
> > new file mode 100644
> > index 000..8de92b5
> > --- /dev/null
> > +++ b/drivers/mfd/menf21bmc.c
> > @@ -0,0 +1,220 @@
> > +/*
> > + * MEN 14F021P00 Board Management Controller (BMC) MFD Core Driver.
> > + *
> > + * Copyright (C) 2014 MEN Mikro Elektronik Nuernberg GmbH
> > + * Author: Andreas Werner
> > + * All rights reserved.
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > it
> > + * under the terms of the GNU General Public License as published by
> > the
> > + * Free Software Foundation; either version 2 of the License, or (at
> > your
> > + * option) any later version.
> > + *
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#define BMC_CMD_REV_MAJOR 0x80
> > +#define BMC_CMD_REV_MINOR 0x81
> > +#define BMC_CMD_REV_MAIN 0x82
> > +#define BMC_CMD_REV_BUILD 0x83
> > +#define BMC_CMD_REV_VERI 0x84
> > +#define BMC_CMD_WD_ARM_SET 0x18
> > +#define BMC_CMD_WD_ARM_GET 0x19
> > +
> > +static struct mfd_cell menf21bmc_cell[] = {
> > + {
> > + .name = "menf21bmc_wd",
>
> I prefer wdog to wd, as it's a little move obvious what we're dealing
> with.
I agree.
>
> > + },
> > + {
> > + .name = "menf21bmc_led",
> > + },
> > +};
>
> If these are the only struct attributes, please place them on a single
> line (each).
>
Ok i'll change that.
> > +static int
> > +menf21bmc_read_byte_data(struct i2c_client *client, u8 reg)
> > +{
> > + int ret;
> > + struct menf21bmc *data = i2c_get_clientdata(client);
> > +
> > + mutex_lock(&data->lock);
> > + ret = i2c_smbus_read_byte_data(client, reg);
> > + mutex_unlock(&data->lock);
> > +
> > + return ret;
> > +}
Re: [PATCH 1/2] ARM: dts: Enable USB 3503 hub on exynos5250-snow
> Ok, there was already a patch posted by you for this[1], which had > quite a much discussion > on it. > Would you like to give some pointers based on that ? > One that Olof had suggested was to use gpio-reset driver which is yet > to make to mainline. > But i think with that too we need to take care of the timing for > resetting the hub before PHY > gets reset. Oh, right, I remember now. Seems like there wasn't much consensus on how to solve the problem there, and I think I didn't really have time to work on it any more either. I think coupling in another driver to reset the device isn't a bad idea... this could even be usb3503 if you modified it a little, and it could also address Tomasz' concerns from that thread that the solution should be extensible to other HSIC devices that need a different reset sequence. But you need some mechanism to hook the two drivers together and make sure phy-samsung-usb2 synchronously calls the reset function at exactly the right point to ensure the timing works right. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/3] drivers/mfd/menf21bmc: introduce MEN 14F021P00 BMC MFD Core driver
On Wed, May 28, 2014 at 06:52:56AM -0700, Guenter Roeck wrote:
> On 05/28/2014 06:29 AM, Guenter Roeck wrote:
> >On 05/28/2014 04:51 AM, Andreas Werner wrote:
> >>aOn Wed, May 28, 2014 at 09:24:05AM +0100, Lee Jones wrote:
> >>>>>>The MEN 14F021P00 Board Management Controller provides an
> >>>>>>I2C interface to the host to access the feature implemented in the BMC.
> >>>>>>The BMC is a PIC Microntroller assembled on CPCI Card from MEN
> >>>>>>Mikroelektronik
> >>>>>>and on a few Box/Display Computer.
> >>>>>>
> >>>>>>Added MFD Core driver, supporting the I2C communication to the device.
> >>>>>>
> >>>>>>The MFD driver currently supports the following features:
> >>>>>>- Watchdog
> >>>>>>- LEDs
> >>>>>>
> >>>>>>Signed-off-by: Andreas Werner
> >>>>>>---
> >>>>>> drivers/mfd/Kconfig | 12 +++
> >>>>>> drivers/mfd/Makefile | 1 +
> >>>>>> drivers/mfd/menf21bmc.c | 220
> >>>>>> ++
> >>>>>> include/linux/mfd/menf21bmc.h | 31 ++
> >>>>>> 4 files changed, 264 insertions(+)
> >>>>>> create mode 100644 drivers/mfd/menf21bmc.c
> >>>>>> create mode 100644 include/linux/mfd/menf21bmc.h
> >>>
> >>>[...]
> >>>
> >>>>>>+static int menf21bmc_write_byte(struct i2c_client *client, u8 val)
> >>>>>>+{
> >>>>>>+int ret;
> >>>>>>+struct menf21bmc *data = i2c_get_clientdata(client);
> >>>>>>+
> >>>>>>+mutex_lock(&data->lock);
> >>>>>>+ret = i2c_smbus_write_byte(client, val);
> >>>>>>+mutex_unlock(&data->lock);
> >>>>>>+
> >>>>>>+return ret;
> >>>>>>+}
> >>>>>
> >>>>>Didn't we ask you to remove these? Just make the i2c_smbus_* calls
> >>>>>from within the driver. The I2C subsystem conducts its own locking.
> >>>>>I'm really starting to frown on aggregation for the sake of
> >>>>>aggregation. It's just overhead.
> >>>>>
> >>>>
> >>>>Correct me if I'm wrong but as far as I remember Guenther asked to retain
> >>>>the
> >>>>original API, not the remove the "abstraction layer". Once we build a
> >>>>board with
> >>>>one of these BMCs attached via e.g. SPI we would have to reintroduce it
> >>>>anyways,
> >>>>in order to re-use these drivers.
> >>>
> >>>If there are two or more possible interfaces then I agree, these
> >>>aggregations would be the best approach. However, as it stands, that's
> >>>not currently the case.
> >>>
> >>>Genuine question; are Men on the verge of building such a board, or
> >>>are we talking about 'ifs' and 'maybes'?
> >>>
> >>
> >>I think it was a missunderstanding. I also thought that i just
> >>have to adapt the wrapper to the original API, that is what I did in the
> >>patch,
> >>and not to delete the functions completly.
> >>
> >>Anayway, we currently have another project which use a STM32 MCR connected
> >>to USB.
> >>A nice feature of this STM is to update the firmware using the USB
> >>interface.
> >>This is easy to implement and fast.
> >>
> >>We want to use such a functionality in all of our MCRs to easily update the
> >>firmware
> >>at the customer if we found a bug.
> >>
> >>We also plan to have a BMC connected to USB. Then we have i2c and USB.
> >>
> >
> >Even more likely that you would have to change the API in that case to be
> >less
> >I2C centric.
> >
>
> ... especially since you have "struct i2c_client *client" in your API
> function.
>
> Guenter
>
>
Ok I agree. I will change that and delete the wrapper functions completley.
I will prepare and send a v3.
Thanks for the discussion.
Regards
Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ARM: dts: Enable USB 3503 hub on exynos5250-snow
We originally tried using this driver on ChromiumOS and never got it to work reliably. IIRC the issue was that if the hub had already been initialized by firmware, the USB stack might enumerate it before the usb3503 driver is probed and then the later reset will silently disrupt that connection. (I think I tried to force the 3503 to probe earlier as well, and there was some other issue with that although I don't recall the details.) This will not be an issue for the Snow and Peach_Pi(t) boards (since neither of them shipped with firmware that supports this hub), but it will be an issue for Spring and Skate. On ChromiumOS we decided to carry a local (and admittedly ugly) patch to pull that reset line from the USB PHY driver instead, since that's the only way I could get it to work in all cases (see http://crosreview.com/58963). This doesn't mean I'm against this patch per se, just wanted to point out the trade-offs. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/3] drivers/mfd/menf21bmc: introduce MEN 14F021P00 BMC MFD Core driver
aOn Wed, May 28, 2014 at 09:24:05AM +0100, Lee Jones wrote:
> > > > The MEN 14F021P00 Board Management Controller provides an
> > > > I2C interface to the host to access the feature implemented in the BMC.
> > > > The BMC is a PIC Microntroller assembled on CPCI Card from MEN
> > > > Mikroelektronik
> > > > and on a few Box/Display Computer.
> > > >
> > > > Added MFD Core driver, supporting the I2C communication to the device.
> > > >
> > > > The MFD driver currently supports the following features:
> > > > - Watchdog
> > > > - LEDs
> > > >
> > > > Signed-off-by: Andreas Werner
> > > > ---
> > > > drivers/mfd/Kconfig | 12 +++
> > > > drivers/mfd/Makefile | 1 +
> > > > drivers/mfd/menf21bmc.c | 220
> > > > ++
> > > > include/linux/mfd/menf21bmc.h | 31 ++
> > > > 4 files changed, 264 insertions(+)
> > > > create mode 100644 drivers/mfd/menf21bmc.c
> > > > create mode 100644 include/linux/mfd/menf21bmc.h
>
> [...]
>
> > > > +static int menf21bmc_write_byte(struct i2c_client *client, u8 val)
> > > > +{
> > > > + int ret;
> > > > + struct menf21bmc *data = i2c_get_clientdata(client);
> > > > +
> > > > + mutex_lock(&data->lock);
> > > > + ret = i2c_smbus_write_byte(client, val);
> > > > + mutex_unlock(&data->lock);
> > > > +
> > > > + return ret;
> > > > +}
> > >
> > > Didn't we ask you to remove these? Just make the i2c_smbus_* calls
> > > from within the driver. The I2C subsystem conducts its own locking.
> > > I'm really starting to frown on aggregation for the sake of
> > > aggregation. It's just overhead.
> > >
> >
> > Correct me if I'm wrong but as far as I remember Guenther asked to retain
> > the
> > original API, not the remove the "abstraction layer". Once we build a board
> > with
> > one of these BMCs attached via e.g. SPI we would have to reintroduce it
> > anyways,
> > in order to re-use these drivers.
>
> If there are two or more possible interfaces then I agree, these
> aggregations would be the best approach. However, as it stands, that's
> not currently the case.
>
> Genuine question; are Men on the verge of building such a board, or
> are we talking about 'ifs' and 'maybes'?
>
I think it was a missunderstanding. I also thought that i just
have to adapt the wrapper to the original API, that is what I did in the patch,
and not to delete the functions completly.
Anayway, we currently have another project which use a STM32 MCR connected to
USB.
A nice feature of this STM is to update the firmware using the USB interface.
This is easy to implement and fast.
We want to use such a functionality in all of our MCRs to easily update the
firmware
at the customer if we found a bug.
We also plan to have a BMC connected to USB. Then we have i2c and USB.
Regards
Andy
> --
> Lee Jones
> Linaro STMicroelectronics Landing Team Lead
> Linaro.org │ Open source software for ARM SoCs
> Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/3] drivers/watchdog/menf21bmc_wd: introduce MEN 14F021P00 BMC Watchdog driver
Added driver to support the 14F021P00 BMC Watchdog.
The BMC is a Board Management Controller including watchdog functionality.
This driver use the I2C interface to the BMC using the menf21bmc MFD Core
driver.
Signed-off-by: Andreas Werner
---
drivers/watchdog/Kconfig| 7 ++
drivers/watchdog/Makefile | 1 +
drivers/watchdog/menf21bmc_wd.c | 217
3 files changed, 225 insertions(+)
create mode 100644 drivers/watchdog/menf21bmc_wd.c
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 2b4c1fc..ede3201 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -95,6 +95,13 @@ config GPIO_WATCHDOG
If you say yes here you get support for watchdog device
controlled through GPIO-line.
+config MENF21BMC_WATCHDOG
+ tristate "MEN 14F021P00 BMC Watchdog"
+ depends on MFD_MENF21BMC
+ select WATCHDOG_CORE
+ help
+ Say Y here to include support for the MEN 14F021P00 BMC Watchdog.
+
config WM831X_WATCHDOG
tristate "WM831x watchdog"
depends on MFD_WM831X
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 1b5f3d5..0a5465d 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -178,3 +178,4 @@ obj-$(CONFIG_WM831X_WATCHDOG) += wm831x_wdt.o
obj-$(CONFIG_WM8350_WATCHDOG) += wm8350_wdt.o
obj-$(CONFIG_MAX63XX_WATCHDOG) += max63xx_wdt.o
obj-$(CONFIG_SOFT_WATCHDOG) += softdog.o
+obj-$(CONFIG_MENF21BMC_WATCHDOG) += menf21bmc_wd.o
diff --git a/drivers/watchdog/menf21bmc_wd.c b/drivers/watchdog/menf21bmc_wd.c
new file mode 100644
index 000..abd2869
--- /dev/null
+++ b/drivers/watchdog/menf21bmc_wd.c
@@ -0,0 +1,217 @@
+/*
+ * MEN 14F021P00 Board Management Controller (BMC) Watchdog Driver.
+ *
+ * Copyright (C) 2014 MEN Mikro Elektronik Nuernberg GmbH
+ * Author: Andreas Werner
+ * All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define DEVNAME "menf21bmc_wd"
+
+#define BMC_CMD_WD_ON 0x11
+#define BMC_CMD_WD_OFF 0x12
+#define BMC_CMD_WD_TRIG0x13
+#define BMC_CMD_WD_TIME0x14
+#define BMC_CMD_WD_STATE 0x17
+#define BMC_WD_OFF_VAL 0x69
+#define BMC_CMD_RST_RSN0x92
+
+#define BMC_WD_TIMEOUT_MIN 1 /* in sec */
+#define BMC_WD_TIMEOUT_MAX 6553/* in sec */
+
+static bool nowayout = WATCHDOG_NOWAYOUT;
+module_param(nowayout, bool, 0);
+MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once started (default="
+ __MODULE_STRING(WATCHDOG_NOWAYOUT) ")");
+
+struct menf21bmc_wd_data {
+ struct watchdog_device wdt;
+ struct menf21bmc *menf21bmc;
+};
+
+static int menf21bmc_wd_set_bootstatus(struct menf21bmc_wd_data *data)
+{
+ int rst_rsn;
+ struct menf21bmc *menf21bmc = data->menf21bmc;
+
+ rst_rsn = menf21bmc->read_byte_data(menf21bmc->client,
+ BMC_CMD_RST_RSN);
+ if (rst_rsn < 0)
+ return rst_rsn;
+
+ if (rst_rsn == 0x02)
+ data->wdt.bootstatus |= WDIOF_CARDRESET;
+ else if (rst_rsn == 0x05)
+ data->wdt.bootstatus |= WDIOF_EXTERN1;
+ else if (rst_rsn == 0x06)
+ data->wdt.bootstatus |= WDIOF_EXTERN2;
+ else if (rst_rsn == 0x0A)
+ data->wdt.bootstatus |= WDIOF_POWERUNDER;
+
+ return 0;
+}
+
+static int menf21bmc_wd_start(struct watchdog_device *wdt)
+{
+ struct menf21bmc_wd_data *data = watchdog_get_drvdata(wdt);
+ struct menf21bmc *menf21bmc = data->menf21bmc;
+
+ return menf21bmc->write_byte(menf21bmc->client, BMC_CMD_WD_ON);
+}
+
+static int menf21bmc_wd_stop(struct watchdog_device *wdt)
+{
+ struct menf21bmc_wd_data *data = watchdog_get_drvdata(wdt);
+ struct menf21bmc *menf21bmc = data->menf21bmc;
+
+ return menf21bmc->write_byte_data(menf21bmc->client,
+ BMC_CMD_WD_OFF, BMC_WD_OFF_VAL);
+}
+
+static int
+menf21bmc_wd_settimeout(struct watchdog_device *wdt, unsigned int timeout)
+{
+ int ret;
+ struct menf21bmc_wd_data *data = watchdog_get_drvdata(wdt);
+ struct menf21bmc *menf21bmc = data->menf21bmc;
+
+ /*
+* BMC Watchdog does have a resolution of 100ms.
+* Watchdog API defines the timeout in seconds, so we have to
+* multiply the value.
+*/
+ ret = menf21bmc->write_word_data(menf21bmc->client,
+ BMC_CMD_WD_T
[PATCH v2 3/3] drivers/leds/leds-menf21bmc: introduce MEN 14F021P00 BMC LED driver
Added driver to support the 14F021P00 BMC LEDs.
The BMC is a Board Management Controll include four LEDs which
can be switched on and off.
This driver use the I2C interface to the BMC using the menf21bmc MFD Core
driver.
Signed-off-by: Andreas Werner
---
drivers/leds/Kconfig | 6 ++
drivers/leds/Makefile | 2 +-
drivers/leds/leds-menf21bmc.c | 136 ++
3 files changed, 143 insertions(+), 1 deletion(-)
create mode 100644 drivers/leds/leds-menf21bmc.c
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 1e81d7a..8f98e0f 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -466,6 +466,12 @@ config LEDS_OT200
This option enables support for the LEDs on the Bachmann OT200.
Say Y to enable LEDs on the Bachmann OT200.
+config LEDS_MENF21BMC
+ tristate "LED support for the MEN 14F021P00 BMC"
+ depends on LEDS_CLASS && MFD_MENF21BMC
+ help
+ Say Y here to include support for the MEN 14F021P00 BMC LEDs.
+
comment "LED driver for blink(1) USB RGB LED is under Special HID drivers
(HID_THINGM)"
config LEDS_BLINKM
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index 79c5155..1c465fe 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -54,7 +54,7 @@ obj-$(CONFIG_LEDS_MAX8997)+= leds-max8997.o
obj-$(CONFIG_LEDS_LM355x) += leds-lm355x.o
obj-$(CONFIG_LEDS_BLINKM) += leds-blinkm.o
obj-$(CONFIG_LEDS_VERSATILE) += leds-versatile.o
-
+obj-$(CONFIG_LEDS_MENF21BMC) += leds-menf21bmc.o
# LED SPI Drivers
obj-$(CONFIG_LEDS_DAC124S085) += leds-dac124s085.o
diff --git a/drivers/leds/leds-menf21bmc.c b/drivers/leds/leds-menf21bmc.c
new file mode 100644
index 000..6099524
--- /dev/null
+++ b/drivers/leds/leds-menf21bmc.c
@@ -0,0 +1,136 @@
+/*
+ * MEN 14F021P00 Board Management Controller (BMC) LEDs Driver.
+ *
+ * This is the core LED driver of the MEN 14F021P00 BMC.
+ * There are four LEDs available which can be switched on and off.
+ * STATUS LED, HOT SWAP LED, USER LED 1, USER LED 2
+ *
+ * Copyright (C) 2014 MEN Mikro Elektronik Nuernberg GmbH
+ * Author: Andreas Werner
+ * All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#define BMC_CMD_LED_GET_SET0xA0
+#define BMC_BIT_LED_STATUS BIT(0)
+#define BMC_BIT_LED_HOTSWAPBIT(1)
+#define BMC_BIT_LED_USER1 BIT(2)
+#define BMC_BIT_LED_USER2 BIT(3)
+
+struct menf21bmc_led_data {
+ struct led_classdev cdev;
+ struct menf21bmc *menf21bmc;
+ u8 led_bit;
+ const char *name;
+};
+
+static struct menf21bmc_led_data leds[] = {
+ {
+ .name = "menf21bmc:led_status",
+ .led_bit = BMC_BIT_LED_STATUS,
+ },
+ {
+ .name = "menf21bmc:led_hotswap",
+ .led_bit = BMC_BIT_LED_HOTSWAP,
+ },
+ {
+ .name = "menf21bmc:led_user1",
+ .led_bit = BMC_BIT_LED_USER1,
+ },
+ {
+ .name = "menf21bmc:led_user2",
+ .led_bit = BMC_BIT_LED_USER2,
+ }
+};
+
+static DEFINE_MUTEX(led_lock);
+
+static void
+menf21bmc_led_set(struct led_classdev *led_cdev, enum led_brightness value)
+{
+ int led_val;
+ struct menf21bmc_led_data *led = container_of(led_cdev,
+ struct menf21bmc_led_data, cdev);
+ struct menf21bmc *menf21bmc = led->menf21bmc;
+
+ mutex_lock(&led_lock);
+ led_val = menf21bmc->read_byte_data(menf21bmc->client,
+ BMC_CMD_LED_GET_SET);
+ if (led_val < 0)
+ goto err_out;
+
+ if (value == LED_OFF)
+ led_val &= ~led->led_bit;
+ else
+ led_val |= led->led_bit;
+
+ menf21bmc->write_byte_data(menf21bmc->client,
+ BMC_CMD_LED_GET_SET, led_val);
+err_out:
+ mutex_unlock(&led_lock);
+}
+
+static int menf21bmc_led_probe(struct platform_device *pdev)
+{
+ int i;
+ int ret;
+ struct menf21bmc *menf21bmc = dev_get_drvdata(pdev->dev.parent);
+
+ for (i = 0; i < ARRAY_SIZE(leds); i++) {
+ leds[i].cdev.name = leds[i].name;
+ leds[i].cdev.brightness_set = menf21bmc_led_set;
+ leds[i].menf21bmc = menf21bmc;
+
+ ret = led_classdev_register(&pdev->dev, &leds[i].cdev);
+ if (ret < 0)
+ goto err_free_leds;
+ }
+ dev_
[PATCH v2 1/3] drivers/mfd/menf21bmc: introduce MEN 14F021P00 BMC MFD Core driver
The MEN 14F021P00 Board Management Controller provides an
I2C interface to the host to access the feature implemented in the BMC.
The BMC is a PIC Microntroller assembled on CPCI Card from MEN Mikroelektronik
and on a few Box/Display Computer.
Added MFD Core driver, supporting the I2C communication to the device.
The MFD driver currently supports the following features:
- Watchdog
- LEDs
Signed-off-by: Andreas Werner
---
drivers/mfd/Kconfig | 12 +++
drivers/mfd/Makefile | 1 +
drivers/mfd/menf21bmc.c | 220 ++
include/linux/mfd/menf21bmc.h | 31 ++
4 files changed, 264 insertions(+)
create mode 100644 drivers/mfd/menf21bmc.c
create mode 100644 include/linux/mfd/menf21bmc.h
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index ab5a43c..7c2e8d2 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -427,6 +427,18 @@ config MFD_MAX8998
additional drivers must be enabled in order to use the functionality
of the device.
+config MFD_MENF21BMC
+ tristate "MEN 14F021P00 Board Management Controller Support"
+ depends on I2C=y
+ select MFD_CORE
+ help
+ Say yes here to add support for the MEN 14F021P00 BMC
+ which is a Board Management Controller connected to the I2C bus.
+ This driver provides common support for accessing the devices;
+ additional drivers must be enabled in order to use the
+ functionality of the BMC device.
+
+
config EZX_PCAP
bool "Motorola EZXPCAP Support"
depends on SPI_MASTER
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 5913208..8f2be38 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -167,3 +167,4 @@ obj-$(CONFIG_MFD_AS3711)+= as3711.o
obj-$(CONFIG_MFD_AS3722) += as3722.o
obj-$(CONFIG_MFD_STW481X) += stw481x.o
obj-$(CONFIG_MFD_IPAQ_MICRO) += ipaq-micro.o
+obj-$(CONFIG_MFD_MENF21BMC)+= menf21bmc.o
diff --git a/drivers/mfd/menf21bmc.c b/drivers/mfd/menf21bmc.c
new file mode 100644
index 000..8de92b5
--- /dev/null
+++ b/drivers/mfd/menf21bmc.c
@@ -0,0 +1,220 @@
+/*
+ * MEN 14F021P00 Board Management Controller (BMC) MFD Core Driver.
+ *
+ * Copyright (C) 2014 MEN Mikro Elektronik Nuernberg GmbH
+ * Author: Andreas Werner
+ * All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define BMC_CMD_REV_MAJOR 0x80
+#define BMC_CMD_REV_MINOR 0x81
+#define BMC_CMD_REV_MAIN 0x82
+#define BMC_CMD_REV_BUILD 0x83
+#define BMC_CMD_REV_VERI 0x84
+#define BMC_CMD_WD_ARM_SET 0x18
+#define BMC_CMD_WD_ARM_GET 0x19
+
+static struct mfd_cell menf21bmc_cell[] = {
+ {
+ .name = "menf21bmc_wd",
+ },
+ {
+ .name = "menf21bmc_led",
+ },
+};
+
+static int
+menf21bmc_read_byte_data(struct i2c_client *client, u8 reg)
+{
+ int ret;
+ struct menf21bmc *data = i2c_get_clientdata(client);
+
+ mutex_lock(&data->lock);
+ ret = i2c_smbus_read_byte_data(client, reg);
+ mutex_unlock(&data->lock);
+
+ return ret;
+}
+
+static int
+menf21bmc_read_word_data(struct i2c_client *client, u8 reg)
+{
+ int ret;
+ struct menf21bmc *data = i2c_get_clientdata(client);
+
+ mutex_lock(&data->lock);
+ ret = i2c_smbus_read_word_data(client, reg);
+ mutex_unlock(&data->lock);
+
+ return ret;
+}
+
+static int menf21bmc_write_byte_data(struct i2c_client *client, u8 reg, u8 val)
+{
+ int ret;
+ struct menf21bmc *data = i2c_get_clientdata(client);
+
+ mutex_lock(&data->lock);
+ ret = i2c_smbus_write_byte_data(client, reg, val);
+ mutex_unlock(&data->lock);
+
+ return ret;
+}
+
+static int menf21bmc_write_word_data(struct i2c_client *client, u8 reg, u16
val)
+{
+ int ret;
+ struct menf21bmc *data = i2c_get_clientdata(client);
+
+ mutex_lock(&data->lock);
+ ret = i2c_smbus_write_word_data(client, reg, val);
+ mutex_unlock(&data->lock);
+
+ return ret;
+}
+
+static int menf21bmc_write_byte(struct i2c_client *client, u8 val)
+{
+ int ret;
+ struct menf21bmc *data = i2c_get_clientdata(client);
+
+ mutex_lock(&data->lock);
+ ret = i2c_smbus_write_byte(client, val);
+ mutex_unlock(&data->lock);
+
+ return ret;
+}
+
+static int menf21bmc_wd_leave_prod_mode(struct i2c_client *client)
+{
+ int val, ret;
+
+ val = menf21bmc_read_byte_data(client, BMC_CMD_WD_ARM_GET);
+ if (val <
[PATCH v2 0/3] Introduce MEN 14F02100 BMC driver series
This patch set add support for the MEN 14F021P00 Board Management called BMC. The BMC is a PIC Mikrocontroller which assembled on almost all of our 3U Compact PCI CPU board and a few Box PCs. The main part of the BMC is to start and monitor the board, but there are a lot more features which can be accessed using an I2C Host interface Features supported in this Patchset: - Watchdog - LEDs The Patchset includes a MFD Core driver, Watchdog and LEDs driver. Changes in v2: - changed i2c_smbus_read wrapper function to return both, value and error. - moved "leave production mode" from Watchdog driver to mfd core. - fixed some return values in the watchdog driver to return the original error value instead of -EIO. Andreas Werner (3): drivers/mfd/menf21bmc: introduce MEN 14F021P00 BMC MFD Core driver drivers/watchdog/menf21bmc_wd: introduce MEN 14F021P00 BMC Watchdog driver drivers/leds/leds-menf21bmc: introduce MEN 14F021P00 BMC LED driver drivers/leds/Kconfig| 6 ++ drivers/leds/Makefile | 2 +- drivers/leds/leds-menf21bmc.c | 136 + drivers/mfd/Kconfig | 12 +++ drivers/mfd/Makefile| 1 + drivers/mfd/menf21bmc.c | 220 drivers/watchdog/Kconfig| 7 ++ drivers/watchdog/Makefile | 1 + drivers/watchdog/menf21bmc_wd.c | 217 +++ include/linux/mfd/menf21bmc.h | 31 ++ 10 files changed, 632 insertions(+), 1 deletion(-) create mode 100644 drivers/leds/leds-menf21bmc.c create mode 100644 drivers/mfd/menf21bmc.c create mode 100644 drivers/watchdog/menf21bmc_wd.c create mode 100644 include/linux/mfd/menf21bmc.h -- 1.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] drivers/mfd/menf21bmc: introduce MEN 14F021P00 BMC MFD Core driver
aOn Mon, May 19, 2014 at 06:39:53PM +0100, Lee Jones wrote: > On Mon, 19 May 2014, Guenter Roeck wrote: > > > On 05/19/2014 05:43 AM, Andreas Werner wrote: > > >aOn Sat, May 17, 2014 at 08:47:42AM -0700, Guenter Roeck wrote: > > >>On 05/16/2014 09:37 AM, Andreas Werner wrote: > > >>>The MEN 14F021P00 Board Management Controller provides an > > >>>I2C interface to the host to access the feature implemented in the BMC. > > >>>The BMC is a PIC Microntroller assembled on CPCI Card from MEN > > >>>Mikroelektronik > > >>>and on a few Box/Display Computer. > > >>> > > >>>Added MFD Core driver, supporting the I2C communication to the device. > > >>> > > >>>The MFD driver currently supports the following features: > > >>> - Watchdog > > >>> - LEDs > > >>> > > >>>Signed-off-by: Andreas Werner > > >>>--- > > >>> drivers/mfd/Kconfig | 12 +++ > > >>> drivers/mfd/Makefile | 1 + > > >>> drivers/mfd/menf21bmc.c | 193 > > >>> ++ > > >>> include/linux/mfd/menf21bmc.h | 32 +++ > > >>> 4 files changed, 238 insertions(+) > > >>> create mode 100644 drivers/mfd/menf21bmc.c > > >>> create mode 100644 include/linux/mfd/menf21bmc.h > > >>> > > >>>diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig > > >>>index ab5a43c..7c2e8d2 100644 > > >>>--- a/drivers/mfd/Kconfig > > >>>+++ b/drivers/mfd/Kconfig > > >>>@@ -427,6 +427,18 @@ config MFD_MAX8998 > > >>> additional drivers must be enabled in order to use the > > >>> functionality > > >>> of the device. > > >>> > > >>>+config MFD_MENF21BMC > > >>>+tristate "MEN 14F021P00 Board Management Controller Support" > > >>>+depends on I2C=y > > >>>+select MFD_CORE > > >>>+help > > >>>+ Say yes here to add support for the MEN 14F021P00 BMC > > >>>+ which is a Board Management Controller connected to the I2C > > >>>bus. > > >>>+ This driver provides common support for accessing the devices; > > >>>+ additional drivers must be enabled in order to use the > > >>>+ functionality of the BMC device. > > >>>+ > > >>>+ > > >>> config EZX_PCAP > > >>> bool "Motorola EZXPCAP Support" > > >>> depends on SPI_MASTER > > >>>diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile > > >>>index 5913208..8f2be38 100644 > > >>>--- a/drivers/mfd/Makefile > > >>>+++ b/drivers/mfd/Makefile > > >>>@@ -167,3 +167,4 @@ obj-$(CONFIG_MFD_AS3711) += as3711.o > > >>> obj-$(CONFIG_MFD_AS3722) += as3722.o > > >>> obj-$(CONFIG_MFD_STW481X) += stw481x.o > > >>> obj-$(CONFIG_MFD_IPAQ_MICRO) += ipaq-micro.o > > >>>+obj-$(CONFIG_MFD_MENF21BMC) += menf21bmc.o > > >>>diff --git a/drivers/mfd/menf21bmc.c b/drivers/mfd/menf21bmc.c > > >>>new file mode 100644 > > >>>index 000..77de1a8 > > >>>--- /dev/null > > >>>+++ b/drivers/mfd/menf21bmc.c > > >>>@@ -0,0 +1,193 @@ > > >>>+/* > > >>>+ * MEN 14F021P00 Board Management Controller (BMC) MFD Core Driver. > > >>>+ * > > >>>+ * Copyright (C) 2014 MEN Mikro Elektronik Nuernberg GmbH > > >>>+ * Author: Andreas Werner > > >>>+ * All rights reserved. > > >>>+ * > > >>>+ * This program is free software; you can redistribute it and/or > > >>>modify it > > >>>+ * under the terms of the GNU General Public License as published > > >>>by the > > >>>+ * Free Software Foundation; either version 2 of the License, or (at > > >>>your > > >>>+ * option) any later version. > > >>>+ * > > >>>+ */ > > >>>+ > > >>>+#include > > >>>+#include > > >>>+#include > > >>>+#include > > >>>+#include > > >>>+#include > > >>>+ > >
Re: [PATCH 1/3] drivers/mfd/menf21bmc: introduce MEN 14F021P00 BMC MFD Core driver
aOn Sat, May 17, 2014 at 08:47:42AM -0700, Guenter Roeck wrote:
> On 05/16/2014 09:37 AM, Andreas Werner wrote:
> >The MEN 14F021P00 Board Management Controller provides an
> >I2C interface to the host to access the feature implemented in the BMC.
> >The BMC is a PIC Microntroller assembled on CPCI Card from MEN
> >Mikroelektronik
> >and on a few Box/Display Computer.
> >
> >Added MFD Core driver, supporting the I2C communication to the device.
> >
> >The MFD driver currently supports the following features:
> > - Watchdog
> > - LEDs
> >
> >Signed-off-by: Andreas Werner
> >---
> > drivers/mfd/Kconfig | 12 +++
> > drivers/mfd/Makefile | 1 +
> > drivers/mfd/menf21bmc.c | 193
> > ++
> > include/linux/mfd/menf21bmc.h | 32 +++
> > 4 files changed, 238 insertions(+)
> > create mode 100644 drivers/mfd/menf21bmc.c
> > create mode 100644 include/linux/mfd/menf21bmc.h
> >
> >diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> >index ab5a43c..7c2e8d2 100644
> >--- a/drivers/mfd/Kconfig
> >+++ b/drivers/mfd/Kconfig
> >@@ -427,6 +427,18 @@ config MFD_MAX8998
> > additional drivers must be enabled in order to use the functionality
> > of the device.
> >
> >+config MFD_MENF21BMC
> >+tristate "MEN 14F021P00 Board Management Controller Support"
> >+depends on I2C=y
> >+select MFD_CORE
> >+help
> >+ Say yes here to add support for the MEN 14F021P00 BMC
> >+ which is a Board Management Controller connected to the I2C bus.
> >+ This driver provides common support for accessing the devices;
> >+ additional drivers must be enabled in order to use the
> >+ functionality of the BMC device.
> >+
> >+
> > config EZX_PCAP
> > bool "Motorola EZXPCAP Support"
> > depends on SPI_MASTER
> >diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> >index 5913208..8f2be38 100644
> >--- a/drivers/mfd/Makefile
> >+++ b/drivers/mfd/Makefile
> >@@ -167,3 +167,4 @@ obj-$(CONFIG_MFD_AS3711) += as3711.o
> > obj-$(CONFIG_MFD_AS3722) += as3722.o
> > obj-$(CONFIG_MFD_STW481X) += stw481x.o
> > obj-$(CONFIG_MFD_IPAQ_MICRO) += ipaq-micro.o
> >+obj-$(CONFIG_MFD_MENF21BMC) += menf21bmc.o
> >diff --git a/drivers/mfd/menf21bmc.c b/drivers/mfd/menf21bmc.c
> >new file mode 100644
> >index 000..77de1a8
> >--- /dev/null
> >+++ b/drivers/mfd/menf21bmc.c
> >@@ -0,0 +1,193 @@
> >+/*
> >+ * MEN 14F021P00 Board Management Controller (BMC) MFD Core Driver.
> >+ *
> >+ * Copyright (C) 2014 MEN Mikro Elektronik Nuernberg GmbH
> >+ * Author: Andreas Werner
> >+ * All rights reserved.
> >+ *
> >+ * This program is free software; you can redistribute it and/or modify it
> >+ * under the terms of the GNU General Public License as published by the
> >+ * Free Software Foundation; either version 2 of the License, or (at your
> >+ * option) any later version.
> >+ *
> >+ */
> >+
> >+#include
> >+#include
> >+#include
> >+#include
> >+#include
> >+#include
> >+
> >+#define BMC_CMD_REV_MAJOR 0x80
> >+#define BMC_CMD_REV_MINOR 0x81
> >+#define BMC_CMD_REV_MAIN0x82
> >+#define BMC_CMD_REV_BUILD 0x83
> >+#define BMC_CMD_REV_VERI0x84
> >+
> >+static struct mfd_cell menf21bmc_cell[] = {
> >+{
> >+.name = "menf21bmc_wd",
> >+},
> >+{
> >+.name = "menf21bmc_led",
> >+},
> >+};
> >+
> >+static int
> >+menf21bmc_read_byte_data(struct i2c_client *client, u8 reg, uint8_t *val)
> >+{
> >+int ret;
> >+struct menf21bmc *data = i2c_get_clientdata(client);
> >+
> >+mutex_lock(&data->lock);
> >+ret = i2c_smbus_read_byte_data(client, reg);
> >+mutex_unlock(&data->lock);
> >+
> >+if (ret < 0) {
> >+dev_err(&client->dev, "failed to read byte at 0x%02x\n", reg);
> >+return ret;
> >+}
> >+
> >+*val = (uint8_t)ret;
> >+
> >+return 0;
> >+}
> >+
> I personally would prefer if you would retain the original API, which returns
> both value
> and error code as return value. I don't see the benefit of changing the API
> as you did -
> it just complicates the code.
>
> Thanks,
> Guenter
>
I think it is ok for a wrapper like this because it does not really change an
API because
it is menf21bmc related.
I did the same in rtc-rx8581, and it was already done in rtc_ds1307.c.
I personally prefer this way because the return of the function and the return
value of the i2c_smbus_read - which is the value read from the device - are
seperated.
If it is a no go for the mfd/wdt core i can change it back to the original
i2c_smbus API.
If it is ok on your side for a wrapper like this, we can let it as it is.
Thanks
Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] drivers/watchdog/menf21bmc_wd: introduce MEN 14F021P00 BMC Watchdog driver
aOn Sat, May 17, 2014 at 08:57:27AM -0700, Guenter Roeck wrote:
> On 05/16/2014 09:37 AM, Andreas Werner wrote:
> >Added driver to support the 14F021P00 BMC Watchdog.
> >The BMC is a Board Management Controller including watchdog functionality.
> >
> >This driver use the I2C interface to the BMC using the menf21bmc MFD Core
> >driver.
> >
> >Signed-off-by: Andreas Werner
> >---
> > drivers/watchdog/Kconfig| 7 ++
> > drivers/watchdog/Makefile | 1 +
> > drivers/watchdog/menf21bmc_wd.c | 263
> >
> > 3 files changed, 271 insertions(+)
> > create mode 100644 drivers/watchdog/menf21bmc_wd.c
> >
> >diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
> >index 2b4c1fc..ede3201 100644
> >--- a/drivers/watchdog/Kconfig
> >+++ b/drivers/watchdog/Kconfig
> >@@ -95,6 +95,13 @@ config GPIO_WATCHDOG
> > If you say yes here you get support for watchdog device
> > controlled through GPIO-line.
> >
> >+config MENF21BMC_WATCHDOG
> >+tristate "MEN 14F021P00 BMC Watchdog"
> >+depends on MFD_MENF21BMC
> >+select WATCHDOG_CORE
> >+help
> >+ Say Y here to include support for the MEN 14F021P00 BMC Watchdog.
> >+
> > config WM831X_WATCHDOG
> > tristate "WM831x watchdog"
> > depends on MFD_WM831X
> >diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
> >index 1b5f3d5..0a5465d 100644
> >--- a/drivers/watchdog/Makefile
> >+++ b/drivers/watchdog/Makefile
> >@@ -178,3 +178,4 @@ obj-$(CONFIG_WM831X_WATCHDOG) += wm831x_wdt.o
> > obj-$(CONFIG_WM8350_WATCHDOG) += wm8350_wdt.o
> > obj-$(CONFIG_MAX63XX_WATCHDOG) += max63xx_wdt.o
> > obj-$(CONFIG_SOFT_WATCHDOG) += softdog.o
> >+obj-$(CONFIG_MENF21BMC_WATCHDOG) += menf21bmc_wd.o
> >diff --git a/drivers/watchdog/menf21bmc_wd.c
> >b/drivers/watchdog/menf21bmc_wd.c
> >new file mode 100644
> >index 000..31ccea8
> >--- /dev/null
> >+++ b/drivers/watchdog/menf21bmc_wd.c
> >@@ -0,0 +1,263 @@
> >+/*
> >+ * MEN 14F021P00 Board Management Controller (BMC) Watchdog Driver.
> >+ *
> >+ * Copyright (C) 2014 MEN Mikro Elektronik Nuernberg GmbH
> >+ * Author: Andreas Werner
> >+ * All rights reserved.
> >+ *
> >+ * This program is free software; you can redistribute it and/or modify it
> >+ * under the terms of the GNU General Public License as published by the
> >+ * Free Software Foundation; either version 2 of the License, or (at your
> >+ * option) any later version.
> >+ *
> >+ */
> >+
> >+#include
> >+#include
> >+#include
> >+#include
> >+#include
> >+#include
> >+
> >+#define DEVNAME "menf21bmc_wd"
> >+
> >+#define BMC_CMD_WD_ON 0x11
> >+#define BMC_CMD_WD_OFF 0x12
> >+#define BMC_CMD_WD_TRIG 0x13
> >+#define BMC_CMD_WD_TIME 0x14
> >+#define BMC_CMD_WD_STATE0x17
> >+#define BMC_CMD_WD_ARM_SET 0x18
> >+#define BMC_CMD_WD_ARM_GET 0x19
> >+#define BMC_CMD_ARM_STATE 0x19
> >+#define BMC_WD_OFF_VAL 0x69
> >+#define BMC_CMD_RST_RSN 0x92
> >+
> >+#define BMC_WD_TIMEOUT_MIN 1 /* in sec -> BMC min = 0.1 s */
>
> I find the comment a bit confusing. The timeout is in seconds. The BMC minimum
> timeout may be 0.1s, but that is not reflected in the define. Maybe replace
> the comment with something like
> /* in sec (BMC min = 0.1 s) */
OK. I think I just write /* in sec */ as the comment because
it is explained in menf21bmc_wd_settimout() function.
>
> >+#define BMC_WD_TIMEOUT_MAX 6553/* in sec -> BMC max = 6553,5 s */
> >+
> >+static bool nowayout = WATCHDOG_NOWAYOUT;
> >+module_param(nowayout, bool, 0);
> >+MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once started
> >(default="
> >+__MODULE_STRING(WATCHDOG_NOWAYOUT) ")");
> >+
> >+struct menf21bmc_wd_data {
> >+struct watchdog_device wdt;
> >+struct menf21bmc *menf21bmc;
> >+};
> >+
> >+static int menf21bmc_wd_set_bootstatus(struct menf21bmc_wd_data *data)
> >+{
> >+u8 rst_rsn;
> >+int ret;
> >+struct menf21bmc *menf21bmc = data->menf21bmc;
> >+
> >+ret = menf21bmc->read_byte_data(menf21bmc->client,
> >+BMC_CMD_RST_RSN, &rst_rsn);
> >+if (r
[PATCH 3/3] drivers/leds/leds-menf21bmc: introduce MEN 14F021P00 BMC LED driver
Added driver to support the 14F021P00 BMC LEDs.
The BMC is a Board Management Controll include four LEDs which
can be switched on and off.
This driver use the I2C interface to the BMC using the menf21bmc MFD Core
driver.
Signed-off-by: Andreas Werner
---
drivers/leds/Kconfig | 6 ++
drivers/leds/Makefile | 2 +-
drivers/leds/leds-menf21bmc.c | 135 ++
3 files changed, 142 insertions(+), 1 deletion(-)
create mode 100644 drivers/leds/leds-menf21bmc.c
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 1e81d7a..8f98e0f 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -466,6 +466,12 @@ config LEDS_OT200
This option enables support for the LEDs on the Bachmann OT200.
Say Y to enable LEDs on the Bachmann OT200.
+config LEDS_MENF21BMC
+ tristate "LED support for the MEN 14F021P00 BMC"
+ depends on LEDS_CLASS && MFD_MENF21BMC
+ help
+ Say Y here to include support for the MEN 14F021P00 BMC LEDs.
+
comment "LED driver for blink(1) USB RGB LED is under Special HID drivers
(HID_THINGM)"
config LEDS_BLINKM
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index 79c5155..1c465fe 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -54,7 +54,7 @@ obj-$(CONFIG_LEDS_MAX8997)+= leds-max8997.o
obj-$(CONFIG_LEDS_LM355x) += leds-lm355x.o
obj-$(CONFIG_LEDS_BLINKM) += leds-blinkm.o
obj-$(CONFIG_LEDS_VERSATILE) += leds-versatile.o
-
+obj-$(CONFIG_LEDS_MENF21BMC) += leds-menf21bmc.o
# LED SPI Drivers
obj-$(CONFIG_LEDS_DAC124S085) += leds-dac124s085.o
diff --git a/drivers/leds/leds-menf21bmc.c b/drivers/leds/leds-menf21bmc.c
new file mode 100644
index 000..1548d08
--- /dev/null
+++ b/drivers/leds/leds-menf21bmc.c
@@ -0,0 +1,135 @@
+/*
+ * MEN 14F021P00 Board Management Controller (BMC) LEDs Driver.
+ *
+ * This is the core LED driver of the MEN 14F021P00 BMC.
+ * There are four LEDs available which can be switched on and off.
+ * STATUS LED, HOT SWAP LED, USER LED 1, USER LED 2
+ *
+ * Copyright (C) 2014 MEN Mikro Elektronik Nuernberg GmbH
+ * Author: Andreas Werner
+ * All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#define BMC_CMD_LED_GET_SET0xA0
+#define BMC_BIT_LED_STATUS BIT(0)
+#define BMC_BIT_LED_HOTSWAPBIT(1)
+#define BMC_BIT_LED_USER1 BIT(2)
+#define BMC_BIT_LED_USER2 BIT(3)
+
+struct menf21bmc_led_data {
+ struct led_classdev cdev;
+ struct menf21bmc *menf21bmc;
+ u8 led_bit;
+ const char *name;
+};
+
+static struct menf21bmc_led_data leds[] = {
+ {
+ .name = "menf21bmc:led_status",
+ .led_bit = BMC_BIT_LED_STATUS,
+ },
+ {
+ .name = "menf21bmc:led_hotswap",
+ .led_bit = BMC_BIT_LED_HOTSWAP,
+ },
+ {
+ .name = "menf21bmc:led_user1",
+ .led_bit = BMC_BIT_LED_USER1,
+ },
+ {
+ .name = "menf21bmc:led_user2",
+ .led_bit = BMC_BIT_LED_USER2,
+ }
+};
+
+static DEFINE_MUTEX(led_lock);
+
+static void
+menf21bmc_led_set(struct led_classdev *led_cdev, enum led_brightness value)
+{
+ u8 led_val;
+ int ret;
+ struct menf21bmc_led_data *led = container_of(led_cdev,
+ struct menf21bmc_led_data, cdev);
+ struct menf21bmc *menf21bmc = led->menf21bmc;
+
+ mutex_lock(&led_lock);
+ ret = menf21bmc->read_byte_data(menf21bmc->client,
+ BMC_CMD_LED_GET_SET, &led_val);
+ if (!ret) {
+ if (value == LED_OFF)
+ led_val &= ~led->led_bit;
+ else
+ led_val |= led->led_bit;
+
+ menf21bmc->write_byte_data(menf21bmc->client,
+ BMC_CMD_LED_GET_SET, led_val);
+ }
+ mutex_unlock(&led_lock);
+}
+
+static int menf21bmc_led_probe(struct platform_device *pdev)
+{
+ int i;
+ int ret;
+ struct menf21bmc *menf21bmc = dev_get_drvdata(pdev->dev.parent);
+
+ for (i = 0; i < ARRAY_SIZE(leds); i++) {
+ leds[i].cdev.name = leds[i].name;
+ leds[i].cdev.brightness_set = menf21bmc_led_set;
+ leds[i].menf21bmc = menf21bmc;
+
+ ret = led_classdev_register(&pdev->dev, &leds[i].cdev);
+ if (ret < 0)
+ goto err_free
[PATCH 2/3] drivers/watchdog/menf21bmc_wd: introduce MEN 14F021P00 BMC Watchdog driver
Added driver to support the 14F021P00 BMC Watchdog.
The BMC is a Board Management Controller including watchdog functionality.
This driver use the I2C interface to the BMC using the menf21bmc MFD Core
driver.
Signed-off-by: Andreas Werner
---
drivers/watchdog/Kconfig| 7 ++
drivers/watchdog/Makefile | 1 +
drivers/watchdog/menf21bmc_wd.c | 263
3 files changed, 271 insertions(+)
create mode 100644 drivers/watchdog/menf21bmc_wd.c
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 2b4c1fc..ede3201 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -95,6 +95,13 @@ config GPIO_WATCHDOG
If you say yes here you get support for watchdog device
controlled through GPIO-line.
+config MENF21BMC_WATCHDOG
+ tristate "MEN 14F021P00 BMC Watchdog"
+ depends on MFD_MENF21BMC
+ select WATCHDOG_CORE
+ help
+ Say Y here to include support for the MEN 14F021P00 BMC Watchdog.
+
config WM831X_WATCHDOG
tristate "WM831x watchdog"
depends on MFD_WM831X
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 1b5f3d5..0a5465d 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -178,3 +178,4 @@ obj-$(CONFIG_WM831X_WATCHDOG) += wm831x_wdt.o
obj-$(CONFIG_WM8350_WATCHDOG) += wm8350_wdt.o
obj-$(CONFIG_MAX63XX_WATCHDOG) += max63xx_wdt.o
obj-$(CONFIG_SOFT_WATCHDOG) += softdog.o
+obj-$(CONFIG_MENF21BMC_WATCHDOG) += menf21bmc_wd.o
diff --git a/drivers/watchdog/menf21bmc_wd.c b/drivers/watchdog/menf21bmc_wd.c
new file mode 100644
index 000..31ccea8
--- /dev/null
+++ b/drivers/watchdog/menf21bmc_wd.c
@@ -0,0 +1,263 @@
+/*
+ * MEN 14F021P00 Board Management Controller (BMC) Watchdog Driver.
+ *
+ * Copyright (C) 2014 MEN Mikro Elektronik Nuernberg GmbH
+ * Author: Andreas Werner
+ * All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define DEVNAME "menf21bmc_wd"
+
+#define BMC_CMD_WD_ON 0x11
+#define BMC_CMD_WD_OFF 0x12
+#define BMC_CMD_WD_TRIG0x13
+#define BMC_CMD_WD_TIME0x14
+#define BMC_CMD_WD_STATE 0x17
+#define BMC_CMD_WD_ARM_SET 0x18
+#define BMC_CMD_WD_ARM_GET 0x19
+#define BMC_CMD_ARM_STATE 0x19
+#define BMC_WD_OFF_VAL 0x69
+#define BMC_CMD_RST_RSN0x92
+
+#define BMC_WD_TIMEOUT_MIN 1 /* in sec -> BMC min = 0.1 s */
+#define BMC_WD_TIMEOUT_MAX 6553/* in sec -> BMC max = 6553,5 s */
+
+static bool nowayout = WATCHDOG_NOWAYOUT;
+module_param(nowayout, bool, 0);
+MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once started (default="
+ __MODULE_STRING(WATCHDOG_NOWAYOUT) ")");
+
+struct menf21bmc_wd_data {
+ struct watchdog_device wdt;
+ struct menf21bmc *menf21bmc;
+};
+
+static int menf21bmc_wd_set_bootstatus(struct menf21bmc_wd_data *data)
+{
+ u8 rst_rsn;
+ int ret;
+ struct menf21bmc *menf21bmc = data->menf21bmc;
+
+ ret = menf21bmc->read_byte_data(menf21bmc->client,
+ BMC_CMD_RST_RSN, &rst_rsn);
+ if (ret < 0)
+ return -EIO;
+
+ if (rst_rsn == 0x02)
+ data->wdt.bootstatus |= WDIOF_CARDRESET;
+ else if (rst_rsn == 0x05)
+ data->wdt.bootstatus |= WDIOF_EXTERN1;
+ else if (rst_rsn == 0x06)
+ data->wdt.bootstatus |= WDIOF_EXTERN2;
+ else if (rst_rsn == 0x0A)
+ data->wdt.bootstatus |= WDIOF_POWERUNDER;
+
+ return 0;
+}
+
+static int menf21bmc_wd_leave_prod_mode(struct platform_device *pdev)
+{
+ int ret;
+ uint8_t val;
+ struct menf21bmc_wd_data *data = platform_get_drvdata(pdev);
+ struct menf21bmc *menf21bmc = data->menf21bmc;
+
+ ret = menf21bmc->read_byte_data(menf21bmc->client,
+ BMC_CMD_WD_ARM_GET, &val);
+ if (ret < 0)
+ return -EIO;
+
+ /*
+* Production mode should be not active after delivery of the Board.
+* To be sure we check it, inform the user and leave the mode
+* if active.
+*/
+ if (val == 0x00) {
+ dev_info(&pdev->dev,
+ "BMC in production mode. Leave production mode\n");
+
+ ret = menf21bmc->write_byte(menf21bmc->client,
+ BMC_CMD_WD_ARM_SET);
+ if (ret < 0)
+
[PATCH 1/3] drivers/mfd/menf21bmc: introduce MEN 14F021P00 BMC MFD Core driver
The MEN 14F021P00 Board Management Controller provides an
I2C interface to the host to access the feature implemented in the BMC.
The BMC is a PIC Microntroller assembled on CPCI Card from MEN Mikroelektronik
and on a few Box/Display Computer.
Added MFD Core driver, supporting the I2C communication to the device.
The MFD driver currently supports the following features:
- Watchdog
- LEDs
Signed-off-by: Andreas Werner
---
drivers/mfd/Kconfig | 12 +++
drivers/mfd/Makefile | 1 +
drivers/mfd/menf21bmc.c | 193 ++
include/linux/mfd/menf21bmc.h | 32 +++
4 files changed, 238 insertions(+)
create mode 100644 drivers/mfd/menf21bmc.c
create mode 100644 include/linux/mfd/menf21bmc.h
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index ab5a43c..7c2e8d2 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -427,6 +427,18 @@ config MFD_MAX8998
additional drivers must be enabled in order to use the functionality
of the device.
+config MFD_MENF21BMC
+ tristate "MEN 14F021P00 Board Management Controller Support"
+ depends on I2C=y
+ select MFD_CORE
+ help
+ Say yes here to add support for the MEN 14F021P00 BMC
+ which is a Board Management Controller connected to the I2C bus.
+ This driver provides common support for accessing the devices;
+ additional drivers must be enabled in order to use the
+ functionality of the BMC device.
+
+
config EZX_PCAP
bool "Motorola EZXPCAP Support"
depends on SPI_MASTER
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 5913208..8f2be38 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -167,3 +167,4 @@ obj-$(CONFIG_MFD_AS3711)+= as3711.o
obj-$(CONFIG_MFD_AS3722) += as3722.o
obj-$(CONFIG_MFD_STW481X) += stw481x.o
obj-$(CONFIG_MFD_IPAQ_MICRO) += ipaq-micro.o
+obj-$(CONFIG_MFD_MENF21BMC)+= menf21bmc.o
diff --git a/drivers/mfd/menf21bmc.c b/drivers/mfd/menf21bmc.c
new file mode 100644
index 000..77de1a8
--- /dev/null
+++ b/drivers/mfd/menf21bmc.c
@@ -0,0 +1,193 @@
+/*
+ * MEN 14F021P00 Board Management Controller (BMC) MFD Core Driver.
+ *
+ * Copyright (C) 2014 MEN Mikro Elektronik Nuernberg GmbH
+ * Author: Andreas Werner
+ * All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define BMC_CMD_REV_MAJOR 0x80
+#define BMC_CMD_REV_MINOR 0x81
+#define BMC_CMD_REV_MAIN 0x82
+#define BMC_CMD_REV_BUILD 0x83
+#define BMC_CMD_REV_VERI 0x84
+
+static struct mfd_cell menf21bmc_cell[] = {
+ {
+ .name = "menf21bmc_wd",
+ },
+ {
+ .name = "menf21bmc_led",
+ },
+};
+
+static int
+menf21bmc_read_byte_data(struct i2c_client *client, u8 reg, uint8_t *val)
+{
+ int ret;
+ struct menf21bmc *data = i2c_get_clientdata(client);
+
+ mutex_lock(&data->lock);
+ ret = i2c_smbus_read_byte_data(client, reg);
+ mutex_unlock(&data->lock);
+
+ if (ret < 0) {
+ dev_err(&client->dev, "failed to read byte at 0x%02x\n", reg);
+ return ret;
+ }
+
+ *val = (uint8_t)ret;
+
+ return 0;
+}
+
+static int
+menf21bmc_read_word_data(struct i2c_client *client, u8 reg, uint16_t *val)
+{
+ int ret;
+ struct menf21bmc *data = i2c_get_clientdata(client);
+
+ mutex_lock(&data->lock);
+ ret = i2c_smbus_read_word_data(client, reg);
+ mutex_unlock(&data->lock);
+
+ if (ret < 0) {
+ dev_err(&client->dev, "failed to read word at 0x%02x\n", reg);
+ return ret;
+ }
+ *val = (uint16_t)ret;
+
+ return 0;
+}
+
+static int menf21bmc_write_byte_data(struct i2c_client *client, u8 reg, u8 val)
+{
+ int ret;
+ struct menf21bmc *data = i2c_get_clientdata(client);
+
+ mutex_lock(&data->lock);
+ ret = i2c_smbus_write_byte_data(client, reg, val);
+ mutex_unlock(&data->lock);
+
+ return ret;
+}
+
+static int menf21bmc_write_word_data(struct i2c_client *client, u8 reg, u16
val)
+{
+ int ret;
+ struct menf21bmc *data = i2c_get_clientdata(client);
+
+ mutex_lock(&data->lock);
+ ret = i2c_smbus_write_word_data(client, reg, val);
+ mutex_unlock(&data->lock);
+
+ return ret;
+}
+
+static int menf21bmc_write_byte(struct i2c_client *client, u8 val)
+{
+ int ret;
+ struct menf21bmc *data = i2c_get_clientdata(client);
+
+
[PATCH 0/3] Introduce MEN 14F021P00 Board Management Controller driver set
This patch set add support for the MEN 14F021P00 Board Management Controller called BMC. The BMC is a PIC Mikrocontroller which assembled on almost all of our 3U Compact PCI CPU boards and a few Box PCs. The main part of the BMC is to start and monitor the board, but there are a lot more features which can be accessed using an I2C Host interface. Features supported in this Patchset: - Watchdog - LEDs The Patchset includes a MFD Core driver, Watchdog and LEDs driver. Andreas Werner (3): drivers/mfd/menf21bmc: introduce MEN 14F021P00 BMC MFD Core driver drivers/watchdog/menf21bmc_wd: introduce MEN 14F021P00 BMC Watchdog driver drivers/leds/leds-menf21bmc: introduce MEN 14F021P00 BMC LED driver drivers/leds/Kconfig| 6 + drivers/leds/Makefile | 2 +- drivers/leds/leds-menf21bmc.c | 135 + drivers/mfd/Kconfig | 12 ++ drivers/mfd/Makefile| 1 + drivers/mfd/menf21bmc.c | 193 + drivers/watchdog/Kconfig| 7 ++ drivers/watchdog/Makefile | 1 + drivers/watchdog/menf21bmc_wd.c | 263 include/linux/mfd/menf21bmc.h | 32 + 10 files changed, 651 insertions(+), 1 deletion(-) create mode 100644 drivers/leds/leds-menf21bmc.c create mode 100644 drivers/mfd/menf21bmc.c create mode 100644 drivers/watchdog/menf21bmc_wd.c create mode 100644 include/linux/mfd/menf21bmc.h -- 1.9.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Question: hwmon: Adding addtitional sysfs entries
On Sat, May 10, 2014 at 08:32:40AM -0700, Guenter Roeck wrote: > On 05/10/2014 09:02 AM, Andreas Werner wrote: > >On Sat, May 10, 2014 at 05:32:13AM -0700, Guenter Roeck wrote: > >>On 05/10/2014 06:22 AM, Andreas Werner wrote: > >>>Hi, > >>>i am currently working on an implemenation of my Board Management > >>>Controller (BMC). > >>> > >>>This Controller is a MCR assembled on almost all of our Compact PCI or > >>>Compact PCI Serial > >>>Cards as well as on some other CPU Boards. > >>> > >>>The BMC includes LED´s, Watchdog, Voltage Monitoring and some other > >>>features. > >>>I have already implemented an MFD driver, LED and Watchdog driver. > >>> > >>>Currently i am working on the hwmon implemenation. This includes for the > >>>first step the > >>>voltage monitoring. > >>> > >>>The BMC has some other feature which are not supported by any of the > >>>subsystem. > >>> - Errorcounter (Board status) > >>> - Power Failure status > >>> - Operating ours > >> > >>Guess you mean hours here. > > > >Yes sorry my mistake. > > > >> > >>> - Do software reset, do cold reset > >>> - Set power modes > >>> - Backplate Geographical Address > >>> > >>>These are all informations related to the Board where the BMC is assembled > >>>to. > >>>I think all those features could be part of the hwmon implementation. > >>> > >>Why ? > > > >As all of the settings are CPU board related i thought it will be an good > >idea > >to put as much settings as possible to a group to one subsystem. > >This would be easier for the User Application. > > > Bad argument, even for the users. A user would not normally expect to find > the above information in unrelated subsystems such as hwmon. Keep in mind that > the Linux kernel is supposed to be useful for more than the application > developers > in your company, and think about it - assume you would have to implement an > application which runs on more than one hardware, and attributes like the > above > would be spread throughout the system. It would be all but impossible to write > generic applications, so you would want to avoid adding anything non-standard > as much as you can. And if you have to implement something non-standard, at > least > implement it where people at least have a chance to find it. > Ok, you are right :-) > >> > >>>Is it possible to add "custom" sysfs entries in my hwmon driver to support > >>>all these features? > >>>Does lm-sensor ingore those custom features or is it a problem for > >>>lm-sensors? > >>> > >>>What is the normal way to add those features? > >>> > >> > >>The hwmon subsystem isn't really the correct location for this > >>functionality. > >>Power management should be done with a regulator driver (possibly power). > >>The other attributes and functionality would better fit into the mfd core > >>driver. > >> > > > >MFD Core sounds good. That is also perfect for the User App. > > > >>You might want to tie the reset functions into the system reset > >>functionality. > > > >I do not understand this. Is there another subsystem or something like that > >were I can put the Reset stuff to? > > > Assuming you are talking about system reset, there is a function named > machine_restart() > to accomplish that. This is architecture and, in many cases, machine specific > functionality. > For example, many arm architectures have a different means to reset the > system, and there > is a separate function pointer named arm_pm_restart to tie into that > functionality. > > Many restart functions are implemented in the drivers/power/reset directory, > which may be > a good location for yours. > Just for explanation and to avoid missunderstanding. The reset functionality of the BMC is to send a I2C command from the Host to the BMC, and the BMC does the reset or power down. There is also a functionality where you can send a command the Controller and he will press the "power button" which cause an ACPI event to shutdown the PC if configured. Thanks for the /drivers/power informations there is really nice code in there where I can pick up some stuff to implement functions like that. > > > >I guess the hwmon subsys is the right place for the voltage monitoring > >(3,3V, 5V etc) isn´t it? > > > Yes, that is what it is for. Thanks, works fine. Nice integration in lm_sensors thats what I love in Linux :-) > > Guenter > Regards Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Question: hwmon: Adding addtitional sysfs entries
On Sat, May 10, 2014 at 05:32:13AM -0700, Guenter Roeck wrote: > On 05/10/2014 06:22 AM, Andreas Werner wrote: > >Hi, > >i am currently working on an implemenation of my Board Management Controller > >(BMC). > > > >This Controller is a MCR assembled on almost all of our Compact PCI or > >Compact PCI Serial > >Cards as well as on some other CPU Boards. > > > >The BMC includes LED´s, Watchdog, Voltage Monitoring and some other features. > >I have already implemented an MFD driver, LED and Watchdog driver. > > > >Currently i am working on the hwmon implemenation. This includes for the > >first step the > >voltage monitoring. > > > >The BMC has some other feature which are not supported by any of the > >subsystem. > > - Errorcounter (Board status) > > - Power Failure status > > - Operating ours > > Guess you mean hours here. Yes sorry my mistake. > > > - Do software reset, do cold reset > > - Set power modes > > - Backplate Geographical Address > > > >These are all informations related to the Board where the BMC is assembled > >to. > >I think all those features could be part of the hwmon implementation. > > > Why ? As all of the settings are CPU board related i thought it will be an good idea to put as much settings as possible to a group to one subsystem. This would be easier for the User Application. > > >Is it possible to add "custom" sysfs entries in my hwmon driver to support > >all these features? > >Does lm-sensor ingore those custom features or is it a problem for > >lm-sensors? > > > >What is the normal way to add those features? > > > > The hwmon subsystem isn't really the correct location for this functionality. > Power management should be done with a regulator driver (possibly power). > The other attributes and functionality would better fit into the mfd core > driver. > MFD Core sounds good. That is also perfect for the User App. > You might want to tie the reset functions into the system reset functionality. I do not understand this. Is there another subsystem or something like that were I can put the Reset stuff to? > > Guenter > I guess the hwmon subsys is the right place for the voltage monitoring (3,3V, 5V etc) isn´t it? Regards Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Question: hwmon: Adding addtitional sysfs entries
Hi, i am currently working on an implemenation of my Board Management Controller (BMC). This Controller is a MCR assembled on almost all of our Compact PCI or Compact PCI Serial Cards as well as on some other CPU Boards. The BMC includes LED´s, Watchdog, Voltage Monitoring and some other features. I have already implemented an MFD driver, LED and Watchdog driver. Currently i am working on the hwmon implemenation. This includes for the first step the voltage monitoring. The BMC has some other feature which are not supported by any of the subsystem. - Errorcounter (Board status) - Power Failure status - Operating ours - Do software reset, do cold reset - Set power modes - Backplate Geographical Address These are all informations related to the Board where the BMC is assembled to. I think all those features could be part of the hwmon implementation. Is it possible to add "custom" sysfs entries in my hwmon driver to support all these features? Does lm-sensor ingore those custom features or is it a problem for lm-sensors? What is the normal way to add those features? Regards Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [regression 3.15-rc3] Resume from s4 broken by 1f81b6d22a5980955b01e08cf27fb745dc9b686f
Hmmm... very odd. I unfortunately don't have a machine that can easily do S4 at hand, but I did test this on an IVB with XHCI_RESET_ON_RESUME in S3 (essentially the same code path), and I didn't run into any problems. How exactly does your machine fail on resume? Is it a kernel crash or just a hang? Can you try getting some debug output (by setting 'echo N > /sys/module/printk/parameters/console_suspend' and trying to catch the crash on the screen or a serial line, or maybe through pstore)? I really don't see much that could go wrong with this patch, so without more info it will be hard to understand your problem. Also, I noticed that you have two HID devices plugged in during suspend. Does it make a difference if you have different devices (e.g. a mass storage stick) or none at all? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
mcb: review mcb irq patch
Reviewed-by: Andreas Werner -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] usb: xhci: Correct last context entry calculation for Configure Endpoint
The current XHCI driver recalculates the Context Entries field in the
Slot Context on every add_endpoint() and drop_endpoint() call. In the
case of drop_endpoint(), it seems to assume that the add_flags will
always contain every endpoint for the new configuration, which is not
necessarily correct if you don't make assumptions about how the USB core
uses the add_endpoint/drop_endpoint interface (add_flags only contains
endpoints that are new additions in the new configuration).
Furthermore, EP0_FLAG is not consistently set in add_flags throughout
the lifetime of a device. This means that when all endpoints are
dropped, the Context Entries field can be set to 0 (which is invalid and
may cause a Parameter Error) or -1 (which is interpreted as 31 and
causes the driver to keep using the old, incorrect value).
The only surefire way to set this field right is to also take all
existing endpoints into account, and to force the value to 1 (meaning
only EP0 is active) if no other endpoint is found. This patch implements
that as a single step in the final check_bandwidth() call and removes
the intermediary calculations from add_endpoint() and drop_endpoint().
Signed-off-by: Julius Werner
---
drivers/usb/host/xhci.c | 51 +
1 file changed, 18 insertions(+), 33 deletions(-)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 924a6cc..fec6423 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -1562,12 +1562,10 @@ int xhci_drop_endpoint(struct usb_hcd *hcd, struct
usb_device *udev,
struct xhci_hcd *xhci;
struct xhci_container_ctx *in_ctx, *out_ctx;
struct xhci_input_control_ctx *ctrl_ctx;
- struct xhci_slot_ctx *slot_ctx;
- unsigned int last_ctx;
unsigned int ep_index;
struct xhci_ep_ctx *ep_ctx;
u32 drop_flag;
- u32 new_add_flags, new_drop_flags, new_slot_info;
+ u32 new_add_flags, new_drop_flags;
int ret;
ret = xhci_check_args(hcd, udev, ep, 1, true, __func__);
@@ -1614,24 +1612,13 @@ int xhci_drop_endpoint(struct usb_hcd *hcd, struct
usb_device *udev,
ctrl_ctx->add_flags &= cpu_to_le32(~drop_flag);
new_add_flags = le32_to_cpu(ctrl_ctx->add_flags);
- last_ctx = xhci_last_valid_endpoint(le32_to_cpu(ctrl_ctx->add_flags));
- slot_ctx = xhci_get_slot_ctx(xhci, in_ctx);
- /* Update the last valid endpoint context, if we deleted the last one */
- if ((le32_to_cpu(slot_ctx->dev_info) & LAST_CTX_MASK) >
- LAST_CTX(last_ctx)) {
- slot_ctx->dev_info &= cpu_to_le32(~LAST_CTX_MASK);
- slot_ctx->dev_info |= cpu_to_le32(LAST_CTX(last_ctx));
- }
- new_slot_info = le32_to_cpu(slot_ctx->dev_info);
-
xhci_endpoint_zero(xhci, xhci->devs[udev->slot_id], ep);
- xhci_dbg(xhci, "drop ep 0x%x, slot id %d, new drop flags = %#x, new add
flags = %#x, new slot info = %#x\n",
+ xhci_dbg(xhci, "drop ep 0x%x, slot id %d, new drop flags = %#x, new add
flags = %#x\n",
(unsigned int) ep->desc.bEndpointAddress,
udev->slot_id,
(unsigned int) new_drop_flags,
- (unsigned int) new_add_flags,
- (unsigned int) new_slot_info);
+ (unsigned int) new_add_flags);
return 0;
}
@@ -1654,11 +1641,9 @@ int xhci_add_endpoint(struct usb_hcd *hcd, struct
usb_device *udev,
struct xhci_hcd *xhci;
struct xhci_container_ctx *in_ctx, *out_ctx;
unsigned int ep_index;
- struct xhci_slot_ctx *slot_ctx;
struct xhci_input_control_ctx *ctrl_ctx;
u32 added_ctxs;
- unsigned int last_ctx;
- u32 new_add_flags, new_drop_flags, new_slot_info;
+ u32 new_add_flags, new_drop_flags;
struct xhci_virt_device *virt_dev;
int ret = 0;
@@ -1673,7 +1658,6 @@ int xhci_add_endpoint(struct usb_hcd *hcd, struct
usb_device *udev,
return -ENODEV;
added_ctxs = xhci_get_endpoint_flag(&ep->desc);
- last_ctx = xhci_last_valid_endpoint(added_ctxs);
if (added_ctxs == SLOT_FLAG || added_ctxs == EP0_FLAG) {
/* FIXME when we have to issue an evaluate endpoint command to
* deal with ep0 max packet size changing once we get the
@@ -1739,24 +1723,14 @@ int xhci_add_endpoint(struct usb_hcd *hcd, struct
usb_device *udev,
*/
new_drop_flags = le32_to_cpu(ctrl_ctx->drop_flags);
- slot_ctx = xhci_get_slot_ctx(xhci, in_ctx);
- /* Update the last valid endpoint context, if we just added one past */
- if ((le32_to_cpu(slot_ctx->dev_info) & LAST_CTX_MASK) <
- LAST_CTX(last_ctx)) {
- slot_ctx->dev_info &= cpu_to_le32(~LAST_CTX_MASK);
- slot_ctx->dev_in
Re: [PATCH] usb: xhci: Correct last context entry calculation for Configure Endpoint
Okay, thanks, sounds good. I personally don't care that much about the stable backport. Let me respin this with a fixed commit message and the type change Felipe suggested. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] usb: xhci: Correct last context entry calculation for Configure Endpoint
*bump* Sarah, Mathias, can we decide how to proceed with this? I think the section Alan quoted is a pretty good argument in favor of my interpretation (although of course this would not be the first time that two sections of a spec contradict each other). But more importantly, we have a case that just generates a clearly wrong Slot Context right now (the one that only drops endpoints), and I see no way how you could construct a correct Slot Context for that case with Sarah's interpretation. We need to resolve that somehow. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] usb: xhci: Prefer endpoint context dequeue pointer over stopped_trb
> You don't actually add the stable@ tag here, why not? > > You have read Documentation/stable_kernel_rules.txt for how stable > kernel trees work, so why not add the label here? Sorry... I actually didn't know about that file, I just added the "should be backported" line because I have seen that in other commits. I will adhere to those rules in the future. The patch is a little over the line limit (150+ lines with context, although most of it are scattered single-line changes). The issue it solves is that a USB device may silently stop working until it is disconnected, not sure if that's enough to qualify as "oh, that's not good". I'll let you decide whether it still should be queued up for stable backports or not. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] usb: xhci: Prefer endpoint context dequeue pointer over stopped_trb
+hdegoede
> I tried to apply this patch on top of 3.15-rc1, but it fails because of the
> streams support added to xhci_find_new_dequeue_state()
>
> After some manual editing the interesting parts of
> xhci_find_new_dequeue_state() looks like this:
>
> @@ -577,46 +568,57 @@ void xhci_find_new_dequeue_state(struct xhci_hcd
> *xhci,
> if (ep->ep_state & EP_HAS_STREAMS) {
> struct xhci_stream_ctx *ctx =
> &ep->stream_info->stream_ctx_array[stream_id];
> - state->new_cycle_state = 0x1 &
> le64_to_cpu(ctx->stream_ring);
> + hw_dequeue = le64_to_cpu(ctx->stream_ring);
> } else {
> struct xhci_ep_ctx *ep_ctx
>
> = xhci_get_ep_ctx(xhci, dev->out_ctx, ep_index);
> - state->new_cycle_state = 0x1 & le64_to_cpu(ep_ctx->deq);
> + hw_dequeue = le64_to_cpu(ep_ctx->deq);
> }
>
> + /* Find virtual address and segment of hardware dequeue pointer */
>
> + state->new_deq_seg = ep_ring->deq_seg;
> + state->new_deq_ptr = ep_ring->dequeue;
> + while (xhci_trb_virt_to_dma(state->new_deq_seg, state->new_deq_ptr)
> + != (dma_addr_t)(hw_dequeue & ~0x1)) {
> + next_trb(xhci, ep_ring, &state->new_deq_seg,
> + &state->new_deq_ptr);
> + if (state->new_deq_ptr == ep_ring->dequeue) {
> + WARN_ON(1);
> + return;
> + }
> + }
>
> Also the comparison of the dequeue pointers, using (hw_dequeue & ~0x1) might
> have some troubles with streams. Endpoint context TR dequeue pointer LO
> field has bits 3:1 reserved (probably zero) but stream context uses those
> bits. Would it make sense to use (hw_dequeue & ~0xf) here instead?
Ah, yes, looks like that patch wasn't in Linus' tree yet back when I
wrote this. I think your merge looks pretty good... just use
(hw_dequeue & ~0xf) instead of (hw_dequeue & ~0x1) to get the pointer
as you said, and this should work fine.
> But I'm still concerned about the dequeue pointer in the streams case.
> streams may be nested, we might be pointing at another stream context
> instead of the dequeue pointer.
>
> So there's still some work needed. Are you interested in re-working this to
> fit on top of 3.15-rc1 or should I add it to my todo list?
Hmmm... maybe the stream_id parameter is already pointing to the
correct secondary stream (if applicable) so you can rely on having a
normal dequeue pointer there? The xhci_triad_to_transfer_ring()
function seems to make the same assumption... At any rate, if there is
a problem here it would also be in the original c4bedb77e ("xhci: For
streams the css flag most be read from the stream-ctx on ep stop")
already, so I think you should follow up with that patch's author and
fix it in a separate commit if necessary.
I unfortunately don't have a device using streams to test with, so I
couldn't do more for this patch than you've already done. I think if
you change the hw_dequeue masking as you said that should guarantee
that the patch at least won't make things worse for streams, and that
should be good enough.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] usb: xhci: Prefer endpoint context dequeue pointer over stopped_trb
Hi Mathias, > The patch looks fine. Mathias is taking over for xHCI driver > maintainership in 3.15. He's currently handling queuing bug fix patches > for 3.14 while I finish queueing feature patches for 3.15. Mathias, > will you test and queue this up for 3.14? Did you pick this patch up anywhere yet or are there still issues with it? I just want to make sure it doesn't slip through the cracks. (Maybe I just didn't see it yet... are you still queueing patches in sarah/xhci.git or do you have your own repository somewhere?) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] usb: xhci: Correct last context entry calculation for Configure Endpoint
> http://marc.info/?l=linux-usb&m=137158978503741&w=2 > > There's an xHCI spec ambiguity: Does the last valid context entry refer > to the last valid endpoint context in the *input* device context or the > *output* device context? > > The code currently assumes it refers to the input device context, namely > the endpoints we're adding or changing. If hardware needs the last > valid endpoint context for the re-calculated *output* device context, > then yes, this needs to be changed. However, based on spec errata, I > believe that's not the intent of the spec authors: > > http://marc.info/?l=linux-kernel&m=137208958411696&w=2 Oh, okay, it didn't even occur to me to interpret it that way. It seems very odd since then Context Entries is essentially redundant with the information already provided by the Add Context flags. > What is the impact if we calculate the valid last valid endpoint context > for the input context? Do you have evidence of hardware misbehaving? > If so, which hardware? I haven't actually seen a problem from this, it just seemed like the right thing to do for me when looking at it. The only real error we had was when the command fails due to Context Entries being 0. However, the question remains: What is the right value for Context Entries when we have no Add Context flags, or only the SLOT_FLAG? It should be perfectly legal to just drop a bunch of endpoints without adding/changing anything else, such as when you switch a UVC interface back to alternate setting 0 (which has no endpoints). Then the Input Context really ends at the Slot Context (DCI = 0), but Context Entries = 0 is very clearly forbidden in the spec. I guess we could just force it to 1 there and it would probably work, but that would technically be incorrect since the EP0 context is not updated and not part of the Add Context flags. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] usb: xhci: Correct last context entry calculation for Configure Endpoint
The current XHCI driver recalculates the Context Entries field in the
Slot Context on every add_endpoint() and drop_endpoint() call. In the
case of drop_endpoint(), it seems to assume that the add_flags will
always contain every endpoint for the new configuration, which is not
necessarily correct if you don't make assumptions about how the USB core
uses the add_endpoint/drop_endpoint interface (add_flags only contains
endpoints that are new additions in the new configuration).
Furthermore, EP0_FLAG is not consistently set in add_flags throughout
the lifetime of a device. This means that when all endpoints are
dropped, the Context Entries field can be set to 0 (which is invalid and
may cause a Parameter Error) or -1 (which is interpreted as 31 and
causes the driver to keep using the old, incorrect value).
The only surefire way to set this field right is to also take all
existing endpoints into account, and to force the value to 1 (meaning
only EP0 is active) if no other endpoint is found. This patch implements
that as a single step in the final check_bandwidth() call and removes
the intermediary calculations from add_endpoint() and drop_endpoint().
This patch should be backported to kernels as old as 2.6.31 that contain
the commit f94e0186312b0fc39f41eed4e21836ed74b7efe1 "USB: xhci:
Bandwidth allocation support".
Signed-off-by: Julius Werner
---
drivers/usb/host/xhci.c | 51 +
1 file changed, 18 insertions(+), 33 deletions(-)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 924a6cc..e7d9dfa 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -1562,12 +1562,10 @@ int xhci_drop_endpoint(struct usb_hcd *hcd, struct
usb_device *udev,
struct xhci_hcd *xhci;
struct xhci_container_ctx *in_ctx, *out_ctx;
struct xhci_input_control_ctx *ctrl_ctx;
- struct xhci_slot_ctx *slot_ctx;
- unsigned int last_ctx;
unsigned int ep_index;
struct xhci_ep_ctx *ep_ctx;
u32 drop_flag;
- u32 new_add_flags, new_drop_flags, new_slot_info;
+ u32 new_add_flags, new_drop_flags;
int ret;
ret = xhci_check_args(hcd, udev, ep, 1, true, __func__);
@@ -1614,24 +1612,13 @@ int xhci_drop_endpoint(struct usb_hcd *hcd, struct
usb_device *udev,
ctrl_ctx->add_flags &= cpu_to_le32(~drop_flag);
new_add_flags = le32_to_cpu(ctrl_ctx->add_flags);
- last_ctx = xhci_last_valid_endpoint(le32_to_cpu(ctrl_ctx->add_flags));
- slot_ctx = xhci_get_slot_ctx(xhci, in_ctx);
- /* Update the last valid endpoint context, if we deleted the last one */
- if ((le32_to_cpu(slot_ctx->dev_info) & LAST_CTX_MASK) >
- LAST_CTX(last_ctx)) {
- slot_ctx->dev_info &= cpu_to_le32(~LAST_CTX_MASK);
- slot_ctx->dev_info |= cpu_to_le32(LAST_CTX(last_ctx));
- }
- new_slot_info = le32_to_cpu(slot_ctx->dev_info);
-
xhci_endpoint_zero(xhci, xhci->devs[udev->slot_id], ep);
- xhci_dbg(xhci, "drop ep 0x%x, slot id %d, new drop flags = %#x, new add
flags = %#x, new slot info = %#x\n",
+ xhci_dbg(xhci, "drop ep 0x%x, slot id %d, new drop flags = %#x, new add
flags = %#x\n",
(unsigned int) ep->desc.bEndpointAddress,
udev->slot_id,
(unsigned int) new_drop_flags,
- (unsigned int) new_add_flags,
- (unsigned int) new_slot_info);
+ (unsigned int) new_add_flags);
return 0;
}
@@ -1654,11 +1641,9 @@ int xhci_add_endpoint(struct usb_hcd *hcd, struct
usb_device *udev,
struct xhci_hcd *xhci;
struct xhci_container_ctx *in_ctx, *out_ctx;
unsigned int ep_index;
- struct xhci_slot_ctx *slot_ctx;
struct xhci_input_control_ctx *ctrl_ctx;
u32 added_ctxs;
- unsigned int last_ctx;
- u32 new_add_flags, new_drop_flags, new_slot_info;
+ u32 new_add_flags, new_drop_flags;
struct xhci_virt_device *virt_dev;
int ret = 0;
@@ -1673,7 +1658,6 @@ int xhci_add_endpoint(struct usb_hcd *hcd, struct
usb_device *udev,
return -ENODEV;
added_ctxs = xhci_get_endpoint_flag(&ep->desc);
- last_ctx = xhci_last_valid_endpoint(added_ctxs);
if (added_ctxs == SLOT_FLAG || added_ctxs == EP0_FLAG) {
/* FIXME when we have to issue an evaluate endpoint command to
* deal with ep0 max packet size changing once we get the
@@ -1739,24 +1723,14 @@ int xhci_add_endpoint(struct usb_hcd *hcd, struct
usb_device *udev,
*/
new_drop_flags = le32_to_cpu(ctrl_ctx->drop_flags);
- slot_ctx = xhci_get_slot_ctx(xhci, in_ctx);
- /* Update the last valid endpoint context, if we just added one past */
- if ((le32_to_cpu(slot_ctx->d
[PATCH v2 2/2] usb: Make DELAY_INIT quirk wait 100ms between Get Configuration requests
The DELAY_INIT quirk only reduces the frequency of enumeration failures
with the Logitech HD Pro C920 and C930e webcams, but does not quite
eliminate them. We have found that adding a delay of 100ms between the
first and second Get Configuration request makes the device enumerate
perfectly reliable even after several weeks of extensive testing. The
reasons for that are anyone's guess, but since the DELAY_INIT quirk
already delays enumeration by a whole second, wating for another 10th of
that isn't really a big deal for the one other device that uses it, and
it will resolve the problems with these webcams.
Signed-off-by: Julius Werner
---
drivers/usb/core/config.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/usb/core/config.c b/drivers/usb/core/config.c
index 8d72f0c..062967c 100644
--- a/drivers/usb/core/config.c
+++ b/drivers/usb/core/config.c
@@ -717,6 +717,10 @@ int usb_get_configuration(struct usb_device *dev)
result = -ENOMEM;
goto err;
}
+
+ if (dev->quirks & USB_QUIRK_DELAY_INIT)
+ msleep(100);
+
result = usb_get_descriptor(dev, USB_DT_CONFIG, cfgno,
bigbuffer, length);
if (result < 0) {
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] usb: Make DELAY_INIT quirk wait 100ms between Get Configuration requests
> What am I supposed to do with this line? :) > Oh damn, sorry, forgot to take that out on the second one. We have this really annoying commit hook that adds them automatically. v2 incoming... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] usb: Add device quirk for Logitech HD Pro Webcams C920 and C930e
We've encountered a rare issue when enumerating two Logitech webcams
after a reboot that doesn't power cycle the USB ports. They are spewing
random data (possibly some leftover UVC buffers) on the second
(full-sized) Get Configuration request of the enumeration phase. Since
the data is random this can potentially cause all kinds of odd behavior,
and since it occasionally happens multiple times (after the kernel
issues another reset due to the garbled configuration descriptor), it is
not always recoverable. Set the USB_DELAY_INIT quirk that seems to work
around the issue.
Signed-off-by: Julius Werner
---
drivers/usb/core/quirks.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/usb/core/quirks.c b/drivers/usb/core/quirks.c
index 8f37063..739ee8e 100644
--- a/drivers/usb/core/quirks.c
+++ b/drivers/usb/core/quirks.c
@@ -47,6 +47,10 @@ static const struct usb_device_id usb_quirk_list[] = {
/* Microsoft LifeCam-VX700 v2.0 */
{ USB_DEVICE(0x045e, 0x0770), .driver_info = USB_QUIRK_RESET_RESUME },
+ /* Logitech HD Pro Webcams C920 and C930e */
+ { USB_DEVICE(0x046d, 0x082d), .driver_info = USB_QUIRK_DELAY_INIT },
+ { USB_DEVICE(0x046d, 0x0843), .driver_info = USB_QUIRK_DELAY_INIT },
+
/* Logitech Quickcam Fusion */
{ USB_DEVICE(0x046d, 0x08c1), .driver_info = USB_QUIRK_RESET_RESUME },
--
1.8.3.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 2/2] usb: Make DELAY_INIT quirk wait 100ms between Get Configuration requests
The DELAY_INIT quirk only reduces the frequency of enumeration failures
with the Logitech HD Pro C920 and C930e webcams, but does not quite
eliminate them. We have found that adding a delay of 100ms between the
first and second Get Configuration request makes the device enumerate
perfectly reliable even after several weeks of extensive testing. The
reasons for that are anyone's guess, but since the DELAY_INIT quirk
already delays enumeration by a whole second, wating for another 10th of
that isn't really a big deal for the one other device that uses it, and
it will resolve the problems with these webcams.
Change-Id: Ibf738426307fe8ef362768db2decc9bc2b30a930
Signed-off-by: Julius Werner
---
drivers/usb/core/config.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/usb/core/config.c b/drivers/usb/core/config.c
index 8d72f0c..062967c 100644
--- a/drivers/usb/core/config.c
+++ b/drivers/usb/core/config.c
@@ -717,6 +717,10 @@ int usb_get_configuration(struct usb_device *dev)
result = -ENOMEM;
goto err;
}
+
+ if (dev->quirks & USB_QUIRK_DELAY_INIT)
+ msleep(100);
+
result = usb_get_descriptor(dev, USB_DT_CONFIG, cfgno,
bigbuffer, length);
if (result < 0) {
--
1.8.3.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] usb: xhci: Prefer endpoint context dequeue pointer over stopped_trb
We have observed a rare cycle state desync bug after Set TR Dequeue
Pointer commands on Intel LynxPoint xHCs (resulting in an endpoint that
doesn't fetch new TRBs and thus an unresponsive USB device). It always
triggers when a previous Set TR Dequeue Pointer command has set the
pointer to the final Link TRB of a segment, and then another URB gets
enqueued and cancelled again before it can be completed. Further
investigation showed that the xHC had returned the Link TRB in the TRB
Pointer field of the Transfer Event (CC == Stopped -- Length Invalid),
but when xhci_find_new_dequeue_state() later accesses the Endpoint
Context's TR Dequeue Pointer field it is set to the first TRB of the
next segment.
The driver expects those two values to be the same in this situation,
and uses the cycle state of the latter together with the address of the
former. This should be fine according to the XHCI specification, since
the endpoint ring should be stopped when returning the Transfer Event
and thus should not advance over the Link TRB before it gets restarted.
However, real-world XHCI implementations apparently don't really care
that much about these details, so the driver should follow a more
defensive approach to try to work around HC spec violations.
This patch removes the stopped_trb variable that had been used to store
the TRB Pointer from the last Transfer Event of a stopped TRB. Instead,
xhci_find_new_dequeue_state() now relies only on the Endpoint Context,
requiring a small amount of additional processing to find the virtual
address corresponding to the TR Dequeue Pointer. Some other parts of the
function were slightly rearranged to better fit into this model.
This patch should be backported to kernels as old as 2.6.31 that contain
the commit ae636747146ea97efa18e04576acd3416e2514f5 "USB: xhci: URB
cancellation support."
Signed-off-by: Julius Werner
---
drivers/usb/host/xhci-ring.c | 66
drivers/usb/host/xhci.c | 1 -
drivers/usb/host/xhci.h | 2 --
3 files changed, 30 insertions(+), 39 deletions(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index a0b248c..b8277c7 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -549,6 +549,7 @@ void xhci_find_new_dequeue_state(struct xhci_hcd *xhci,
struct xhci_generic_trb *trb;
struct xhci_ep_ctx *ep_ctx;
dma_addr_t addr;
+ u64 hw_dequeue;
ep_ring = xhci_triad_to_transfer_ring(xhci, slot_id,
ep_index, stream_id);
@@ -558,56 +559,56 @@ void xhci_find_new_dequeue_state(struct xhci_hcd *xhci,
stream_id);
return;
}
- state->new_cycle_state = 0;
- xhci_dbg_trace(xhci, trace_xhci_dbg_cancel_urb,
- "Finding segment containing stopped TRB.");
- state->new_deq_seg = find_trb_seg(cur_td->start_seg,
- dev->eps[ep_index].stopped_trb,
- &state->new_cycle_state);
- if (!state->new_deq_seg) {
- WARN_ON(1);
- return;
- }
/* Dig out the cycle state saved by the xHC during the stop ep cmd */
xhci_dbg_trace(xhci, trace_xhci_dbg_cancel_urb,
"Finding endpoint context");
ep_ctx = xhci_get_ep_ctx(xhci, dev->out_ctx, ep_index);
- state->new_cycle_state = 0x1 & le64_to_cpu(ep_ctx->deq);
+ hw_dequeue = le64_to_cpu(ep_ctx->deq);
+
+ /* Find virtual address and segment of hardware dequeue pointer */
+ state->new_deq_seg = ep_ring->deq_seg;
+ state->new_deq_ptr = ep_ring->dequeue;
+ while (xhci_trb_virt_to_dma(state->new_deq_seg, state->new_deq_ptr)
+ != (dma_addr_t)(hw_dequeue & ~0x1)) {
+ next_trb(xhci, ep_ring, &state->new_deq_seg,
+ &state->new_deq_ptr);
+ if (state->new_deq_ptr == ep_ring->dequeue) {
+ WARN_ON(1);
+ return;
+ }
+ }
+ /*
+* Find cycle state for last_trb, starting at old cycle state of
+* hw_dequeue. If there is only one segment ring, find_trb_seg() will
+* return immediately and cannot toggle the cycle state if this search
+* wraps around, so add one more toggle manually in that case.
+*/
+ state->new_cycle_state = hw_dequeue & 0x1;
+ if (ep_ring->first_seg == ep_ring->first_seg->next &&
+ cur_td->last_trb < state->new_deq_ptr)
+ state->new_cycle_state ^= 0x1;
state->new_deq_ptr = cur_td->last_trb;
xhci_dbg_trace(xhci, trace_xhci_dbg_cancel_urb,
"Finding segment containing
[PATCH] rtc: Add SMBus-only adapters support to rtc-rx8581
This patch adds support for SMBus-only adapters (e.g. i2c-piix4).
The driver has implementet only support for I2C adapter
which implements the I2C_FUNC_SMBUS_I2C_BLOCK functionality before.
With this patch it is possible to load and use the RTC driver with
I2C and SMBUS adapters like the rtc-ds1307 does.
Tested on AMD G Series Platform (i2c-piix4 adapter driver).
Signed-off-by: Andreas Werner
---
drivers/rtc/rtc-rx8581.c | 81
1 file changed, 68 insertions(+), 13 deletions(-)
diff --git a/drivers/rtc/rtc-rx8581.c b/drivers/rtc/rtc-rx8581.c
index 00b0eb7..de8d9c4 100644
--- a/drivers/rtc/rtc-rx8581.c
+++ b/drivers/rtc/rtc-rx8581.c
@@ -52,8 +52,45 @@
#define RX8581_CTRL_STOP 0x02 /* STOP bit */
#define RX8581_CTRL_RESET 0x01 /* RESET bit */
+struct rx8581 {
+ struct i2c_client *client;
+ struct rtc_device *rtc;
+ s32 (*read_block_data)(const struct i2c_client *client, u8 command,
+ u8 length, u8 *values);
+ s32 (*write_block_data)(const struct i2c_client *client, u8 command,
+ u8 length, const u8 *values);
+};
+
static struct i2c_driver rx8581_driver;
+static int rx8581_read_block_data(const struct i2c_client *client, u8 command,
+ u8 length, u8 *values)
+{
+ s32 i, data;
+
+ for (i = 0; i < length; i++) {
+ data = i2c_smbus_read_byte_data(client, command + i);
+ if (data < 0)
+ return data;
+ values[i] = data;
+ }
+ return i;
+}
+
+static int rx8581_write_block_data(const struct i2c_client *client, u8 command,
+ u8 length, const u8 *values)
+{
+ s32 i, ret;
+
+ for (i = 0; i < length; i++) {
+ ret = i2c_smbus_write_byte_data(client, command + i,
+ values[i]);
+ if (ret < 0)
+ return ret;
+ }
+ return length;
+}
+
/*
* In the routines that deal directly with the rx8581 hardware, we use
* rtc_time -- month 0-11, hour 0-23, yr = calendar year-epoch.
@@ -62,6 +99,7 @@ static int rx8581_get_datetime(struct i2c_client *client,
struct rtc_time *tm)
{
unsigned char date[7];
int data, err;
+ struct rx8581 *rx8581 = i2c_get_clientdata(client);
/* First we ensure that the "update flag" is not set, we read the
* time and date then re-read the "update flag". If the update flag
@@ -80,14 +118,13 @@ static int rx8581_get_datetime(struct i2c_client *client,
struct rtc_time *tm)
err = i2c_smbus_write_byte_data(client,
RX8581_REG_FLAG, (data & ~RX8581_FLAG_UF));
if (err != 0) {
- dev_err(&client->dev, "Unable to write device "
- "flags\n");
+ dev_err(&client->dev, "Unable to write device
flags\n");
return -EIO;
}
}
/* Now read time and date */
- err = i2c_smbus_read_i2c_block_data(client, RX8581_REG_SC,
+ err = rx8581->read_block_data(client, RX8581_REG_SC,
7, date);
if (err < 0) {
dev_err(&client->dev, "Unable to read date\n");
@@ -140,6 +177,7 @@ static int rx8581_set_datetime(struct i2c_client *client,
struct rtc_time *tm)
{
int data, err;
unsigned char buf[7];
+ struct rx8581 *rx8581 = i2c_get_clientdata(client);
dev_dbg(&client->dev, "%s: secs=%d, mins=%d, hours=%d, "
"mday=%d, mon=%d, year=%d, wday=%d\n",
@@ -176,7 +214,7 @@ static int rx8581_set_datetime(struct i2c_client *client,
struct rtc_time *tm)
}
/* write register's data */
- err = i2c_smbus_write_i2c_block_data(client, RX8581_REG_SC, 7, buf);
+ err = rx8581->write_block_data(client, RX8581_REG_SC, 7, buf);
if (err < 0) {
dev_err(&client->dev, "Unable to write to date registers\n");
return -EIO;
@@ -231,22 +269,39 @@ static const struct rtc_class_ops rx8581_rtc_ops = {
static int rx8581_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
- struct rtc_device *rtc;
+ struct rx8581 *rx8581;
dev_dbg(&client->dev, "%s\n", __func__);
- if (!i2c_check_functionality(client->adapter, I2C_FUNC_I2C))
- return -ENODEV;
+ if (!i2c_check_functionality(client->adapter, I2C_FUNC_SMBUS_BYTE_DATA)
+ && !i2c_c
Re: [PATCH] USB: core: Add warm reset while reset-resuming SuperSpeed HUBs
>> ...although, the spec says that it does not wait for the port resets >> to complete. As far as I can see re-issuing a warm reset and waiting >> is the only way to guarantee the core times the recovery. Presumably >> the portstatus debounce in hub_activate() mitigates this, but that >> 100ms is less than a full reset timeout. It's definitely not just a timing issue for us. I can't reproduce all the same cases as Vikas, but when I attach a USB analyzer to the ones I do see the host controller doesn't even start sending a reset. >>> The xHCI spec requires that when the xHCI host is reset, a USB reset is >>> driven down the USB 3.0 ports. If hot reset fails, the port may migrate >>> to warm reset. See table 32 in the xHCI spec, in the definition of >>> HCRST. It sounds like this host doesn't drive a USB reset down USB 3.0 >>> ports at all on host controller reset? Oh, interesting, I hadn't seen that yet. So I guess the spec itself is fine if it were followed to the letter. I did some more tests about this on my Exynos machine: when I put a device to autosuspend (U3) and manually poke the xHC reset bit, I do see an automatic warm reset on the analyzer and the ports manage to retrain to U0. But after a system suspend/resume which calls xhci_reset() in the process, there is no reset on the wire. I also noticed that it doesn't drive a reset (even after manual poking) when there is no device connected on the other end of the analyzer. So this might be our problem: maybe these host controllers (Synopsys DesignWare) issue the spec-mandated warm reset only on ports where they think there is a device attached. But after a system suspend/resume (where the whole IP block on the SoC was powered down), the host controller cannot know that there is still a device with an active power session attached, and therefore doesn't drive the reset on its own. Even though this is a host controller bug, we still have to deal with it somehow. I guess we could move the code into xhci_plat_resume() and hide it behind a quirk to lessen the impact. But since reset_resume is not a common case for most host controllers, it's hard to say if this is DesignWare specific or a more widespread implementation mistake. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] usb: core: Make sure usb_set_configuration(-1) cannot fail
> Sorry for not getting back to this sooner. Ironically, it looks like > this change isn't needed any more, thanks to Thomas Pugliese's patch: > > http://marc.info/?l=linux-usb&m=13866180520&w=2 Yes... thanks for pointing it out, that would make this patch obsolete. I'll wait a few days with this to see if that patch gets accepted as it is. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] USB: core: Add warm reset while reset-resuming SuperSpeed HUBs
> I don't know what you mean by "fails". The system goes to sleep and > then later on wakes up, doesn't it? > > Do you mean that the Jetflash device gets disconnected when the system > wakes up? That's _supposed_ to happen under those circumstances. > When hub_activate() sees HUB_RESET_RESUME, all child devices get > disconnected except those where udev->persist_enabled is set. This patch was written in response to the same bug as my "usb: hub: Use correct reset for wedged USB3 devices that are NOTATTACHED" submission. My patch only helps when the port gets stuck in Compliance Mode, but Vikas reports that he can sometimes see it stuck in Polling or Recovery states as well. The underlying issue is a deadlock in the USB 3.0 link training state machine when the host controller is unilaterally reset on resume (without driving a reset on the bus). The host port starts out back in Rx.Detect without remembering anything about its previous state, but the device is still in U3. The host detects Rx terminations, moves to Polling and starts sending LFPS link training packets, but the device doesn't expect those and interprets them as link problems (moving to Recovery). What happens next seems to be device specific, but apparently the device can end up in SS.Inactive while the host port gets stuck in Polling or Recovery (or some kind of livelock between those). This patch tries to warm reset all USB 3.0 ports on reset-resume (after xhci_reset() was called) that had devices connected to them before suspend. This seems to be the only way to ensure the devices' state machines get back to a well-defined state that the host can work with. I don't think this is a specific hardware bug, it's just an unfortunate design flaw that the USB 3.0 spec doesn't account for a root hub port being reset independently of its connected device. I think Sarah is correct that it could be limited to root hubs, though. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC 2/4] xhci: Add quirk for DWC3-Exynos controller
On Tue, Dec 10, 2013 at 2:55 AM, Vivek Gautam wrote:
> The DWC3-exynos eXtensible host controller on Exynos5420 SoC
> is quirky in a way that the PHY needs to be tuned to get it
> working at SuperSpeed.
> By default this PHY works as High-speed phy and therefore
> detects even Super-speed devices as high-speed ones.
> So, the PHY needs to be tuned after controller has been reset.
>
> Adding a xHCI quirk for this purpose.
>
> Signed-off-by: Vivek Gautam
> ---
> drivers/usb/host/xhci-plat.c | 19 +++
> drivers/usb/host/xhci.h |1 +
> 2 files changed, 20 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
> index d9c169f..395c9e9 100644
> --- a/drivers/usb/host/xhci-plat.c
> +++ b/drivers/usb/host/xhci-plat.c
> @@ -21,6 +21,25 @@
>
> static void xhci_plat_quirks(struct device *dev, struct xhci_hcd *xhci)
> {
> + struct device *parent_dev;
> + struct device *vendor_parent_dev;
> +
> + parent_dev = dev->parent;
> + vendor_parent_dev = parent_dev->parent;
Is this guaranteed to exist for all current and future xhci-plat
controllers or should you maybe check one or both for NULL?
> +
> + /*
> +* The DWC3-exynos host controller on Exynos5420 SoC is quirky
> +* in a way that the PHY needs to be tuned to get it working
> +* at SuperSpeed. By default this PHY works as High-speed phy
> +* and so detects even Super-speed devices as high-speed ones.
> +* Therefor the PHY needs to be tuned after controller
> +* has been reset, since a controller reset actually forces the
> +* PHY to fall back to its default state wherein it works as
> +* High-Speed PHY only.
> +*/
> + if (!strstr(dev_name(vendor_parent_dev), "exynos"))
> + xhci->quirks |= XHCI_DWC3_EXYNOS;
> +
> /*
> * As of now platform drivers don't provide MSI support so we ensure
> * here that the generic code does not try to make a pci_dev from our
> diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
> index 7807f62..f69af8c 100644
> --- a/drivers/usb/host/xhci.h
> +++ b/drivers/usb/host/xhci.h
> @@ -1560,6 +1560,7 @@ struct xhci_hcd {
> #define XHCI_PLAT (1 << 16)
> #define XHCI_SLOW_SUSPEND (1 << 17)
> #define XHCI_SPURIOUS_WAKEUP (1 << 18)
> +#define XHCI_DWC3_EXYNOS (1 << 19)
I think in general it's better to name quirks after what they do
rather than a specific device, that way you might be able to reuse
them. How about XHCI_TUNE_AFTER_RESET? (Or you could leave out the
quirk completely and just differentiate by whether the PHY implements
the tune() method or not.)
> unsigned intnum_active_eps;
> unsigned intlimit_active_eps;
> /* There are two roothubs to keep track of bus suspend info for */
> --
> 1.7.6.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 v2] usb: core: Make sure usb_set_configuration(-1) cannot fail
usb_deauthorize_device() tries to unset the configuration of a USB
device and then unconditionally blows away the configuration descriptors
with usb_destroy_configuration(). This is bad if the
usb_set_configuration() call failed before the configuration could be
correctly unset, since pointers like udev->actconfig can keep pointing
to the now invalid memory. We have encountered hard to reproduce crashes
from devices disconnected during suspend due to this, where khubd's
disconnect handling races with userspace tools that change authorization
on resume.
It seems desirable that a USB device can always be marked as
unconfigured (reclaiming its bandwidth) in the kernel, regardless of
communication problems. This patch changes usb_set_configuration() to
ignore all failures in the case where no new configuration is being set.
Signed-off-by: Julius Werner
---
drivers/usb/core/message.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/core/message.c b/drivers/usb/core/message.c
index bb31597..f980b6d 100644
--- a/drivers/usb/core/message.c
+++ b/drivers/usb/core/message.c
@@ -1706,7 +1706,8 @@ static void __usb_queue_reset_device(struct work_struct
*ws)
* underlying call that failed. On successful completion, each interface
* in the original device configuration has been destroyed, and each one
* in the new configuration has been probed by all relevant usb device
- * drivers currently known to the kernel.
+ * drivers currently known to the kernel. Guaranteed not to fail if the
+ * device is to be unconfigured (@configuration = -1).
*/
int usb_set_configuration(struct usb_device *dev, int configuration)
{
@@ -1774,7 +1775,7 @@ free_interfaces:
/* Wake up the device so we can send it the Set-Config request */
ret = usb_autoresume_device(dev);
- if (ret)
+ if (ret && cp)
goto free_interfaces;
/* if it's already configured, clear out old state first.
@@ -1797,7 +1798,7 @@ free_interfaces:
* installed, so that the xHCI driver can recalculate the U1/U2
* timeouts.
*/
- if (dev->actconfig && usb_disable_lpm(dev)) {
+ if (dev->actconfig && usb_disable_lpm(dev) && cp) {
dev_err(&dev->dev, "%s Failed to disable LPM\n.", __func__);
mutex_unlock(hcd->bandwidth_mutex);
ret = -ENOMEM;
--
1.7.12.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] usb: core: Abort deauthorization if unsetting configuration fails
> Instead, how about changing usb_set_configuration() so that it will > never fail when the new config is -1? Except perhaps for -ENODEV > errors (the device has been disconnected), which > usb_deauthorize_device() could check for. Yes, that should work as well. It's really just one autoresume and one disable_lpm that can fail in that case so it shouldn't be too intrusive. I would prefer not to special-case ENODEV though, no need to add more complexity than necessary. I will write up a new version for that tomorrow. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] usb: core: Abort deauthorization if unsetting configuration fails
usb_deauthorize_device() tries to unset the configuration of a USB
device and then unconditionally blows away the configuration descriptors
with usb_destroy_configuration(). This is bad if the
usb_set_configuration() call failed before the configuration could be
correctly unset, since pointers like udev->actconfig can keep pointing
to the now invalid memory. We have encountered hard to reproduce crashes
from devices disconnected during suspend due to this, where khubd's
disconnect handling races with userspace tools that change authorization
on resume.
This patch ensures that usb_deauthorize_device() aborts when
usb_set_configuration() fails, and the underlying status code (such as
ENODEV) is returned to userspace.
Signed-off-by: Julius Werner
---
drivers/usb/core/hub.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index a7c04e2..ade315f 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -2420,13 +2420,17 @@ fail:
*/
int usb_deauthorize_device(struct usb_device *usb_dev)
{
+ int result = 0;
+
usb_lock_device(usb_dev);
if (usb_dev->authorized == 0)
goto out_unauthorized;
- usb_dev->authorized = 0;
- usb_set_configuration(usb_dev, -1);
+ result = usb_set_configuration(usb_dev, -1);
+ if (result)
+ goto error_deconfigure;
+ usb_dev->authorized = 0;
kfree(usb_dev->product);
usb_dev->product = kstrdup("n/a (unauthorized)", GFP_KERNEL);
kfree(usb_dev->manufacturer);
@@ -2437,9 +2441,10 @@ int usb_deauthorize_device(struct usb_device *usb_dev)
usb_destroy_configuration(usb_dev);
usb_dev->descriptor.bNumConfigurations = 0;
+error_deconfigure:
out_unauthorized:
usb_unlock_device(usb_dev);
- return 0;
+ return result;
}
--
1.7.12.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] usb: xhci-plat: Enable USB 2.0 hardware LPM support for platform xHCs
*ping* Is anyone still reading this or should I resubmit? Sorry for being annoying, just please let me know if this is already considered to get picked up at the next opportunity or if you've intentionally decided against it for now. I want to make sure it didn't fall through the cracks somewhere. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] usb: hub: Use correct reset for wedged USB3 devices that are NOTATTACHED
I'm not sure if it's worth it further looking into this for the SUSPENDED state (Sarah's post sounds like that shouldn't happen)... but at any rate, that would be orthogonal to my patch, right? I'm really only interested in the NOTATTACHED case, which solves a real issue on my system. Do you still have questions about that before you'd consider picking it up, Greg? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3] I2C: busses: i2c-eg20t Do not print error message in syslog if no ACK received
Using the i2c-eg20t driver and call i2cdetect or probe on the bus,
the driver will print a lot of error messages if there was no ACK
received.
i2cdetect normally print a table with all the available devices. If there
is no device on the address, the table will be empty.
Currently with the i2c-eg20t driver, the table is not visible because
the error messages destroy the table.
Error message: pch_i2c_getack return -71
This patch prevent the driver to print the messages to syslog.
The pch_i2c_wait_for_check_xfer function is the only one who is
calling pch_i2c_getack, so we can delete the function and add the
read to pch_i2c_wait_for_check_xfer.
If no ACK is received, the Message will be printed as a dbg
message.
Fixed print message to be a one liner so we can grep for the
error message.
Tested on Intel Atom E6xx and Eg20t Chipset.
Signed-off-by: Andreas Werner
---
Revision 2:
- delete the pch_err completly instead of changing to pch_dbg
because there is already a pch_dbg at the function who calls
pch_i2c_getack.
- Fixed message line issue
Revision 3:
- delete the pch_i2c_getack function and add the ACK read to
pch_i2c_wait_for_check_xfer.
drivers/i2c/busses/i2c-eg20t.c | 26 --
1 file changed, 4 insertions(+), 22 deletions(-)
diff --git a/drivers/i2c/busses/i2c-eg20t.c b/drivers/i2c/busses/i2c-eg20t.c
index 0f37529..ff15ae9 100644
--- a/drivers/i2c/busses/i2c-eg20t.c
+++ b/drivers/i2c/busses/i2c-eg20t.c
@@ -312,24 +312,6 @@ static void pch_i2c_start(struct i2c_algo_pch_data *adap)
}
/**
- * pch_i2c_getack() - to confirm ACK/NACK
- * @adap: Pointer to struct i2c_algo_pch_data.
- */
-static s32 pch_i2c_getack(struct i2c_algo_pch_data *adap)
-{
- u32 reg_val;
- void __iomem *p = adap->pch_base_address;
- reg_val = ioread32(p + PCH_I2CSR) & PCH_GETACK;
-
- if (reg_val != 0) {
- pch_err(adap, "return%d\n", -EPROTO);
- return -EPROTO;
- }
-
- return 0;
-}
-
-/**
* pch_i2c_stop() - generate stop condition in normal mode.
* @adap: Pointer to struct i2c_algo_pch_data.
*/
@@ -344,6 +326,7 @@ static void pch_i2c_stop(struct i2c_algo_pch_data *adap)
static int pch_i2c_wait_for_check_xfer(struct i2c_algo_pch_data *adap)
{
long ret;
+ void __iomem *p = adap->pch_base_address;
ret = wait_event_timeout(pch_event,
(adap->pch_event_flag != 0), msecs_to_jiffies(1000));
@@ -366,10 +349,9 @@ static int pch_i2c_wait_for_check_xfer(struct
i2c_algo_pch_data *adap)
adap->pch_event_flag = 0;
- if (pch_i2c_getack(adap)) {
- pch_dbg(adap, "Receive NACK for slave address"
- "setting\n");
- return -EIO;
+ if (ioread32(p + PCH_I2CSR) & PCH_GETACK) {
+ pch_dbg(adap, "Receive NACK for slave address setting\n");
+ return -ENXIO;
}
return 0;
--
1.8.4.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] I2C: busses: i2c-eg20t Do not print error message in syslog if no ACK received
On Sun, Nov 17, 2013 at 06:08:38PM +0100, Wolfram Sang wrote:
> On Sun, Nov 17, 2013 at 05:53:29PM +0100, Andreas Werner wrote:
> > On Sun, Nov 17, 2013 at 01:18:09PM +0100, Wolfram Sang wrote:
> > >
> > > > Is there another reason why pch_i2c_getack returned EPROTO?
> > > > May be ENXIO was introduced later?
> > >
> > > Imperfect review :)
> > >
> > > > I think we can just replace the -EIO with -ENXIO or do you want to pick
> > > > up the return
> > > > vale of pch_i2c_getack and return that ?
> > >
> > > The latter. As a rule of thumb, it is usually more sustainable to pass
> > > through error codes. Overloading them should only be done when really
> > > necessary IMO.
> > >
> > Ok, if that will be ok in pch_i2c_wait_for_check_xfer i will resend
> > the patch.
> >
> > ret = pch_i2c_getack(adap);
> >
> > if (ret)
> > pch_dbg(adap, "Receive NACK for slave address setting\n");
> >
> > return (int)ret;
>
> Hmm, the cast looks ugly. Looking at the driver more closely, my
> preferred solution would be to elimiate the getack function and just do
> that directly in wait_for_check_xfer:
>
> if (ioread32(adap->pch_base_address + PCH_I2CSR) & PCH_GETACK) {
> pch_dbg ...
> return -ENXIO;
> }
>
> Something like that...
>
Sometimes its really usfull to look closely :-)
I agree you, because the function is just called one time, so
we can really delete this function.
regards
Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] I2C: busses: i2c-eg20t Do not print error message in syslog if no ACK received
On Sun, Nov 17, 2013 at 01:18:09PM +0100, Wolfram Sang wrote: > > > Is there another reason why pch_i2c_getack returned EPROTO? > > May be ENXIO was introduced later? > > Imperfect review :) > > > I think we can just replace the -EIO with -ENXIO or do you want to pick up > > the return > > vale of pch_i2c_getack and return that ? > > The latter. As a rule of thumb, it is usually more sustainable to pass > through error codes. Overloading them should only be done when really > necessary IMO. > Ok, if that will be ok in pch_i2c_wait_for_check_xfer i will resend the patch. ret = pch_i2c_getack(adap); if (ret) pch_dbg(adap, "Receive NACK for slave address setting\n"); return (int)ret; Regards Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] I2C: busses: i2c-eg20t Do not print error message in syslog if no ACK received
On Sun, Nov 17, 2013 at 12:08:46PM +0100, Wolfram Sang wrote:
> On Sun, Nov 17, 2013 at 09:58:51AM +0100, Andreas Werner wrote:
> > Revision 2:
> > - delete the pch_err completly instead of changing to pch_dbg
> > because there is already a pch_dbg at the function who calls
> > pch_i2c_getack.
> > - Fixed message line issue
>
> I prefer this below "---" after Signed-off.
Ok i will change it next time.
>
> >
> > diff --git a/drivers/i2c/busses/i2c-eg20t.c b/drivers/i2c/busses/i2c-eg20t.c
> > index 0f37529..5c39f90 100644
> > --- a/drivers/i2c/busses/i2c-eg20t.c
> > +++ b/drivers/i2c/busses/i2c-eg20t.c
> > @@ -321,10 +321,8 @@ static s32 pch_i2c_getack(struct i2c_algo_pch_data
> > *adap)
> > void __iomem *p = adap->pch_base_address;
> > reg_val = ioread32(p + PCH_I2CSR) & PCH_GETACK;
> >
> > - if (reg_val != 0) {
> > - pch_err(adap, "return%d\n", -EPROTO);
> > + if (reg_val != 0)
> > return -EPROTO;
>
> That could be fixed to -ENXIO according to
> Documentation/i2c/fault-codes.
Yes you are right -ENXIO should returned if no ACK was received.
Is there another reason why pch_i2c_getack returned EPROTO?
May be ENXIO was introduced later?
>
> > @@ -367,8 +365,7 @@ static int pch_i2c_wait_for_check_xfer(struct
> > i2c_algo_pch_data *adap)
> > adap->pch_event_flag = 0;
> >
> > if (pch_i2c_getack(adap)) {
> > - pch_dbg(adap, "Receive NACK for slave address"
> > - "setting\n");
> > + pch_dbg(adap, "Receive NACK for slave address setting\n");
> > return -EIO;
>
> What about returning the value we got from pch_i2c_getack?
>
EIO is almost ok, because EIO means something went wrong when performing
an I/O operation, but yes we can return the value from pch_i2c_getack (ENXIO)
to get more detailed informations whats going wrong exactly (no ACK reveiced).
I think we can just replace the -EIO with -ENXIO or do you want to pick up the
return
vale of pch_i2c_getack and return that ?
Regards
Andy
> Regards,
>
>Wolfram
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Black screen with GMA500 driver on Atom E680 (invalid VBT signature)
On Thu, Nov 14, 2013 at 08:57:58PM +, One Thousand Gnomes wrote: > > but if you checkout the PCI table in the driver, there is the device > > and vendor ID mentioned, that means for me that the driver supports > > the Graphic core in E680. > > And after loading the driver, it will parse for $VBT. > > I just find a comment in the PCI table with "E620" but > > the device and vendor id is the same for E680. > > > > What do you mean with "Moorestown style" ? > > There are essentially two styles of configuration table used with PVR > graphics. One is basically the same as that used on 'real' Intel graphics > the other first introduced with one of the SoC devices is a firmware > table in a completely different format. > > The netbook and PC oriented devices use the VBT, the tablet SoC > devices and embedded ones seem to vary and have a VBT/GCT in different > form that is found via config 0xFC on the chipset - see mid_bios.c > > Alan Hi, if i dump the memory on 0xFC of the config space, there is just some from the BIOS vendor with a BIOS Version, but nothing like $GCT. In the Datasheet the 0xFC is described as "storage" does it mean there should be the settings for the Graphic like VBT? I did not find more information abaout GCT and how to implement it. The board uses sdvo->vga for the output, the second board uses sdvo->DVI and LVDS but there is always a black screen on each output interface. So i think there is wether a VBT not a GCT. Regards andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] I2C: busses: Do not print error message in syslog if no ACK received
On Thu, Nov 14, 2013 at 05:39:52AM -0800, Joe Perches wrote:
> On Wed, 2013-11-13 at 20:24 +0100, Marek Vasut wrote:
> > > On Tue, Nov 12, 2013 at 07:33:40PM +0100, Marek Vasut wrote:
> > > > > > That is because if you look at the only caller of this function,
> > > > > > which is pch_i2c_wait_for_check_xfer(), you will see that at the
> > > > > > only place where pch_i2c_getack() is called there is already
> > > > > > pch_dbg():
> > > > > >
> > > > > > 369 if (pch_i2c_getack(adap)) {
> > > > > > 370 pch_dbg(adap, "Receive NACK for slave address"
> > > > > > 371 "setting\n");
> > > > > > 372 return -EIO;
> > > > > > 373 }
> > >
> > > Sorry i misunderstood that. You are absolutly right, thats the best
> > > solution for that. Remove the pch_err at getack so that only the pch_dbg
> > > get printed where getack is called. This should be enough information.
> >
> > No problem ;-)
>
> If this is the approach taken, please coalesce the format.
> As is there's a missing space between address and setting.
> This should be:
>
> pch_dbg(adap, "Received NACK for slave address setting\n");
>
>
Hi,
yes you are right, i will also add it and resand the patch in a few days.
regards
Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Black screen with GMA500 driver on Atom E680 (invalid VBT signature)
On Thu, Nov 14, 2013 at 01:52:09PM +, One Thousand Gnomes wrote: > > My question now is, is it a bug in the driver or in the VGA Bios? > > > > I´ve checked the VGA bios and did a hex dump but there is really no "$VBT" > > string. > > On an Atom Gen1 CPU with intel GMA500 Graphic there is the string in the > > VGA BIOS. > > But if i create the VGA BIOS for intel Atom E680 which has a GMA600 Graphic > > there is no string. > > > > Does anybody of you running the GMA500 driver with and Atom E680 without > > having this > > problem? Or does anybody know how to get this string into the VGA BIOS? > > E680 I believe will try and use the other style of parsing. I never got > my hands on one to confirm that but in general E6xx seems to use > Moorestown style tables instead and you'll only get support for some > outputs. > Hi, but if you checkout the PCI table in the driver, there is the device and vendor ID mentioned, that means for me that the driver supports the Graphic core in E680. And after loading the driver, it will parse for $VBT. I just find a comment in the PCI table with "E620" but the device and vendor id is the same for E680. What do you mean with "Moorestown style" ? Regards Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Black screen with GMA500 driver on Atom E680 (invalid VBT signature)
I´ve a question about the GMA 500 driver (gma500_gfx) with an Intel Atom E680.
Since the gma500 driver is in the Kernel, i get a black screen after loading
the driver.
The last message i can see are "Invalid VBT signature".
I have check the driver file "intel_bios.c" and there the driver map
the bios rom and search for the string "$VBT", but the driver cannot
find the string and return with "Invalid VBT signature".
Above the function with the relevant code.
int psb_intel_init_bios(struct drm_device *dev)
{
struct drm_psb_private *dev_priv = dev->dev_private;
struct pci_dev *pdev = dev->pdev;
struct vbt_header *vbt = NULL;
struct bdb_header *bdb = NULL;
u8 __iomem *bios = NULL;
size_t size;
int i;
dev_priv->panel_type = 0xff;
/* XXX Should this validation be moved to intel_opregion.c? */
if (dev_priv->opregion.vbt) {
struct vbt_header *vbt = dev_priv->opregion.vbt;
if (memcmp(vbt->signature, "$VBT", 4) == 0) {
DRM_DEBUG_KMS("Using VBT from OpRegion: %20s\n",
vbt->signature);
bdb = (struct bdb_header *)((char *)vbt +
vbt->bdb_offset);
} else
dev_priv->opregion.vbt = NULL;
}
if (bdb == NULL) {
bios = pci_map_rom(pdev, &size);
if (!bios)
return -1;
/* Scour memory looking for the VBT signature */
for (i = 0; i + 4 < size; i++) {
if (!memcmp(bios + i, "$VBT", 4)) {
vbt = (struct vbt_header *)(bios + i);
break;
}
}
if (!vbt) {
dev_err(dev->dev, "VBT signature missing\n");
pci_unmap_rom(pdev, bios);
return -1;
}
bdb = (struct bdb_header *)(bios + i + vbt->bdb_offset);
}
/* Grab useful general dxefinitions */
parse_general_features(dev_priv, bdb);
parse_driver_features(dev_priv, bdb);
parse_lfp_panel_data(dev_priv, bdb);
parse_sdvo_panel_data(dev_priv, bdb);
parse_sdvo_device_mapping(dev_priv, bdb);
parse_device_mapping(dev_priv, bdb);
parse_backlight_data(dev_priv, bdb);
parse_edp(dev_priv, bdb);
if (bios)
pci_unmap_rom(pdev, bios);
return 0;
}
My question now is, is it a bug in the driver or in the VGA Bios?
I´ve checked the VGA bios and did a hex dump but there is really no "$VBT"
string.
On an Atom Gen1 CPU with intel GMA500 Graphic there is the string in the VGA
BIOS.
But if i create the VGA BIOS for intel Atom E680 which has a GMA600 Graphic
there is no string.
Does anybody of you running the GMA500 driver with and Atom E680 without having
this
problem? Or does anybody know how to get this string into the VGA BIOS?
Regards
Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] I2C: busses: Do not print error message in syslog if no ACK received
On Tue, Nov 12, 2013 at 07:33:40PM +0100, Marek Vasut wrote:
> Dear Andreas Werner,
>
> > On Tue, Nov 12, 2013 at 07:00:59PM +0100, Marek Vasut wrote:
> > > Dear Andreas Werner,
> > >
> > > > Using the i2c-eg20t driver and call i2cdetect or probe on the bus,
> > > > the driver will print a lot of error messages if there was no ACK
> > > > received.
> > > >
> > > > i2cdetect normally print a table with all the available devices. If
> > > > there is no device on the address, the table will be empty.
> > > > Currently with the i2c-eg20t driver, the table is not visible because
> > > > the error messages destroy the table.
> > > >
> > > > Error message: pch_i2c_getack return -71
> > > >
> > > > This patch prevent the driver to print the messages to syslog if debug
> > > > is not set.
> > > >
> > > > Tested on Intel Atom E6xx and Eg20t Chipset.
> > > >
> > > > Signed-off-by: Andreas Werner
> > > > ---
> > > >
> > > > drivers/i2c/busses/i2c-eg20t.c | 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/i2c/busses/i2c-eg20t.c
> > > > b/drivers/i2c/busses/i2c-eg20t.c index 0f37529..b10c651 100644
> > > > --- a/drivers/i2c/busses/i2c-eg20t.c
> > > > +++ b/drivers/i2c/busses/i2c-eg20t.c
> > > > @@ -322,7 +322,7 @@ static s32 pch_i2c_getack(struct i2c_algo_pch_data
> > > > *adap) reg_val = ioread32(p + PCH_I2CSR) & PCH_GETACK;
> > > >
> > > > if (reg_val != 0) {
> > > >
> > > > - pch_err(adap, "return%d\n", -EPROTO);
> > > > + pch_dbg(adap, "return%d\n", -EPROTO);
> > > >
> > > > return -EPROTO;
> > > >
> > > > }
> > >
> > > I'd just kill the pch_err() line altogether:
> > But why? I think there a few pch_err message which are interesting to
> > have in syslog, without building the dbg driver.
>
> See below for explanation why this one particular pch_err() line can go.
> Sorry
> if I was not clear enough, I meant only this one particular pch_err() line,
> NOT
> all of them.
>
> >
> > > if (reg_val)
> > >
> > > return -EPROTO;
> > >
> > > That is because if you look at the only caller of this function, which is
> > > pch_i2c_wait_for_check_xfer(), you will see that at the only place where
> > > pch_i2c_getack() is called there is already pch_dbg():
> > >
> > > 369 if (pch_i2c_getack(adap)) {
> > > 370 pch_dbg(adap, "Receive NACK for slave address"
> > > 371 "setting\n");
> > > 372 return -EIO;
> > > 373 }
> > >
Sorry i misunderstood that. You are absolutly right, thats the best solution
for that.
Remove the pch_err at getack so that only the pch_dbg get printed where getack
is called.
This should be enough information.
> > > btw. (idea for subsequent patch) this pch_dbg() should be fixed to be a
> > > one- liner /wrt the text so we can grep for the error messages. Such
> > > text arg should never be split in multiple lines in kernel.
> >
> > Ok i will wait a few days for further comments to this patch and then
> > i will resend the patch with a one liner message.
>
> Sure, wait at least for Wolfram's consent on this please ;-)
>
> Best regards,
> Marek Vasut
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] I2C: busses: Do not print error message in syslog if no ACK received
On Tue, Nov 12, 2013 at 07:00:59PM +0100, Marek Vasut wrote:
> Dear Andreas Werner,
>
> > Using the i2c-eg20t driver and call i2cdetect or probe on the bus,
> > the driver will print a lot of error messages if there was no ACK
> > received.
> >
> > i2cdetect normally print a table with all the available devices. If there
> > is no device on the address, the table will be empty.
> > Currently with the i2c-eg20t driver, the table is not visible because
> > the error messages destroy the table.
> >
> > Error message: pch_i2c_getack return -71
> >
> > This patch prevent the driver to print the messages to syslog if debug is
> > not set.
> >
> > Tested on Intel Atom E6xx and Eg20t Chipset.
> >
> > Signed-off-by: Andreas Werner
> > ---
> > drivers/i2c/busses/i2c-eg20t.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/i2c/busses/i2c-eg20t.c
> > b/drivers/i2c/busses/i2c-eg20t.c index 0f37529..b10c651 100644
> > --- a/drivers/i2c/busses/i2c-eg20t.c
> > +++ b/drivers/i2c/busses/i2c-eg20t.c
> > @@ -322,7 +322,7 @@ static s32 pch_i2c_getack(struct i2c_algo_pch_data
> > *adap) reg_val = ioread32(p + PCH_I2CSR) & PCH_GETACK;
> >
> > if (reg_val != 0) {
> > - pch_err(adap, "return%d\n", -EPROTO);
> > + pch_dbg(adap, "return%d\n", -EPROTO);
> > return -EPROTO;
> > }
>
> I'd just kill the pch_err() line altogether:
But why? I think there a few pch_err message which are interesting to have in
syslog,
without building the dbg driver.
>
> if (reg_val)
> return -EPROTO;
>
> That is because if you look at the only caller of this function, which is
> pch_i2c_wait_for_check_xfer(), you will see that at the only place where
> pch_i2c_getack() is called there is already pch_dbg():
>
> 369 if (pch_i2c_getack(adap)) {
> 370 pch_dbg(adap, "Receive NACK for slave address"
> 371 "setting\n");
> 372 return -EIO;
> 373 }
>
> btw. (idea for subsequent patch) this pch_dbg() should be fixed to be a one-
> liner /wrt the text so we can grep for the error messages. Such text arg
> should
> never be split in multiple lines in kernel.
Ok i will wait a few days for further comments to this patch and then
i will resend the patch with a one liner message.
>
> Best regards,
> Marek Vasut
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] I2C: busses: Do not print error message in syslog if no ACK received
Using the i2c-eg20t driver and call i2cdetect or probe on the bus,
the driver will print a lot of error messages if there was no ACK
received.
i2cdetect normally print a table with all the available devices. If there
is no device on the address, the table will be empty.
Currently with the i2c-eg20t driver, the table is not visible because
the error messages destroy the table.
Error message: pch_i2c_getack return -71
This patch prevent the driver to print the messages to syslog if debug is not
set.
Tested on Intel Atom E6xx and Eg20t Chipset.
Signed-off-by: Andreas Werner
---
drivers/i2c/busses/i2c-eg20t.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-eg20t.c b/drivers/i2c/busses/i2c-eg20t.c
index 0f37529..b10c651 100644
--- a/drivers/i2c/busses/i2c-eg20t.c
+++ b/drivers/i2c/busses/i2c-eg20t.c
@@ -322,7 +322,7 @@ static s32 pch_i2c_getack(struct i2c_algo_pch_data *adap)
reg_val = ioread32(p + PCH_I2CSR) & PCH_GETACK;
if (reg_val != 0) {
- pch_err(adap, "return%d\n", -EPROTO);
+ pch_dbg(adap, "return%d\n", -EPROTO);
return -EPROTO;
}
--
1.8.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] usb: hub: Use correct reset for wedged USB3 devices that are NOTATTACHED
This patch adds a check for USB_STATE_NOTATTACHED to the
hub_port_warm_reset_required() workaround for ports that end up in
Compliance Mode in hub_events() when trying to decide which reset
function to use. Trying to call usb_reset_device() with a NOTATTACHED
device will just fail and leave the port broken.
Signed-off-by: Julius Werner
---
drivers/usb/core/hub.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index e6b682c..0188056 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -4799,8 +4799,9 @@ static void hub_events(void)
hub->ports[i - 1]->child;
dev_dbg(hub_dev, "warm reset port %d\n", i);
- if (!udev || !(portstatus &
- USB_PORT_STAT_CONNECTION)) {
+ if (!udev ||
+ !(portstatus & USB_PORT_STAT_CONNECTION) ||
+ udev->state == USB_STATE_NOTATTACHED) {
status = hub_port_reset(hub, i,
NULL, HUB_BH_RESET_TIME,
true);
--
1.8.4.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] usb: hub: Use correct reset for wedged USB3 devices that are NOTATTACHED
> I don't know either. But Sarah has said that ports can spontaneously > go into Compliance Mode for no apparent reason. If that can happen, > maybe it can happen while the port is in U3 and the device is > suspended. In such cases, though, you'd need to do a reset-resume > rather than a simple reset. Okay. Looks like this is a more complicated question so let's keep it out of this patch. We could always add another check to handle USB_STATE_SUSPENDED later. > I think keeping dev_dbg() is best. If you're searching for the > solution to a problem, you should have debugging enabled and so you > ought to see the message. Sure, I'll submit a second version in a moment. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] usb: hub: Use correct reset for wedged USB3 devices that are NOTATTACHED
> Who makes those calls, drivers? Any specific ones that you know need to be fixed? Well, the one I'm worried about is the one this patch is fixing, in hub_events(). I have seen this happen when having certain USB3 devices plugged into a host controller that always looses power on suspend-to-ram (dwc3-exynos). Since the host controller resets itself the port no longer has PORT_STAT_ENABLE set and that causes hub_activate() to mark the device as USB_STATE_NOTATTACHED. The next time khubd runs hub_events(), the port may be in Compliance Mode (because the unexpected HC reset can confuse the link state machines on both sides) and the kernel correctly tries to reset it, but doesn't take the fact into account that usb_reset_device() doesn't work on NOTATTACHED devices. > But what can a user do if those messages show up? Nothing. I was just thinking this might help developers follow the kernel decisions better and understand a potential problem faster (e.g. if the user posted his log in a bug report somewhere). > What if the device is in USB_STATE_SUSPENDED? I'm not sure that is possible at that point in hub_events(), I don't know of a way that could lead to this situation. I could still add the check just to be sure if you want it, though. > Not at all. If a device is unplugged, its state changes to NOTATTACHED > before the driver is unbound. During that time, the driver will see > all its URBs failing, so it may very well try to reset the device. > (For example, usbhid behaves like this.) That isn't a bug. Oh, okay, I wasn't quite sure how that plays together. Would you think it's still valuable to print it out (maybe as dev_info() instead of dev_warn()) instead of just silently ignoring the reset request? It would have certainly been useful for me to find this problem faster, but I can take it out again if you think it would result in too much noise. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] usb: xhci-plat: Enable USB 2.0 hardware LPM support for platform xHCs
*bump* Hi Sarah, is there anything else that needs to be resolved to pick this patch up? Looks like Matthias' recent LPM fixes are all in now so there should be no way this could cause any trouble? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] usb: hub: Use correct reset for wedged USB3 devices that are NOTATTACHED
This patch adds a check for USB_STATE_NOTATTACHED to the
hub_port_warm_reset_required() workaround for ports that end up in
Compliance Mode in hub_events() when trying to decide which reset
function to use. Trying to call usb_reset_device() with a NOTATTACHED
device will just fail and leave the port broken.
Also bumped the messages about this kind of reset failure from dev_dbg()
to dev_warn() to make it easier to notice, since calling that function
with a NOTATTACHED device would almost always be a bug
Signed-off-by: Julius Werner
---
drivers/usb/core/hub.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index e6b682c..0188056 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -4799,8 +4799,9 @@ static void hub_events(void)
hub->ports[i - 1]->child;
dev_dbg(hub_dev, "warm reset port %d\n", i);
- if (!udev || !(portstatus &
- USB_PORT_STAT_CONNECTION)) {
+ if (!udev ||
+ !(portstatus & USB_PORT_STAT_CONNECTION) ||
+ udev->state == USB_STATE_NOTATTACHED) {
status = hub_port_reset(hub, i,
NULL, HUB_BH_RESET_TIME,
true);
@@ -5074,7 +5075,7 @@ static int usb_reset_and_verify_device(struct usb_device
*udev)
if (udev->state == USB_STATE_NOTATTACHED ||
udev->state == USB_STATE_SUSPENDED) {
- dev_dbg(&udev->dev, "device reset not allowed in state %d\n",
+ dev_warn(&udev->dev, "device reset not allowed in state %d\n",
udev->state);
return -EINVAL;
}
@@ -5237,7 +5238,7 @@ int usb_reset_device(struct usb_device *udev)
if (udev->state == USB_STATE_NOTATTACHED ||
udev->state == USB_STATE_SUSPENDED) {
- dev_dbg(&udev->dev, "device reset not allowed in state %d\n",
+ dev_warn(&udev->dev, "device reset not allowed in state %d\n",
udev->state);
return -EINVAL;
}
--
1.8.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] X86: MM: Add PAT Type write-through in combination with mtrr
On Sun, Nov 03, 2013 at 09:44:46AM -0800, H. Peter Anvin wrote: > On 11/03/2013 04:02 AM, Andreas Werner wrote: > > > > Since marking IO Memory as cachable is not valid, WT is the > > best way for caching/bursting on MMIO Devices. > > > > Uh... WT *is* cachable... > > -hpa > > Sorry my mistake, i mean "marking IO Memory as WB is not valid" regards Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] X86: MM: Add PAT Type write-through in combination with mtrr
Revision 2:
added comment in code.
This patch adds the Write-through memory type in combination with mtrr.
If you call ioremap_cache to request cachable memory (write-back) the
function tries to set the PAT to write-back only if the mtrr setting of
the requested region is also marked as Write-Back.
If the mttr regions are marked e.g. as Write-through or with other
types, the function will always return UC- memory.
If you check the Intel document " IA-32 SDM vol 3a table Effective
Memory Type", there
are many other combinations possible.
This patch will only add the following combination:
PAT=Write-Back + MTRR=Write-Through.
Since marking IO Memory as cachable is not valid, WT is the
best way for caching/bursting on MMIO Devices.
Tested on - Intel (R) Atom E680 (Tunnel Creek)
- Intel (R) Core(TM)2 Duo
Signed-off-by: Andreas Werner
---
arch/x86/mm/pat.c | 18 +++---
1 file changed, 15 insertions(+), 3 deletions(-)
diff --git a/arch/x86/mm/pat.c b/arch/x86/mm/pat.c
index 6574388..cf05ee6 100644
--- a/arch/x86/mm/pat.c
+++ b/arch/x86/mm/pat.c
@@ -149,10 +149,22 @@ static unsigned long pat_x_mtrr_type(u64 start, u64 end,
unsigned long req_type)
u8 mtrr_type;
mtrr_type = mtrr_type_lookup(start, end);
- if (mtrr_type != MTRR_TYPE_WRBACK)
- return _PAGE_CACHE_UC_MINUS;
- return _PAGE_CACHE_WB;
+ switch (mtrr_type) {
+ case MTRR_TYPE_WRBACK:
+
+ /*
+* Return also WB (PAT) if MTTR is set to WT.
+* Since marking IO Memory as cachable is not valid,
+* WT is the best way for caching/bursting reads
+* on MMIO.
+*/
+ case MTRR_TYPE_WRTHROUGH:
+ return _PAGE_CACHE_WB;
+
+ default:
+ return _PAGE_CACHE_UC_MINUS;
+ }
}
return req_type;
--
1.8.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] X86: MM: Add PAT Type write-through in combination with mtrr
On Mon, Oct 28, 2013 at 02:58:47PM +0100, Borislav Petkov wrote: > On Mon, Oct 28, 2013 at 01:03:58PM +0100, Andreas Werner wrote: > > > That doesn't mean you can return _PAGE_CACHE_WB for MTRR_TYPE_WRTHROUGH. > > > The correct thing to do, IMHO, would be to set the PWT bit in the PTEs > > > of those pages comprising your buffer. > > > > > But why? the combination of PAT=WB and MTRR=WT is allowed isn´t it? > > What should i return instead of? > > Well, since the pat code can't give you PWT, I'm thinking the cleaner > thing would be to do it yourself. I.e., allocate a WT buffer with > mtrr_add and then set the PWT bit of each page in that buffer. > > Alternatively, your solution - albeit not that correct - is a simple one > and probably could use a good comment in the code explaining why you're > doing that if we decide to go that way. At the moment if you check the function in pat.c there is also UC returned if the requested type is not WB. So that was my idea to add WT and return WB. If i understand it right, i have to add a comment why i do that and if that is good enough, the patch could be submitted to the kernel? regards Andy > > -- > Regards/Gruss, > Boris. > > Sent from a fat crate under my desk. Formatting is fine. > -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] X86: MM: Add PAT Type write-through in combination with mtrr
On Mon, Oct 28, 2013 at 12:45:41PM +0100, Borislav Petkov wrote: > Drop Dave's stale mail address. > > On Mon, Oct 28, 2013 at 12:25:05PM +0100, Andreas Werner wrote: > > > but you end up doing > > > > > > PAT=Write-Back + MTRR=Write-Through = Effective Memory of Write-Back > > > > > No the effective memory type is WT, check out the Intel document with the > > table of Effective memory type combinations. > > You need to read what I'm saying more carefully. Sorry then i missunderstood something? > > > Yes but, there is no way in the kernel to mark a memory WT, > > That doesn't mean you can return _PAGE_CACHE_WB for MTRR_TYPE_WRTHROUGH. > The correct thing to do, IMHO, would be to set the PWT bit in the PTEs > of those pages comprising your buffer. > But why? the combination of PAT=WB and MTRR=WT is allowed isn´t it? What should i return instead of? regards Andy > -- > Regards/Gruss, > Boris. > > Sent from a fat crate under my desk. Formatting is fine. > -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] X86: MM: Add PAT Type write-through in combination with mtrr
On Mon, Oct 28, 2013 at 11:57:31AM +0100, Borislav Petkov wrote: > On Mon, Oct 28, 2013 at 11:34:28AM +0100, Andreas Werner wrote: > > Yes the reads are only for packet data, the commands or configuration > > registers are mapped non cachable. > > > > I´ve tried WB, but on PCIe Tracer i could not see any burst access. > > Thats the reason why i have created this patch. > > > > Is there a chance to get this patch into the kernel? Or > > is this solution so special? > > Ok, but your patch returns WB pat type for WT MTRR type, AFAICT. > > You want to do: > > PAT=Write-Back + MTRR=Write-Through = Effective Memory of Write-Through > Yes thats right. > but you end up doing > > PAT=Write-Back + MTRR=Write-Through = Effective Memory of Write-Back > No the effective memory type is WT, check out the Intel document with the table of Effective memory type combinations. > What am I missing or misunderstanding? > > AFAICT, you want to return _PAGE_PWT for MTRR_TYPE_WRTHROUGH, no? Yes but, there is no way in the kernel to mark a memory WT, there is just ioremap_wc for Write combining and ioremap_cache for Write Back, and as you can see in the Intel Effective Memory type table, if you combine PAT=WB and MTRR=WT you will get a effective memory of WT. regards Andy > > -- > Regards/Gruss, > Boris. > > Sent from a fat crate under my desk. Formatting is fine. > -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] X86: MM: Add PAT Type write-through in combination with mtrr
On Mon, Oct 28, 2013 at 11:51:01AM +0100, Ingo Molnar wrote: > > * Andreas Werner wrote: > > > On Mon, Oct 28, 2013 at 11:31:32AM +0100, Ingo Molnar wrote: > > > > > > * Borislav Petkov wrote: > > > > > > > On Mon, Oct 28, 2013 at 11:17:49AM +0100, Ingo Molnar wrote: > > > > > > > > > And regular write-back cacheable isn't sufficient because the > > > > > CPU could do things like prefetch your range automatically? > > > > > > > > Yeah, he's doing a CLFLUSH anyway which basically makes it a > > > > write-through... > > > > > > The CLFLUSH is done afterwards (making it a use-once thing), so WB > > > might still be faster and would avoid the PAT headache ... > > > > > > Thanks, > > > > > > Ingo > > What i do right now is: > > 1. clflush the data range to read from my mmio device > > 2. read the data. > > On PCIe Tracer i see the pcie bursts. > > > > If i mark the region WB and call clflush my system will crash without > > any message, it just stop working. > > Yeah, I was wondering whether it's valid at all to mark IO memory as > cacheable - with the lack of MESI transactions and all that ... > > So it's apparently not valid and we've got to live with WT as the > 'best' caching/bursting method for reads. > > Thanks, > > Ingo Yeah, as you can see in the link i´ve posted before, the guy who did the post mentioned also that WB on MMIO is not valid, he said "id could work on some CPUs", and therefore he decided to do it like I with WC (write) and WT (read). regards Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: MM: Add PAT Type write-through in combination with mtrr
On Mon, Oct 28, 2013 at 11:31:32AM +0100, Ingo Molnar wrote: > > * Borislav Petkov wrote: > > > On Mon, Oct 28, 2013 at 11:17:49AM +0100, Ingo Molnar wrote: > > > > > And regular write-back cacheable isn't sufficient because the > > > CPU could do things like prefetch your range automatically? > > > > Yeah, he's doing a CLFLUSH anyway which basically makes it a > > write-through... > > The CLFLUSH is done afterwards (making it a use-once thing), so WB > might still be faster and would avoid the PAT headache ... > > Thanks, > > Ingo What i do right now is: 1. clflush the data range to read from my mmio device 2. read the data. On PCIe Tracer i see the pcie bursts. If i mark the region WB and call clflush my system will crash without any message, it just stop working. regards Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
